ETSI GR ENI 056 V4.1.1 (2025-10)

Experiential Networked Intelligence (ENI); Study on Multi-Agent Frameworks for Next-Generation Core Networks

DGR/ENI-0056v411_Stud_MultiA

General Information

• Status: Not Published
• Technical Committee: ENI - Experiential Networked Intelligence
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 05-Nov-2025
• Completion Date: 17-Oct-2025

Standards Content (Sample)

GROUP REPORT
Experiential Networked Intelligence (ENI);
Study on Multi-Agent Frameworks for
Next-Generation Core Networks
Disclaimer
The present document has been produced and approved by the Experiential Networked Intelligence (ENI) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR ENI 056 V4.1.1 (2025-10)

Reference
DGR/ENI-0056v411_Stud_MultIA
Keywords
6G, AI, AI-native, GenAI
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2025.
All rights reserved.
ETSI
3 ETSI GR ENI 056 V4.1.1 (2025-10)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Background . 9
4.1 Service Based Architecture . 9
4.1.1 SBA Reference Model . 9
4.1.2 Service Based Interface . 9
4.1.3 Network Function Service Framework . 9
4.2 Open-Source Multi-Agent Frameworks and Communication Mechanisms . 10
4.2.1 Introduction. 10
4.2.2 Overview of Existing Multi-Agent Frameworks . 11
4.2.3 Multi-Agent Communication Mechanisms . 12
4.2.4 Existing Multi-Agent Protocols . 14
4.2.4.1 Introduction . 14
4.2.4.2 Context-Oriented Protocols . 15
4.2.4.2.1 Introduction . 15
4.2.4.2.2 Model Context Protocol (MCP) . 15
4.2.4.3 Inter-Agent Protocols . 16
4.2.4.3.1 Introduction . 16
4.2.4.3.2 The Agent-to-Agent (A2A) Protocol . 16
4.2.4.3.3 Agent Communication Protocol . 18
4.2.4.3.4 Agent Network Protocol (ANP) . 18
4.2.4.4 Comparison of Inter-Agent Protocols . 19
4.3 The Role of MCP and A2A in an ENI System . 20
5 Multi-Agents System in Core Network . . 21
5.1 Benefits of Multi-Agent Systems . 21
5.1.1 Energy Consumption and Inference Time . 21
5.1.2 Modularity and Extensibility . 21
5.1.3 Robustness . 21
5.1.4 Distributed Decision-making . 22
5.2 Design Principles . 23
5.3 Example AI Agents for the Core Network . 24
6 Inter-Agent Communication . 24
6.1 Agent-Based Interface . 24
6.1.1 Motivation. 24
6.1.2 Definition and Characteristics. 25
6.1.3 Interface Design Principles . 26
6.2 Key Methods . 26
6.2.1 Agent-to-User . 26
6.2.2 Agent-to-ARF . 27
6.2.2.1 Agent Registration, De-Registration and Update . 27
6.2.2.2 Agent Discovery and Selection . 28
6.2.3 Agent-to-Agent . 30
6.2.4 Agent-to-Resource . 31
6.2.5 Agent-to-Infrastructure . 31
ETSI
4 ETSI GR ENI 056 V4.1.1 (2025-10)
6.3 Agent Communication Model . 32
7 Multi-Agent Collaboration Mechanism . 33
7.1 Workflow Orchestration . 33
7.2 Closed-loop Optimization Mechanism . 34
7.2.1 Multi-Agent Coordination and Optimization . 34
7.2.2 Network Feedback Reinforcement Learning . 35
7.2.3 Multi-Agent Self-Reflection . 36
7.2.4 Multi-Agent Conflict Resolution . 37
8 Standard Impact Analysis . 39
9 Conclusion and Recommendations . 40
Annex A: More details about the A2A Protocol . 41
Annex B: AGNTCY™ and Agent Connect Protocol . 44
History . 46

