ETSI GR ZSM 020 V1.1.1 (2026-01)

Zero-touch network and Service Management (ZSM); Study on the Utilization of Agents in Autonomous Networks

DGR/ZSM-020_GRonAgents

General Information

• Status: Not Published
• Technical Committee: ZSM - Zero-touch network and Service Management
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 04-Feb-2026
• Completion Date: 28-Jan-2026

Standards Content (Sample)

–
GROUP REPORT
Zero-touch network and Service Management (ZSM);
Study on the Utilization of Agents in Autonomous Networks
Disclaimer
The present document has been produced and approved by the Zero-touch network and Service Management (ZSM) 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 ZSM 020 V1.1.1 (2026-01)

Reference
DGR/ZSM-020_GRonAgents
Keywords
agents, AI
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 2026.
All rights reserved.
ETSI
3 ETSI GR ZSM 020 V1.1.1 (2026-01)
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 Multi-Agent Systems . 8
4.1 Introduction to Agents . 8
4.1.1 Concept of Agent . 8
4.1.2 Agent Taxonomy . 8
4.2 Overview of Multi-Agent Systems . 9
4.2.1 Communication in Multi-Agent Systems . 9
4.2.2 Industry References . 9
4.3 Agents in the ZSM Framework . 9
4.3.1 Agent Entity . 9
4.3.2 Multi-Agent Systems in ZSM . 10
5 Zero-touch automation scenarios using multi-agent systems . 11
5.1 Agent Capabilities Registration and Discovery . 11
5.1.1 Description . 11
5.1.2 Scenario details for centralized registration . 12
5.1.3 Scenario details for de-centralized agent advertisement . 12
5.1.4 Group-based Agents Registration and Discovery . 12
5.2 Cross-domain fault resolution using E2ES MD cross-domain agent . 13
5.2.1 Description . 13
5.2.2 Cross-domain fault resolution with E2ES MD cross-domain agent . 13
5.3 Autonomous Agents Negotiation . 14
5.3.1 Description . 14
5.3.2 Task Negotiation process . 14
5.3.3 Task Execution Information Phase . 15
5.4 Agent-based Dynamic Workflow . 16
5.4.1 Description . 16
5.4.2 Collaboration and coordination. 16
5.4.3 Dynamic workflow using agents and a workflow coordinator . 17
5.5 Terminology Alignment between Agents . 17
5.5.1 Description . 17
5.5.2 Cross-Domain Terminology Alignment for Agent Communication . 18
6 Importance of Communication in Multi-Agent Systems . 18
6.1 Agent Communication Models . 18
6.1.1 Introduction to Communication Models . 18
6.1.2 Peer-to-Peer Communication . 19
6.1.3 Publish/Subscribe Communication . 19
6.1.4 Multicast-Group Communication . 20
6.2 Agent Interaction and Coordination . 20
6.2.1 Identity Management for Agents . 20
6.2.2 Task Delegation and Escalation . 21
6.2.3 Negotiation and Collaboration . 21
6.2.4 Conflict Resolution . 22
6.3 Agents Organization . 23
ETSI
4 ETSI GR ZSM 020 V1.1.1 (2026-01)
6.3.1 Agent Capability Profile . 23
6.3.2 Agent Registry: Registration and Discovery of Agents . 23
6.4 Knowledge Sharing between Agents . 24
6.4.1 Key Concepts . 24
6.4.2 Memory Structures in Autonomous Agents . 24
7 Potential new ZSM Capabilities to support Multi-Agent Systems. 25
7.1 General Capabilities . 25
7.1.1 Agent Management Capabilities . 25
7.1.2 Agent Capability Profile Capabilities . 26
7.1.3 Registration and Discovery Capabilities . 26
7.1.4 Identity Management Capabilities . 26
7.1.5 Interaction Capabilities . 27
7.1.6 Knowledge Sharing Capabilities . 27
7.1.7 Agent Teams Capabilities . 28
7.1.8 Terminology Alignment Capabilities . 28
7.2 Recommendations for Normative work . 28
Annex A: Change history . 30
History . 32

