]> Telefonica

diego.r.lopez@telefonica.com

Deutsche Telekom

nathalie.romo-moreno@telekom.de

Orange

lionel.tailhardat@orange.com

Huawei

maqiufang1@huawei.com

Huawei

bill.wu@huawei.com

Huawei

yangyuanyuan55@huawei.com

Nokia

shailesh.prabhu@nokia.com

A2A Network Management This document discusses the applicability of A2A protocol to the network management in the multi-domain heterogeneous network environment that utilizes IETF technologies. It explores operational aspect, key components, generic workflow and deployment scenarios. The impact of integrating A2A into the network management system is also discussed. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction With the advancement of large language models (LLMs), the concept of AI agents has gradually attracted significant attention. An AI agent refers to a category of software applications that utilizes LLMs to interact with users or other agents and accomplish specific tasks. Take a multimodal AI agent as an example, it can collaborate with other domain-specific agents to complete diverse tasks such as translation, configuration generation, and API development. A2A protocol provides a standardized way for AI agents to communicate and collaborate across different platforms and frameworks through a structured process, regardless of their underlying technologies. Agents can advertise their capabilities using an 'Agent Card' in JSON format, or send messages to communicate context, replies, artifacts, or user instructions, which make it easier to build AI applications that can interact with heterogeneous AI ecosystems in specific domains. With significant adoption of AI Agents across the Internet, Agent to Agent Communication protocol may become the foundation for the next wave of Internet communication technologies across domains . The application of A2A in the network management field is meant to develop various rich AI driven network applications, realize intent based networks management automation in the multi-vendor heterogeneous network environment. By establishing standard interfaces for dynamic Capability Discovery, intelligent message routing, heterogeneous AI ecosystems interaction, cross-platform collaboration, A2A enables AI Agents to: o Understand contextual nuances o Negotiate and adapt in real-time o Make collaborative decisions o Maintain persistent, intelligent interactions This document discusses the applicability of A2A to the network management in the multi-domain heterogeneous network environment that utilizes IETF technologies. It explores operational aspect, key components, generic workflow and deployment scenarios. The impact of integrating A2A into the network management system is also discussed.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

• AI Agent: A software system or program that is capable of autonomously performing goals and tasks on behalf of a user or another system.
• Agent Card: A common metadata file that describes an agent's capabilities, skills, interface URLs, and authentication requirements. Clients discover and identify the agent through this file.
• A2A Server: An AI agent that receives requests and performs tasks
• A2A Client: An AI agent that sends requests to servers
• message: An A2A message represents a single turn of communication between a client and a server Agent. A message contains one or more Part objects.
• part: A part object is a granular container for the actual content, which can hold different types of content using exactly one of the following content fields:

Overview of key challenges for the network management As described in , 3 key challenges to apply A2A protocol to network management have been listed: o High Risk Operations of Agent2Agent interaction

• High risk operation can can to large-scale network outages.

o The timeliness requirement of Agent2Agent collaboration

• "Token-based" generation and reasoning approach, limited by computing power and algorithms, result in slow reasoning speeds.
• Task-oriented "request-response" model without event subscription is unlike to meet time constraints for tasks such as fault diagnosis, complaint handling, and user experience improvement.

o The Agent2agent Collaboration Reliability

• Incorrect or outdated network configuration data results in incorrect repair advice when diagnosing network incidents or faults.
• Task collaboration is incomplete or not sufficient to handle strategies such as task rejection, missing information during task collaboration, and failure to achieve task objectives.

Agent2Agent Architecture Design for Network Management

A Reference Agent-to-Agent Architecture for Network Management

As described in , in the multi-agent communication deployment scenario, AI Agents can be deployed at both service layer,network layer and Network Element Level, e.g., both service orchestrator and network controller can introduce AI Agent and allow Agent to Agent communication. Service AI Agent within the service orchestrator can provide registration center for other network AI agents and task agents within the network controller to register its location. In the meanwhile Network AI Agent within the network Controller can provide registration center for task agents at the network level and Network element level AI agent within the smart network element. The interaction in the multi-agent communication deployment scenario can be broken down into:

