LLM-Agent-UMF: LLM-based Agent Unified Modeling Framework for Seamless Design of Multi Active/Passive Core-Agent Architectures

1 Introduction

• LLMs support language and reasoning tasks, while standalone models lack capabilities such as information retrieval and mathematical reasoning that agents can obtain through tools and other resources.The paper defines an autonomous agent as a system that senses and acts on an environment over time according to an agenda.Source: §1 · p. 2
• LLM-Agent-UMF introduces a core-agent that separates agent components and their interactions, classifies core-agents as active or passive, and aims to improve architectural clarity and component reusability.The framework seeks to shift from multi-agent systems to multi-core agents.Source: §1 · p. 2
• The paper applies its framework to existing solutions to identify agent modules and assess the feasibility and requirements of combining agents.The stated aim is an agent with fully enhanced capabilities.Source: §1 · p. 2
• The framework adapts an existing functional model and adds a security module alongside planning, memory, profile, and action modules.The paper identifies security as an enhancing module and describes the core-agent structure as an adaptation of the framework in [5].Source: §1 · p. 2
• The paper presents its methodology, framework, and evaluation in separate sections, with the evaluation applying the framework to state-of-the-art agents and designing novel multi-core architectures.The methodology includes literature review, quality requirements, design principles, and validation.Source: §1 · pp. 2–3

2 Related Work

• Related work describes tool-augmented LLMs as combining language capabilities with interfaces to external tools and APIs, including for retrieval, planning, and execution.TALM is given as an example.Source: §2 · p. 3
• Tool-augmented LLM agents are described as performing NLP, reasoning, programming, and text-generation tasks, while addressing standalone LLM limits such as context length and tool use.The passage characterizes these agents as more proficient in the listed areas than other types of agents.Source: §2 · p. 3
• The paper reports an absence of direct security measures or guardrails in examined agents and cites risks involving ethical use, malicious data, privacy, robustness, and jailbreaks.It presents these concerns as motivation for including security measures in its framework.Source: §2 · p. 3
• Existing agents are described as lacking a primary focus on architectural design, despite software principles such as modularity, composability, and maintainability being important to flexibility and adaptability.The paper presents architectural frameworks as blueprints for modular, extensible, and interoperable designs.Source: §2 · pp. 3–4
• Prior frameworks emphasize functional dimensions, including the five axes in [7], but the cited work did not define software components of the agent.The survey framework [5] presents four functional modules: Profile, Memory, Planning, and Action.Source: §2 · p. 4
• The surveyed framework [5] identifies Profile, Memory, Planning, and Action modules, but related work notes ambiguity about whether the LLM, tools, data sources, and memory belong to the agent.The paper argues that unclear boundaries can hinder compatibility and reusability.Source: §2 · p. 4

3 Methodology

• AFTRAM’s four-phase spiral guided development and evaluation, with requirements and architectural views in Methodology and attribute, tradeoff, and risk analyses in later sections.The framework focuses on the SDLC’s Requirements Specification and Software Design phases; AFTRAM phases were mapped to IMRaD sections for transparency and reproducibility.Source: §3 · p. 4

3.1 Literature Review Process

• A literature review spanning 13 objectives informed structured planning analysis, clearer memory terminology and perspectives, and security practices for the framework.Planning is analyzed across process, strategies, techniques, and feedback sources; memory across scope, location, and format. Security guidance includes Secure by Design and rule- and LLM-based guardrails.Source: §3.1 · pp. 5–6

3.2 Quality Requirements

• The framework explicitly addresses quality requirements spanning adaptability, maintainability, scalability, resilience, performance, interoperability, security, privacy, and safety; recovery remains future work.The requirements were derived from existing frameworks and software-engineering best practices.Source: §3.2 · p. 6

3.3 Design Principles

• Design principles group general architecture, security and privacy, and framework-level guidance, including modularity, security by design, technology agnosticism, variability management, and extensibility.These principles are intended to support quality requirements such as flexibility, maintainability, and security.Source: §3.3 · p. 7

3.4 Contributions: Core-Agent as Keystone Component

• The core-agent names the previously implicit coordinating component that orchestrates LLM, tool, and environment interactions through planning, memory, profile, action, and security modules.The framework presents it as the keystone component that clarifies software boundaries and supports modularity and reusability.Source: §3.4 · p. 8
• A dedicated security module adds layered safeguards, while active core-agents handle planning and decisions and passive core-agents streamline execution [13] [28].The framework proposes uniform multi-passive or multi-active architectures and hybrid one-active-many-passive or many-active-many-passive architectures; it identifies one-active-many-passive as optimal for balancing simplicity and management.Source: §3.4 · pp. 8–9

3.5 Comparison with Prior Frameworks