ETSI
5 ETSI GR ZSM 020 V1.1.1 (2026-01)
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) Zero-touch network and
Service Management (ZSM).
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 ZSM 020 V1.1.1 (2026-01)
1 Scope
The present document provides a comprehensive review on the definition of agents, how agents can be used for network
and service management and how they can fit in the ZSM framework. To achieve this, the focus was on use cases
involving agents for network and service management and on multi-agent communication use cases.
As autonomous technologies continue to advance, the use of autonomous agents for network and service management
becomes relevant.
In addition, effective communication between agents is important for coordinating tasks, sharing knowledge, and
optimizing performance across various applications. The present document reviews its applicability for zero-touch
network and service management.
By analysing existing frameworks and methodologies, the present document provides recommendations of additional
capabilities needed in the ZSM framework to support utilization of agents.
Collaboration with other SDOs (e.g. in IRTF NMRG, ITU-T SG13, TM Forum) is recommended when appropriate.
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] Stuart Russell and Peter Norvig: "Artificial Intelligence - A Modern Approach", Fourth Edition.
[i.2] ETSI GS ZSM 009-1: "Zero-touch network and Service Management (ZSM); Closed-Loop
Automation; Part 1: Enablers".
[i.3] Google for Developers: "Announcing the Agnt2Agent Protocol (A2A)", R. Surapaneni, M. Jha, M.
Vakoc, T. Segal.
[i.4] V. Pandey: "Building the Internet of Agents: Introducing AGNTCY.org".
[i.5] ETSI GS ZSM 016: "Zero-touch network and Service Management (ZSM); Intent-driven Closed
Loops".
[i.6] ETSI GR ZSM 011: "Zero-touch network and Service Management (ZSM); Intent-driven
autonomous networks; Generic aspects".
[i.7] ETSI GR ZSM 009-3: "Zero-touch network and Service Management (ZSM); Closed-Loop
Automation; Part 3: Advanced topics".
[i.8] ETSI GS ZSM 002: "Zero-touch network and Service Management (ZSM); Reference
Architecture".
[i.9] ETSI GS ZSM 014: "Zero-touch network and Service Management (ZSM); ZSM security
aspects".
ETSI
7 ETSI GR ZSM 020 V1.1.1 (2026-01)
[i.10] Xiao, Y., Shi, G., Zhang, P.: "Towards Agentic AI Networking in 6G: A Generative Foundation
Model-as-Agent Approach", March 2025.
[i.11] Dev, K., Khowaja, S. A., Singh, K., Zeydan, E., Debbah, M.: "Advanced Architectures Integrated
with Agentic AI for Next-Generation Wireless Networks", February 2025.
[i.12] Arzo, S. T., Scotece, D., Bassoli, R., Granelli, F., Foschini, L., Fitzek, F.H.P.: "A New Agent-
Based Intelligent Network Architecture", November 2022.
[i.13] Chen, W., You, Z., Li, R., Guan, Y., Qian, C., Zhao, C., Yang, C., Xie, R., Liu, Z., Sun, M.:
"Internet of Agents: Weaving a Web of Heterogeneous Agents for Collaborative Intelligence",
July 2024.
[i.14] CrewAI: "The Leading Multi-Agent Platform".
[i.15] LangGraph: "Balance agent control with agency".
[i.16] LangChain: "Engineer reliable agents".
[i.17] Sumers, T.R., Yao, S., Narasimhan, K., Griffiths, T.L.: "Cognitive Architectures for Language
Agents", March 2024.
[i.18] ETSI GS ZSM 007: "Zero-touch network and Service Management (ZSM); Terminology for
concepts in ZSM".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS ZSM 007 [i.18] and the following apply:
autonomous agent: intent-driven, autonomous AI entity designed to perceive its environment, analyse information using
the agent's existing knowledge, make decisions also based on this knowledge and execute actions to achieve predefined
goals described in the intent with minimal to no human intervention, as well as continuously learning and adapting its
behaviours based on the changing conditions in the environment
task: element of operational management that the ZSM framework aims to automate entirely
NOTE 1: A task is typically realized programmatically as an action, operation, or complex workflow performed by
underlying management functions or management services.
NOTE 2: In the context of the present document, task represents a structured unit of work that one autonomous
agent delegates to another. It provides a persistent, trackable, and stateful context for asynchronous long-
running collaborations between agents, ensuring clarity, disambiguation, and accountability.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS ZSM 007 [i.18] and the following apply:
CLA Closed-Loop Automation
IME Intent Management Entity
LLM Large Language Model
MAS Multi-Agent System
MnS Management Service
OASF Open Agent Schema Framework
URI Unified Resource Identification
ETSI
8 ETSI GR ZSM 020 V1.1.1 (2026-01)
4 Multi-Agent Systems
4.1 Introduction to Agents
4.1.1 Concept of Agent
In its simplest form, an agent is anything that can be viewed as perceiving its environment through sensors and acting
upon that environment through actuators in order to achieve a goal [i.1].
In the context of zero-touch network and service management, the definition of the autonomous agent can be found in
clause 3.1. This definition emphasizes a number of capabilities already described for the Closed-Loop Automation
(CLA) [i.2], with the implication that agents realize one or multiple close control loops with the combination and
chaining of management services (monitoring, analytics, decision-making and execution). Consequently, agents are
able to constantly monitor and assess the state of the network and services and take corrective actions when the goals of
the agent are not fulfilled. Moreover, this definition highlights that agents are capable of interpreting declarative intents
and autonomously selecting actions and decisions to fulfil the goals described in the intents. The definition also stresses
the importance of self-learning and the adaptability of the agent based on the changing conditions in the environment.
The focus of the present document is to discuss the interoperability between these agents within the scope of ZSM
framework, including agents running within the same domain and in different domains. The interactions between agents
and external entities such as human operators are also considered, as this is important for the gradual increase of
autonomy offered by these autonomous agents.
4.1.2 Agent Taxonomy
There are multiple ways to classify agents, based on their capabilities, functionality and other characteristics. Possible
classifications include:
• By Decision-Maker:
- Human as Decision-Maker. These agents (also known as Copilots) function primarily as augmentation
tools for human operators, providing decision support, insights, and execution capabilities while
maintaining the human as the primary control entity.
- Agent as Decision-Maker. These agents possess decision-making capabilities and can independently
analyse situations and formulate response strategies. There could be further classified into:
 Supervised autonomous agents: These agents incorporate human or other agent oversight