• AI Agent to Agent interaction
• AI Agent to Tools/APIs/Models interaction

For AI Agent to Tools/APIs/Models interaction, to enable comprehensive functionality (e.g., large AI model and small AI model collaboration, network AI agent and Network element AI agent collaboration for routing protocol troubleshooting), additional protocol extensions are required to address two critical aspects: (1) standardized tool invocation mechanisms for agent-tool/api/model interoperability, and (2) monitoring frameworks for tool usage tracking and auditing. AI Agent to Agent interaction, human operators require a real-time monitoring interface for long-running workflows or tasks requiring continuous supervision with dual capabilities: (1) live network state observation and (2) validation of agent-proposed remediation actions during anomaly resolution scenarios. A general workflow is as follows:

• User Input Submission: An operator submits a natural language request to a Service AI agent.
• Agent Intent Processing: The service AI agent processes natural language inputs by parsing instructions into structured tasks.
• Autonomous Close Loop Workflow Management: The service AI agent decomposing tasks into workflow map with subtasks, and distributes subtasks via an Agent Card Registry to specialized task agents based on their capabilities.
• Task Execution: Iteration continues until all tasks reach executable task agents in the hierarchy.
• Task Report: Task agents report outcomes to the central agent, which dynamically adjusts the workflow based on result analysis and policy rules.

Multi-Agent Orchestration Patterns for Network Management To efficiently coordinate multiple specialized AI Agents across the architecture defined in , different orchestration patterns derived from distributed AI systems may be applied.

Sequential Pipeline The sequential pipeline pattern organizes a complex task into a linear, step-by-step execution sequence where each agent completes its execution and then passes the output to the next agent. This pattern is typically applied within the service or network Level to handle tasks with multiple fixed steps and each step requires different expertise and toolsets. As illustrated in , a configuration generation agent initially translates a network intent to generate network configuration, subsequently handing them over to a configuration validation agent for pre-deployment validation, which finally passes the verified artifacts to a configuration distribution agent for actual deployment. By ensuring that each specialist agent only perceives the direct output of its immediate predecessor, this pattern effectively guarantees deterministic execution workflows for network operations.

An Example Workflow for Sequential Pipeline Config-Validate Agent|----->Config-Dist Agent| +----------------+ +---------------------+ +-----------------+ ]]>

Fan-Out/Fan-in The Fan-Out/Fan-In pattern involves a higher-level coordinator agent that dispatches segmented or decomposed sub-tasks to multiple sub-agents in parallel, subsequently collecting and aggregating the results of sub-agents. In the context of network management, this pattern could be applied between the Service Level and the Network Level to achieve multi-domain end-to-end coordination. As an examaple in , a Service AI Agent acts as the central coordinator that dispatches an end-to-end service provisioning task to an IP Network AI Agent, an Optical Network AI Agent, and a RAN AI Agent at the network layer simultaneously. Once these specialized domain agents execute their parallel tasks, the Service AI Agent gathers and merges their independent results. It is also possible for the service AI agent to deliver an identical task (e.g., a root cause analysis for a network incident) to different domain AI Agents and then combine their results. This pattern significantly mitigates the latency of sequential agentic reasoning and operations.

An Example Workflow for Fan-Out/Fan-in

Supervisor Unlike the Fan-Out/Fan-In pattern which focuses on the static, parallel distribution and aggregation of decomposed sub-tasks, the Supervisor pattern establishes a centralized supervisor agent that maintains the overall workflow planning, and dynamic decides which task agent to invoke based on the real-time execution feedback of individual task agents. This pattern inherently drives cross-layer collaboration or a single-domain network autonomy. As illustrated in , a supervisor Network AI Agent acts as the central brain that fulfills the service assurance intent. Upon receiving a link degradation alert, the supervisor first invokes a Fault Diagnosis Task Agent to identify the root cause. If the diagnosis reports a localized hardware issue, the supervisor dynamically decides to route the task to a Traffic Steering Task Agent to reroute alternative paths. Once the rerouting configuration is applied, the supervisor sequences a Service Verification Task Agent to monitor service statistics. If the statistic metrics indicate that the SLA has still not recovered, the supervisor Network AI Agent dynamically loops back to invoke the diagnosis or steering agents with updated constraints for further iteration. This pattern allows the flexibility necessary for complex, adaptive workflows while keeping the efficiency of underlying agentic reasoning and operations.