ETSI
5 ETSI GR ENI 056 V4.1.1 (2025-10)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Experiential Networked
Intelligence (ENI).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI GR ENI 056 V4.1.1 (2025-10)
1 Scope
The present document studies Multi-Agent Systems (MASs), which comprise multiple Artificial Intelligence (AI)
agents designed to solve a set of complex tasks collaboratively. It reviews popular existing open-source frameworks to
implement MASs and existing multi-agent topologies, conversation patterns and key design principles. This includes
interface design for collaborative inference, key performance indicators to quantify the performance of MASs, as well
as various workflow options to perform closed-loop optimization between AI agents. While focusing primarily on the
employment of MASs in the next generation mobile networks, the present document explicitly discusses recommended
architectural changes in the design principles of core network together with potential standard impacts.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] 3GPP TS 23.501 (V19.2.1): "System architecture for the 5G System (5GS)".
[i.2] 3GPP TS 29.500 (V19.2.0): "Technical Realization of Service Based Architecture".
[i.3] 3GPP TS 29.501 (V18.3.0): "Principles and Guidelines for Services Definition".
[i.4] IEEE 802.11™: "IEEE Standard for Information Technology--Telecommunications and
Information Exchange between Systems Local and Metropolitan Area Networks--Specific
Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
[i.5] 3GPP TS 33.501 (V19.1.0): "Security architecture and procedures for 5G system".
[i.6] J. Kaplan, et al.: "Scaling Laws for Neural Language Models," arXiv preprint arXiv:2001.08361,
2020.
[i.7] Q. Wu, et al.: "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversations",
Conference on Language Modeling, 2024.
[i.8] T. Guo, et al.: "Large Language Model Based Multi-Agents: A survey of progress and challenges",
arXiv preprint arXiv:2402.01680, 2024.
[i.9] C. Chan, et al.: "Chateval: Towards better LLM-based Evaluators Through Multi-Agent Debate",
arXiv preprint arXiv:2308.07201, 2023.
[i.10] GitHub for the Agent Network Protocol.
[i.11] J. Rosenberg, C. Jennings: "Framework, Use Cases and Requirements for AI Agents", (accessed
on 08 May 2025).
[i.12] ETSI GR ENI 051 (V4.1.1): "Experiential Networked Intelligence (ENI); Study on AI Agents
based Next-generation Network Slicing".
ETSI
7 ETSI GR ENI 056 V4.1.1 (2025-10)
[i.13] ETSI GR ENI 016 (07-2021): "Experiential Networked Intelligence (ENI); Functional Concepts
for Modular System Operation".
[i.14] ETSI GS ENI 019 (V4.1.1): "Experiential Networked Intelligence (ENI); Representing, Inferring,
and Proving Knowledge in ENI".
[i.15] Agent Communication Protocol.
[i.16] Anthropic: "Building Effective Agents", 2024.
[i.17] A. Ehtesham, A. Singh, G. K. Gupta, S. Kumar: "A Survey of Agent Interoperability Protocols:
Model Context Protocol (MCP), Agent Communication Protocol (ACP), Agent-to-Agent Protocol
(A2A), and Agent Network Protocol (ANP)", arXiv preprint arXiv: 2505.02279, 2025.
[i.18] Y. Lu, J. Wang: "KARMA: Leveraging Multi-Agent LLMs for Automated Knowledge Graph
Enrichment", arXiv preprint arxiv: 2502.06472, 2025.
[i.19] ETSI GS ENI 005 (V4.1.1): "Experiential Networked Intelligence (ENI); ENI System
Architecture".
[i.20] Model Context Protocol (MCP).
[i.21] A2A Protocol.
[i.22] Semantic Versioning.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
5G System: 3GPP system consisting of 5G Access Network (AN), 5G Core Network and UE [i.1]
Customized Service Network (CSN): logical network that is generated on-demand by AI agents in the mobile core
rd
network according to the customers' intents and is comprised of network functions, application functions, 3 party
APIs, and the associated computing and communication resources
interface: point across which two or more components exchange information [i.19]
Multi-Agent System (MAS): collection of autonomous, interacting agents that work together (or compete) to solve
problems that are too large, dynamic, or complex for any single agent to solve alone
Network Function (NF): 3GPP adopted or 3GPP defined processing function in a network, which has defined
functional behaviour and 3GPP defined interfaces [i.1]
semantic similarity: metric defined over a set of documents or terms that measures the degree to which two linguistic
items share similar meanings through "is-a" relationships (synonymy and hyponymy)
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP Third Generation Partnership Project
5G Fifth Generation
A2A Agent2Agent
ETSI
8 ETSI GR ENI 056 V4.1.1 (2025-10)
ABAC Attribute-Based Access Control
ABI Agent-Based Interface
ACP Agent Communication Proxy
ADK Agent Development Kit
ADP Agent Description Protocol
AI Artificial Intelligence
AMF Access and Mobility Management Function
ANP Agent Network Protocol
API Application Programming Interface
ARF Agent Repository Function
AUSF Authentication Server Function
CN Core Network
CRA Conflict Resolution Agent
CRM Customer Relationship Management
CSN Customized Service Network
E2E End-to-End
HTTP Hypertext Transfer Protocol
ID Identifier
JSON JavaScript Object Notation
JWT JSON Web Token
LLM Large Language Model
LSP Language Server Protocol
MAD Multi-Agent Debate
MAS Multi-Agent System
MCP Model Context Protocol
NAS Non-Access Stratum
NEF Network Exposure Function
NF Network Function
NRF Network Repository Function
NSSF Network Slice Selection Function
NWDAF Network Data Analytics Function
OASF Open Agent Schema Framework
P2P Peer-to-Peer
PCF Policy Control Function
PDU Protocol Data Unit
PnP Plug-and-Play
PLMN Public Land Mobile Network
QoS Quality of Service
RAN Radio Access Network
RAG Retrieval-Augmented Generation
RBAC Role-Based Access Control
RFC Request for Comments
RPC Remote Procedure Call
RTP Real-time Transport Protocol
SBA Service-Based Architecture
SBI Service-Based Interface
SCP Service Communication Proxy
SDO Standards Development Organization
SDK Software Development Kit
SIP Session Initiation Protocol
SLA Service Level Agreement
SM Session Management
SMF Session Management Function
SSE Server-Sent Events
TTL Time to Live
UE User Equipment
UDM Unified Data Management
UPF User Plane Function
URI Uniform Resource Identifier
URL Uniform Resource Locator
UUID Universally Unique Identifier
ETSI
9 ETSI GR ENI 056 V4.1.1 (2025-10)
4 Background
4.1 Service Based Architecture
4.1.1 SBA Reference Model
The system functionality in a 5G mobile network is achieved by a set of Network Functions (NFs) providing services to
other NFs. To name a few examples, Access and Mobility Management Function (AMF) and Network Slice Selection
Function (NSSF) are NFs providing Namf_Location and Nssf_NSSelection services, respectively. While the former
allows a service consumer to request location information for a specific UE, the latter allows the service consumer NF
to request information about a network slice. As can be seen here, an NF service is a specific capability exposed by a
(service producer) network function to other NFs that are authorized to consume that service. As a design principle,
3GPP requests each of the NF services to be self-contained, acted upon and managed independently from other services
of the same NF.
4.1.2 Service Based Interface
Service-Based Interfaces (SBIs) are used in the 5G SBA to enable communication between NFs. Each SBI can consist
of multiple services. A Service-Based Interface (SBI) represents how the set of services is provided or exposed by a
given NF. This is the interface where the NF service operations are invoked [i.2]. As specified by 3GPP in [i.1], 5G
system architecture contains more than twenty SBIs, including but not limited to Namf, Nsmf, and Nssf exhibited by the
AMF, SMF and NSSF, respectively.
In the 5G SBA, each SBI provides access to multiple services via standardized Application Programming Interfaces
(APIs). As defined in [i.3], each 5G CN SBI API specification is required to include the following information (among
others) for each specified service, purpose of the API, URIs of resources, supported HTTP methods for a given resource
(e.g. HTTP GET), supported representations (e.g. JSON), request body schema(s) (where applicable), response body
schema(s) (where applicable), and supported response status codes.
By following the design principles mentioned above, 5G SBIs are built on explicit service operations, meaning that a
service producer expects a structured and pre-defined input (i.e. service request) upon which it generates a pre-defined
output (i.e. service response). The relationship between the input and output is specified and any deviation leads to
undesired behaviour, such as the rejection of a service request, e.g. due to a syntax error, input size error, followed by
the corresponding HTTP status code of 400 (i.e. bad request).
4.1.3 Network Function Service Framework
As introduced earlier, the SBA consists of multiple NF services offered by different NF instances, typically running on
different machines in a distributed fashion. This mandates a set of mechanisms that allow the NF consumers to know
about the existence of other NF services, as well as their location for interacting with them. To address this, the 3GPP
has defined the NF service framework, which includes a list of mechanisms to enable the use of NF services in the
service-based architecture. These are:
i) NF service registration and de-registration;
ii) NF service discovery;
iii) NF service authorization; and
iv) Inter-service communication [i.2].
For the registration and de-registration of NF services, the Network Repository Function (NRF) plays a central role. In
addition to few other services, the NRF offers Nnrf_NFManagement service and Nnrf_NFDiscovery services that define
how each service producer NF instance informs the NRF of the list of NF services that it supports and how each service
consumer NF instance discovers other NF instances with the potential services they offer, respectively. The registration
of an NF is done by sending a Nnrf_NFManagement_NFRegister request to the NRF that contains the NF profile. The
NF profile contains information related to the NF instance to be registered, such as its NF instance ID and its supported
NF service list. Typically, this is done when the service producer NF instance becomes operative for the first time.
ETSI
10 ETSI GR ENI 056 V4.1.1 (2025-10)
Similar to the registration procedure, the standard allows an NF instance to de-register from the NRF before shutting
itself down or disconnecting from the network in a controlled manner.
In the specific case of SBA security, the NF service authorization is ensured both by the NRF and the NF service
producer. More specifically, the NRF is able to hide the NFs in one trust domain from entities in a different one; and
ensures that the NF discovery and registration requests are authorized. At the service producer-consumer level, each NF
validates the incoming messages, where invalid messages according to the protocol specification and network state are
rejected/discarded [i.5]. This validation typically involves checking a JSON Web Token (JWT) based on the OAuth2.0
framework, which the consumer obtains from the NRF.
The SBA in 5G considers two options for the communication between NF service consumers and producers, namely,
direct- and indirect communication. As the name suggests, while two NFs are able to send messages to directly each
other in the direct communication mode, in case of indirect communication the communication takes place via an
in-between entity called Service Communication Proxy (SCP).
NOTE 1: The SCP centralizes functions like load balancing, routing, and delegate discovery (where the SCP queries
the NRF on behalf of the consumer), simplifying the logic required in each individual NF.
More specifically, when using direct communication, an NF service consumer sends a service discovery request to the
NRF using the Nnrf_NFDiscovery service. After having received the necessary information about the producer of the
requested service (and the NF instance producing it), the corresponding service is invoked by sending messages directly
to the NF service producer. When the communication takes place indirectly, then the SCP is responsible for routing
messages between the service consumer and producer. The SCP is sometimes implemented in a distributed manner
(e.g. there can be multiple SCPs between the service consumer and producer NFs).
NOTE 2: An NF is configured with its serving SCP(s).
4.2 Open-Source Multi-Agent Frameworks and Communication
Mechanisms
4.2.1 Introduction
AI Agents are software applications that utilize Large Language Models (LLMs) to interact with humans (or other AI
Agents) for purposes of performing tasks [i.11]. While an LLM provides the core capacity for language understanding,
reasoning, and generation, an AI Agent is more accurately defined as a software entity that encapsulates this cognitive
core within a broader system, enabling it to perceive its environment, make autonomous decisions, and execute actions
to achieve specified goals.
The transition from a simple LLM-powered application to a true AI Agent is marked by the introduction of several key
architectural components and capabilities. Foremost among these are planning and reasoning faculties dedicated to the
strategic use of available resources. These resources are not limited to internal knowledge but extend to a diverse array
of external utilities, including software tools, Application Programming Interfaces (APIs) for accessing web services
and databases, and extensive document corpuses for retrieval-augmented generation. The agent's defining characteristic
is its ability to formulate a plan, select the appropriate tool for a given sub-task, execute that tool, observe the outcome,
and reason about the next step in a cyclical process. This iterative loop of thought and action moves the system from a
passive, input-output mechanism to a proactive, goal-oriented problem solver.
While single-agent systems represent a powerful paradigm, their capabilities are inherently bounded. As the complexity
of tasks increases, a single agent sometimes encounters significant bottlenecks. These limitations include a finite
context window, which restricts the amount of information the agent holds in its working memory, and the challenge of
effectively selecting from an ever-expanding suite of tools, which leads to poor or inefficient decision-making. Multi-
Agent Systems (MASs) have emerged as a direct architectural response to these challenges, designed to solve problems
that are beyond the capacity of any individual agent.
The following clauses provide a brief overview of existing open-source frameworks to implement Multi-Agent Systems
(MASs) and discuss different topologies and patterns for agent-to-agent communication within a MAS.
ETSI
11 ETSI GR ENI 056 V4.1.1 (2025-10)
4.2.2 Overview of Existing Multi-Agent Frameworks
Multi-agent frameworks have emerged as powerful tools for developing complex AI systems, enabling multiple agents
to collaborate and solve tasks beyond the capabilities of individual models. There are various open-source frameworks
available to implement multi-agent systems. Some prominent examples are AutoGen, CrewAI, and LangGraph. Each
framework offers unique strengths, catering to different needs in multi-agent system development.
AutoGen focuses on a multi-agent conversation framework where agents communicate with each other to accomplish
tasks. Its core philosophy is that complex tasks are orchestrated and automated by framing them as structured dialogues
between a collection of capable, customizable, and "conversable" agents. This approach simplifies the development of
complex LLM workflows by abstracting them into automated chats. These agents are conversable, customizable, and
are able to integrate LLMs, humans, and tools. It supports both static and dynamic conversations, allowing for flexible
interaction patterns based on the workflow. AutoGen emphasizes human involvement, enabling human feedback and
judgment in the decision-making process. This is particularly useful for tasks requiring human oversight.
CrewAI is another example of open-source multi-agent frameworks. CrewAI is an open-source Python framework
designed to facilitate the creation of autonomous AI agent teams that collaborate on complex tasks. Its core philosophy
is built around the intuitive and powerful metaphor of a "crew" of agents working together, much like a human project
team or a company with specialized departments. This approach emphasizes role-based agent design, where each agent
is defined by a specific role, a clear goal, and a detailed backstory. These narrative elements are not merely descriptive;
they serve as a form of meta-prompting that guides the agent's behaviour, decision-making, and collaborative style.
CrewAI organizes agents into roles with specific goals and tools. It uses event-driven workflows to manage agent
interactions dynamically, while supporting conditional logic and state management. In contrast to AutoGen, which
integrates human feedback more prominently, CrewAI focuses more on autonomous agent collaboration.
LangGraph is an open-source AI agent framework built on top of LangChain, designed to create, deploy, and manage
complex generative AI workflows. LangGraph is an open-source library, built by the creators of LangChain, designed
to orchestrate agentic and multi-agent workflows by modelling them as cyclical graphs. This graph-based paradigm is a
direct and powerful response to the inherent limitations of the linear, sequential execution models (or "chains") that
characterized early LLM applications. Many complex reasoning processes, such as chain-of-thought or ReAct (Reason
and Act) patterns, are naturally cyclical. LangGraph provides the primitives to build these cycles explicitly, enabling
more flexible, robust, and sophisticated agent behaviours. It utilizes a graph-based architecture, where workflows are
structured as directed graphs consisting of nodes and edges. In LangGraph, workflows are modelled as graphs, enabling
branching, looping, and conditional logic. This makes it ideal for handling complex interactions and dynamic decision-
making. LangGraph also supports running multiple tasks simultaneously for a more efficient workflow execution.
Agent Development Kit (ADK) is an open-source, flexible, and modular framework designed to simplify the creation,
orchestration, evaluation, and deployment of AI agents. It is model-agnostic and deployment-agnostic, allowing
integration with various frameworks and environments. It is a code-first toolkit designed to bring the discipline and
practices of traditional software development to the world of AI agents. It provides a flexible and modular framework
for defining agent logic, tool integrations, and orchestration directly in code (primarily Python, with Java support as
well), emphasizing crucial software engineering principles like testability, versioning, and modularity.
Each of these frameworks supports a large variety of existing LLMs, such as GPT-4, Llama3, and Mistral. Table 4.2.2-1
compares these four multi-agent frameworks.
ETSI
12 ETSI GR ENI 056 V4.1.1 (2025-10)
Table 4.2.2-1: Comparison of AutoGen, CrewAI, LangGraph, and ADK
Feature AutoGen CrewAI LangGraph ADK
Multi-Agent Autonomous Agent Stateful Graph-Based Code-First Software
Philosophy
Conversation Teams Workflows Engineering
A cyclical graph of Agents as modular,
Conversable agents A "crew" of agents with
Primary nodes (agents or testable software
engaging in defined roles, goals, and
Abstraction
functions) and edges components defined
automated "chats" tasks
(control flow) directly in code
Balances both;
supports dynamic, High developer control; High developer control;
Offers a dual model:
LLM-driven the graph structure and promotes deterministic
Control vs. Crews for high autonomy
conversations but conditional edges need logic and orchestration,
Autonomy and Flows for granular,
allows for to be explicitly defined treating agents as
event-driven control
human-in-the-loop by the developer. versioned code assets.
control
Internal External Interoperability:
Internal Orchestration: Internal Orchestration:
Orchestration: Natively supports the A2A
Manages collaboration Models agent
Communication Focuses on patterns protocol for
within a crew via interactions as state
Model
like group chat and communication between
sequential or parallel transitions within a self-
nested chat within a disparate, remote agent
processes contained graph
single system systems
Seamless
Explicit, cyclical, and
human-in-the-loop Intuitive role-playing The A2A protocol for
stateful graph
Key integration and metaphor and the duality building open,
architecture enabling
Differentiator dynamic of autonomous Crews interoperable, and
durable and observable
conversational vs. controlled Flows distributed agent services
execution
patterns
Interactive problem-
Business process Complex, long-running
solving, tasks Building enterprise-grade,
automation, modelling tasks, workflows
requiring human standalone agentic
real-world teams, requiring robust error
Ideal Use Cases oversight, rapid microservices intended to
applications requiring a handling and looping,
prototyping of collaborate with external,
balance of creativity and applications needing
conversational multi-vendor systems
structure deep observability
agents
4.2.3 Multi-Agent Communication Mechanisms
Multi-Agent Communication Patterns
AutoGen mentions different multi-agent conversation patterns (depicted in Figure 4.2.3-1):
• Two-agent chat: considers two agents that exchange messages one-after-another, i.e. first Agent A then
Agent B. An example of the two-agent chat pattern is a customer support scenario where a client and a
specialist communicate.
• Sequential chat: involves a sequence of chats between two or more agents. This pattern extends the two-agent
chat by chaining multiple conversations together. It is designed for tasks with interdependent steps. This
approach is particularly useful for tasks requiring a sequence of inter-dependent multi-agent conversations
(i.e. when they have to run one after the other). An example of a sequential chat is when Agent A tells Agent B
"Retrieve pointcloud data of Central Park" followed by Agent A requesting Agent C to "Plot a 3D map based
on the pointcloud data". Note that the second task depends on the result of the first one.
• Nested chat: According to this pattern, one agent holds the current conversation while invoking conversations
with other agents depending on the content of the current message and context. This is useful for creating a
hierarchical structure of agents, as the nested agents are not allowed to communicate directly with other agents
outside the same group.
ETSI
13 ETSI GR ENI 056 V4.1.1 (2025-10)
• Group chat: Involves more than two agents in a single conversation thread, sharing the same context. Each
agent participating in the group chat is typically specialized for a particular task, such as a 'code generator',
'code reviewer', and a 'code executor'. In a group chat pattern, the agents do not talk directly with each other.
Instead, everything is managed by the 'Group Chat Manager', which is a special agent that uses an LLM to
orchestrate the conversation flow. The group chat manager selects an agent from the group as the "speaker",
and then the speaker agent talks to the manager. The manager then broadcasts the message to all agents and
chooses the next speaker. Therefore, group chat follows a publish-subscribe communication model, where
each participating agent is a publisher and a subscriber of the same topic with the manager serving as the
message broker.
Figure 4.2.3-1: Visualization of two-agent chat, sequential chat and nested chat patterns
The communication pattern plays an important role in determining the performance of a MAS. For a given task, the
MAS with different conversation patterns may output different results. Therefore, it is important to design the
customized conversation patterns for various network services.
Multi-Agent Topologies
LangGraph mentions different multi-agent topologies that are used to design and implement multi-agent systems. In the
following, each AI agent is represented as a graph node, where the agent-to-agent messages are passed from one graph
node to another. The following content does not necessarily imply a distributed implementation where nodes (i.e. AI
Agents) are physically decoupled from each other, meaning, they are running on different machines. On the contrary, it
studies different multi-agent topologies from a conceptual point-of-view, without diving deep into technical
implications, which are discussed later in clause 6, when the agent-to-agent communication implies actual data
transmission between different network nodes.
Single Agent: For completeness, the simplest topology possible is considered when there is only a single agent.
Figure 4.2.3-2a) shows that the AI agent has an LLM inside, which is the sub-component of an AI agent making it an
intelligent system that solves various complex tasks. Moreover, an AI agent has multiple tools that are available to be
called to assist task execution and output generation (e.g. web search tool). No agent-to-agent communication takes
place in this topology.
Network: As depicted in Figure 4.2.3-2b), when each AI agent can directly talk to all other AI agents in the multi-agent
system, then this is called the "network" topology. This is similar to "complete graph" from graph theory, where each
pair of distinct vertices is connected by a unique edge.
Supervisor: The supervisor topology is illustrated in Figure 4.2.3-2c) which contains a supervisor agent deciding which
agent needs to be called next. This means the supervisor agent is operating as a task scheduler and handoffs to other
agents. The agents that are not in the supervisor role are allowed to only communicate with the supervisor agent, which
corresponds to the "star topology" from graph theory. This pattern is highly effective for task delegation where a central
intelligence is needed to orchestrate the workflow. It is analogous to AutoGen's GroupChatManager and is
implemented in LangGraph by having a supervisor node that uses conditional edges to route to the appropriate worker
node. The decision mechanism is implementation-specific, ranging from a turn-based policy like round robin or a more
advanced policy that utilizes the LLM of the supervisor agent. A special case of this is using a t
...