checkpoints where operator verification, adjustment, or explicit approval is required before critical
actions are implemented.
 Fully autonomous agents: These advanced agents operate with complete operational independence,
continuously monitoring environments, analysing conditions, making decisions, and executing
actions without human intervention. They leverage comprehensive knowledge bases and adaptive
learning mechanisms to handle complex scenarios independently, enabling true zero-touch
operations. Fully autonomous agents could also trigger "actions" to be executed by supervised
autonomous agents.
• By functionality: According to the function they perform in the Management Domain (MD) such as managing
faults and network changes or optimizing the network. Examples could include: Fault Management Agent,
Network Change Agent, Quality Optimization Agent, Energy Efficiency Optimization Agent and Network
Deployment Agent.
• Based on the type of actions they perform, e.g. recommender agent (provides recommendations), analyser
agent (analyses data), configuration agents (use apis to change configs in the network), etc.
ETSI
9 ETSI GR ZSM 020 V1.1.1 (2026-01)
4.2 Overview of Multi-Agent Systems
4.2.1 Communication in Multi-Agent Systems
A Multi-Agent System (MAS) is a system composed of multiple interacting, autonomous agents, each capable of
perceiving its environment, making decisions, and taking actions to achieve individual or collective goals. These agents
can work independently or collaboratively, often engaging in coordination, negotiation, or competition to solve complex
problems or accomplish tasks.
Communication is a central element in a MAS, as it enables interaction, collaboration, and coordination among agents
that operate autonomously. Through communication, agents exchange information about their environment, share
knowledge, advertise capabilities, negotiate fulfilment of tasks, and coordinate actions to achieve collective results. In
this context, communication does not merely serve as a means to transmit data but functions as the foundation for
distributed intelligence. It allows agents to establish shared situational awareness, align operational objectives, and
maintain coherence in decision-making.
4.2.2 Industry References
The AI agent ecosystem has experienced significant momentum in recent months with multiple industry initiatives
launching open standards for multi-agent communications. The AGNTCY coalition [i.4], established in early 2025 has
introduced a comprehensive framework for agent interoperability. This open-source initiative develops standardized
protocols enabling diverse AI agents to discover, communicate, and collaborate across platforms. Concurrently, Google
released its Agent2Agent (A2A) protocol on April, 2025 [i.3], providing an alternative open standard for agent
communication. Backed by over 50 major technology partners, A2A standardizes how autonomous agents discover and
interact with one another using familiar web technologies like HTTP and JSON. The protocol enables agents to
advertise their capabilities, exchange structured information, and coordinate actions regardless of their underlying
frameworks or vendors.
These complementary initiatives reflect the industry's recognition that standardized agent communication protocols are
essential for realizing the full potential of multi-agent systems in enterprise environments, where specialized AI agents
often operate in isolation due to interoperability challenges.
4.3 Agents in the ZSM Framework
4.3.1 Agent Entity
As explained in clause 4.1, the agent entity realizes one or multiple closed loops and it is capable of interpreting
declarative intents. The concepts of close loop and Intent Management Entity (IME) are fully described in ETSI
GS ZSM 009-1 [i.2] and ETSI GR ZSM 011 [i.6] respectively. This is shown in Figure 1.
ETSI
10 ETSI GR ZSM 020 V1.1.1 (2026-01)