An Example Workflow for Supervisor

Peer-to-Peer (P2P) Agents communicate and collaborate directly with each other without a centralized coordinator, using the Agent-to-Agent protocol. The Peer-to-Peer pattern enables AI agents to communicate, negotiate, and collaborate directly with each other without relying on a centralized coordinator or supervisor. This interaction typically manifests in cross-provider or inter-domain scenarios where autonomous boundaries must be respected. For instance, when establishing an end-to-end network service delivery across heterogeneous infrastructure, a Network AI Agent managing Autonomous Domain A communicates directly via the A2A protocol with a peer Network AI Agent managing Autonomous Domain B to negotiate dynamic bandwidth allocation and policy constraints. Network AI Agent| | Domain A | | Domain B | +----------------+ +----------------+ ]]>

YANG-based Structured Data for A2A Communication While the A2A framework natively supports unstructured textual content for agent-to-agent data exchange, network management and operation scenarios usually demand rigorous clarity, unambiguous intent transmission and machine-interpretable data interaction - attributes that natural language cannot reliably provide due to its inherent ambiguity, contextual variability and lack of standardized syntax. Natural language expressions of network operational intent may have incomplete information, leading to incorrect task execution, inconsistent configuration deployment and potential large-scale network outages, which are unacceptable in the high-reliability requirements of network management. YANG , as a standardized data modeling language defined by the IETF for network management, provides a extensible way to structure network management data and operational service and network intent; using YANG-modeled structured data to populate A2A communication payloads could help eliminate the ambiguity of natural language, and align A2A communication with the existing IETF-based network management ecosystem, enabling seamless integration with traditional network management protocols such as NETCONF and RESTCONF . The well-defined hierarchies and structures of YANG data models also enable Agents to quickly parse, validate and process communication data and support the definition of service or network intent for specific multi-domain and multi-vendor heterogeneous network scenarios. In addition, YANG-structured data can serve as a precise supplement to natural language input, where implicit parameters, missing constraints, or detailed operational conditions that are not fully expressed in natural language can be explicitly defined and carried in the YANG data part. The following example illustrates a A2A message with both a YANG-based structured data and natural language parts to balance human readability and machine parse-ability. The message could be sent from a network AI Agent, after receving the intent from the operator to diagnose a specific network incident, to a incident diagnosis task Agent. The data part complies with the Network Incident YANG data model defined in .

Operational Considerations The introduction of A2A-based agent interactions into network management has several operational implications that must be considered when deploying the architecture in large-scale or multi-domain networks. This section highlights key aspects related to performance, scalability, reliability, latency, and agent lifecycle operations.

Agent Skills as Expertise Expansion of AI Agents While AI agents have intelligence and capabilities, they may not always have expertise that we expect when performing specific network management and operation tasks. Agent Skills , introduced by Anthropic, is an open standard that allows developers to package specialized knowledge, workflow, and scripts and empowers a general AI Agent to become an expert in a specified field. Each skill is organized as a seperate folder that consists of a "skill.md" to define the basic information of the skill, and other files such as scripts, reference documents, etc. Agent Skills use progressive disclosure as a design pattern to load these resources to reduce token consumption and use less of the context window. Network operators could encode their domain expertise (e.g., troubleshooting workflow logic for fault scenarios) into structured skills, e.g., by defining the fault_diagnose_link skill to organize the logic of "checking link connectivity -> analyzing error syslogs -> verifying hardware status -> outputting a resolution solution"), it quickly equips AI Agents with domain expertise.