• Compared with [5]’s four functional modules, LLM-Agent-UMF defines five core-agent modules and addresses functional overlap, ambiguous terminology, unclear component boundaries, and absent security.The added security module is presented as supporting modularity, clarity, and trustworthiness.Source: §3.5 · p. 9
• Planning and memory receive structured analyses that separate planning responsibilities from storage and retrieval, moving reflection into planning to reduce overlap and clarify architecture.Planning is analyzed by process, strategies, techniques, and feedback sources; memory by scope, location, and format.Source: §3.5 · pp. 9–11
• The profile module clarifies three role-defining methods and adds fine-tuned pluggable modules to support dynamic adaptation while reducing context size and memory footprint.The methods are Handcrafted In-Context Learning, LLM-Generation, and Dataset Alignment.Source: §3.5 · p. 10
• The action module analyzes goals, triggers, action space, and impact, adding Plan Following and API Call Request triggers while separating execution from memory storage.Reflection is incorporated into planning feedback sources and action impact analysis.Source: §3.5 · p. 10
• A dedicated security module adds layered safeguards for prompts, responses, and data privacy, addressing a component absent from the compared frameworks.Its design draws on Security by Design, Privacy by Design, the C.I.A. Triad, Trust Boundaries Definition, and Defense in Depth.Source: §3.5 · pp. 10–11

3.6 Validation Approach

• The framework was applied to thirteen state-of-the-art agents and five novel multi-core designs to assess quality attributes without implementing the agents.The selected agents spanned tool use, memory, planning, chemistry, security, and proprietary systems.Source: §3.6 · p. 11
• Security modules were absent in 78% of tool-using agents, and passive core-agents required less synchronization than active ones.ChemCrow and ChatGPT 4o demonstrated robust privacy measures.Source: §3.6 · p. 11
• The five designs explored multi-passive Toolformer–Confucius, ToolLLM–ChatDB variants, LLMSafeGuard integration with ToolLLM, and a hybrid active-passive architecture.The scenarios examined privacy gaps, synchronization and module conflicts, modular security extensions, and privacy vulnerabilities in tool use.Source: §3.6 · p. 11

• The framework places the core-agent at the center of a modular, scalable architecture for designing LLM-based agents.It is presented as addressing limitations in existing frameworks.Source: §4 · p. 11
• The framework specifies the core-agent’s internal modules and active/passive classifications.Source: §4 · p. 11
• It also outlines multi-core architectures, emphasizing modularity, security, and flexibility.Source: §4 · p. 11

• The core-agent orchestrates interactions among LLMs, tools, and the environment to translate high-level goals into actionable outcomes.Source: §4.1 · pp. 11–12
• Its five modules are planning, memory, profile, action, and security.The modular structure is designed for extensibility and maintainability.Source: §4.1 · p. 12
• Active core-agents are authoritative managers of complex tasks, while passive ones execute specific actions without authority.Source: §4.1 · p. 12
• The hybrid one-active-many-passive setup balances simplicity and functionality.Source: §4.1 · p. 12

4.2 Modeling the Core-Agent Internal Structure

• The core-agent coordinates five modular components—planning, memory, profile, action, and security—that can be independently developed or replaced and reused across agents or applications.This separation is intended to support new capabilities and adaptation to new technologies.Source: §4.2 · p. 12

4.2.1 Planning Module

• Planning decomposes tasks and generates plans using single-path or multi-path strategies, with feedback supporting iterative refinement and adaptation.Decomposition may be all at once or iterative; multi-path planning generates and evaluates alternatives. Feedback can come from humans, tools, and sibling core-agents.Source: §4.2.1 · pp. 12–14

4.2.2 Memory Module

• Memory supports reading and writing task-related information, organized by scope, location, and format to support decision-making and task execution.Scope distinguishes short-term from long-term memory; location distinguishes embedded memory from external memory extensions. Formats include natural language, embeddings, SQL databases, and structured lists, which can be combined.Source: §4.2.2 · pp. 14–15

4.2.3 Profile Module

• The profile module configures the LLM’s task-specific persona through handcrafted prompts, LLM generation, dataset alignment, or fine-tuned pluggable modules.Fine-tuned modules can reduce prompt context size and memory footprint; generated profiles may require validation for bias or inaccuracy, while dataset alignment depends on data quality and representativeness.Source: §4.2.3 · pp. 15–16

4.2.4 Action Module

• The action module translates plans into low-level actions, organized by goals, triggers, available actions, and impacts, while collaborating with security to meet integrity, safety, and privacy criteria.It can act through tools or read-only resources; retrieval-augmented generation can support transparency and traceability, including in critical settings such as healthcare.Source: §4.2.4 · pp. 16–17

4.2.5 Security Module