Figure 1: Agents in ZSM Framework
Figure 1 illustrates how the agent implements the CLA capability, which is a core component of the ZSM framework.
Thus, the agent is capable of constantly monitor the network, analyse, make decisions and execute those decisions when
the goals that were provided to the agent via the intent are not fulfilled.
As defined previously, the autonomous agent is continuously learning and adapting its behaviours to changing
conditions in the environment. The concept of cognitive loops was introduced in ETSI GR ZSM 009-3 [i.7], where it
was described that closed-loops may be logically partitioned into two interacting internal loops: a Cognitive Loop and
an Operational Loop. The cognitive loop enables self-learning by analysing the outcomes of actions executed by the
operational loop, and thus provides the agent with its learning and adaptive capabilities.
4.3.2 Multi-Agent Systems in ZSM
The agents in a MAS need to communicate and share information. The focus of the present document is to report on the
standardization requirements for these agents to discover their capabilities, communicate with, and work alongside each
other. These standardization requirements are among agents operating within the same or in different MDs within the
ZSM Framework.
Figure 2 illustrates the architecture of the ZSM framework, focusing on the integration of agents across multiple
Management Domains (MDs) and the role of cross-domain communication. It highlights how agents operate within
individual domains and collaborate across domains to achieve end-to-end service automation. Figure 2 also highlights
the use of an Agent Registry, where agents can register their capabilities. This registry facilitates capability discovery
by enabling agents to identify and interact with neighbouring agents, allowing for efficient collaboration across
domains.
ETSI
11 ETSI GR ZSM 020 V1.1.1 (2026-01)