Knowledge Base as Ground Truth Data Another critical operational consideration for Agent-to-Agent (A2A) communication in network management is addressing the hallucination of Large Language Models (LLMs), which primarily stems from knowledge gaps within the models themselves. To mitigate this, a dedicated and machine-interpretable knowledge base can be constructed using unstructured product documents, maintenance manuals, historical fault tickets, network topology diagrams, configuration specifications, and expert experience, etc. The knowledge base enables LLMs to retrieve accurate, network operation and maintenance-specific information for reliable responses while ensuring data privacy and security, supporting domain knowledge plug-in to supplement knowledge Q&A. A shared knowledge base helps eliminate information asymmetry between heterogeneous Agents, ensuring that all Agents across the entire A2A system base their judgments and actions on consistent knowledge standards to avoid miscommunication or inconsistent operations. Throughout the entire A2A operational lifecycle, the knowledge base is not a static resource but a dynamic core that permeates Agent initialization, communication and interaction, task execution, and result feedback, making knowledge base management a prerequisite for effective A2A system operational design. Notably, The emerging Model Context Protocol (MCP) can facilitate the efficient updates and queries of the knowledge base by providing standardized interfaces, and build a standardized external knowledge base for multi-Agent system.

Event-driven Agent to Agent Communication The event-driven Agent to Agent communication enhances the task-based A2A procotol to support proactive and real-time communication based on network events. By leveraging the Message Broker such as Apache Kafka to facilitate the exchange of event messages among different AI agents, it allows the real-time response to maintain network reliability and service assurance in network management and operations. gives an overview of the architecure.

An Architecture for Event-driven A2A AI Agent | | | | | +---+-----+ +-----^----+ | | | Events | Events | +----------------+ | +----------->Messaging topics|--------------+ +----------------+ ]]>

The event-driven extension introduces a publish/subscribe paradigm alongside the primary task-driven interaction. For example, a "Fault Agent" identifies a link failure by data analyzing and publishes a message to the Message Broker, the "recovery agent" subscribes to the topic and it could initiate a task to generate recovery strategies such as link switching and traffic rerouting and submit to the operator for approval upon consuming the message.

Scalability Large operational networks may contain tens of thousands of devices, multiple administrative domains, and a distributed set of controllers and orchestrators. The use of conversational, context-rich A2A messaging increases message volume compared to static RPC-based interfaces such as NETCONF or RESTCONF. Operators should evaluate:

• The number of agents required per domain or per function.
• The expected message growth as workflows involve multiple agents performing negotiation, capability discovery, and state exchange.
• The impact of concurrent multi-agent workflows on control-plane stability.
• Whether hierarchical or federated agent structures are needed to avoid message storms and to localize decisions.

Mechanisms for rate-limiting, backoff, and prioritization may be needed to prevent overload.

Latency and Performance Constraints Task decomposition and negotiation across multiple agents can introduce non-trivial latency, especially when agents rely on external AI inference engines or large language models (LLMs). Operational environments may impose strict timing requirements, for example during:

• Service activation with customer-facing SLAs.
• Fault detection and automated remediation loops.
• Real-time telemetry-driven control such as congestion mitigation.

Implementations should define performance envelopes, including:

• Maximum agent-to-agent message processing latency.
• Timeout and retry behavior for workflow steps.
• Acceptable degradation under load or partial failures.

Fallback mechanisms (e.g., reverting to direct controller APIs or static policies) should be provided when A2A interactions cannot meet timing constraints.

Reliability and Failure Handling A2A workflows may involve long-lived tasks that span multiple agents and systems. Operational networks require predictable and safe behavior under partial failures. Operators should consider:

• How workflow state is checkpointed or restored if an agent becomes unreachable.
• How to detect and mitigate inconsistent or stale agent state.
• Whether workflows can be retried idempotently.
• Requirements for transactionality or rollback comparable to NETCONF confirmed-commit semantics.

Implementations should include mechanisms for workflow monitoring, circuit-breakers, and automatic escalation to human operators in case of sustained failure.