• Security continuously monitors actions and enforces safety and security requirements through safeguards and guardrails, independently of cognitive functions such as planning and memory.Its safeguards address prompts, responses, and data privacy; protecting sensitive information sent to external resources is a particular concern. Guardrails may be rule-based or LLM-based.Source: §4.2.5 · pp. 17–18
• Rule-based guardrails screen inputs and outputs against predefined rules, while LLM-powered guardrails adapt more readily to evolving threats and diverse use cases.Rule-based checks may block unsafe content or issue alerts, but require ongoing manual updates; LLM-powered checks can better account for context, nuance, and intent.Source: §4.2.5 · pp. 18–19
• Neural-symbolic agents can resolve conflicts between requirements, reason symbolically from historical data, and collaborate with other AI systems, though security LLMs may add computational overhead.Lightweight models designed for guardrail tasks can reduce resource demands while retaining LLM-powered security benefits.Source: §4.2.5 · p. 19
• The core-agent can pass customized guardrail rules to an auxiliary LLM for input classification and requirement checks, as illustrated by LLaMA Guard [13].LLaMA Guard analyzes inputs and outputs against user-specified categories; the passage also notes its relevance to models such as Llama 3.1 [69].Source: §4.2.5 · p. 19

4.3 Active/Passive Core-Agent Classification

• The action module is indispensable in every core-agent, while the taxonomy distinguishes active and passive types by their managerial authority.The framework uses this distinction to describe differences in module structure and alignment.Source: §4.3 · p. 19

4.3.1 Active Core-Agents

• Active core-agents orchestrate components with planning, adaptive memory, profile, action, and security, supporting complex tasks but increasing implementation and synchronization complexity.They are described as stateful and able to use past interactions to inform future actions and decisions.Source: §4.3.1 · p. 20, §4.3.2 · p. 22

4.3.2 Passive Core-Agents

• Passive core-agents leave planning and reasoning-related memory to the LLM, executing externally requested actions without changing internal state or a predetermined plan.Toolformer exemplifies this division: the LLM selects and integrates API calls, while the core-agent executes them.Source: §4.3 · p. 19, §4.3.2 · pp. 20–21
• Passive cores retain security despite not handling human prompts; human communication is bidirectional but can only be initiated by the passive core-agent.The LLM handles prompt safety in this setup, while the core-agent’s security module protects privacy in interactions with people or third-party systems.Source: §4.3.2 · pp. 21–22
• Passive cores simplify reuse and integration but cannot handle complex tasks, initiate human contact, access context except through API requests, or control the LLM profile.Active cores, by contrast, can access memory and contextual data and dynamically control the LLM profile, but require more complex implementation and synchronization.Source: §4.3.2 · p. 22

4.4 Multi Active/Passive Core-Agent Architecture

• The framework classifies multi-core architectures as uniform or hybrid to distribute responsibilities within a single agent amid multi-agent coordination challenges.Uniform systems use only active or only passive core-agents; hybrid systems combine both types.Source: §4.4 · pp. 22–23, §4.4.1 · p. 23

4.4.1 Uniform multi-core agent

• Uniform multi-passive systems let the LLM direct specialized executors, which are easy to add without complex synchronization.Adding passive cores requires adapting the LLM profile, statically or dynamically through an active core-agent.Source: §4.4.1 · p. 23, Figure 10 · p. 23
• Uniform multi-active systems use full-module active cores for complex cognitive tasks, but growing inter-core communication creates synchronization challenges and may require consensus such as Raft.The framework contrasts their broader capabilities with the simpler uniform multi-passive design.Source: §4.4.1 · pp. 23–24, Figure 11 · p. 24

4.4.2 Hybrid multi-core agent

• One-active-many-passive pairs a manager that dynamically configures LLM profiles with parallel workers, balancing flexibility and scalability against multi-active complexity.The design can dynamically allocate resources and adjust configuration to task requirements.Source: §4.4.2 · p. 24, Figure 12 · p. 25
• Many-active-many-passive architectures suit dynamic environments requiring resilience, but call for careful synchronization, communication protocols, task delineation, and error handling.The paper presents this design as intricate, particularly in synchronization among active core-agents.Source: §4.4.2 · pp. 24–25, Figure 13 · p. 25
• Core modularity supports adding or detaching passive cores within one agent as demand changes, aligning with the Open-Closed Principle and avoiding a transition to multi-agent systems.The paper links dynamic scaling to accommodating growing demands and maintaining optimal performance.Source: §4.4.2 · pp. 25–26

5.1 Evaluation of the new core-agent terminology

• The framework identifies implicit core-agents in Toolformer, ToolLLM, ChatDB, LLM+P [44], and LLMSafeGuard [45], clarifying their modules and supporting consistent terminology.Toolformer’s core-agent has an action module; ToolLLM’s includes action and implicit planning; ChatDB’s mediates SQL memory operations; LLM+P [44] uses PDDL-based planning; and LLMSafeGuard [45] coordinates safety validation.Source: §5.1 · pp. 26–27