Figure 2: Agents in the ZSM Framework
NOTE: The agent registry is a management function that could be provided as part of the integration fabric,
similar to how management service registration is handled, or as part of the cross-domain data services.
As show in Figure 2, the agent entity is the element within the ZSM framework providing the management services for
agent communications. It produces management services to receive communication from other agents or authorized
ZSM consumers and it consumes management services to send communication to other agents or ZSM entities.
5 Zero-touch automation scenarios using multi-agent
systems
5.1 Agent Capabilities Registration and Discovery
5.1.1 Description
In order to enhance interaction and collaboration among agents, it should be possible for agents to register or advertise
their capabilities so that they can be discovered by other agents.
Currently, there is no industry-wide consensus on a standardized method for describing agent capabilities:
• A2A [i.3]: Agents can advertise their capabilities using an "Agent Card" in JSON format, allowing the client
agent to identify the best agent that can perform a task and leverage A2A to communicate with the remote
agent.
• Agntcy [i.4]: Open Agent Schema Framework (OASF) provides a standard form in which the identity and
capabilities of an agent can be described in a vendor and platform agnostic manner. It provides a common,
interoperable agentic definition which can be used for describing and discovering agents and multi-agent
software.
ETSI
12 ETSI GR ZSM 020 V1.1.1 (2026-01)
Similarly to ETSI GS ZSM 016 [i.5], where the IME profile was introduced, it is proposed the usage of an Agent
Capability Profile that describes at least:
• The agent means of communication.
• The management domain of the agent.
• Agent capabilities.
5.1.2 Scenario details for centralized registration
A precondition of this use case is that there is an agent registry that can be accessed by authorized consumers (note that
an authorized consumer may only have access to some of the agent details in the registry).
The present clause describes the detailed steps that an agent should follow to use the registration and discovery
capabilities of the ZSM Framework:
1) An agent will use a registration/deregistration MnS for the registration/de-registration of its agent profile.
2) Once registered, the agent registry may optionally advertise the registered agents' capabilities.
3) An agent will use a discovery MnS for agents for the discovery of registered agents and the means to access
them, supporting both synchronous and asynchronous communication mechanisms.
5.1.3 Scenario details for de-centralized agent advertisement
A precondition of this use case is that there is a mechanism for agents to advertise their existence to other authorized
consumers.
The present clause describes the detailed steps that an agent may use to advertise their existence to other agents in the
ZSM Framework:
1) The agent will use an advertisement capability (such as using a publish/subscribe communication mechanism)
to inform other agents about its profile.
2) Another agent will use an agent discovery MnS to query additional information from the agent that advertised
its existence if necessary.
5.1.4 Group-based Agents Registration and Discovery
In multi-agent environment, agents can register themselves with different functionality or capability. As described in
clause 4.1.2, agents can be classified in several dimensions:
• By Decision-Maker, depending on the role of the agent.
• By functionality, assigning the agent to different functional scenario.
• By the type of actions, which correspond to specific capabilities the agent has.
When agents need to collaborate, discovering the correct target agents becomes challenging due to mismatching in
agent descriptions. For example: Agent A from one MD domain registers itself based on functionality (e.g. as a Fault
Management Agent), while Agent B from a different MD domain registers itself based on capability (e.g. as an
Analyzer Agent). The mismatch of terminology and granularity makes it difficult for Agent A to discover Agent B in
cross-domain fault handling collaboration task.
Therefore, the agent registration can be further expanded by including an Agent Grouping Mechanism to enhance the
efficiency of registration and discovery among agents. For example, a registry owner may pre-define a set of "Agent
Groups" and at registration time an agent may choose which groups it should belong to. An example would be a
Functional Scenario Agent Group, with the possible values of Fault Management, Quality Optimization and Energy
Efficiency to be selected at registration time.
ETSI
13 ETSI GR ZSM 020 V1.1.1 (2026-01)
Agent Groups can be created by different categories including by capability (e.g. "analytical capability"), by scenario
(e.g. "Fault Diagnosis scenario") and by role ("Human Decision") in registry. Agents from different domains or vendors
can choose any of these Agent Groups at registration time.

