LLM-Agent-UMF: Unified Modeling for LLM Agents

• LLM-Agent-UMF is a framework defining multi-agent systems by splitting agent functionality into five modules—planning, memory, profile, action, and security—to ensure clear module responsibilities.
• It standardizes system architecture by introducing a core-agent that integrates LLMs with tools and data sources, thereby enabling flexible, secure agent ensembles.
• The framework supports diverse architectures including active, passive, and hybrid models, optimizing trade-offs between modularity, risk, and scalability.

LLM-Agent-UMF (LLM-based Agent Unified Modeling Framework) is a modular architectural and conceptual foundation for constructing, analyzing, and scaling multi-agent systems in which LLMs are coordinated with external tools and data sources by explicitly defined software elements termed core-agents. The framework formalizes both the software boundary between LLMs, tools, and agent orchestration logic, and the internal decomposition of agents into five distinct modules—planning, memory, profile, action, and security—for improved modularity, clarity, and risk/safety analysis. LLM-Agent-UMF resolves long-standing inconsistencies and gaps in the construction of LLM-powered autonomous agents by enabling systematic classification, robust trade-off assessment, and design of multi-active/passive agent ensembles that preserve both flexibility and security (Hassouna et al., 2024).

1. Motivations and Objectives

Pre-existing approaches to LLM-augmented agent frameworks suffer from architectural fragmentation and inconsistent terminology, with ad hoc integration of tool APIs, LLM query pipelines, and environment actuators. Functional overlaps—such as entanglement of planning and memory—hinder composability and replaceability of components, while cross-cutting concerns (privacy, security, safety) are frequently neglected or post-hoc extensions. Monolithic designs inhibit scalability, fault tolerance, and maintainability.

LLM-Agent-UMF aims to standardize design patterns by introducing a "core-agent" that mediates between LLMs and toolchains, exposing a set of single-responsibility modules, classifying the authority of agent nodes (active vs passive), and enabling explicit architectural trade-off and risk analysis for multi-agent topologies (Hassouna et al., 2024). This unification facilitates comparative evaluation, module interchangeability, and explicit surfacing of often-overlooked dimensions such as security and profile management.

2. Functional and Software Architectural Decomposition

LLM-Agent-UMF formalizes three primary software entities:

• LLMs: The LLM itself (frozen or adaptive) providing reasoning, generation, and commonsense abstraction.
• Tools/Data: External services accessible via APIs or code execution (e.g., databases, vision models, structured knowledge bases).
• Core-Agent: The software orchestrator, newly formalized, mediating between LLM, tools, and environment.

Within each core-agent, exactly five logical modules are defined:

Module	Responsibility	Perspectives/Methods
Planning	Decomposition/generation of plans	Single-path, multi-path, rule- or LM-based
Memory	Short/long-term state, context	Scope (short/long), Location, Format
Profile	LLM persona/role alignment	In-context, LLM-generated, dataset-aligned, fine-tuned
Action	Environment and tool interaction	Goal, Trigger, Space, Impact
Security	Safeguards/guardrails	Rule-based & LLM-based; prompt/response/data privacy

The agent's software structure is illustrated as a UML component diagram: User → (Core-Agent: Planning, Memory, Profile, Action, Security) → [LLM] and [Tools/Data]. Each module is owned by the core-agent and realizes the single responsibility principle, facilitating independent optimization, extension, or replacement (Hassouna et al., 2024).

3. Core-Agent Typology and Authority

A core-agent is classified by its authoritative scope through the presence or absence of key modules:

• Active Core-Agent: Owns both planning and memory modules (authority indicator $\alpha=1$); capable of autonomous task decomposition, adaptive profile management, and dynamic context tracking. Used as managers or principal agents in ensemble architectures.
• Passive Core-Agent: Contains only action (and optionally security); operates as a stateless executor or tool-caller, lacking decision-making authority ($\alpha=0$).

Formally, with module set $\mathcal{M} = \{\textsc{Plan},\textsc{Mem},\textsc{Prof},\textsc{Act},\textsc{Sec}\}$, the core-agent's status is

$\alpha(C) = \begin{cases} 1 & \text{if } \textsc{Plan} \in C \text{ and } \textsc{Mem} \in C \ 0 & \text{otherwise} \end{cases}$

Active core-agents own full context and authority; passive agents simply execute delegated instructions (Hassouna et al., 2024).