Agent Lifecycle and Resource Management Production deployment of A2A-based systems requires active management of agent lifecycles, including:

• Agent onboarding and registration.
• Updates and model re-training (for AI-driven agents).
• Decommissioning and revocation of compromised agents.
• Resource consumption limits for CPU, memory, and inference workloads.

Operators should maintain visibility into the operational state of all agents and their dependencies, including telemetry on message rates, errors, and workflow completion metrics.

Inter-Domain Operational Challenges In multi-domain scenarios (e.g., between business units, operators, or federated networks), operational concerns are amplified due to:

• Differences in local policies or SLAs.
• Variations in controller capabilities and data models.
• Latency and reliability across administrative boundaries.
• Need for shared or interoperable agent capability descriptions.

Standardized operational practices may be required for agent discovery, trust establishment, conflict resolution, and accountability.

Security Considerations The communication between Agents for the exchange of context information, capability information and user instruction is security sensitive and requires authentication, authorization, and integrity protection. Legacy communication protocols such as HTTPS/TLS, designed for human-centric interactions, simply cannot withstand the high-speed exchanges between intelligent agents. Key security challenges in AI agent communication include:

• Identity Verification: Ensuring that agents are who they claim to be
• Data Integrity: Preventing unauthorized modifications during transmission
• Confidentiality: Protecting sensitive information from potential breaches
• Scalable Security: Maintaining robust protection across diverse and complex networks

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Five9 Cisco AI Agents are software applications that utilize Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. AI Agents can make use of resources - including APIs and documents - to perform those tasks, and are capable of reasoning about which resources to use. To facilitate AI agent operation, AI agents need to communicate with users, and then interact with other resources over the Internet, including APIs and other AI agents. This document describes a framework for AI Agent communications on the Internet, identifying the various protocols that come into play. It introduces use cases that motivate features and functions that need to be present in those protocols. It also provides a brief survey of existing work in standardizing AI agent protocols, including the Model Context Protocol (MCP), the Agent to Agent Protocol (A2A) and the Agntcy Framework, and describes how those works fit into this framework. The primary objective of this document is to set the stage for possible standards activity at the IETF in this space. Huawei China Mobile Telefonica China Unicom Daejeon University A Network Digital Twin (NDT) provides a network emulation tool usable for different purposes such as scenario planning, impact analysis, and change management. Agentic AI enables dynamic goal-driven execution and adaptive behavior and closed-loop autonomy. By integrating a Network Digital Twin into network management together with the Agentic AI, it allows the network management activities to take user intent or service requirements as input, automatically assess, model, and refine optimization strategies under realistic conditions but in a risk-free environment. Such environment that operates to meet these types of requirements is said to have AI driven Network Operations. AI driven Network Operations brings together existing technologies such as Agentic AI and Network Digital Twin which may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture for AI driven network operations and shows how these components work together with network digital twin and Agentic AI capabilities. It provides a cookbook of existing technologies to satisfy the architecture and realize intent- based network management to meet the needs of the network service. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). CMCC Telefonica Huawei Ciena This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help reduce troubleshooting tickets and resolve network incidents for the sake of network service health and probable cause analysis.

Usage Example This section describes the deployment of a network configuration within a secure video meeting context. The scheduling agent is deployed to the Service Orchestrator, while the worker agent is deployed to the network controller. Registered on the Service Orchestrator, the agent card formally defines a worker agent's capabilities, interfaces, and operational characteristics within network management systems. See the following Agent card examples for two worker agents (QoS Agent and Security Agent): Suppose a user submits a natural language request such as "The meeting will have 100 participants. The security level is Top Secret" to the platform integrated with the Service Orchestrator. The platform parses the request and converts it into JSON format as follows: The Service Orchestrator sends subtasks in a structured format to the Network Controller. For example, the subtasks for set_qos and enable_encryption are structured as follows: The network controller executes network management operations on network devices and returns the results to the Service Orchestrator in JSON format. Example responses for the subtasks are shown below:

Contributors InnovCOM Sup'COM

houda.chihi@supcom.tn