Figure 3: Basic Interaction Flow for Group based Registration
1) Registry pre-creates AgentGroups based on business scenarios or capabilities.
2) Agent sends discovery request to the Registry to retrieve AgentGroups information.
3) Registry responses to the Agent with the list of AgentGroups information.
4) Agent determines which AgentGroups to join based on the business scenarios or capabilities that are supported
by both itself and the target groups, as reflected in the AgentGroups information. If there are no suitable
AgentGroup the Agent can create a new one dynamically, and register it to Registry with the next Agent
registration step.
5) Agent sends a registration request to the Registry, applying to join the AgentGroups selected. If the
AgentGroup is dynamically created by the Agent, the Registry will first complete the registration of it.
6) Registry responses for agent register.
5.2 Cross-domain fault resolution using E2ES MD
cross-domain agent
5.2.1 Description
This use case demonstrates how multiple agents collaborate within the ZSM framework, which supports agent
capability registration and discovery as explained in the previous use case. The scenario focuses on the escalation of a
fault detected in one MD, leading to the formation of a cross-domain investigation team of agents led by the E2ES MD
agent to resolve the issue.
The actors for this use case include multiple MD fault agents which can detect faults in their own domain and perform
additional analysis on the status of the network when requested and E2ES MD agent which coordinates activities across
multiple MDs and forms teams for complex, cross-domain issue resolutions.
5.2.2 Cross-domain fault resolution with E2ES MD cross-domain agent
Preconditions
• All agents have registered their capabilities in a centralized agent registry using standardized profiles and the
agent registry supports discovery of agent profiles and capabilities to ZSM authorized consumers (centralized
scenario).
• Agents can advertise their existence and capabilities to other existing agents, and discovery mechanisms are in
place for agents to enquire additional information from advertising agent (decentralized scenario).
ETSI
14 ETSI GR ZSM 020 V1.1.1 (2026-01)
The present clause describes the detailed steps that agents will execute:
1) Fault Detection by one MD agent: The fault agent of a MD, detects a persistent fault affecting its domain.
After analysing the fault, the agent determines that the root cause may extend beyond its own domain.
NOTE 1: An example would be a wireless MD detecting a fault that affects the wireless service quality but the
source of the fault is in a transmission MD which provides backhaul connectivity for the wireless MD.
2) Capability Discovery and Escalation: The agent from the MD that has the fault queries the agent registry
(centralized use case) or other existing agents (decentralized use case) to discover agents capable of handling
cross-domain issues. It then identifies a E2ES MD cross-domain agent as having the necessary coordination
and investigation capabilities. The MD agent escalates the fault to the cross-domain E2ES MD agent,
providing detailed context and diagnostic data.
3) Cross-Domain Agent Forms Investigation Team: The E2ES MD cross-domain agent receives the escalation
and analyses the fault context. It queries the registry (centralized use case) or other existing agents
(decentralized use case) to identify and select additional agents with relevant expertise based on their
capabilities and it forms an investigation team.
NOTE 2: For the example of the wireless MD being affected by the transmission MD, the cross-domain agent will
form a team comprising at least one agent from the wireless MD, one agent from the transmission MD
and the E2ES MD cross-domain agent.
4) Collaborative Investigation and Resolution: Using the communication means specified in their capability
profile, the E2ES MD cross-domain agent coordinates the investigation and assigns tasks to the rest of the
agents in the investigation team. These tasks may include remediation actions across different domains.
NOTE 3: The task assignation process may include a negotiation stage where agents will agree about the task
details and completion details.
5) Post-Resolution Actions: Once the fault is fully identified or resolved, the E2ES MD cross-domain agent
provides feedback to all agents that were part of the investigation team.
5.3 Autonomous Agents Negotiation
5.3.1 Description
This use case describes how autonomous agents negotiate the assignment of tasks among themselves. Unlike static
allocation models where tasks are pre-assigned based on predefined rules, negotiation enables agents to dynamically
determine the most suitable executor for a given task.
The negotiation process allows agents to self-organize by factoring in agent capabilities, resource availability,
performance history, costs, and priorities. Through structured communication, agents propose, bid, or decline tasks until
an agreement is reached. This results in more efficient and adaptive task distribution, especially in environments subject
to change, uncertainty, or resource constraints.
5.3.2 Task Negotiation process
Preconditions
• Agents are discoverable, and their capabilities can be dynamically queried.
• Agents can exchange information securely and reliably.
• Agents have defined decision models (e.g. utility functions, constraints, preferences) to guide negotiation.
• External inputs such as an operator intent are available to influence negotiation outcomes (e.g. cost thresholds,
fairness criteria, service-level parameters).
• Agents should provide an interface for negotiation.
ETSI
15 ETSI GR ZSM 020 V1.1.1 (2026-01)
The detailed steps for this use case are the following:
1) Task Initiation: An initiating agent identifies a task or set of tasks that require execution.
2) Candidate Identification: Using agent capability discovery, the initiating agent identifies potential agents
capable of executing the task.
3) Negotiation: Initiating agent provide task details to potential agents, who in return communicate back their
willingness, constraints, or costs for executing the task. The initiating agent may compare proposals based on
capability fit, efficiency, cost, reliability, or other defined metrics. There could be several rounds of
communication during the negotiation phase.
4) Agreement Formation: The selected agent formally accepts execution responsibilities, including agreed
parameters such as time, quality, or resource use.
5) Task Execution: The task is executed by the assigned agent, with progress updates provided as agreed.
6) Completion and Confirmation: Upon success (or failure), results are confirmed to the initiating agent.
7) Post-process Analysis: The negotiation and execution records may be analysed for continuous improvement
(e.g. learning agent preferences, negotiation strategies or improving fairness).
5.3.3 Task Execution Information Phase
In multi-agent systems, agents resolve complex business scenario problems through task mechanisms. For example, an
OSS Agent can assign a cross-domain task (e.g. Base Station fault diagnosis) to domain-specific agents (e.g. IP Fault
Agent), which will accomplish the task based on its autonomous capability.
However, during the task execution, the domain-specific agent may encounter execution abnormal states due to
insufficient contextual information. Taking base station fault diagnosis task as an example, with the internal reasoning
using domain-specific Large Language Models (LLMs), the IP Fault Agent detects that for the task progression, there is
a lack of device configuration and traffic log information from the wireless domain, leading to the task entering a
blocking state or failure state.
To resolve the abnormal states problem encountered during task execution, there should be a task execution information
phase for the multi-agent negotiation mechanism.
Preconditions: Assuming the sam
...