5.2 Evaluation of active/passive core-agent internal structure delineation

• The analysis classifies Toolformer [38], Confucius [39], and ToolAlpaca as passive, while identifying active core-agents in ToolLLM [42], ChatDB [23], and Chameleon [8].Gorilla [41] is passive in zero-shot mode, but uses an active core-agent with an API retriever in its second mode.Source: §5.2 · pp. 27–28
• ChatGPT 4o mini’s refusal of an illegal prompt leaves its architecture uncertain, while the authors hypothesize ChatGPT 4o has a fully featured active core-agent for code execution.The mini’s guardrails could be implemented within the LLM or by an external active core-agent; the proposed 4o workflow checks for coding tasks, changes the LLM profile, executes generated code in isolation, then resets the profile.Source: §5.2 · p. 29
• 78% (7 out of 9) of studied agents using external tools lacked necessary privacy measures; only ChemCrow and ChatGPT managed this aspect effectively.ChemCrow used privacy-focused IBM Research tools, while ChatGPT required user validation before sharing data with third parties.Source: §5.2 · p. 29
• Only 31% (4 out of 13) of examined agents used passive core-agents, versus 69% with active ones; passive agents may ease synchronization and improve scalability.The analysis also notes that ToolLLM’s memory module is simpler than ChatDB’s, so integration should preserve distinct module strengths and account for planning in both systems.Source: §5.2 · pp. 29–30

5.3.1 Toolformer and Confucius as a multi passive core-agents system

• LA1 combines passive Toolformer [38] and Confucius [39] core-agents to handle familiar and unseen tools, but the design lacks privacy safeguards for data transfers.The LLM-Agent-UMF analysis flags the need to monitor transfers between the core-agents and external service providers.Source: §5.3.1 · pp. 30–31

5.3.2 ToolLLM and ChatDB as a multi active core-agent system

• LA2-A keeps ToolLLM [42] and ChatDB [23] as separate active core-agents requiring synchronization, whereas LA2-B merges their capabilities into one monolithic active core-agent.LA2-A could use Raft and share one Llama 3.1 8B; LA2-B must coordinate API retrieval with SQL memory and select the appropriate LLM profile.Source: Figure 16 · p. 31, §5.3.2 · p. 31, Figure 17 · p. 32

5.3.3 Implanting the LLMSafeGuard security module into ToolLLM

• LA3 augments ToolLLM [42] with LLMSafeGuard’s [45] security module, adding real-time text safeguarding while retaining ToolLLM’s four primary modules.The framework identifies the missing module and supports its integration without functional conflict.Source: §5.3.3 · p. 32, Figure 18 · p. 32

5.3.4 Hybrid multi active/passive core-agents system

• LLM+P was selected as LA4’s active core-agent for its planning module and augmented with LLMSafeGuard to add the missing security module.LLM+P generates PDDL descriptions from natural-language inputs, which an integrated planner evaluates to establish an optimal plan.Source: §5.3.4 · p. 33
• Toolformer and Confucius passive core-agents can be integrated by adding their profiles to LA4’s active agent, without advanced synchronization mechanisms.Their profiles allow the active core-agent to dynamically adapt LLM behavior for tool and API use.Source: §5.3.4 · p. 33
• Toolformer and Confucius API calls are not monitored or protected against information leakage; safeguards could reside in each passive agent or centrally in the active agent.Choosing technologies and implementation details is left to future work.Source: §5.3.4 · pp. 33–34
• The five scenarios illustrate how architectural reasoning can guide agent design before development, with the aim of improving robustness and functionality.The following section addresses framework limitations and future work.Source: §5.3.4 · p. 34

6 Conclusion and future work

• LLM-Agent-UMF defines a five-module core-agent, distinguishes active from passive types, and proposes uniform and hybrid multi-core architectures.The modules are planning, memory, profile, action, and security.Source: §6 · p. 34
• The one-active-many-passive architecture balances ease of development with the power of hybrid architectures.Source: §6 · p. 34
• Applying the framework to state-of-the-art agents identifies their modules and limitations and reveals prospects for merging capabilities.Source: §6 · p. 34
• Multi-active architectures face synchronization challenges that require further investigation.Suggested directions include a Raft-elected coordinator or a gateway that selects an active core-agent based on load, availability, and domain.Source: §6 · p. 34
• A shared core-agent terminology supports consistent, maintainable, and adaptable solutions within a common architecture.Source: §6 · p. 34

CRediT authorship contribution statement

• Ben Hassouna led project administration and supervision and contributed across writing, methodology, validation, visualization, investigation, data curation, formal analysis, and conceptualization; Chaari and Belhaj contributed writing, methodology, investigation, data curation, and formal analysis.Source: CRediT authorship contribution statement · p. 34