Paper deep dive
Describing Agentic AI Systems with C4: Lessons from Industry Projects
Andreas Rausch, Stefan Wittek
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 94%
Last extracted: 3/22/2026, 5:17:16 AM
Summary
This paper proposes a hierarchical, C4-aligned architectural documentation systematics for agentic AI systems. It addresses the challenge of documenting complex multi-agent collaborations, artifact exchanges, and tool invocations in industrial settings by extending UML-based modeling to capture agent-specific concerns like quality gates, task orchestration, and memory management.
Entities (6)
Relation Signals (3)
C4 Model â adaptedfor â Agentic AI Systems
confidence 95% · This paper introduced an adapted C4-adherent, UML-based notation for architecting agentic AI systems
Test Script Generator â demonstrates â C4 Model
confidence 90% · Figure 1 depicts a selection of the architectural description, illustrating the system across all levels of the C4 model.
Agentic AI Systems â utilizes â UML Activity Diagram
confidence 90% · It is based on UML Activity Diagram syntax to describe argentic ai specific elements.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Different domains foster different architectural styles -- and thus different documentation practices (e.g., state-based models for behavioral control vs. ER-style models for information structures). Agentic AI systems exhibit another characteristic style: specialized agents collaborate by exchanging artifacts, invoking external tools, and coordinating via recurring interaction patterns and quality gates. As these systems evolve into long-lived industrial solutions, documentation must capture these style-defining concerns rather than relying on ad-hoc code sketches or pipeline drawings. This paper reports industrial experience from joint projects and derives a documentation systematics tailored to this style. Concretely, we provide (i) a style-oriented modeling vocabulary and a small set of views for agents, artifacts, tools, and their coordination patterns, (ii) a hierarchical description technique aligned with C4 to structure these views across abstraction levels, and (iii) industrial examples with lessons learned that demonstrate how the approach yields transparent, maintainable architecture documentation supporting sustained evolution.
Tags
Links
- Source: https://arxiv.org/abs/2603.15021v1
- Canonical: https://arxiv.org/abs/2603.15021v1
Trouble viewing inline? Open PDF directly â
Full Text
27,153 characters extracted from source content.
Expand or collapse full text
Describing Agentic AI Systems with C4: Lessons from Industry Projects Andreas Rausch Institute for Software and Systems Engineering Clausthal University of Technology Clausthal-Zellerfeld, Germany arau@tu-clausthal.de Stefan Wittek Institute for Software and Systems Engineering Clausthal University of Technology Clausthal-Zellerfeld, Germany switt@tu-clausthal.de AbstractâDifferent domains foster different architectural stylesâand thus different documentation practices (e.g., state- based models for behavioral control vs. ER-style models for information structures). Agentic AI systems exhibit another characteristic style: specialized agents collaborate by exchanging artifacts, invoking external tools, and coordinating via recurring interaction patterns and quality gates. As these systems evolve into long-lived industrial solutions, documentation must capture these style-defining concerns rather than relying on ad-hoc code sketches or pipeline drawings. This paper reports industrial experience from joint projects and derives a documentation systematics tailored to this style. Concretely, we provide (i) a style-oriented modeling vocabulary and a small set of views for agents, artifacts, tools, and their coordination patterns, (i) a hierarchical description technique aligned with C4 to structure these views across abstraction levels, and (i) industrial examples with lessons learned that demonstrate how the approach yields transparent, maintainable architecture documentation supporting sustained evolution. Index TermsâSoftware architecture, Agentic AI systems, Large language models (LLMs), Multi-agent systems I. INTRODUCTION Major technology shifts yield new architectural styles and, eventually, fitting description techniques. Different domains foster different stylesâand thus different documentation prac- tices (e.g., state-based models for behavioral control vs. ER- style models for information structures). For instance, the Internet/REST era established characteristic web-system archi- tectures [1] along with recurring description elements such as clients, services, resources identified via URIs, HTTP methods, and API contracts (e.g., OpenAPI specifications) [2]. Likewise, ROS 2 shaped recurring architectures for distributed robotic systems [3] and domain-specific description elements (nodes, topics, services, launch configurations). Architectural description evolves accordingly to support communication, maintainability, and systematic evolution. A comparable shift is currently underway with LLMs and agentic AI frameworks. Many organizations are moving from âAI as a componentâ to agentic AI systems in which special- ized agents collaborate, interact with users, and invoke external tools (e.g., tool/function calling, MCP-style tool access) to automate tasks that were previously performed manually. Typical examples include generating executable test scripts from requirements or estimating the price of a used product on the resell market. In our joint projects with industrial partners, we observed that these agentic AI systems quickly become long-lived, evolving products. They accumulate dependencies and con- straints around agent responsibilities and boundaries, inter- action protocols, exchanged artifacts and memory, tool in- terfaces, and operational governance (permissions, budgets, validation, human approvals). Yet in practice, many imple- mentations remain documented in an ad-hoc mannerâoften as informal pipeline sketches or code-level structuresâmaking change-impact analysis, maintenance, and systematic evolu- tion unnecessarily difficult. Architecture description for agentic AI systems in indus- trial contexts is still emerging. While individual modeling approaches exist, they are rarely integrated into established ar- chitecture documentation frameworks such as C4 [4] or arc42 [5]. To document agentic AI systems within such frameworks, the documentation must reflect their characteristic styleâ agents collaborating via artifacts, tool invocations, and coordi- nation patterns with quality gates. This motivates a lightweight systematics that integrates these style-specific concerns into a hierarchical, framework-compatible documentation structure. This paper is an industry experience report that reflects on what has worked for us in practice when describing agentic AI systems. Rather than proposing a comprehensive new ADL, we provide (i) an architectural style centered on agents, artifacts, tools, and users and their interaction patterns, (i) a hierarchical, decomposition-based functional description technique aligned with established architecture documentation approaches such as C4, and (i) representative industrial ex- amples with cross-case lessons learned. Together, these results support understanding, maintenance, and systematic evolution of agentic AI systems. The remainder of this paper is structured as follows: Sec- tion I reviews related work on architectural style anchors and lightweight documentation practices. Section I details the architectural style observed in our projects and presents our hierarchical description technique aligned with C4. Section IV demonstrates the approach through tree industrial examplesâa requirements-to-test-script generator, a blueprint-guided archi- tecture recovery system and a resell price estimation system. arXiv:2603.15021v1 [cs.SE] 16 Mar 2026 Additional the section also consolidates lessons learned. Fi- nally, Section V concludes the paper and outlines directions for future work. I. RELATED WORK A. Architectural Style Anchors for Agentic AI Systems Agentic AI systems combine multiple specialized agents, tool access, and human interaction in recurring architectural structures. From a software-architecture perspective, many realizations resemble variants of established styles: (i) pipes- and-filters for staged processing pipelines [6], (i) blackboard architectures that coordinate specialized problem solvers via a shared workspace [7], and (i) orchestration vs. choreography as alternative collaboration patterns for distributed components [8]. These anchors provide useful intuitions for decomposition and interaction, but they do not explicitly address agentic- specific concerns such as bounded autonomy, artifact-centric handoffs, and operational quality gates. Closer to our scope, research on multi-agent systems (MAS) has long captured coordination knowledge in pattern form, including systematic overviews of MAS design patterns [9]. More recently, Liu et al. present an agent design pattern catalogue for foundation-model-based agents [10]. While such catalogues are valuable for designing agentic systems, they do not yet provide a lightweight, practitioner-friendly architecture description approach that supports communication, mainte- nance, and evolution across industrial teams. B. Architecture Description and Agentic Modeling Practices Architecture description standards and practitioner ap- proaches provide complementary guidance on how to docu- ment architectures. ISO/IEC/IEEE 42010 structures architec- ture descriptions around stakeholders, concerns, viewpoints, and views [11]. For pragmatic day-to-day documentation, the C4 model communicates software architectures via a small set of scalable views [4], and arc42 provides a widely used, practitioner-oriented template for architecture documen- tation [5]. However, these frameworks are largely technology- agnostic and do not prescribe agentic-specific documentation constructs (e.g., explicit agent roles and boundaries, interac- tion protocols/workflows, artifact and memory structures with provenance, tool access, and operational quality gates). In parallel, first modeling and reference-architecture ap- proaches tailored to agentic AI are emerging. For example, Ait et al. propose a BPMN extension for modeling humanâagentic collaborative workflows [12]. Beyond workflow modeling, several works propose agentic-specific architectural guidance, including reference architectures [13], architecture option tax- onomies and decision models [14], and architecture proposals for LLM-based multi-agent systems [15]. Complementary efforts capture recurring agent structures and coordination knowledge in catalogs and patterns [10] or provide unified modeling frameworks for designing agent architectures [16]. While valuable, these approaches are typically presented in isolation and are not yet integrated into holistic, hierarchical architecture documentation frameworks such as C4 or arc42, limiting their use as a consistent systematics for communica- tion, maintenance, and evolution in industrial practice. I. ARCHITECTURAL STYLE AND C4-BASED HIERACHICAL DESCRIPTION FOR AGENTIC AI SYSTEMS Across multiple joint industry projects, we observed that successful agentic AI systems consistently adopt a recog- nizable architectural pattern: a group of specialized agents collaborates by exchanging artifacts, invoking internal and external tools, and coordinating decisions through explicit interaction patterns. This aligns with emerging catalogs for foundation-model-based agents, which describe these systems as cooperating ensembles with recurring coordination mecha- nisms and shared work artifacts [10]. In practice, two complementary coordination modes pre- dominate: orchestration, where a dedicated conductor dele- gates tasks to worker agents, and choreography, where peer agents react to events, such as artifact updates, to trigger subsequent processing steps [8]. A recurring structural nu- cleus is the plannerâexecutor pattern, often supplemented by a verifier/critic for validation [10]. While orchestrators impose a collaboration protocol (defining actor sequences and quality gates), choreographed variants realize these protocols via event-driven reactions. Importantly, these architectures are typically hierarchical; an agent ensemble can be treated as a higher-level subsystem, necessitating a description technique that supports multi-level decomposition rather than flat work- flow representations. To document this style throughout the system lifecycle, we propose a hierarchical decomposition aligned with the C4 model. This approach positions the agentic system within its Context and decomposes it down to the Component and Code levels, making ensembles, individual agents, and their respective interfaces explicit. This multi-level approach is essential for maintaining concise descriptions while enabling change-impact analysis and evolution planning. Figure 1 illustrates our proposed notation and architectural description for the Test Script Generator System. This diagram encompasses all four levels of the C4 model, adapted for agentic systems. A. C1: Context The C1 Context level provides a high-level overview of the system, depicting the system itself, the Users, and any external Systems. Connections at this level are directional and explicitly labeled with the artifacts being exchanged. A distinguishing feature of our notation is the explicit depiction of the Large Language Model (LLM) driving the agents; this allows for the specification of particular LLM versions or the use of multiple models. Additionally, all external tools are visually highlighted with a red background. B. C2: Container The C2 Container level zooms into the system boundary to provide a runtime view. We utilize UML Deployment Diagram syntax to depict the system nodes. Connections at Agent RoleTest Executor GoalExecute tests and report results test «task» «TaskCall» test:TestPipeline TestPipeline «agent» gpt-4 Test Script Generator generate «task» fix «task» ... Developer «agent» generate «task» ... execute «task» ... TestCaseRetriever «agent» Jenkins Tool «LLM» gpt-4 Test Script Generator User Jenkins ServerOpen AI Server frontend Database «execution environment» Browser User node.js backend TestGenerator.py Backend ServerUser Client «TaskCall» summarize:Executor «TaskCall» execute:Executor «TaskCall» fix:Developer «TaskCall» generate:Developer «TaskCall» generate:DevTeam «TaskCall» retrieve:TestRetriever C1: Context C2: Container C3: Component C4: Code Task TestCodeCode being tested TestLogContent of Test Log TaskAnalyze the raw logs and summarize failures... OutputFinal Test Report generate «task» summarize «task» execute «task» Executor «agent» DevTeam «agent» TestGeneratorTeam «agent» ReportTestCode Jenkins Tool Report [Report = IO] Report CodeExamples TestCode Report TestCode TestCode TestSpec Code ExamplesTestCode TestCode, Report TestCode / TestLog LLM requests/responseTestSpec «MCP»«HTTP» «SQL» «HTTP» «dataStore» TestCode TestCode Report TestLog TestLogTestCode Report else TestLog Test Code Code Examples Test Spec Test Code Code ExamplesTestSpec «ToolCall» run:Jenkins Tool Fig. 1. All C4 architectural levels of Test Script Generator example. this level represent specific protocols, such as HTTP or the Model Context Protocol (MCP). Consistent with the previous level, external tools remain distinctively marked with a red background. C. C3: Component The C3 level provides a hierarchical decomposition of the systems behavior. It is based on UML Activity Diagram syntax to describe argentic ai specific elements. 1) Agents: Are activities with the stereotype <<agent>> represent single agents (e.g. Executor later described in C4), groups of agents, and their workflows (e.g. TestPipeline). 2) Task:To visually bundle behavior into specific tasks(e.g.,test),weutilizeinterruptionactivity regionsârepresentedasroundedboxeswithdashed linesâmarked with the stereotype <<task>>. 3) Artifacts: Object nodes are used to specify artifacts, defining both inputs (e.g., TestCode) and outputs (e.g., Report). Crucially, in this notation, it is the Tasks that require inputs and produce outputs, not the Agents themselves, as these requirements vary based on the specific task being performed. An agent may be responsible for multiple tasks. 4) Memory: Object nodes with the <<datastore>> stereotype are used to model a shared memory (i.e. for TestCode in the DevTeam) that agents update during execution. 5) Quality Gates: Agent decisions can be modeled using Decision Node and Guards (i.e. the quality gate [Report=IO] in generate:DevTeam, this is an instance of the verifier/critic pattern). 6) TaskCall: A central addition to our notation is the Call Behavior Action with the stereotype <<TaskCall>>. As the name suggests, a <<TaskCall>> realizes the invocation of a specific task on a specific agent (e.g., execute:Executor). This facilitates our suggested decomposition strategy: Task Calls are decomposed into Agent Tasks, which are further composed of Task Calls etc. 7) Interaction Pattern: Our notation uses activity diagram syntax to model the interaction patterns of the agents. De- vTeam exampels a workflow like interaction, here the agents produce artifacts in a defined pipeline combined with a quality gate and loops. The Resell App described later follows the orchestration interaction pattern. D. C4: Code The C4 Code level represents the lowest level of decom- position, consisting of leaf actions. While it retains the C3 syntax, it introduces leaf actions to describe implementation details. 1) Tools: The ToolCall element depicts the invocation of internal or external tools (e.g., run:JenkinsTool). 2) Prompts: Furthermore, this level includes specific de- scriptions of the Prompts passed to the LLM (e.g., in a summarize:Extractor Task), presented as a table. The structure typically follows the specific Agentic Framework used, distin- guishing between static elements (such as role descriptions) and task-specific elements (such as current task descriptions and input artifacts like TestCode or TestLog). IV. INDUSTRIAL EXAMPLES A. Example - Test Script Generator The primary objective of the Test Script Generator is to automate the creation of GUI test scripts based on formal Requirement Specifications. This system is specifically de- signed to automate the currently manual testing efforts of a large legacy system (System Under Test). To enhance the quality and syntactic correctness of the output, the generation process is augmented by a knowledge base of existing test scripts, which serve as reference examples (implemented in retrieve:TestRetriever). Figure 1 depicts a selection of the architectural description, illustrating the system across all levels of the C4 model. A focal point of this architecture is the Core Generation Loop defined at the C3 Component level. This workflow is orchestrated by the GeneratorTeam. The process initiates by ingesting retrieved code examples (Code Examples) and the target Test Specification (TestSpec). The generate:Developer task utilizes these inputs to synthe- size an initial version of the test code. Subsequently, the test:TestPipeline executes this code against the legacy system, producing a detailed execution report. A critical feature of this architecture is its self-correcting capability. If the execution results in errors (classified as âNot In Orderâ or NIO), an iterative feedback loop is triggered. The fix:Developer task analyzes the flawed code alongside the error report to generate a corrected version. Note that this update mechanism is described using the dataStorage of UML Activity Diagrams. This cycle repeats until the test executes successfully. Finally, the validated TestCode and the corresponding Report are released to the wider system as final artifacts. B. Example - Blueprint-Guided Architecture Recovery System AutomatedArchitectureRecoveryPipeline <<agent>> <<task call>> extract:NodeAnalyzer recovery <<task>> PUML and PNG System Architecture PUML & PNG Component Architecture <<task call>> synthesize:SystemTeam Repository and Recovery Job Requset <<accept event>> Job Requested <<task call>> synthesize:ComponentTeam * List of ROS Nodes & Code External Git Repository Fig. 2. Part of the C3: Component level description of Blueprint-Guided Architecture Recovery example. As a second case study, we introduce the Blueprint-Guided Architecture Recovery System. In contrast to the generation use case, this system focuses on the reverse engineering of architectural models from existing source code. Specifically, it targets ROS 2 systems, aiming to recover hierarchical functional architectures by analyzing code and launch config- urations. The recovery process is guided by a formal notation defined in an architectural blueprint, ensuring that the inferred models conform to specific domain constraints. Figure 2 illustrates the core workflow of this system using our C3 notation. The entire process is encapsulated within the AutomatedArchitectureRecoveryPipeline. The workflow is initiated by an external Job Request (control flow) and operates on an external Git Repository (object flow), demonstrating a clear separation between execution triggers and data sources. Following the deterministic extraction phase, the workflow transitions into the generative stage. Here, the List ROS Nodes & Code serves as the central interface artifact. The processing of this list showcases the expressive power of our activity- diagram-based syntax: âą The segmented object node depicts the list as a collection of elements. âą The asterisk (*) atop the synthesize:ComponentTeam <<TaskCall>> indicates that the list is processed element-wise, producing a distinct PUML & PNG of Component Architecture for each identified node. âą Conversely, the list is processed as a holistic entity by the synthesize:SystemTeam <<TaskCall>> to reconstruct the global system-level hierarchy and composition, which is finally outputted. C. Example - Resell App The Resell App streamlines selling used products on plat- forms like eBay. It uses a Multimodal Large Language Model to analyze images, followed by a MarketSearchConductor agent that identifies matching offers to estimate prices. Figure 3 illustrates this agent in C3 Notation. First the agent derives a query from the image Analysis. This query is than delegated to a Ebay and a Amazon researcher. Both provide a Product List, which is integrated and filed toward relevance with respect to the original image analysis. Note that this is an instance of the orchestration interaction pattern. Note also that in this case the agent is also calling tasks on itself (createQuery and integrateAndFilter). To make this clear in the notation, we drop the instance marking (:Market- SearchConductor) and the color. «TaskCall» integrateAndFilter search «task» «task» integrateAndFilter.. «task» createQuerry... «TaskCall» createQuery «TaskCall» search:EbayResearcher «TaskCall» search:AmazonResearcher MarketSearchConductor «agent» Product List query Image Analysis Fig. 3. Part of the C3: Component level description of the Resell App System example. D. Lessons Learned The application of our adapted C4 notation to agentic systems has revealed several insights regarding the balance between formal modeling and architectural clarity. A primary observation concerns the C2 Container Level, where we noted a loss of information regarding artifacts passed over connections. Because standard deployment diagrams prioritize physical node distribution and communication protocols, such as HTTP or MCP, they do not natively represent internal interfaces or artifact exchanges between components on the same node. While prioritizing protocols maintains a clean runtime view, it is suboptimal as these artifacts inevitably reappear in detailed C3 and C4 decompositions. A further challenge is the redundancy of input object nodes required to maintain task interface transparency. Artifacts like TestCode must often be duplicated within an agentâs task region to clarify specific inputs for tasks. While this repetition does not strictly adhere to standard UML activity diagram syntax, it is necessary to ensure that the interface requirements of discrete tasks remain explicit. Finally, we observed that iconization could significantly en- hances readability. Our current notation relies heavily on text- based stereotypes like <<agent>> and <<task>>, which increase cognitive load as system complexity grows. By incor- porating domain-specific icons, we can reduce visual clutter and improve the immediate understanding of the system. V. CONCLUSION AND FUTURE WORK This paper introduced an adapted C4-adherent, UML-based notation for architecting agentic AI systems, demonstrated through a test script generation loop, a blueprint-guided ROS 2 architecture recovery pipeline and a resell price estimation system. Future work should focus on refining the C2 level to better bridge the gap between deployment structure and func- tional data flow and establishing a standardized icon set that maintains formal UML semantics while providing a more intuitive experience for architects. Additional an explicated notation for different interaction patterns like orchestration or choreography would be a promising direction. Beyond immediate visualization benefits, this work con- tributes to the emerging discipline of AI Engineer- ing. By treating agentic workflows as first-class archi- tectural concernsârather than opaque implementation de- tailsâorganizations can enforce governance, auditability, and systematic reuse. As these systems scale, the ability to decom- pose complex agent ensembles into understandable, reviewable views will be the deciding factor between fragile prototypes and robust industrial products. REFERENCES [1] R. T. Fielding, âArchitectural styles and the design of network- based software architectures,â Ph.D. dissertation, University of California, Irvine, 2000, ph.D. dissertation. [Online]. Available: https: //w.ics.uci.edu/ ⌠fielding/pubs/dissertation/fielding dissertation.pdf [2] OpenAPI Initiative, âOpenapi specification,â Online specification, accessed: 2026-02-15. [Online]. Available: https://spec.openapis.org/ [3] S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, âRobot operating system 2: Design, architecture, and uses in the wild,â Science Robotics, vol. 7, no. 66, p. eabm6074, May 2022. [Online]. Available: https://w.science.org/doi/10.1126/scirobotics.abm6074 [4] S. Brown, âThe C4 model for visualising software architecture,â accessed: Feb. 8, 2026. [Online]. Available: https://c4model.com/ [5] G. Starke and P. Hruschka, âarc42: Template for architecture documentation,â accessed: Feb. 8, 2026. [Online]. Available: https: //arc42.org/ [6] Microsoft, âPipes and filters pattern,â Azure Architecture Center, accessed: Feb. 8, 2026. [Online]. Available: https://learn.microsoft.com/ en-us/azure/architecture/patterns/pipes-and-filters [7] D. D. Corkill, âBlackboard systems,â AI Expert, vol. 6, no. 9, p. 40â47, Sep. 1991. [Online]. Available: https://mas.cs.umass.edu/ Documents/Corkill/ai-expert.pdf [8] A. Megargel, C. M. Poskitt, and V. Shankararaman, âMicroservices orchestration vs. choreography: A decision framework,â in Proceedings of the IEEE 25th International Enterprise Distributed Object Computing Conference (EDOC), 2021, p. 134â141. [9] J. Juziuk, D. Weyns, and T. Holvoet, âDesign patterns for multi-agent systems: A systematic literature review,â in Agent-Oriented Software Engineering: Reflections on Architectures, Methodologies, Languages, and Frameworks, O. Shehory and A. Sturm, Eds.Berlin, Germany: Springer, 2014, p. 79â99. [10] Y. Liu, S. K. Lo, Q. Lu, L. Zhu, D. Zhao, X. Xu, S. Harrer, and J. Whittle, âAgent design pattern catalogue: A collection of architectural patterns for foundation model based agents,â Journal of Systems and Software, vol. 220, p. 112278, Feb. 2025. [11] ISO/IEC/IEEE, âISO/IEC/IEEE 42010:2022, software, systems and enterprise â architecture description,â 2022. [Online]. Available: https://w.iso.org/standard/74393.html [12] A. Ait, J. L. C Ì anovas Izquierdo, and J. Cabot, âTowards modeling human-agentic collaborative workflows: A BPMN extension,â in Soft- ware Engineering and Advanced Applications: 51st Euromicro Confer- ence, SEAA 2025, Salerno, Italy, September 10â12, 2025, Proceedings, Part I, D. Taibi and D. Smite, Eds. Cham, Switzerland: Springer, 2025, p. 367â382. [13] Q. Lu, J. Zhou, L. Zhu, X. Xu, Z. Xing, S. Harrer, and J. Whittle, âTo- wards responsible generative AI: A reference architecture for designing foundation model based agents,â in 2024 IEEE International Conference on Software Architecture Companion (ICSA-C). IEEE, 2024, p. 119â 126. [14] J. Zhou, Q. Lu, J. Chen, L. Zhu, X. Xu, Z. Xing, and S. Harrer, âA taxonomy of architecture options for foundation model-based agents: Analysis and decision model,â arXiv:2408.02920, Aug. 2024. [Online]. Available: https://arxiv.org/abs/2408.02920 [15] M. Becattini, R. Verdecchia, and E. Vicario, âSallma: A software archi- tecture for LLM-based multi-agent systems,â in 2025 IEEE/ACM Inter- national Workshop on New Trends in Software Architecture (SATrends). IEEE, 2025, p. 5â8. [16] A. B. Hassouna, H. Chaari, and I. Belhaj, âLlm-agent-umf: Llm- based agent unified modeling framework for seamless design of multi active/passive core-agent architectures,â Information Fusion, vol. 127, p. 103865, Mar. 2026.