]> 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. In network management field, 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, heterogeneous AI ecosystems interaction, cross-platform collaboration, A2A enables network management 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 lead 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.
• Network events need to be correlated with the tasks they trigger. Task update delivery alone does not define how alarms are selected, correlated, or used to initiate diagnosis.

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 the 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. Figure 1 shows one possible deployment. A2A does not require an agent at every layer or on every 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 example, an enterprise Service AI Agent may delegate network diagnosis to a vendor-provided Network AI Agent through A2A, while each agent manages access to its own tools. 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.
• Workflow Management: The service AI agent decomposes the request into subtasks, selects task agents using their Agent Cards, and sends requests to their A2A endpoints.
• Task Execution: Iteration continues until all tasks reach executable task agents in the hierarchy.
• 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 defines the order of execution; it does not guarantee the correctness of each agent's output.

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 dynamically decides which task agent to invoke based on the real-time execution feedback of individual task agents. This pattern supports 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. The supervisor tracks subtask dependencies and outcomes and revises the plan as needed, within the authorized task scope.

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 an extensible way to structure network management data and operational service and network intent; using YANG-modeled structured data to populate A2A communication payloads can make parameters and constraints explicit and support their validation, and align A2A communication with the existing IETF-based network management ecosystem, supporting 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 . The following example uses the JSON-RPC binding of A2A v1.0 , with text and structured data in the same message. The Network AI Agent acts as the A2A client and sends a diagnosis request to the Incident Diagnosis Task Agent, acting as the A2A server. The request is sent over HTTPS to the server's advertised endpoint. The data part carries an incident instance using the ietf-incident module defined in . It uses the JSON encoding defined in . The example uses the module's access domain identity. The A2A fields and the YANG instance data are validated separately. The metadata keys yang_module, revision, request_type, priority, and response_deadline are application-defined conventions in this example, not standardized A2A fields. Their interpretation requires agreement between the participating agents.

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 for use by an AI Agent 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"). These resources provide domain-specific guidance for task execution. The Agent Skills packages discussed here are implementation resources, distinct from the skill descriptions advertised in an A2A Agent Card. A generated skill should be reviewed and tested before it is used for network changes.

Knowledge Base and Data Freshness A knowledge base can provide product documentation, troubleshooting procedures, and historical incident records. Current topology, configuration, and operational state should be checked against authoritative management systems. Information exchanged between agents should identify its source and observation time so that the receiver can assess its relevance and freshness. MCP may provide interfaces for agents to query a knowledge base. Access remains subject to local policy.

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 integration uses a publish/subscribe paradigm alongside the primary task-driven interaction. For example, a "Fault Agent" identifies a link failure by analyzing data 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. Conversational, context-rich A2A workflows may require additional message exchanges for task coordination. 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. A2A deployments use TLS to protect communications and authenticate callers using the configured authentication scheme. Each receiving agent should authorize the requested operation against local policy. Permission to request diagnosis does not imply permission to change network configuration. Where operator approval is required, it should be bound to the proposed action and its target resources. Audit records should link the A2A task to the local operations performed and their results. 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 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 NDT 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 NDT 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 NDT and Agentic AI capabilities. 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 data model for the network incident lifecycle management. This YANG module provides a standard way to report, diagnose, and help reduce troubleshooting tickets and resolve network incidents for the sake of network service health and probable root cause analysis. This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.

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