4. Multi-Core Agent Architectural Patterns

LLM-Agent-UMF permits composable design of multi-agent systems supporting scalability, robustness, and division of labor. Major patterns include:

• Multi-Passive: $n$ passive core-agents act as parallel specialist executors; no inter-core synchronization.
• Multi-Active: $k$ active core-agents; coordination may require distributed consensus protocols.
• Hybrid One-Active–Many-Passive: A single active manager schedules, monitors, and delegates tasks to $m$ passive worker agents (highlighted as best trade-off in the paper).
• Many-Active–Many-Passive: General mesh for high fault tolerance; significant synchronization complexity.

Architectural trade-offs are qualitatively described along axes of modularity (μ), synchronization overhead (σ), robustness/risk (ρ), and latency (ℓ), with decisions made to maximize composite objective functions of the form:

$f(\text{arch}) = w_1 \mu - w_2 \sigma - w_3 \rho$

where $w_i$ are domain- or scenario-specific weights (Hassouna et al., 2024).

5. Module-Specific Semantics and Interactions

5.1 Planning

Responsible for iterative or non-iterative task decomposition, leveraging single-path (chain-of-thought), multi-path (Tree/Graph-of-Thoughts), rule-based planners, or LLM-powered strategies. Accepts feedback from internal modules, tools, or external core-agents.

5.2 Memory

Manages agent state, supports both short-term (in-process, ephemeral) and long-term (persistent, externalized vector or SQL stores), and enables retrieval via explicit query semantics:

$$m_t = \mathit{Update}(m_{t-1}, o_t),\quad \mathit{Retrieve}(m_t, q) \rightarrow r$$

5.3 Profile

Encapsulates the LLM’s role/behavioral persona using in-context prompt templates, explicit LLM generation, dataset-derived alignments, or pluggable fine-tuning adapters (PEFT, LoRA).

5.4 Action

Executes plans by interacting with tools or the environment, supporting various trigger modes (plan-following, API call), action goals, and impact scopes.

5.5 Security

Implements safeguarding at input (prompt), output (response), and data transfer stages, utilizing both rule-based and neural agent guardrails. Boolean checkers enforce access policies:

$$\Gamma_{\mathrm{prompt}(u)} \in \{\mathrm{allow}, \mathrm{deny}\},\quad \Gamma_{\mathrm{resp}(r)} \in \{\mathrm{safe}, \mathrm{unsafe}\}$$

6. Evaluation and Empirical Analysis

The framework’s suitability and descriptive power were validated by mapping thirteen state-of-the-art LLM-agents to the LLM-Agent-UMF module taxonomy. Surveyed agents included representatives such as Toolformer, Confucius, ToolAlpaca (passive), Gorilla, ToolLLM, GPT4Tools, Chameleon, ChatDB, LLM+P, ChemCrow, LLMSafeGuard (active), as well as ChatGPT 4o mini and ChatGPT 4o. The survey found that 78% of tool-using systems lacked an explicit security module; memory logic was frequently conflated with planning, and profile management approaches varied widely (Hassouna et al., 2024).

The evaluation was performed using the AFTRAM (Architecture Tradeoff & Risk Analysis Framework) methodology:

• Scenario and requirement gathering
• Functional and software architectural mapping
• Attribute-specific impact/risk analysis (modularity, security, scalability)
• Sensitivity analysis and scenario-based scoring to inform system selection and domain adaptation.

7. Design Insights, Best Practices, and Open Challenges

Adoption of core-agent modularity is recommended as standard practice:

• Always implement a security module with both rule-based and LLM-powered guardrails.
• Clarify planning strategies and memory perspectives to avoid overlaps and ambiguities.
• Use pluggable profile mechanisms for persona management and role separation.
• Prefer the one-active–many-passive multi-core architecture for balance in power, simplicity, and risk.
• Systematically apply the single-responsibility and open-closed principles for extensibility.

Open research questions include: development of lightweight synchronization protocols for multi-active ensembles, explicit quantitative risk scoring for performance/security trade-offs, automated module composition and configuration tooling, and dynamic runtime adaptation of agent cores for load management or failover (Hassouna et al., 2024).

---

LLM-Agent-UMF establishes an extensible, rigorously defined paradigm for language-model-based agent systems, separating reasoning, execution, state, persona, and safety into explicit, composable modules and supporting scalable multi-agent deployments through architectural primitives rooted in software engineering best practices.