# drafts

name: draft-zhang-agent-gap-network
rev: 00
title: Problem Statement and Gap Analysis for Agent-enabled Mobile Core Network
time: 2026-01-09T07:09:47Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T13:34:18Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420319+00:00
abstract:
This document provides the problem statement and gap analysis of
   agent-enabled mobile core network.

full_text:
Network Working Group                                      Y. Zhang, Ed.
Internet-Draft                                             X. Zhang, Ed.
Intended status: Standards Track                             Y. Yue, Ed.
Expires: 8 January 2026                                     China Unicom
                                                             7 July 2025


Problem Statement and Gap Analysis for Agent-enabled Mobile Core Network
                    draft-zhang-agent-gap-network-00

Abstract

   This document provides the problem statement and gap analysis of
   agent-enabled mobile core network.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.






Zhang, et al.            Expires 8 January 2026                 [Page 1]

Internet-Draft  Problem and Gap for Agent-enabled Networ       July 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Changes in Interaction Content  . . . . . . . . . . . . .   3
     3.2.  Changes in Interaction Entity . . . . . . . . . . . . . .   3
     3.3.  Changes in Interaction Protocol . . . . . . . . . . . . .   4
   4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Network for Agent Communication . . . . . . . . . . . . .   4
     4.2.  Agent-based Network Enhancement . . . . . . . . . . . . .   4
   5.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  GAP analysis of service capabilities  . . . . . . . . . .   4
       5.1.1.  User-Driven Service Mechanism . . . . . . . . . . . .   4
       5.1.2.  Communication Dumb Pipeline Model . . . . . . . . . .   4
     5.2.  GAP analysis of foundational capabilities . . . . . . . .   5
       5.2.1.  Fixed NF and Processes  . . . . . . . . . . . . . . .   5
       5.2.2.  Network Intelligence  . . . . . . . . . . . . . . . .   5
       5.2.3.  Network Programmability . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   With the development of AI technology, AI Agent, as advanced form of
   AI capability, is rapidly becoming an important evolutionary
   direction.  While traditional AI (such as ChatGPT) mainly relies on
   user input commands, the Agent can independently think, make
   decisions, and perform complex tasks, just like an AI assistant,
   capable of independently completing multi-step operations.  The
   development of Agent has directly brought about profound changes in
   terminal form and business content.  Besides, it will also profoundly
   change the traditional mobile network architecture and business
   model.

   Agent communication is an important reference and connotation of 6G
   mobile network evolution.  The emergence of Agent brings new
   communication terminal forms and business scenarios, which brings new
   demands to the transmission protocols and network capabilities of
   mobile networks, and 6G needs to evolve and enhance new capabilities
   as a communication bridge for next-generation Agent services and
   terminals.  Also, 6G can improve its own level of intelligence by
   taking advantage of the perception and decision-making of the Agent.






Zhang, et al.            Expires 8 January 2026                 [Page 2]

Internet-Draft  Problem and Gap for Agent-enabled Networ       July 2025


   From the document of 3GPP Technical Report (TR) 22.870 [TR22.870],
   the AI Agent is defined as an automated intelligent entity capable of
   e.g. interacting with its environment, acquiring contextual
   information, reasoning, self-learning, decision-making, executing
   tasks (autonomously or in collaboration with other Al Agents) to
   achieve a specific goal.  The current content of the report already
   provides some use cases for AI Agent communication.  The use cases
   are mainly focused on Networt for AI Agent, including scenarios such
   as connected cars, takeaway booking, child care, and earthquake
   rescue.  There are fewer use cases in AI Agent for Network, focusing
   on network operation and maintenance.

2.  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 RFC2119 [RFC8174] when, and only when, they appear in all
   capitals, as shown here.  Abbreviations and definitions used in this
   document: *AI: Artificial Intelligence. *NF: Network Function.

3.  Problem statement

   The AI Agent brings changes to the network in terms of interaction
   content, interaction object and interaction protocol.

3.1.  Changes in Interaction Content

   The traditional communication content is mainly singlemodality such
   as text, video/image, and voice for the transmission of transparent
   media.  The AI Agent integrate physical and virtual world, driving
   the evolution of communication interaction content to multimodality
   data, such as the perception and transmission of multimodality data
   of actions, states/emotions, space, and haptics.

3.2.  Changes in Interaction Entity

   AI Agent extend the scope of traditional interaction entities, which
   are no longer limited to simple dialogs between human-machine-objects
   and enabling based on fixed processes.  Instead, it extends to multi-
   entity interactions within AI Agent(such as tools), between AI
   Agents, and between AI Agent and current network objects (such as
   network elements, application systems, IoT devices).  The extension
   of interaction entities not only enhances the autonomous
   collaboration capability, but also promotes more complex and
   intelligent task collaboration and decision-making modes.





Zhang, et al.            Expires 8 January 2026                 [Page 3]

Internet-Draft  Problem and Gap for Agent-enabled Networ       July 2025


3.3.  Changes in Interaction Protocol

   AI Agent can autonomous decision-making, semantic understanding, and
   learning-evolution capabilities, and interact with users in a more
   natural and flexible way.  In AI Agent communication, the traditional
   protocol paradigm based on fixed syntax and static layering is
   broken.  A transmission protocol with semantic understanding, dynamic
   negotiation, and autonomous collaboration is required.  Also, the new
   protocol can support multimodality data transfer and transformation.

4.  Use Cases

4.1.  Network for Agent Communication

   TBD.

4.2.  Agent-based Network Enhancement

   TBD.

5.  Gap Analysis

5.1.  GAP analysis of service capabilities

5.1.1.  User-Driven Service Mechanism

   The current communication network is mainly a user-driven service
   model, in which the user initiates a communication request, and the
   network passively responds and establishes a connection to provide
   communication services.  For AI Agent communication, it is not only a
   simple data transmission, but also an interactive behavior with the
   goal of completing a specific task.  The network needs to analyze and
   understand the task and behavior.  And perceive the task context
   state, so as to better optimize the allocation of resources to meet
   the user's needs.  The network needs to sense and understand the
   tasks and behaviors of, as well as perceive the task context state,
   so as to better optimize the resource allocation and guarantee that
   tasks are completed on demand.

5.1.2.  Communication Dumb Pipeline Model

   The traditional mobile network serves as a 'dumb pipeline', providing
   undifferentiated basic bit stream transmission services, mainly
   guaranteeing communication indexes such as bandwidth and delay.  In
   AI Agent communication, the traffic often presents multimodality,
   upstream and downstream peer-to-peer, and short bursts, etc.  The
   network require the capability to support dynamic, semantic, and
   multimodality communication traffic demand brought by AI Agent



Zhang, et al.            Expires 8 January 2026                 [Page 4]

Internet-Draft  Problem and Gap for Agent-enabled Networ       July 2025


   communication.

5.2.  GAP analysis of foundational capabilities

5.2.1.  Fixed NF and Processes

   The current mobile core network is characterized by precise
   definition, serial processing and linkage impact.  Events trigger the
   serial processing of multiple NFs.  NFs and processes are basically
   fixed, and the linkage impact will be produced when the functions are
   changed.

5.2.2.  Network Intelligence

   Although the intelligence technology has been introduced into the
   current mobile network, it is mainly realized through optimization
   and transformation at the existing architectural level, which is
   still a 'plug-in' intelligence and can only provide single
   intelligence or local enhancement capability.  For example, the 5GC
   NWDAF has the ability of intelligent sensing and analyzing, it cannot
   make autonomous decision scheduling based on the analysis results.
   For AI Agent communication, mobile networks should consider
   endogenous intelligence at the early stage of design and build AI-
   native network capabilities.

5.2.3.  Network Programmability

   The current network provides services through the collaboration of
   NFs and deployed services, it is difficult to realize network-level
   update, and the network programmability is insufficient.  In
   capability opening, the closed operation of NFs brings about a lack
   of openness to external capabilities.  In addition, the network also
   lacks the capabilities to call and respond to external capabilities.

6.  Security Considerations

   TBD

7.  IANA Considerations

   TBD

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.



Zhang, et al.            Expires 8 January 2026                 [Page 5]

Internet-Draft  Problem and Gap for Agent-enabled Networ       July 2025


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Yaomin Zhang (editor)
   China Unicom
   Beijing
   China
   Email: zhangym2533@chinaunicom.cn


   Xuebei Zhang (editor)
   China Unicom
   Beijing
   China
   Email: zhangxb170@chinaunicom.cn


   Yi Yue (editor)
   China Unicom
   Beijing
   China
   Email: yuey80@chinaunicom.cn


























Zhang, et al.            Expires 8 January 2026                 [Page 6]

categories:
["Agent-to-agent communication protocols", "Autonomous network operations", "ML-based traffic management / optimization"]


name: draft-cui-ai-agent-task
rev: 00
title: Task-oriented Coordination Requirements for AI Agent Protocols
time: 2026-01-09T07:09:56Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T22:35:35Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420344+00:00
abstract:
AI agent communication requires intelligent task level coordination
   to manage dynamic workloads across large-scale, heterogeneous
   networking environments.  This draft proposes general requirements
   for an agent protocol to enable autonomous task coordination at
   scale, including dynamic task discovery, negotiation, and context-
   aware scheduling with real-time adaptability.

full_text:
Network Working Group                                             Y. Cui
Internet-Draft                                       Tsinghua University
Intended status: Informational                                     C. Du
Expires: 8 January 2026                          Zhongguancun Laboratory
                                                             7 July 2025


     Task-oriented Coordination Requirements for AI Agent Protocols
                       draft-cui-ai-agent-task-00

Abstract

   AI agent communication requires intelligent task level coordination
   to manage dynamic workloads across large-scale, heterogeneous
   networking environments.  This draft proposes general requirements
   for an agent protocol to enable autonomous task coordination at
   scale, including dynamic task discovery, negotiation, and context-
   aware scheduling with real-time adaptability.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Cui & Du                 Expires 8 January 2026                 [Page 1]

Internet-Draft           Agent Task Coordination               July 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Task Coordination Framework . . . . . . . . . . . . . . .   3
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Necessity . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Task Complexity . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Resource Optimization . . . . . . . . . . . . . . . . . .   5
     3.3.  Quality of Service  . . . . . . . . . . . . . . . . . . .   5
     3.4.  Dynamic Adjustment  . . . . . . . . . . . . . . . . . . .   5
   4.  Protocol Requirements . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Task Description  . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Task State  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Communication Mechanism . . . . . . . . . . . . . . . . .   6
     4.4.  Context Sharing . . . . . . . . . . . . . . . . . . . . .   8
     4.5.  Exception Handling  . . . . . . . . . . . . . . . . . . .   8
   5.  Existing Protocol Analysis  . . . . . . . . . . . . . . . . .   8
   6.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

1.1.  Purpose

   With the rapid advancements of AI technologies and their
   applications, AI agents utilizing Large Language Models (LLMs) have
   emerged as a pivotal direction in global technological evolution and
   market development.  The single-agent systems exhibit inherent
   limitations when addressing complex tasks in dynamic environments,
   the efficient multi-agent collaboration for complex task completion
   has garnered increasing attention, wherein task-oriented coordination
   constitutes a critical component of standardized multi-agent systems.



Cui & Du                 Expires 8 January 2026                 [Page 2]

Internet-Draft           Agent Task Coordination               July 2025


   This document examines the requirements for standardizing AI Agent
   protocols to support task coordination in multi-agent systems.

1.2.  Terminology

   Task:
      ISO/IEC 22989, task is actions required to achieve a specific
      goal.  These actions can be physical or cognitive.  For instance,
      computing or creation of predictions, translations, synthetic data
      or artefacts or navigating through a physical space.

   Shared Message Pool:
      A pool where agents publish structured messages and subscribe to
      relevant messages based on their profiles.

   Coordinator Agent:
      An agent that receives tasks and decomposes or distributes tasks
      to other agents.

   Execution Agent:
      An agent responsible for executing tasks distributed by the
      Coordinator Agent.

   Normative Language:
      The key words "MUST", "REQUIRED", and "SHOULD" in this document
      are to be interpreted as described in [RFC2119].

1.3.  Task Coordination Framework

                                                             +---------+
                                        +------------------->| Agent X |
                                        |2.Task1 distributed +---------+
                                        |                        |
                                        |                        |
                                        |                        |
     +---------+  1.Task submitted  +---------+ 3.Task1 completed|
     |   Task  |------------------->|         |<-----------------+
     | Invoker |<------------------ | Agent A |<-----------------+
     +---------+  4.Task completed  +---------+ 3.Task2 completed|
                                        |                        |
                                        |                        |
                                        |                        |
                                        |2.Task2 distributed +---------+
                                        +------------------->| Agent Y |
                                                             +---------+

                   Figure 1: Task Coordination Framework




Cui & Du                 Expires 8 January 2026                 [Page 3]

Internet-Draft           Agent Task Coordination               July 2025


   The system operates as follows: when a task invoker submits a task to
   Agent A (Coordinator), the agent performs task decomposition and
   distributes task 1 and task 2 to Agents X (Execution) and Y
   (Execution) respectively.  Upon receiving completion notifications
   from both agents, Agent A aggregates the results and delivers the
   final output back to the originating user.

2.  Use Cases

   Some typical use cases in which multiple agents work together to
   complete tasks:

   *  High throughput tasks: There are many tasks that have high
      bandwidth requirements.  For example, in the collaborative
      framework for coordinating heterogeneous embodied agents-
      specifically, the robot dogs and drones-in a wide-area public
      network, the drone is assigned for wide-area surveillance and task
      delegation, while functionally specialized robot dogs perform
      ground-level operations such as video surveillance, material
      transport and obstacle clearance.

   *  Low latency tasks: In collaborative multi-agent systems, control
      signal transmission tasks impose significantly more stringent
      latency requirements than routine model training data transfer.
      For example, the home robot remotely sends an alarm message to the
      end user.

   *  High reliability tasks: Smart factory scenarios require critical
      reliability of agent task execution and fault-tolerant operation
      stability.

   These categories of use cases (may be further extended) demonstrate
   the collaboration among agents spanning multiple distinct domains to
   achieve end-to-end task completion.  The embodied agents (such as the
   robots and unmanned aerial vehicles) interacting with physical
   environments through embodied interfaces, while virtual agents (such
   as the various software applications and personal assistant)
   providing complementary capabilities, has demonstrated the advantages
   of collaboratively completing complex tasks in various scenarios.

3.  Necessity

3.1.  Task Complexity

   As task complexity increases, heterogeneous agents require multiple
   interaction rounds, precise planning, ordered execution, and
   efficient context sharing mechanisms to enhance resolution quality
   and robustness.



Cui & Du                 Expires 8 January 2026                 [Page 4]

Internet-Draft           Agent Task Coordination               July 2025


3.2.  Resource Optimization

   Through task coordination and resource consumption monitoring, the
   multi-agent systems are able to support dynamic allocation of for
   example, the computing, storage and bandwidth resources to optimize
   the resource utilization efficiency.

3.3.  Quality of Service

   Task coordination may dynamically prioritize resources allocations
   based on for example, task priorities, agent expertise and Quality of
   Service requirements.  This ensures timeliness and accuracy of
   critical tasks, reduces service response latency, and maintains
   output stability and reliability.

3.4.  Dynamic Adjustment

   The agents may update or adjust the task during task execution phase
   based on end user's inputs or contextual updates to better respond to
   the final task requirements.

4.  Protocol Requirements

4.1.  Task Description

   Precise task descriptions or task templates are REQUIRED to ensure
   all agents maintain a consistent understanding of the objectives,
   operational constraints and criteria.

   A well-defined task description:

   *  Reduces ambiguity: Minimizes misinterpretations and conflicting
      actions among agents.

   *  Enables verifiability: Translates abstract goals into executable
      and measurable plans.

   *  Improves robustness: Ensures collaboration remains coherent and
      efficient under dynamic conditions.

   Task descriptions assigned to different agents MUST follow the
   minimization principle, i.e., agents SHOULD receive only the minimal,
   contextually necessary information required to fulfill their tasks to
   prevent unauthorized access of sensitive information.







Cui & Du                 Expires 8 January 2026                 [Page 5]

Internet-Draft           Agent Task Coordination               July 2025


4.2.  Task State

   Upon receiving a task, the Coordinator Agent may decompose it into
   multiple tasks and delegate them to different Execution Agents via
   dynamic capability discovery mechanism.  The AI Agent protocol design
   should support comprehensive state descriptions throughout the task
   execution lifecycle.  For example, the definition of potential task
   states, (such as task submitted, running, suspended (awaiting
   external input or output from other agents), completed, canceled,
   rejected and failed) and the coordination operations (such as state
   queries, retrieval and push of intermediate results).

   Based on the length of time to complete the tasks, the task can be
   categorized into Short-term tasks that require a single request-
   response interactions and Long-term tasks that may require multi-
   round interactions or extended waiting periods.  The Coordinator
   Agent may dynamically adjust the target of the task according to the
   intermediate results of the Execution Agents and the context
   information.  The AI Agent protocol design should support long-term
   and short-term tasks coordination.

4.3.  Communication Mechanism

   When multiple agents participate in coordinated tasks, they may need
   to maintain common context sharing, or subscriptions to identical
   message content.  Different communication mechanisms, such as
   request/response and broadcast may need to be supported in the AI
   Agent protocol.  In the moving large artifact task in intelligent
   factory case, the multiple robots responsible for the transportation
   needs to obtain consistent route and destination data to ensure
   operational coherence.

   The applicable communication mechanisms may be vary for different
   agent communication structures, which directly affects the message
   delivery efficiency, implementation feasibility and system
   complexity.  The typical agent communication structures
   [Multi-Agents] including:

   *  Layered communication: Agents at different layers in the
      hierarchical structure have different roles or capabilities.
      Communication occurs either horizontally (intra-layer) or
      vertically (adjacent layers only).

   *  Decentralized communication: Multiple agents form a peer-to-peer
      network permitting direct communications between any two agents.






Cui & Du                 Expires 8 January 2026                 [Page 6]

Internet-Draft           Agent Task Coordination               July 2025


   *  Centralized communication: Central agents coordinate the
      communications, with the other agents primarily interact through
      the central node.

   *  Shared message pool [MetaGPT]: Agents publish structured messages
      to the pool and subscribe to the message types matching their
      profiles.

   The task collaboration mode may also affect the communication
   mechanism between agents:

   *  In the primary/secondary mode, a Coordinator Agent decomposes a
      task into multiple tasks and distributes them to Execution Agents
      for processing.  The Execution Agents return their execution
      results to the Coordinator Agent, which aggregates the results and
      delivers them to the end user.

   *  In the peer negotiation mode, a Coordinator Agent distributes the
      task of the end user to the Execution Agents, which independently
      execute their assigned tasks.  The Execution Agents return their
      results directly to the end user via the Coordinator Agent,
      without requiring further processing by the Coordinator Agent.

   *  In subscription mode, a Coordinator Agent may delegate
      subscription-based tasks to Execution Agents.  For example, a task
      including "book a ticket to Beijing one week before the New Year
      holiday" will be assigned by the Coordinator Agent which will
      perform the task at the specified time to the Execution Agents.

   Different tasks may require long and short connections, the AI Agent
   protocol should be able to provide mechanisms beyond simple request/
   response, including the complex interaction modes for example message
   multicast, publication/subscription (PUB/SUB), asynchronous
   notifications.

   The AI Agent protocol design MUST consider support for relay nodes to
   facilitate task message forwarding.  Relay nodes SHOULD prioritize
   message scheduling and forwarding based on task requirements to
   ensure efficient agent collaboration and meet transmission QoS
   objectives.

   For example, relay nodes MAY implement the following priority
   hierarchy (from highest to lowest):

   *  Control signaling transmission tasks

   *  Media stream transmission tasks




Cui & Du                 Expires 8 January 2026                 [Page 7]

Internet-Draft           Agent Task Coordination               July 2025


   *  Training data stream transmission tasks

   This prioritization scheme ensures that critical messages receive
   preferential treatment during congestion or resource contention
   scenarios.

4.4.  Context Sharing

   When delegating tasks to Execution Agents, the Coordinator Agent may
   include task-relevant contextual about the contact information of the
   end user, the task itself, the historical preference information
   known by the Coordinator Agent, and other necessary conversation
   data, to facilitate the task execution.  For example, in trip
   planning case, this may encompass historically booked flight/hotel
   preferences or dynamically perceived context like recent user dialog.
   The AI Agent protocol design should consequently support context
   sharing mechanisms through standardized definitions of context types,
   length constraints, and encoding formats to enhance the effectiveness
   of task execution.

   The context sharing MAY have an impact on privacy of the user, it is
   necessary to consider the limitations of the scope of context
   sharing, especially for the sensitive information e.g. name, age,
   address of the user.

4.5.  Exception Handling

   Exception handling constitutes a critical mechanism for multi-agent
   collaborative task execution.  If an execution agent cannot complete
   an assigned task due to lack of skills or overloaded, the failure in
   task execution may lead to such as releasing the connections.

5.  Existing Protocol Analysis

   Task-oriented coordination is compatible with multiple types of
   existing protocols, such as TCP, HTTP and etc.

   Transmission Control Protocol (TCP) is to provide reliable, orderly,
   connection-oriented data transmission services for end-to-end
   communication.  In the task-oriented coordination scenarios, some TCP
   capabilities can be directly reused (e.g. retransmission mechanism,
   congest control and etc.).

   The Hypertext Transfer Protocol (HTTP) is the application layer
   protocol for distributed, collaborative, hypermedia information
   systems.  Some HTTP features are also applicable to task-oriented
   coordination.




Cui & Du                 Expires 8 January 2026                 [Page 8]

Internet-Draft           Agent Task Coordination               July 2025


   However, the task-oriented coordination needs to support finer-
   grained access control and context information anonymization
   mechanisms, which may need the enhancements on the protocol, defining
   the task-oriented coordination mechanism at the session layer has
   some advantages.

6.  Conclusions

   Task-oriented coordination constitutes a critical function for multi-
   agent collaboration.  This document discusses the necessity of
   introducing task-oriented coordination to address complex tasks,
   optimize resource utilization, and guarantee service quality.
   Consequently, it analyzes the requirements imposed by task-oriented
   coordination on AI Agent protocol design, specifically concerning
   task descriptions, task states, communication mechanisms, context
   sharing, and exception handling.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   When designing the task-oriented coordination for AI agents
   communication, privacy should always be considered.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

9.2.  Informative References

   [Multi-Agents]
              Guo, T., Chen, X., Wang, Y., Chang, R.i., Pei, S., Chawla,
              N.V., Wiest, O., and X. Zhang, "Large Language Model based
              Multi-Agents: A Survey of Progress and Challenges", 2024.

   [MetaGPT]  Hong, S., Zhuge, M., Chen, J., Zheng, X., Cheng, Y.,
              Zhang, C., Wang, J., Wang, Z., Yau, S., Lin, Z., Zhou, L.,
              Ran, C., Xiao, L., Wu, C., and J. Schmidhuber, "MetaGPT:
              Meta Programming for A Multi-Agent Collaborative
              Framework", 2023.




Cui & Du                 Expires 8 January 2026                 [Page 9]

Internet-Draft           Agent Task Coordination               July 2025


Authors' Addresses

   Yong Cui
   Tsinghua University
   Beijing, 100084
   China
   Email: cuiyong@tsinghua.edu.cn
   URI:   http://www.cuiyong.net/


   Chenguang Du
   Zhongguancun Laboratory
   Beijing, 100094
   China
   Email: ducg@zgclab.edu.cn




































Cui & Du                 Expires 8 January 2026                [Page 10]

categories:
["Agent-to-agent communication protocols", "Agent discovery / registration", "Autonomous network operations"]


name: draft-liu-agent-context-protocol
rev: 00
title: Agent Context Protocol
time: 2026-01-26T07:09:06Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-25T10:06:01Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Agent-to-agent communication protocols", "Data formats / semantics for AI interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420349+00:00
abstract:
This specification defines a standard message and protocol for
   communicating Agent Context information between AI agents.

full_text:
Internet Engineering Task Force                              D. Liu, Ed.
Internet-Draft                                                   Alibaba
Intended status: Standards Track                            23 July 2025
Expires: 24 January 2026


                         Agent Context Protocol
                  draft-liu-agent-context-protocol-00

Abstract

   This specification defines a standard message and protocol for
   communicating Agent Context information between AI agents.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.







Liu                      Expires 24 January 2026                [Page 1]

Internet-Draft              Abbreviated Title                  July 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Architecture of Agent Context Protocol  . . . . . . . . . . .   3
   3.  Agent Context Message . . . . . . . . . . . . . . . . . . . .   5
   4.  Agent Context Protocol  . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   In addition to data and content, the interaction between AI agents
   should also include the communication of agent context information.
   This context information is crucial for the called AI agent to
   generate more accurate content and complete tasks that meet user
   needs while adhering to the security and policy configurations of the
   application and internal organizations.

   Considering that there may be multiple coexisting protocols between
   AI agents, and the ways in which AI agents call each other are
   diverse, it is necessary to maintain semantic consistency and
   standardization in the transmission of agent context information.
   This is critical for improving interoperability among AI agents and
   building a scalable AI agent ecosystem.

   This specification defines the semantic standard and its protocol for
   AI agents to transmit context information, independent of the agent-
   to-agent communication protocol.  Any communication protocol between
   agents can utilize this specification to implement bindings based on
   its semantics.

1.1.  Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.







Liu                      Expires 24 January 2026                [Page 2]

Internet-Draft              Abbreviated Title                  July 2025


2.  Architecture of Agent Context Protocol

   As shown in figure 1, Agent Context Protocol is the "semantic layer"
   of the communication protocol stack between AI agents.















































Liu                      Expires 24 January 2026                [Page 3]

Internet-Draft              Abbreviated Title                  July 2025


                                ┌──────────────────────────────────────────────────────────────────────────────────────┐
                                │                                                                                      │
                                │                                                                                      │
┌───────────────────────────────▼────────────────────────────────┐                     ┌───────────────────────────────▼────────────────────────────────┐
│                                                                │                     │                                                                │
│  ┌──────────────────────────────────────────────────────────┐  │                     │  ┌──────────────────────────────────────────────────────────┐  │
│  │                                                          │  │                     │  │                                                          │  │
│  │                                                          │  │                     │  │                                                          │  │
│  │                                                          │  │                     │  │                                                          │  │
│  │                       Agent Context                      │  │                     │  │                       Agent Context                      │  │
│  │                                                          │  │                     │  │                                                          │  │
│  │                                                          │  │                     │  │                                                          │  │
│  └──────────────────────────────────────────────────────────┘  │                     │  └──────────────────────────────────────────────────────────┘  │
│  ┌──────────────────────────────────────────────────────────┐  │                     │  ┌──────────────────────────────────────────────────────────┐  │
│  │                                                          │  │                     │  │                                                          │  │
│  │                                                          │  │                     │  │                                                          │  │
│  │                   Orchestration                          │  │                     │  │                            Orchestration                 │  │
│  │                                                          │  │                     │  │                                                          │  │
│  │                                                          │  │                     │  │                                                          │  │
│  └──────────────────────────────────────────────────────────┘  │                     │  └──────────────────────────────────────────────────────────┘  │
│  ┌────────────────┐   ┌────────────────┐   ┌────────────────┐  │                     │  ┌────────────────┐   ┌────────────────┐   ┌────────────────┐  │
│  │                │   │                │   │                │  │                     │  │                │   │                │   │                │  │
│  │                │   │                │   │                │  │                     │  │                │   │                │   │                │  │
│  │      Model     │   │      Model     │   │      Model     │  │                     │  │      Model     │   │      Model     │   │      Model     │  │
│  │                │   │                │   │                │  │                     │  │                │   │                │   │                │  │
│  │                │   │                │   │                │  │                     │  │                │   │                │   │                │  │
│  └────────────────┘   └────────────────┘   └────────────────┘  │                     │  └────────────────┘   └────────────────┘   └────────────────┘  │
│  ┌────────────────┐   ┌────────────────┐   ┌────────────────┐  │                     │  ┌────────────────┐   ┌────────────────┐   ┌────────────────┐  │
│  │                │   │                │   │                │  │                     │  │                │   │                │   │                │  │
│  │  Model Context │   │  Model Context │   │  Model Context │  │                     │  │  Model Context │   │  Model Context │   │  Model Context │  │
│  │                │   │                │   │                │  │                     │  │                │   │                │   │                │  │
│  │                │   │                │   │                │  │                     │  │                │   │                │   │                │  │
│  └────────────────┘   └────────────────┘   └────────────────┘  │                     │  └────────────────┘   └────────────────┘   └────────────────┘  │
│  ┌────┐┌────┐┌────┐   ┌────┐┌────┐┌────┐   ┌────┐┌────┐┌────┐  │                     │  ┌────┐┌────┐┌────┐   ┌────┐┌────┐┌────┐   ┌────┐┌────┐┌────┐  │
│  │    ││    ││    │   │    ││    ││    │   │    ││    ││    │  │                     │  │    ││    ││    │   │    ││    ││    │   │    ││    ││    │  │
│  │Tool││Tool││Tool│   │Tool││Tool││Tool│   │Tool││Tool││Tool│  │                     │  │Tool││Tool││Tool│   │Tool││Tool││Tool│   │Tool││Tool││Tool│  │
│  │    ││    ││    │   │    ││    ││    │   │    ││    ││    │  │                     │  │    ││    ││    │   │    ││    ││    │   │    ││    ││    │  │
│  │    ││    ││    │   │    ││    ││    │   │    ││    ││    │  │                     │  │    ││    ││    │   │    ││    ││    │   │    ││    ││    │  │
│  └────┘└────┘└────┘   └────┘└────┘└────┘   └────┘└────┘└────┘  │                     │  └────┘└────┘└────┘   └────┘└────┘└────┘   └────┘└────┘└────┘  │
│                                                                │                     │                                                                │
└────────────────────────────────────────────────────────────────┘                     └────────────────────────────────────────────────────────────────┘


                     Figure 1: Diagram [REPLACE]







Liu                      Expires 24 January 2026                [Page 4]

Internet-Draft              Abbreviated Title                  July 2025


3.  Agent Context Message

   The context of an AI Agent refers to the context of information that
   the Agent can access and utilize when performing tasks or interacting
   with users.

   Providing agent context information is critical for the invoked AI
   Agent to generate more accurate results and complete tasks that meet
   user requirements, security policies, and configurations.  Well-
   defined agent contextual information enables the AI agent to better
   understand and meet user needs in a variety of complex situations,
   thereby improving its overall performance and service quality.

   This agent context information is defined as 'Agent Context Message'
   in this specification.  Agent Context Message is passed between
   orchestration layers where the network traffic originates and is
   terminated.

   The orchestration layer should create the content of Agent Context
   Message and passed as a side channel along with agent workloads.
   Each orchestration layer can choose if it is important to include the
   Agent Context Message into the model invocation prompt, depending on
   the application.  For example, a party might want the orchestrator to
   convert the JSON format of the Agent Context Message into something
   that performs better with models context windows (e.g. Markdown).  As
   another example, the Orchestrator might take the list of rule from
   the Agent Context Message and put them as guidance to the agent when
   making ethical determinations.

   This specification uses JSON to describe the Agent Context Message.
   A variety of agent communication protocols can implement binding
   using the semantics of the Agent Context Message as specified in this
   document.

   The Agent Context Message is defined as follows:

   *  Task Context: AI agents collaborate with other agents to complete
      a specific task and need to share information about the task, such
      as its progress, goals, and to-do items.  On the one hand, this
      information is provided to the collaborating agent.  It can also
      be fed back to the user, so that the user can know the overall
      progress in a timely manner.

   *  MCP Context: The MCP Context information of the Agent includes the
      MCP service list, MCP Function list, and function descriptions.
      This information can be exchanged when a connection is initiated
      between agents and can be stored in the context of the Agent.
      When the Agent's MCP service is updated, this information can be



Liu                      Expires 24 January 2026                [Page 5]

Internet-Draft              Abbreviated Title                  July 2025


      pushed to the Agents that have established connections with it,
      updating the context information.  When a user inputs a task
      request to an Agent or one Agent calls another, the MCP Context
      information can also be provided simultaneously to the other Agent
      in order to select the appropriate MCP Function.

   *  Policy Context: The organizations that deploy the Agent can
      configure policies, such as certain rules that the Agent should
      follow, and provide these policies to local or peer Agents when
      the Agent is started.

   *  Resource Context: Resource context information pertains to the
      resources required for executing tasks and tool functions, as well
      as the resources that the system can provide.

   *  Security Context: The interaction between agents needs to consider
      security aspects such as access control, authentication, and data
      protection.  The security-related context can provide information,
      for example, the authorization token that the initiator agent has
      obtained to simplify the user authorization experience.

            {
             "agentContext": {
               "taskContext": {
                 "taskId": "T123456",
                 "taskName": "Data Analysis Project",
                 "taskProgress": "30%",
                 "goals": ["Analyze Q1 sales data", "Generate predictive models"],
                 "todoItems": [
                   {"itemId": "I001", "description": "Collect raw sales data from Q1"},
                   {"itemId": "I002", "description": "Clean and preprocess the data"}
                 ],
                 "statusUpdates": [
                   {"updateId": "U001", "timestamp": "2023-10-01T12:00:00Z", "message": "Data collection completed."}
                 ]
               },
               "mcpContext": {
                 "mcpServiceList": [
                   {"serviceName": "DataFetcher", "version": "1.0.0"},
                   {"serviceName": "DataProcessor", "version": "2.0.1"}
                 ],
                 "mcpFunctionList": [
                   {"functionName": "fetchData", "description": "Fetches raw data from a specified source."},
                   {"functionName": "processData", "description": "Cleans and processes the fetched data for analysis."}
                 ]
               },
               "policyContext": {
                 "policies": [



Liu                      Expires 24 January 2026                [Page 6]

Internet-Draft              Abbreviated Title                  July 2025


                   {"policyId": "P001", "rule": "Do not share sensitive data with external parties without explicit user consent."},
                   {"policyId": "P002", "rule": "Ensure all communications are encrypted using TLS 1.2 or higher."}
                 ]
               },
               "resourceContext": {
                 "requiredResources": [
                   {"resourceType": "CPU", "quantity": "8 cores"},
                   {"resourceType": "Memory", "quantity": "16 GB RAM"}
                 ],
                 "availableResources": [
                   {"resourceType": "Storage", "quantity": "1 TB SSD"},
                   {"resourceType": "Network", "bandwidth": "1 Gbps"}
                 ]
               },
               "securityContext": {
                 "authenticationInfo": {
                   "token": "eyJhbGciOiJIUzy***"
                 },
                 "accessControl": {
                   "role": "DataAnalyst",
                   "permissions": ["read:data", "write:reports"]
                 },
                 "dataProtection": {
                   "encryptionEnabled": true,
                   "encryptionAlgorithm": "AES-256"
                 }
               }
             }
           }

                      Figure 2: Agent Context Message

4.  Agent Context Protocol

   The Agent Context Protocol is used to exchange agent context message
   defined in section 3 between agents.  The Agent Context Protocol is
   based on the JSON format and uses HTTP as the underlying transport
   protocol.  The Agent Context Protocol support bidirectional
   communication between agents(TBD).

5.  IANA Considerations

   TBD








Liu                      Expires 24 January 2026                [Page 7]

Internet-Draft              Abbreviated Title                  July 2025


6.  Security Considerations

   The Agent Context Message should be protected by encryption and
   authentication (TBD).  Since the intent of this Agent Context Message
   is to provide soft guidance and the Agent Context Message should
   never be load bearing on security.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Acknowledgements

   The author would like to thank Jason Clinton, CISO of Anthropic for
   his constructive suggestions and review.

Contributors

   TBD

Author's Address

   Dapeng Liu (editor)
   Alibaba
   Beijing
   Beijing
   100035
   China
   Email: max.ldp@alibaba-inc.com













Liu                      Expires 24 January 2026                [Page 8]


name: draft-zheng-dispatch-agent-identity-management
rev: 00
title: Agent Identity Managenment
time: 2025-11-03T09:24:50Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-07T09:24:50Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420353+00:00
abstract:
This document specifies agent identity management in the Internet of
   Agents (IOA) system.  It defines the descriptive requirements for
   agent identities, the agent registration process, the structure and
   assignment of agent identifiers, and the basic and extended identity
   management functions performed by the agent gateway based on the
   agent's descriptive information.

full_text:
Dispatch                                                        C. Zheng
Internet-Draft                                                    B. Liu
Intended status: Standards Track                                 N. Geng
Expires: 7 May 2026                                               Q. Gao
                                                                X. Shang
                                                                   Z. Li
                                                     Huawei Technologies
                                                         3 November 2025


                       Agent Identity Managenment
           draft-zheng-dispatch-agent-identity-management-00

Abstract

   This document specifies agent identity management in the Internet of
   Agents (IOA) system.  It defines the descriptive requirements for
   agent identities, the agent registration process, the structure and
   assignment of agent identifiers, and the basic and extended identity
   management functions performed by the agent gateway based on the
   agent's descriptive information.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 May 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights



Zheng, et al.              Expires 7 May 2026                   [Page 1]

Internet-Draft         Agent Identity Managenment          November 2025


   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Overview of the Agent Identity Management . . . . . . . . . .   3
   3.  Agent description Requirements  . . . . . . . . . . . . . . .   4
     3.1.  Basic Information . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Extended Information  . . . . . . . . . . . . . . . . . .   6
   4.  Agent Identity Registration . . . . . . . . . . . . . . . . .   7
   5.  Agent Identity management . . . . . . . . . . . . . . . . . .   7
     5.1.  Agent Identifier  . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Agent Identity Basic Managenment  . . . . . . . . . . . .   9
     5.3.  Agent Identity Extended Management  . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   As intelligent agents become increasingly prevalent in distributed
   and interoperable systems, robust identity management is essential to
   ensure secure, scalable, and policy-compliant operation.  In the
   Internet of Agents (IOA) system, agents—ranging from simple
   automation scripts to high-intelligence autonomous entities—must be
   uniquely identified, authenticated, and governed throughout their
   lifecycle.

   This document outlines the foundational framework for agent identity
   management in the IOA system.  It specifies the required descriptive
   attributes of an agent, the registration process with the agent
   gateway, the format and semantics of agent identifiers, and the basic
   and extended management capabilities enabled by the agent’s identity
   metadata.  While security mechanisms such as authentication protocols
   and cryptographic binding are acknowledged as critical, their
   detailed specification is considered out of scope for this document.










Zheng, et al.              Expires 7 May 2026                   [Page 2]

Internet-Draft         Agent Identity Managenment          November 2025


1.1.  Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Overview of the Agent Identity Management

   The agent identity management architecture in the IOA system
   comprises four core functional modules: Agent Description, Agent
   Identity Registration, Agent Identity Management, and Security
   Considerations.  First, an agent's identity information MUST be
   represented in a normalized form.  The agent then registers this
   normalized identity description with an Agent Gateway.  Upon
   successful authentication of the registering agent, the Agent Gateway
   assigns a unique Agent ID to the agent and, using the Agent ID as a
   key, enforces identity management policies based on the agent's
   normalized identity description.































Zheng, et al.              Expires 7 May 2026                   [Page 3]

Internet-Draft         Agent Identity Managenment          November 2025


                  Agent Gateway
                  +-------------------------------------------+
                  |                                           |
                  | +-------------------------------------+   |
        /---------+-|          Identity Management        |<--+----------\
        |         | +++-----------------------------------+   |          |
        |         |  ||   +--------------------------+        |          |
        |         |  ||-->|Agent ID:Basic Managemnt  |        |          |
        |         |  |    +--------------------------+        |          |
        |         |  |   +---------------------------+        |          |
        |         |  |--->|Agent ID:Basic Managemnt  |        |          |
        |         |       +--------------------------+        |          |
        |         +-------------------------------------------+          |
        |                                                                |
        |<----------------Agent Identity Registion---------------------->|
        |                                                                |
        |        Agent                                                   |
        |         +----------------------------+                         |
        |         | +----------------------+   |                         |
        |         | |      Description     |---+-------------------------/
        |         | +++--------------------+   |
        |         |  ||  +-----------------+   |
        |         |  ||->|Basic Information|   |
        |         |  |   +-----------------+   |
        |         |  |   +------------------+  |
        |         |  |-->|Extend Information|  |
        |         |      +------------------+  |
        |         |                            |
        |         |      +-----------------+   |
        \---------+----->|    Agent ID     |   |
                  |      +-----------------+   |
                  +----------------------------+

           Figure 1: Agent identity management architecture

3.  Agent description Requirements

   To enable accurate agent identity management on the agent gateway, it
   is necessary to define a set of essential information elements for
   describing an agent.

3.1.  Basic Information

   The agent description MUST include the following base information
   elements:

   *  Agent name




Zheng, et al.              Expires 7 May 2026                   [Page 4]

Internet-Draft         Agent Identity Managenment          November 2025


   *  Agent capabilities/skills

   *  Agent author

   *  Agent version

   *  Agent creation time

   *  Agent description model version

   *  Agent location

   *  Agent communication protocol

   *  Agent description (human-readable)

   *  Agent signature

   In addition, the following attributes MUST also be included as part
   of the base information:

   *  Agent validity period

   *  Agent form factor

   *  Agent intelligence level

   *  Agent extended profile URI

   *  Agent role

   *  Translation enablement indicator

   Usecases

   *  Agent validity period: The validity period of an agent on the
      agent gateway specifies the time interval during which the agent
      is considered active and authorized for operation.  The agent
      gateway MAY use this field to enforce publication and maintenance
      policies, automatically deactivating or removing expired or stale
      ("zombie") agents to reduce operational overhead and minimize the
      burden of agent lifecycle management.









Zheng, et al.              Expires 7 May 2026                   [Page 5]

Internet-Draft         Agent Identity Managenment          November 2025


   *  Agent form factor: The form of the agent, such as digital agent or
      embodied agent.  The form field can support the interconnection of
      heterogeneous forms of agents in future IOA systems.  For example,
      agent gateways may have different requirements for access
      authentication and policy control for agents of different forms.
      Communication protocols between agents of different forms may also
      differ.

   *  Agent intelligence level: The intelligence level of an agent can
      be defined using mainstream AI agent intelligence classification
      standards in the future.  This will help application agents to
      select the final communication target among a group of candidate
      agents based on the required intelligence level.  For example,
      when agents have the same capabilities, the one with a higher
      intelligence level can be chosen.

   *  Agent extended profile URI: The address accessible for the
      extended version of the agent.  It helps to continuously and
      dynamically upgrade and update the agent during its online period
      on the extended version address.

   *  Agent role: The roles of agents include two types: consumer and
      producer.  An agent can also assume both roles.  This helps the
      agent gateway determine whether to establish a short connection or
      a long connection with the agent.  It also assists the gateway in
      formulating control strategies when publishing agent information
      on the network, for example, by not publishing information for
      consumers who do not provide services.

   *  Translation enablement indicator: This field describes whether the
      agent message allows the gateway to perform message translation.
      It helps the agent gateway to translate heterogeneous protocol
      communications between agents while respecting the agent's
      preferences.  For example, in scenarios where semantic translation
      might occur, the agent can use this field to protect its data
      privacy.

3.2.  Extended Information

   The agent description SHOULD include the following extended
   information elements:

   *  Network requirements

   *  Trust level

   *  Extension




Zheng, et al.              Expires 7 May 2026                   [Page 6]

Internet-Draft         Agent Identity Managenment          November 2025


   Usecases

   *  Network requirements: The requirements of agents for the network
      include three aspects: experience, monitoring, and security.
      These help the agent gateway implement on-demand QoS guarantee
      strategies (e.g., low latency assurance or high bandwidth
      assurance), security assurance strategies (e.g., path security,
      quantum encryption for communication), and agent task monitoring
      and maintenance strategies (e.g., agent task flow measurements at
      the stream level, packet level, segment level, and etc.).

   *  Trust level: The agent's permission scope defines the boundaries
      of its authorized operations and data access.  This attribute
      enables the agent gateway to enforce fine-grained access control
      policies—for example, restricting agent data from leaving a
      specific administrative domain such as a campus or a
      country—thereby supporting regulatory compliance and data
      sovereignty requirements.

   *  Extension: An extensible information field is provided as a
      reserved mechanism to accommodate future dynamic attributes of the
      agent.

4.  Agent Identity Registration

   The agent MUST register its descriptive information with the agent
   gateway to enable the gateway to perform identity management based on
   this description.  The specific registration interaction protocol
   between the agent and the gateway is outside the scope of this draft.

   Upon receiving an agent's registration information, the agent gateway
   MUST first perform identity authentication.  The specific
   authentication mechanism is outside the scope of this document.
   Following successful authentication, the gateway proceeds to the next
   step of agent identity management.

5.  Agent Identity management

   The agent gateway MUST first assign a unique identifier to the agent.
   Using this identifier as a key, the gateway can perform both basic
   and extended identity management functions by correlating it with the
   agent's descriptive information.









Zheng, et al.              Expires 7 May 2026                   [Page 7]

Internet-Draft         Agent Identity Managenment          November 2025


5.1.  Agent Identifier

   The agent identifier (agent ID) is used to uniquely represent an
   agent within the IOA system.  Specific approaches for constructing
   this identifier MAY employ a hierarchical string scheme (e.g.,
   incorporating domain, subdomain, and instance components) or
   alternatively use a standardized encoding of such a hierarchical
   string (e.g., via URI, UUID, or other IETF-recognized identifier
   formats) to ensure global uniqueness, interoperability, and ease of
   parsing.

   Below is an example definition of an agent identifier in the form of
   a hierarchical string:

   orgtype:org/internal enterprise namespace/client-id

   Where:

   *  orgtype indicates the standardized type or schema that the org
      field conforms to.  This enables consistent interpretation and
      validation of the organizational context associated with the
      agent, such as whether the organization is identified according to
      a public registry (e.g., PENs for orgnizations [RFC9371]), or
      another recognized naming authority.

   *  org field identifies the enterprise or organization to which the
      agent belongs, in accordance with the standard specified by the
      orgtype field.This ensures that the organizational identifier is
      interpreted consistently and unambiguously according to the
      referenced naming scheme or registry.

   *  internal enterprise namespace is defined and managed autonomously
      by the enterprise itself.  It provides a private, organization-
      specific naming scheme for identifying agents, organizational
      units, or other entities within the enterprise’s administrative
      domain, without reliance on external registries or global
      standards.

   *  client-id serves as a locally unique identifier for the agent
      within its administrative or operational domain.  It MAY be
      assigned by the agent gateway upon registration, or alternatively
      issued by a Certificate Authority (CA) during the agent identity
      signing process, ensuring uniqueness and cryptographic binding to
      the agent’s identity credentials.







Zheng, et al.              Expires 7 May 2026                   [Page 8]

Internet-Draft         Agent Identity Managenment          November 2025


5.2.  Agent Identity Basic Managenment

   Based on the base information contained in the agent description, the
   agent gateway can perform fundamental identity management functions
   using the agent ID as the primary key.

   Agent ID : Basic Management functions

   These functions include, but are not limited to:

   *  Identity verification management: validating the authenticity and
      integrity of the agent using attributes such as name, signature,
      and author.

   *  Capability classification management: categorizing agents
      according to their declared skills/capabilities for policy-based
      routing or service matching.

   *  Communication protocol management: enforcing or negotiating
      supported communication protocols to ensure interoperability.

   *  Lifecycle management: tracking and controlling the agent’s
      operational state (e.g., creation, activation, expiration,
      revocation) based on attributes such as creation time and validity
      period.

   *  Form factor classification management: grouping agents by their
      form (e.g., embedded, digital) for resource allocation or policy
      application.

   *  Intelligence level management: applying differentiated handling
      policies based on the agent’s declared intelligence level.For
      example, the agent gateway MAY apply behavior monitoring policies
      of varying intensity based on the agent's declared intelligence
      level, thereby preventing high-intelligence agents from performing
      unauthorized or out-of-scope actions.

   *  Extended profile management: referencing and validating the
      agent’s extended profile URI for dynamic or context-specific
      attributes.

   *  Role-based classification management: assigning or enforcing
      permissions and behaviors according to the agent’s declared role.

   *  Communication translation management: enabling or disabling
      protocol or semantic translation based on the translation
      enablement indicator.




Zheng, et al.              Expires 7 May 2026                   [Page 9]

Internet-Draft         Agent Identity Managenment          November 2025


   These management functions collectively support scalable, secure, and
   policy-compliant operation of agents within the IOA system.

5.3.  Agent Identity Extended Management

   By leveraging the extensible information included in the agent
   description, the agent gateway can perform enhanced identity
   management functions beyond the base set.

   Agent ID : Extended Management functions

   These extended management functions include:

   *  Agent network service management: dynamically provisioning,
      monitoring, or orchestrating network services associated with the
      agent (e.g., QoS requirements, connectivity policies, security
      assurance, and etc.).

   *  Agent permission management: enforcing fine-grained, context-aware
      access control policies based on extended permission scopes, such
      as data residency constraints (e.g., "data must not leave the
      campus or country").

   *  Future extensible identity management functions: supporting
      additional identity-related features that may be defined in future
      specifications, such as behavioral attestation, perfermence
      scoring, or integration with decentralized identity frameworks.

   The extensible information field is designed to be forward-
   compatible, enabling the agent gateway to adapt to evolving
   operational, regulatory, or architectural requirements without
   requiring changes to the core agent description model.

6.  Security Considerations

   Security is a critical consideration in agent identity management.
   This includes authenticating and validating the agent’s identity
   during registration, ensuring the integrity and non-repudiation of
   the agent identifier (e.g., to prevent tampering or spoofing), and
   enforcing access control policies for agent onboarding and
   interaction.  However, the specific security mechanisms and detailed
   considerations related to these aspects are outside the scope of this
   document.

7.  IANA Considerations

   TBD




Zheng, et al.              Expires 7 May 2026                  [Page 10]

Internet-Draft         Agent Identity Managenment          November 2025


8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Chong Zheng
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: zhengchong6@huawei.com


   Bing Liu
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: leo.liubing@huawei.com


   Nan Geng
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: gengnan@huawei.com


   Qiangzhou Gao
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: gaoqiangzhou@huawei.com








Zheng, et al.              Expires 7 May 2026                  [Page 11]

Internet-Draft         Agent Identity Managenment          November 2025


   Xiaotong Shang
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: shangxiaotong@huawei.com


   Zhenbin Li
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: robinli314@163.com





































Zheng, et al.              Expires 7 May 2026                  [Page 12]

categories:
["Identity / authentication for AI agents", "Agent discovery / registration", "Agent-to-agent communication protocols"]


name: draft-zhang-rtgwg-ai-agents-troubleshooting
rev: 00
title: Use Cases and Requirements of Communication Protocol for Troubleshooting Agents on Network Devices
time: 2025-11-03T01:48:49Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-07T01:48:49Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent-to-agent communication protocols", "Autonomous network operations"]
tags: []
fetched_at: 2026-02-27T22:56:03.420356+00:00
abstract:
This document focuses on the use cases and requirements of
   communication protocols for troubleshooting agents on network
   devices.

full_text:
rtgwg                                                           R. Zhang
Internet-Draft                                                    J. Mao
Intended status: Informational                                    B. Liu
Expires: 7 May 2026                                              N. Geng
                                                                X. Shang
                                                                  Q. Gao
                                                                   Z. Li
                                                                  Huawei
                                                         3 November 2025


Use Cases and Requirements of Communication Protocol for Troubleshooting
                       Agents on Network Devices
             draft-zhang-rtgwg-ai-agents-troubleshooting-00

Abstract

   This document focuses on the use cases and requirements of
   communication protocols for troubleshooting agents on network
   devices.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://example.com/LATEST.  Status information for this document may
   be found at https://datatracker.ietf.org/doc/draft-zhang-rtgwg-ai-
   agents-troubleshooting/.

   Discussion of this document takes place on the rtgwg Working Group
   mailing list (mailto:WG@example.com), which is archived at
   https://example.com/WG.

   Source for this draft and an issue tracker can be found at
   https://github.com/USER/REPO.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.





Zhang, et al.              Expires 7 May 2026                   [Page 1]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 May 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Use Case 1: Data Center Network . . . . . . . . . . . . .   4
     3.2.  Use Case 2: Campus Network  . . . . . . . . . . . . . . .   7
     3.3.  Use Case 3: IoT Edge Network  . . . . . . . . . . . . . .   9
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Data Transport Requirement  . . . . . . . . . . . . . . .  10
       4.1.1.  Data Format . . . . . . . . . . . . . . . . . . . . .  10
       4.1.2.  Streaming Capabilities  . . . . . . . . . . . . . . .  11
       4.1.3.  Transaction Integrity . . . . . . . . . . . . . . . .  11
     4.2.  Protocol Implementation Requirements  . . . . . . . . . .  11
       4.2.1.  Mandatory Transport Security  . . . . . . . . . . . .  11
       4.2.2.  Standardized Error Handling . . . . . . . . . . . . .  12
       4.2.3.  Message Prioritization and Preemption . . . . . . . .  12
     4.3.  Operational Requirements  . . . . . . . . . . . . . . . .  12
       4.3.1.  Interoperability and Versioning . . . . . . . . . . .  12
       4.3.2.  Resource Management . . . . . . . . . . . . . . . . .  12
       4.3.3.  Observability and Audit . . . . . . . . . . . . . . .  12
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  13
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13



Zhang, et al.              Expires 7 May 2026                   [Page 2]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


1.  Introduction

   This document focus on communication protocols and associated
   requirements for network troubleshooting interactions among agents on
   network devices.  As modern networks evolve toward greater complexity
   and dynamism, traditional centralized management systems face
   significant challenges in real-time fault detection and resolution.
   Intelligent agents embedded within network devices represent a
   paradigm shift toward distributed, autonomous network operations.
   This draft addresses the need for standardized communication
   methodologies that enable these agents to collaboratively identify,
   diagnose, and recover network issues across diverse environments.

   The contents of this document are as follows:

   First, this document introduces three use cases to illustrate
   communication workflows between network device agents during
   troubleshooting.  Second, this document analyzes existing transport
   protocols for these interactions, highlighting the strengths and
   limitations for agent scenarios.  Finally, this document establishes
   fundamental requirements for implementing effective agent-to-agent
   troubleshooting systems.  By analyzing those interoperable
   communication modes, this draft aims to facilitate the development of
   self-healing networks capable of maintaining service levels despite
   increasing operational complexity.

   The use cases and requirements outlined herein are designed to be
   applicable across various network domains, including data center
   networks, campus networks, and IoT edge networks.

2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Troubleshooting Agent: An agent that runs on network devices to
   identify, diagnose, and recover from network failures.

3.  Use Cases









Zhang, et al.              Expires 7 May 2026                   [Page 3]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


3.1.  Use Case 1: Data Center Network

   In a large-scale data center network, multiple troubleshooting agents
   on network devices, such as switches and routers, need to
   collaboratively identify and diagnose a transient latency issue
   affecting application performance.  The troubleshooting workflow
   begins when an application performance monitoring agent detects
   elevated response times and assign a diagnosis task to
   troubleshooting agents on network devices.  The application
   performance monitoring agent also can reports this issue to the agent
   on the network controller, which then notifies troubleshooting agents
   on network devices to root the cause of this performance issue.  The
   ways by which troubleshooting agents on network devices receive tasks
   is beyond the scope of this draft.

   For this use case, a high-performance, low-cost communication
   protocol is required.  In existing works, gRPC provides significant
   advantages for this scenario.  This part takes gRPC as an example.

   When a troubleshooting agent on the network device receives a task to
   identify, diagnose, and recover from network failures, the
   communication flow may same as this figure.

  +--------------------+  1. establishes connection  +-----------------+
  | +----------------+ +----------------------------->  +-----------+  |
  | |                | | 2. request for related data |  |           |  |
  | |Initiating Agent| +----------------------------->  |   Agent   |  |
  | |                | |        3. response          |  |           |  |
  | +----------------+ <-----------------------------+  +-----------+  |
  |                    | 4. share analysis results   |    Relevant     |
  |   Network Device   +-----------------------------> Network Devices |
  +--------------------+                             +-----------------+

   Figure: Data Center Networks

   The communication flow includes these steps as follows.  This
   document provides message examples for each step.

   Step 1, the initiating agent establishes connections with relevant
   network device agents.  This step may include some security-related
   steps and description about failure.










Zhang, et al.              Expires 7 May 2026                   [Page 4]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


   {
           "Sender": "Agent-I",
           "Failure":
           {
                   "Location": "Host 1",
                   "Type": "Packet loss rate greater than threshold",
                   "Description": "...",
           },
           "Solution":
           {
           },
           "Analysis":
           {
           },
           ...
   }

   Step 2, through bidirectional connection, the initiator requests
   real-time telemetry data including interface statistics, queue
   depths, and latency measurements.

   The request message of initiator could be as following.





























Zhang, et al.              Expires 7 May 2026                   [Page 5]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


   {
           "Sender": "Agent-I",
           "Failure":
           {
                   "Location": "Host 1",
                   "Type": "Packet loss rate greater than threshold",
                   "Description": "...",
           },
           "Solution":
           {
                   "RelatedNetDevice1":
                   {
                           "Type": "Request",
                           "Resource": "Data",
                           "Description": "Traffic patterns of the device's ingress and egress over a certain period of time.",
                           "TransMehtods": ["gRPC", "QUIC"]
                   },
                   "RelatedHost2":
                   {
                           "Type": "Request",
                           "Resource": "Method",
                           "Description": "The device needs to send colored packets to collect path data."
                   },
                   ....
           },
           "Analysis":
           {
           },
           ...
   }

   Step 3, network agents respond with telemetry data in real-time.  The
   related network device would send this message as response.


















Zhang, et al.              Expires 7 May 2026                   [Page 6]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


   {
           "Sender": "Agent-D",
           "Response":
           {
                   "Resource": "Data",
                   "Data":
                   {
                           "Description": "Traffic patterns of this device's ingress and egress over a certain period of time.",
                           "TransMethods": "gRPC",
                           ...
                   }
                   ....
           },
           ...
   }

   Step 4, optionally, the initiating agent share analysis results
   through the same channels, enabling collaborative root cause
   identification.

   Step 5, once the root casue of the failure is identified, agents
   negotiate and implement traffic engineering adjustments.

3.2.  Use Case 2: Campus Network

   A network segmentation issue in an enterprise campus requires
   verification of consistent policy application across multiple
   security domains.  Agents residing in firewalls, switches, and
   wireless controllers must collaboratively audit their configurations
   against intended policies to identify discrepancies causing the
   segmentation failure.

   For this use case, a configuration-oriented troubleshooting scenario,
   HTTP-based RESTCONF offers several benefits.  This part takes
   RESTCONF as an example.  The RESTful architecture provides familiar,
   standardized operations (GET, PATCH, DELETE) for configuration
   manipulation.  YANG data modeling ensures semantic consistency across
   multi-vendor environments, crucial for accurate policy verification.
   HTTP/2's header compression and request multiplexing improve
   efficiency when interacting with numerous agents simultaneously.  The
   protocol's stateless nature simplifies error recovery, while
   standardized status codes and error responses enable predictable
   failure handling.  Rich authentication mechanisms integrate
   seamlessly with existing enterprise security infrastructures.
   However, RESTCONF lacks streaming capabilities for real-time
   telemetry exchange.





Zhang, et al.              Expires 7 May 2026                   [Page 7]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


   In this use case, the agent who is informed to complete this task is
   named coordinator agent.

                        +-----------------------+
                        | +-------------------+ |
                        | |                   | |
                        | | Coordinator Agent | |4. process data
                        | |                   | |
                        | +-------------------+ |
                        |                       |
                        |     Network Device    |
                        +---^------+------------+
                            |      |1. establishes connections
                            |      |2. queries configuration data
            +---------------+------++------------------------+
            |               |       |5. pushes configuration adjustments
            |  3. response  +-------+---------------+        |
            |        +------+       |               |        |
   +--------v--------+     ++-------v--------+     ++--------v-------+
   |   +---------+   |     |   +---------+   |     |   +---------+   |
   |   |  Agent  |   |     |   |  Agent  |   |     |   |  Agent  |   |
   |   +---------+   |     |   +---------+   |     |   +---------+   |
   |                 |     |                 |     |                 |
   | Network Device  |     | Network Device  |     | Network Device  |
   +-----------------+     +-----------------+     +-----------------+

   Figure: Campus Networks

   The communication flow includes these steps:

   1.  A coordinator agent establishes connections with relevant network
       agents.

   2.  The coordinator queries configuration data from multiple device
       agents using standardized YANG data models.

   3.  Each agent responds with structured configuration data
       representing its current operational state.

   4.  The coordinator analyzes the collective configuration data,
       identifies inconsistencies in access control lists and routing
       policies, and generates remediation instructions.

   5.  Using RESTCONF PATCH operations or other network management
       operations, the coordinator pushes configuration adjustments to
       specific agents.





Zhang, et al.              Expires 7 May 2026                   [Page 8]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


   6.  Agents respond with structured error messages if operations fail,
       enabling precise fault localization.

3.3.  Use Case 3: IoT Edge Network

   In an IoT edge network, multiple constrained devices experience
   intermittent connectivity issues.  Lightweight agents on these
   devices must efficiently share fault information and coordinate
   recovery actions while conserving bandwidth and battery resources.

   In IoT network, MQTT protocol is used widely.  This part takes MQTT
   as an example.  MQTT's publish-subscribe model offers distinct
   advantages for distributed troubleshooting scenarios.  The decoupled
   communication pattern allows agents to exchange information without
   direct connections, reducing coordination overhead.  Configurable QoS
   levels enable reliability matching for different message.  For
   example, types—QoS 0 for non-critical telemetry, QoS 1 for important
   fault notifications, and QoS 2 for critical configuration changes.
   The minimal protocol overhead conserves bandwidth and battery life on
   constrained devices.  Last Will and Testament features ensure other
   agents are notified when a device becomes unreachable, enabling rapid
   detection of network partitions.  The topic-based routing simplifies
   message filtering and delivery to interested parties only.

                                                       +----------------+
                                                       |    +-------+   |
                                                       |    | Agent |   |
                                                      ++    +-------+   |
                                                      || Network Device |
2. Identify faiulres  3.publish a failure report      |+----------------+
     +----------------+    +---------------+    1. Subscribe------------+
     |    +-------+   <----++-------------+<----------+|    +-------+   |
     |    | Agent |   |    || MQTT Broker ||          ++    | Agent |   |
     |    +-------+   |    |+-------------+|          ||    +-------+   |
     | Network Device |    | Network Edge  +---------->| Network Device |
     +-------------^--+    +---------------+4. Notification-------------+
                   |                                  |+----------------+
                   +----------------------------------++    +-------+   |
                 5. Offer related data and resources  ||    | Agent |   |
                                                      ++    +-------+   |
                                                       | Network Device |
                                                       +----------------+

   Figure: IoT Edge Networks

   The communication flow includes these steps:





Zhang, et al.              Expires 7 May 2026                   [Page 9]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


   1.  Agents subscribe to relevant fault notification topics on an MQTT
       broker deployed at the network edge.

   2.  The agent on the network device which happened a network failure
       identifies the network failure.

   3.  Agent publishes a structured failure report to appropriate
       topics.

   4.  Subscribed agents receive the notification and contribute
       additional context from their perspectives.

   5.  The subscribed agents may offer some data and resources to
       diagnose or recover FROM this failure.

   6.  The agent on the network device that caused this failure recovers
       the failure or reports it.

4.  Requirements

   According to those use cases, this draft concludes requirements of
   communication protocol for network troubleshooting interactions among
   agents on network devices.

4.1.  Data Transport Requirement

4.1.1.  Data Format

   The interaction between Agents should use human-readable language,
   e.g., natural language.  However, in terms of communication
   performance, messages delivered by agents should be encapsulated in
   structured format.  The message sent by agent would be as follows.



















Zhang, et al.              Expires 7 May 2026                  [Page 10]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


   {
           "Sender": "Agent",
           "Failure":
           {
                   "Location": "..",
                   "Type": "...",
                   "Description": "...",
           },
           "Solution":
           {
           },
           "Analysis":
           {
           },
           ...
   }

4.1.2.  Streaming Capabilities

   Troubleshooting agents MUST support bidirectional streaming for real-
   time telemetry exchange and collaborative analysis.  Streaming
   implementations SHOULD include flow control mechanisms to prevent
   resource exhaustion and MUST maintain message ordering within
   streams.  Agents SHOULD implement priority handling for critical
   troubleshooting messages within streams to ensure timely delivery of
   urgent notifications.

4.1.3.  Transaction Integrity

   For configuration modifications during troubleshooting, agents MUST
   implement transactional semantics to maintain network consistency.
   Multi-agent transactions SHOULD support two-phase commit protocols or
   equivalent distributed consensus mechanisms.  All configuration
   changes MUST be idempotent to allow safe retransmission in case of
   delivery uncertainties.

4.2.  Protocol Implementation Requirements

4.2.1.  Mandatory Transport Security

   All inter-agent communications MUST employ transport-layer security
   (TLS 1.2 or higher) with mutual authentication.  Certificate-based
   authentication is PREFERRED over pre-shared keys for scalable
   deployment.  Agents MUST implement certificate revocation checking
   and SHOULD support forward secrecy cipher suites.






Zhang, et al.              Expires 7 May 2026                  [Page 11]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


4.2.2.  Standardized Error Handling

   Agents MUST implement consistent error reporting mechanisms across
   all communication protocols.  Error responses MUST include machine-
   readable error codes, human-readable descriptions, and suggested
   remediation actions.  Protocol-specific error mappings SHOULD be
   defined to translate underlying transport errors to application-level
   troubleshooting semantics.

4.2.3.  Message Prioritization and Preemption

   Troubleshooting systems MUST implement message prioritization to
   ensure critical fault notifications receive appropriate network
   resources.  Agents SHOULD support preemption of lower-priority
   communications when high-priority troubleshooting sessions require
   immediate attention.  Quality of Service differentiation SHOULD be
   implemented at both transport and application layers.

4.3.  Operational Requirements

4.3.1.  Interoperability and Versioning

   Agents MUST implement protocol version negotiation to maintain
   backward compatibility during upgrades.  Data schema evolution SHOULD
   follow compatibility rules that prevent communication breakdowns.
   Agents SHOULD support graceful degradation of functionality when
   communicating with older implementations.

4.3.2.  Resource Management

   Agent implementations MUST include configurable resource limits to
   prevent exhaustion during mass troubleshooting events.  Memory,
   bandwidth, and processing quotas SHOULD be enforced per communication
   session.  Agents MUST implement circuit breaker patterns to isolate
   misbehaving peers and maintain overall system stability.

4.3.3.  Observability and Audit

   All troubleshooting communications MUST be logged with sufficient
   detail to reconstruct decision processes.  Log entries SHOULD include
   message timestamps, participant identities, and semantic content
   summaries.  Audit trails MUST be protected against tampering and
   available for post-incident analysis.

5.  Security Considerations

   TBD




Zhang, et al.              Expires 7 May 2026                  [Page 12]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


6.  IANA Considerations

   This document has no IANA actions.

7.  Conclusion

   TBD

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Ruyi Zhang
   Huawei
   Email: zhangruyi8@huawei.com


   Jianwei Mao
   Huawei
   Email: maojianwei@huawei.com


   Bing Liu
   Huawei
   Email: leo.liubing@huawei.com


   Nan Geng
   Huawei
   Email: gengnan@huawei.com


   Xiaotong Shang
   Huawei
   Email: shangxiaotong@huawei.com



Zhang, et al.              Expires 7 May 2026                  [Page 13]

Internet-Draft  Use Cases and Requirements of Communicat   November 2025


   Qiangzhou Gao
   Huawei
   Email: gaoqiangzhou@huawei.com


   Zhenbin Li
   Huawei
   Email: robinli314@163.com











































Zhang, et al.              Expires 7 May 2026                  [Page 14]


name: draft-zl-agents-networking-framework
rev: 00
title: Agents Networking Framework for Enterprise and Broadband
time: 2025-11-02T09:03:16Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T09:03:16Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420358+00:00
abstract:
This document introduces agents networking framework and defines the
   core components of agent networking in enterprise and broadband, as
   well as typical interactions among these key components.

full_text:
rtgwg                                                           L. Zhang
Internet-Draft                                                    B. Liu
Intended status: Informational                                   N. Geng
Expires: 6 May 2026                                             X. Shang
                                                                  Q. Gao
                                                                   Z. Li
                                                     Huawei Technologies
                                                         2 November 2025


        Agents Networking Framework for Enterprise and Broadband
                draft-zl-agents-networking-framework-00

Abstract

   This document introduces agents networking framework and defines the
   core components of agent networking in enterprise and broadband, as
   well as typical interactions among these key components.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 6 May 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Zhang, et al.              Expires 6 May 2026                   [Page 1]

Internet-Draft         Agents Networking Framework         November 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  IoA framework and Components  . . . . . . . . . . . . . . . .   3
     2.1.  Overview of Agents Networking . . . . . . . . . . . . . .   3
     2.2.  Agent Certificate Authority . . . . . . . . . . . . . . .   4
     2.3.  Agent Registration Server . . . . . . . . . . . . . . . .   4
     2.4.  AI Agents . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.5.  Agent Gateway . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Interactions of Agents Networking framework . . . . . . . . .   6
     3.1.  Interactions between Agents and ACAs  . . . . . . . . . .   6
       3.1.1.  Certificate Application . . . . . . . . . . . . . . .   6
       3.1.2.  Certificate Management  . . . . . . . . . . . . . . .   7
     3.2.  Interactions between Agents and ARSs  . . . . . . . . . .   8
       3.2.1.  Registration  . . . . . . . . . . . . . . . . . . . .   8
       3.2.2.  Information Management  . . . . . . . . . . . . . . .   8
       3.2.3.  Agents Discovery  . . . . . . . . . . . . . . . . . .   9
     3.3.  Interactions between Agents and AGws  . . . . . . . . . .   9
       3.3.1.  Status Maintenance  . . . . . . . . . . . . . . . . .   9
       3.3.2.  Collaboration Support . . . . . . . . . . . . . . . .  10
     3.4.  Interactions between AGws and AGws  . . . . . . . . . . .  10
       3.4.1.  AGw Interconnection . . . . . . . . . . . . . . . . .  10
       3.4.2.  Resources Synchronization . . . . . . . . . . . . . .  11
       3.4.3.  Status Maintenance  . . . . . . . . . . . . . . . . .  11
       3.4.4.  Relay Forwarding  . . . . . . . . . . . . . . . . . .  12
     3.5.  Interactions between ARSs . . . . . . . . . . . . . . . .  12
   4.  Operational and Manageability Considerations  . . . . . . . .  12
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13









Zhang, et al.              Expires 6 May 2026                   [Page 2]

Internet-Draft         Agents Networking Framework         November 2025


1.  Introduction

   With the rapid development of artificial intelligence, single-agent
   systems have gradually revealed their limitations in handling
   complex, multi-task, and cross-domain scenarios.  Agent networking,
   as a core paradigm for breaking through individual capabilities and
   achieving collective intelligence, has become a key trend in the
   future development of agents.

   This document introduces agents networking framework and defines the
   core components of agent networking in enterprise and broadband, as
   well as typical interactions among these key components.

1.1.  Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  IoA framework and Components

2.1.  Overview of Agents Networking

   The overall framework of agents networking is shown in Figure 1.

       +-----+         +-----+         |       +-----+          +-----+
       |ACA 1|         | ARS1|-----------------| ARS2|          |ACA 2|
       +--+--+         +--+--+         |       +--+--+          +--+--+
          |               |            |          |                |
          +---+-----------+----+       |       +--+------------+---+
              |                |       |       |               |
          +---+---+        +---+---+   |   +---+---+       +---+---+
          |       |        |       |   |   |       |       |       |
          |Agent a|--------|Agent b|   |   |Agent x|-------|Agent y|
          |       |        |       |   |   |       |       |       |
          +---+---+        +---+---+   |   +---+---+       +---+---+
              |                |       |       |               |
              |            +---+---+   |   +---+---+           |
              +------------| AGw 1 |-------| AGw 2 |-----------+
                           +---+---+   |   +---+---+
               Domain1                 |               Domain2

                   Figure 1: Agents Networking framework






Zhang, et al.              Expires 6 May 2026                   [Page 3]

Internet-Draft         Agents Networking Framework         November 2025


   The framework of agents networking consists of four key components,
   the Agent Certificate Authority(ACA), the Agent Registration
   Server(ARS), the Agents, and the Agent Gateway(AGw).

2.2.  Agent Certificate Authority

   An Agent Certificate Authority (ACA) is essentially a trusted third-
   party organization that issues and manages digital certificates for
   intelligent agents (Agents).  Its core function is to ensure the
   authenticity of Agent identities and the security of their
   interactions.  By issuing digital certificates that contain key data
   such as Agent identity information and public keys, it enables other
   Agents or systems to verify the identity of the Agent, preventing the
   access of counterfeit or malicious Agents.

   The major functions of ACA include Certificate Issuance and
   Certificate Management.

   *  Certificate Issuance: It verifies the real identity of an Agent
      (including developer information, affiliated organization,
      functional permissions, etc.).  After verification, a unique
      digital certificate is generated and issued.

   *  Certificate Management: It is responsible for the full-lifecycle
      management of certificates, including certificate renewal (renewal
      before the expiration of validity period) and revocation (when an
      Agent is deregistered or its key is leaked).

2.3.  Agent Registration Server

   An Agent Registration Server(ARS) is specifically responsible for
   Agent identity registration, capability profiling, and accurate
   discovery-matching.  Acting as the "identity management center" and
   "resource directory library" in the Agent ecosystem.  The major
   functions of ARS include agent registration, agent information
   management, and agent discovery.  The ARS can be either centralized
   or distributed, but regardless of the form, information
   synchronization between different servers is essential.  For easily
   deployment, the ARS also can be integrities in the AGw.

   *  Agent registration: The agent sends a registration request with
      its information, upon the verification is passed, then the ARS
      generates a unique "resource ID" for the Agent, creates a profile
      in the "Agent Database" to record all the agent information.

   *  Information management: It is responsible for the full-lifecycle
      management of Agents profiles, including update (when a gent's
      information changes) and delete (when an Agent is discarded).



Zhang, et al.              Expires 6 May 2026                   [Page 4]

Internet-Draft         Agents Networking Framework         November 2025


   *  Agent Discovery: The ARS maintains a dynamically updated "Agent
      Database" that records key information of all Agents registered at
      this ARS and synchronized from other ARSs.  An agent needs
      collaboration just need to send a capability request to the ARS,
      then the ARS will quickly filter out matching target Agents and
      return them information to the requested agent.

2.4.  AI Agents

   The functions that should be supported for AI Agent interconnection
   include task orchestration, task management, and session management.

   *  Task orchestration: It breaks down complex tasks into subtasks,
      assigns them to Agents with corresponding capabilities, and
      clarifies the collaboration process.  Based on the capabilities of
      each Agent (e.g., a Flight Agent specializes in ticket booking, a
      Visa Agent specializes in visa processing), it plans the execution
      sequence and dependency relationships of tasks to ensure efficient
      resource utilization.

   *  Task Management: It tracks subtask progress, handles exceptions,
      and ensures the overall task progresses as planned.  It monitors
      the execution status of each subtask (e.g., "pending," "in
      progress," "completed," "failed"), records task output results
      (such as flight confirmation numbers and visa documents), and
      addresses issues during execution.

   *  Session Management: It maintains the continuity and integrity of
      interactive sessions, ensuring historical information is traceable
      and context is not disconnected.  It manages the lifecycle of
      conversations between Agents, records all interactive content
      (e.g., instructions, feedback, problem discussions), and provides
      contextual support for subsequent interactions to avoid repeated
      communication.

2.5.  Agent Gateway

   An AGw essentially serves as a "Connection Hub" and "Security
   Steward" in the process of agent communication.  Its core role is to
   resolve interconnection issues between different Agents of different
   domains while ensuring secure, efficient, and orderly communication.
   The AGw should support the following functions:

   *  Route Management: When it comes to cross-domain agent
      communication, an agent or AGw may not be able to directly
      establish a connection with another agent in a different domain
      for some reasons.  In such cases, the AGw needs to have routing
      management function.  The routing management function generates



Zhang, et al.              Expires 6 May 2026                   [Page 5]

Internet-Draft         Agents Networking Framework         November 2025


      dynamic routing entries based on Agent information advertised by
      other AGws, and guides message forwarding between cross-domain
      Agents—essentially acting as a "cross-domain traffic commander"
      for the Agent ecosystem.

   *  Security Protection: Agent communication may involve sensitive
      data (such as user privacy, core business data), and malicious
      external Agents may attempt to forge identities, steal data, or
      launch attacks.  The AGw serves as a core barrier for security
      protection.  The AGw should supports the identity verification of
      Agents, data encryption, and access control for agents.

   *  Traffic Control: If multiple Agents simultaneously send discovery
      requests to the AGw, or concentrate on initiating collaboration
      requests after finding target Agents, the AGw may become
      overloaded or the target Agents may crash.  The AGw should impose
      traffic limits on discovery requests.  For example, it sets a cap
      on the number of discovery queries per Agent per minute to prevent
      malicious Agents from occupying resources with frequent queries.

   *  Dual Translation (Protocol and Language): Agents may face two key
      obstacles to direct communication: inconsistent technical
      protocols and different natural language expressions.  The AGw's
      translation function addresses both issues simultaneously to
      ensure seamless information transmission.  On the one hand, it
      automatically identifies the communication protocol (e.g., HTTP,
      MQTT, gRPC, or custom protocols) and data format (e.g., JSON,
      Protobuf) used by the sending Agent, then converts them into the
      standard protocol/format supported by the receiving Agent.  On the
      other hand, it handles natural language differences between Agents
      (e.g., Agent X uses English to send "Book a twin room" while Agent
      Y only understands Chinese).  The AGw automatically translates the
      content into the target language, ensuring the receiving Agent
      accurately grasps the semantic intent without additional language
      adaptation.

3.  Interactions of Agents Networking framework

3.1.  Interactions between Agents and ACAs

3.1.1.  Certificate Application

   This is the most fundamental first interaction between an agent and
   an ACA.  Its purpose is to enable the Agent to pass the ACA's
   verification and obtain a digital certificate that proves its
   legitimacy.  It includes three steps:





Zhang, et al.              Expires 6 May 2026                   [Page 6]

Internet-Draft         Agents Networking Framework         November 2025


   *  Application request: The Agent sends a certificate application to
      the CA, along with key supporting materials.  These materials
      include identity-verifying information (such as the qualification
      documents of its affiliated organization, the identity of its
      developer), the Agent's own attributes (such as function type,
      permission scope, skills), and a public key for subsequent
      encrypted communication (the Agent retains the corresponding
      private key and does not disclose it to external parties).

   *  Application verification: After receiving the application, the ACA
      checks the authenticity and compliance of the materials.  For
      example, it verifies whether the organization's qualifications are
      valid, whether the public key meets encryption standards, and
      whether the Agent's functions fall within permitted scopes.  If no
      issues are identified, the application is approved.

   *  Certificate generation: Upon approval, the ACA generates a digital
      certificate containing specific information.  This information
      includes the Agent's identity details, public key, certificate
      validity period, and the ACA's digital signature (used to prove
      the certificate is legally issued by the CA).  The CA then sends
      this certificate to the applying Agent.

3.1.2.  Certificate Management

   A certificate is not permanently valid.  The Agent must cooperate
   with the ACA to complete operations such as renewal and revocation,
   ensuring the "digital identity" remains valid and secure.

   *  Certificate status query: The Agent can send a query request to
      the ACA at any time to confirm the current status of its
      certificate—such as whether it is still within the validity period
      or has been revoked due to abnormal circumstances.  This allows
      the Agent to identify and resolve certificate-related issues
      promptly (e.g., applying to the CA for recovery if the certificate
      was incorrectly revoked).

   *  Certificate renewal: When the certificate is about to expire, the
      Agent proactively sends a renewal request to the ACA, along with
      the soon-to-expire old certificate.  If its identity information
      (such as affiliated organization, permissions) has not changed,
      the application materials can be simplified.  After the ACA
      approves the request, it generates a new certificate with an
      updated validity period and sends it to the Agent.  The Agent
      replaces the old certificate with the new one to ensure the
      identity credential remains valid.





Zhang, et al.              Expires 6 May 2026                   [Page 7]

Internet-Draft         Agents Networking Framework         November 2025


   *  Certificate revocation application: If the Agent experiences
      issues such as private key leakage, permanent deactivation of
      functions, or deregistration of its affiliated organization, the
      Agent (or its administrator) sends a certificate revocation
      request to the ACA to invalidate the currently held certificate.
      After confirming the request's legitimacy, the ACA adds the
      certificate to the "Certificate Revocation List (CRL)" to prevent
      the invalid certificate from being misused by others.

3.2.  Interactions between Agents and ARSs

3.2.1.  Registration

   An Agent must first complete registration with the ARS before it can
   be discovered by other Agents and participate in collaboration.  This
   is the foundational interaction between the two parties.  It includes
   three steps:

   *  Registration request: The Agent sends a registration request to
      the ARS, accompanied by its information.  This includes its
      identifier (e.g., Agent name), description of core capabilities
      (e.g., "hotel booking," "data format conversion"), supported
      communication protocols/languages (e.g., HTTP, Chinese), and
      credentials for identity verification (e.g., a digital certificate
      issued by an ACA).

   *  Registration verification: The ARS verifies the legitimacy of the
      Agent's identity (e.g., checking if the CA certificate is valid)
      and confirms the completeness of the registration information.
      Upon successful verification, the ARS creates a profile for the
      Agent in its "Agent Database," recording key data such as the
      Agent's capabilities, online status, and communication address to
      complete the registration.

   *  Registration response: The ARS feeds back results ("registration
      successful" or "registration failed," e.g., due to failed identity
      verification or missing information) to the Agent.

3.2.2.  Information Management

   After registration, the Agent needs to continuously interact with the
   ARS to update its status and information, preventing the ARS's
   profile from becoming "outdated" and causing other Agents to match
   invalid resources.

   *  Information update: If an Agent upgrades its capabilities or
      changes its communication address (e.g., IP change due to server
      migration), it needs to proactively send an "information update



Zhang, et al.              Expires 6 May 2026                   [Page 8]

Internet-Draft         Agents Networking Framework         November 2025


      request" to the ARS with the updated content.  After review, the
      ARS updates the corresponding profile information to ensure the
      accuracy of subsequent query results.

   *  Agent deregistration: When the Agent needs to go offline
      permanently (e.g., function deactivation, dissolution of the
      affiliated entity), it sends a "deregistration request" to the ARS
      with the resource ID.  Upon receipt, the ARS marks the Agent's
      profile as "deregistered" or deletes it from the "discoverable
      resource pool" to avoid invalid queries.

3.2.3.  Agents Discovery

   This is the core service provided by ARS for agents, which helps them
   quickly identify target agents that can solve problems through multi-
   dimensional filtering, avoiding random searches, it includes two
   steps.

   *  Discovery request: If an Agent needs a collaborator with agents
      supporting specific capabilities, it sends a discovery request to
      the ARS, specifying the capabilities and associated other
      requirements.

   *  Discover response: Based on the request criteria, the ARS filters
      matching target Agents from the "Agent Database" and feeds back
      the agent information to Agent A, if the target Agents are in
      other domains, the returned communication address should be the
      AGw addresses of those domains.

3.3.  Interactions between Agents and AGws

   When an agent needs to communicate with an agent in another domain,
   the Communication sessions need to go through the AGw (When the two
   agents are within a single domain, whether a communication session
   needs to go through a AGw can be determined as requirements).

   Interactions between an Agent and an AGw revolve around two core
   scenarios: status maintenance and collaboration support.

3.3.1.  Status Maintenance

   During the Agent's operation, ongoing interactions between the two
   parties are required to ensure stable and secure collaboration,
   primarily involving status synchronization and exception handling.







Zhang, et al.              Expires 6 May 2026                   [Page 9]

Internet-Draft         Agents Networking Framework         November 2025


   *  Agent access: An agent should send an access request to the AGw to
      make it reachable by agents in other domains.  The AGw reviews its
      information and verifies its signature.  If the verification
      passed, then the AGw will create a record for it and advertise the
      agent information to other AGws.

   *  Status synchronization: After accessed, the Agent regularly sends
      "heartbeats" (e.g., every 30 seconds) to the AGw to synchronize
      its online status (e.g., "running normally," "temporarily
      offline").  If the AGw does not receive a "heartbeat" for an
      extended period, it marks the Agent's status as "offline" and
      temporarily removes it from the collaborative list, and
      synchronizes this information to other potentially associated AGw
      to prevent other Agents from initiating invalid requests.

   *  Deregistration request: If an Agent needs to stop services, it
      proactively sends a deregistration request to the AGw.  After
      receiving the request, the AGw deletes the Agent's record, and
      synchronizes this information to other potentially associated AGws
      to complete the exit process.

3.3.2.  Collaboration Support

   When an Agent needs to collaborate with other Agents, the AGw
   provides support for "removing communication barriers".  It is
   composed by two phases.

   *  Transformation: When the AGw receives the message send by the
      request agent with a translation request, the AGw first
      decapsulates the received packet, extracting the original content
      from the message.  Then, it performs necessary adaptations, such
      as translating the content into the target language or converting
      the data structure to match the target protocol.  Finally, the AGw
      re-encapsulates the adapted content into the target Agent's
      protocol format and forwards it.

3.4.  Interactions between AGws and AGws

   Interactions between an AGw and an AGw revolve around four core
   phases: AGw interconnection, resources synchronization, status
   synchronization, and relay forwarding.

3.4.1.  AGw Interconnection

   This phase completes mutual identity verification and initial status
   synchronization between AGws.





Zhang, et al.              Expires 6 May 2026                  [Page 10]

Internet-Draft         Agents Networking Framework         November 2025


   *  Interconnection request: The initiating AGw sends an
      interconnection request(the request and ) to the receiving AGw,
      enclosing core information: its unique AGw ID, supported
      protocols, identity certificate, and current basic operational
      status.

   *  Interconnection response: The receiving AGw verifies the
      initiating AGw's identity and protocol compatibility.  If valid,
      it feeds back its own basic information and records AGw A's
      initial information in its "AGw Neighbor List".  If the
      verification failed, then it rejects the request.

3.4.2.  Resources Synchronization

   Resource synchronization and status maintenance focuses on sharing
   static/dynamic information of registered Agents, ensuring AGws can
   accurately locate potential collaboration partners across domains.

   *  Resource synchronization: AGws exchange the summary of registered
      agents' information, including Agent ID, core capabilities (e.g.,
      "flight booking", "real-time translation"), and supported
      communication protocols/languages (e.g., gRPC, Chinese).  The
      Synchronization take place whenever a new AGw peer is established
      or the registered agents' key information changes.

3.4.3.  Status Maintenance

   The Status Maintenance of AGws is used to ensure the peer AGws are
   online and reachable.

   *  Status synchronization: When the interconnection is established,
      the AGws regularly sends "heartbeats" (e.g., every 30 seconds) to
      the peer AGws to synchronize its online status (e.g., "running
      normally," "temporarily offline").  If the AGw does not receive a
      "heartbeat" for an extended period, it marks the AGw's status as
      "offline" and temporarily removes it from the peer list, and set
      the "applicability" attribut of agents registered at that peer AGw
      as inapplicable.

   *  Disconnection request: If an AGw needs to stop services, it
      proactively sends a disconnection request to its peer AGw.  After
      receiving the request, the peer AGw deletes the AGw from its peer
      list, and remove the Agents registered at that peer AGw from the
      "Agent Database".







Zhang, et al.              Expires 6 May 2026                  [Page 11]

Internet-Draft         Agents Networking Framework         November 2025


3.4.4.  Relay Forwarding

   Relay Forwarding leverages pre-synchronized resource and status data
   to enable seamless data transmission between cross-AGw Agents.

   *  When an AGw receives a packet from its agents to an agent in
      another domain, it will decapsulates the packet and get the "agent
      ID" of the target agent.  Then it looks up the routing table to
      get the target AGw and forward the packet to it (during the
      forwarding, the packet will be encapsulated to adapt to the target
      agent).

3.5.  Interactions between ARSs

   Interactions between ARS focus on "breaking resource silos".  Through
   cross-ARS information synchronization, they enable Agent resources
   managed by different ARSs to be globally discoverable and
   collaborable in a trusted manner.  The detailed interactions between
   ARS can be quit different among different ARS forms, it depends on
   the implement manner of ARS.

   Editors' note: typical interactions between ARS will be provide in
   future.

4.  Operational and Manageability Considerations

   TBD

5.  Security Considerations

   TBD

6.  IANA Considerations

   This document has no IANA actions.

7.  Acknowledgements

   TBD

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.





Zhang, et al.              Expires 6 May 2026                  [Page 12]

Internet-Draft         Agents Networking Framework         November 2025


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Li Zhang
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: zhangli344@huawei.com


   Bing Liu
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: leo.liubing@huawei.com


   Nan Geng
   Huawei Technologies
   Beijing
   China
   Email: gengnan@huawei.com


   Xiaotong Shang
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: shangxiaotong@huawei.com


   Qiangzhou Gao
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: gaoqiangzhou@huawei.com








Zhang, et al.              Expires 6 May 2026                  [Page 13]

Internet-Draft         Agents Networking Framework         November 2025


   Zhenbin Li
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: robinli314@163.com













































Zhang, et al.              Expires 6 May 2026                  [Page 14]

categories:
["Agent discovery / registration", "Identity / authentication for AI agents", "Agent-to-agent communication protocols"]


name: draft-narvaneni-agent-uri
rev: 02
title: The agent:// Protocol -- A URI-Based Framework for Interoperable Agents
time: 2025-10-16T00:10:36Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-19T00:10:36Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420361+00:00
abstract:
This document defines the agent:// protocol, a URI template-based
   framework as described in RFC 6570 for addressing, invoking, and
   interoperating with autonomous and semi-autonomous software agents.
   It introduces a layered architecture that supports minimal
   implementations (addressing and transport) and extensible features
   (capability discovery, contracts, orchestration).  The protocol aims
   to foster interoperability among agents across ecosystems, platforms,
   and modalities, enabling composable and collaborative intelligent
   systems.

full_text:
Independent Submission                                      Y. Narvaneni
Internet-Draft                                    Independent Researcher
Intended status: Experimental                            16 October 2025
Expires: 19 April 2026


The agent:// Protocol -- A URI-Based Framework for Interoperable Agents
                      draft-narvaneni-agent-uri-02

Abstract

   This document defines the agent:// protocol, a URI template-based
   framework as described in RFC 6570 for addressing, invoking, and
   interoperating with autonomous and semi-autonomous software agents.
   It introduces a layered architecture that supports minimal
   implementations (addressing and transport) and extensible features
   (capability discovery, contracts, orchestration).  The protocol aims
   to foster interoperability among agents across ecosystems, platforms,
   and modalities, enabling composable and collaborative intelligent
   systems.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 19 April 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.



Narvaneni                 Expires 19 April 2026                 [Page 1]

Internet-Draft                  agent-uri                   October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Scope and Layering . . . . . . . . . . . . . . . . .   4
   4.  URI Scheme Specification  . . . . . . . . . . . . . . . . . .   5
     4.1.  Components  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  ABNF for agent:// URI . . . . . . . . . . . . . . . . . .   6
   5.  Resolution Framework  . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Ecosystem Registries  . . . . . . . . . . . . . . . . . .   8
     5.2.  Trust Anchors . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Transport Bindings  . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Explicit Transport Binding  . . . . . . . . . . . . . . .   9
     6.2.  Default Fallback Behavior . . . . . . . . . . . . . . . .  10
     6.3.  Use Cases and Recommended Bindings  . . . . . . . . . . .  11
   7.  Capability Framework  . . . . . . . . . . . . . . . . . . . .  11
   8.  Interaction Patterns {# interaction-patterns} . . . . . . . .  14
     8.1.  Stateful Interactions {# stateful-interactions} . . . . .  14
       8.1.1.  Recommended practices:  . . . . . . . . . . . . . . .  15
     8.2.  Orchestration Patterns  . . . . . . . . . . . . . . . . .  15
     8.3.  Typical Interaction Flows . . . . . . . . . . . . . . . .  15
       8.3.1.  Client-to-Agent Interaction . . . . . . . . . . . . .  15
       8.3.2.  Agent-to-Agent Interaction  . . . . . . . . . . . . .  16
   9.  Error Handling {# error-handling} . . . . . . . . . . . . . .  17
   10. Security and Privacy Considerations . . . . . . . . . . . . .  19
     10.1.  Compliance and Regulatory Considerations . . . . . . . .  20
   11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . .  21
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     12.1.  URI Scheme Registration Template . . . . . . . . . . . .  21
     12.2.  Well-Known URI Registrations . . . . . . . . . . . . . .  22
     12.3.  Media Type Registration for application/agent+json . . .  23
   13. Appendix A.  Example Agent Descriptor . . . . . . . . . . . .  23
   14. Appendix B.  Use Cases  . . . . . . . . . . . . . . . . . . .  25
   15. Appendix C.  Reference Implementation . . . . . . . . . . . .  25
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  26
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  26
     Normative References  . . . . . . . . . . . . . . . . . . . . .  26
     Informative References  . . . . . . . . . . . . . . . . . . . .  27
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  28

1.  Introduction

   The rise of intelligent software agents necessitates a standardized
   way to identify, invoke, and coordinate them across diverse
   platforms.  While protocols like HTTP [RFC9110] provide a transport
   mechanism for static APIs, agents differ significantly in behavior,
   output variability, and interaction patterns.  The agent:// proposes
   a URI scheme and resolution model designed to complement existing



Narvaneni                 Expires 19 April 2026                 [Page 2]

Internet-Draft                  agent-uri                   October 2025


   agent communication protocols and libraries like [Agent2Agent],
   [FIPA-ACL], Contract Net Protocol [FIPA-CNP], [LangChain], Model
   Context Protocol [MCP], [AutoGen], [SemanticKernel] etc.  This
   document defines a resolution algorithm that maps agent:// URIs to
   transport endpoints using HTTPS, WebSocket, or local bindings as
   defined later.  It serves as an addressing and discovery layer that
   works alongside these communication protocols.

   The agent:// protocol supports diverse agent deployment models
   through a unified addressing scheme:

   *  Cloud-based agents accessible via standard web protocols

   *  Local agents running on the user's device through the
      agent+local:// scheme

   *  On-premises agents within organizational boundaries

   *  Decentralized agents operating across distributed networks

   This flexibility addresses a critical gap in current agent
   ecosystems, enabling applications (including browsers) to discover
   and invoke agents consistently regardless of where they're hosted.
   By providing standardized URI[RFC6570] patterns for both remote and
   local agents, the protocol simplifies previously complex integration
   scenarios like browser-to-local-agent delegation for privileged
   operations.

   +------------------+
   | Agent Applications|
   +------------------+
          <->
   +------------------+
   |   agent:// URI   | <- Addressing, Resolution, Discovery
   +------------------+
          <->
   +------------------+  +------------------+
   |  Agent2Agent     |  |    CNP,. etc     | <- Communication Protocols
   +------------------+  +------------------+
           <->                   <->
   +------------------+  +------------------+
   | Transport Layer  |  | Transport Layer  | <- HTTP, WebSockets, etc.
   +------------------+  +------------------+

                Figure 1: Agent Protocol Stack Architecture

   The agent:// protocol supports:




Narvaneni                 Expires 19 April 2026                 [Page 3]

Internet-Draft                  agent-uri                   October 2025


   *  Unique and resolvable addressing of agents

   *  Optional self-describing capabilities

   *  Consistent invocation semantics over existing transports

   *  Progressive support for advanced patterns like delegation,
      collaboration, and orchestration

   This document outlines the specification for the agent:// protocol,
   beginning with its URI scheme and extending through capability
   description, transport bindings, and extensibility patterns.

   A reference implementation of the agent:// protocol is available to
   demonstrate resolution, transport bindings, capability discovery, and
   orchestration patterns.  Implementers and adopters can find this
   example implementation at: [AGENT-URI-REPO]

2.  Terminology

   *  *Agent*: An autonomous or semi-autonomous software entity that can
      receive instructions and perform actions.

   *  *Agent Descriptor (agent.json)*: A machine-readable document that
      describes an agent's identity, capabilities, and behavior.

   *  *Capability*: A self-contained function or behavior an agent
      offers.

   *  *Resolver*: A service or mechanism that maps a URI to a network
      endpoint or metadata.

   *  *Invocation*: The act of calling a capability on an agent with
      input parameters.

   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 RFC
   2119, BCP 14 [RFC2119], [RFC8174] when, and only when, they appear in
   all capitals, as shown here.

3.  Protocol Scope and Layering

   The agent:// protocol is designed as a layered framework:







Narvaneni                 Expires 19 April 2026                 [Page 4]

Internet-Draft                  agent-uri                   October 2025


    +===================+================================+===========+
    | Layer             | Purpose                        | Mandatory |
    +===================+================================+===========+
    | URI Scheme        | Unique addressing              | Yes       |
    +-------------------+--------------------------------+-----------+
    | Transport Binding | Mechanism for invocation       | Yes       |
    |                   | (e.g., HTTP, WSS, Matrix, IPC) |           |
    +-------------------+--------------------------------+-----------+
    | Agent Descriptor  | Self-describing agent          | Optional  |
    |                   | interface                      |           |
    +-------------------+--------------------------------+-----------+
    | Resolution        | Maps agent URIs to endpoints   | Optional  |
    | Framework         |                                |           |
    +-------------------+--------------------------------+-----------+
    | Application       | Shared vocab for capability    | Optional  |
    | Semantics         | naming                         |           |
    +-------------------+--------------------------------+-----------+

                   Table 1: Protocol Layering Structure

   This layering allows implementations to adopt minimal or full-
   featured configurations, depending on their needs.

4.  URI Scheme Specification

   The format of agent:// URIs is:

   agent://[authority]/[path]?[query]#[fragment]
   agent+<protocol>://[authority]/[path]

                         Figure 2: Agent URI Format

   Examples:

   *  agent://example.com/planning/gen-iti?city=Paris

   *  agent://planner.example.com/claude?text=Hello

   *  agent+https://example.com/assistants/chatgpt?query=hello

   *  agent+local://examplelocalagent

   *  agent:///did:web:example.com:agent:researcher/get-article?doi=...








Narvaneni                 Expires 19 April 2026                 [Page 5]

Internet-Draft                  agent-uri                   October 2025


   To resolve agent://<authority>/<path>?<query>: 1.  Fetch
   https://<authority>/.well-known/agents.json (if present) 2.  Locate
   <path> mapping -> agent descriptor URL 3.  Fetch descriptor
   (agent.json) 4.  Extract transport.endpoint or transport metadata 5.
   Invoke using indicated method or default: - GET for read-only, POST
   for state-changing 6.  If none found -> agent+https:// fallback

4.1.  Components

   *  *Authority*: Uniquely identifies the agent or agent namespace
      (e.g., DNS or DID).

   *  *Path*: Specifies the agent being invoked.  The [path] is opaque
      to agent:// and can represent either a namespace or direct
      capability.

   *  *Query*: Contains serialized parameters.  Query parameters SHOULD
      be URL-encoded as key=value pairs.  If more complex structures are
      needed, clients SHOULD use HTTP POST requests with application/
      json bodies rather than base64-encoding payloads into query
      parameters.

   *  *Fragment*: Optional reference for context or sub-capability.

   *  The optional +<protocol> indicates explicit transport binding.

   *  If not specified, clients use resolution or fall back to HTTPS-
      based invocation.

4.2.  ABNF for agent:// URI





















Narvaneni                 Expires 19 April 2026                 [Page 6]

Internet-Draft                  agent-uri                   October 2025


   agent-uri      = "agent" ["+" protocol] ":" hier-part
                    [ "?" query ] [ "#" fragment ]
   ; hier-part from RFC3986, allowing both //authority and path-rootless

   protocol       = 1*( ALPHA / DIGIT / "-" )
   authority      = [ userinfo "@" ] host [ ":" port ]
                    ; <authority, defined in RFC3986, Section 3.2>
   path           = path-abempty
                    ; begins with "/" or is empty.
                    ; Defined in RFC3986, Section 3.3
   query          = *( pchar / "/" / "?" )
                    ; <query, defined in RFC3986, Section 3.4>
   fragment       = *( pchar / "/" / "?" )
                    ; <fragment, defined in RFC3986, Section 3.5>

   pchar          = unreserved / pct-encoded / sub-delims / ":" / "@"
   unreserved     = ALPHA / DIGIT / "-" / "." / "_" / "~"
   pct-encoded    = "%" HEXDIG HEXDIG
   sub-delims     = "!" / "$" / "&" / "'" / "(" / ")" /
                    "*" / "+" / "," / ";" / "="

   ; Character sets like pchar, unreserved, etc. are defined in RFC3986

               Figure 3: ABNF Grammar for agent:// URI Scheme

5.  Resolution Framework

   Every agent MAY expose a self-describing document at:

   <scheme>://<domain>/<path-to-agent>/agent.json

   Agents reachable over the network SHOULD publish /.well-known/
   agent.json

   If a single agent is deployed at the top level then it should be
   under /.well-known.

   *  /.well-known/agent.json -- For single-agent deployments
      (compatible with AgentCard)

   Multi-agent domains MAY additionally expose /.well-known/agents.json.

   *  /.well-known/agents.json -- For multi-agent domains (maps agent
      names -> descriptors)

   This descriptor is OPTIONAL but RECOMMENDED.  It enables capability
   discovery, transport resolution, and compatibility with ecosystem
   tools.



Narvaneni                 Expires 19 April 2026                 [Page 7]

Internet-Draft                  agent-uri                   October 2025


   When present, the descriptor MAY use the [AgentCard] (as defined by
   Agent2Agent protocol by Google as of April 2025) schema as one
   possible format, or any equivalent [JSON-LD11] based structure that
   expresses the agent's identity, capabilities, and behavioral
   metadata.

   If the agent is deployed at a subdomain (e.g., planner.example.org),
   the agent descriptor SHOULD be published at /.well-known/agent.json
   on that domain.

   Resolvers MUST restrict fetches to HTTPS schemes and MUST NOT resolve
   to private or loopback IP ranges.  Resolvers SHOULD verify TLS
   certificates and may require signed descriptors.

5.1.  Ecosystem Registries

   Domains MAY publish:

   https://<domain>/.well-known/agents.json

   This file should map agent names to their agent.json URLs for
   simplified enumeration.  It is OPTIONAL but RECOMMENDED for better
   ecosystem interoperability.

   Implementations MAY support resolution of agent URIs via:

   *  Static resolution maps

   *  DID resolution

   *  WebFinger or custom resolvers

   Resolvers SHOULD support caching and capability introspection where
   applicable.

   +---------+          +-------------+         +-------------+
   |  Client | --URI--> |  Resolver   | -->URL->| Agent Server|
   +---------+          +-------------+         +-------------+
                                 |
                         (agent.json or agents.json)

                   Figure 4: Agent URI Resolution Process

   *Example*:







Narvaneni                 Expires 19 April 2026                 [Page 8]

Internet-Draft                  agent-uri                   October 2025


   {
     "agents": {
       "planner": "https://planner.example.com/.well-known/agent.json",
       "translator": "https://example.com/translator/agent.json"
     }
   }

   Agents SHOULD use standard HTTP caching mechanisms (Cache-Control,
   ETag, Last-Modified) to enable efficient resolution and minimize
   unnecessary descriptor fetches.  Clients SHOULD respect these headers
   and cache descriptors appropriately

5.2.  Trust Anchors

   Domains MAY use trust anchors (e.g., DNSSEC, HTTPS certificates, or
   DID-based verification) to enhance identity assurance.

   A practical example of URI resolution, agent descriptor fetching, and
   caching strategies is included in the reference implementation
   available at: [AGENT-URI-REPO]

6.  Transport Bindings

6.1.  Explicit Transport Binding

   Use the agent+<protocol>:// scheme for clarity:

     +===========+================+=============+====================+
     | Transport | Format         | Method      | Description        |
     +===========+================+=============+====================+
     | HTTPS     | agent+https:// | GET/POST    | Secure HTTP-based  |
     |           |                |             | invocation         |
     +-----------+----------------+-------------+--------------------+
     | WebSocket | agent+wss://   | NDJSON      | Real-time          |
     | Secure    |                | stream      | streaming          |
     +-----------+----------------+-------------+--------------------+
     | Local     | agent+local:// | IPC/broker  | Runtime-registered |
     |           |                | call        | local agents       |
     +-----------+----------------+-------------+--------------------+
     | Unix      | agent+unix://  | Unix domain | IPC for co-located |
     | Socket    |                | socket      | agents             |
     +-----------+----------------+-------------+--------------------+

                     Table 2: Transport Binding Formats







Narvaneni                 Expires 19 April 2026                 [Page 9]

Internet-Draft                  agent-uri                   October 2025


   The agent+<transport>:// scheme allows explicit declaration of such
   bindings, enabling clarity, extensibility, and optimized routing.
   When no explicit transport is declared, clients MAY rely on
   resolution metadata (e.g., agent.json) or default to HTTPS-based
   invocation.

   This flexibility ensures the protocol can adapt to different
   performance, privacy, or coordination requirements while remaining
   consistent at the addressing and invocation layer.

   Local agents should be accessed using:

   agent+local://<agent-name>

   agent+local:// requires explicit user consent and origin binding.
   Implementations MUST prompt before first use.

   This allows agent runtimes to register their presence using a local
   resolver (e.g., via IPC, sockets, or service registry).  The
   transport mechanism is implementation-specific.

   The agent+local:// scheme specifically addresses the current lack of
   standardized methods for browser-based applications to invoke locally
   installed agents.  This enables web applications to delegate tasks to
   local agents that can perform privileged operations such as file
   system access, desktop automation, or hardware interaction -
   capabilities that are typically restricted in browser environments.
   Security considerations for such invocations are discussed in
   Section 10.

6.2.  Default Fallback Behavior

   If the protocol is omitted (i.e., agent:// is used), clients:

   1.  Check .well-known/agents.json (if available)

   2.  Retrieve the agent descriptor at agent.json for the specified
       path

   3.  Use the transport or endpoint hints from the descriptor

   If nothing is found, clients MAY fall back to:

   *  HTTPS (default transport protocol)

   *  HTTP POST if payload present, otherwise GET





Narvaneni                 Expires 19 April 2026                [Page 10]

Internet-Draft                  agent-uri                   October 2025


      Note: This fallback behavior is provided for convenience and basic
      interoperability, but production systems SHOULD prefer explicit
      transport bindings or resolver-based discovery for robustness and
      clarity.

   Clients SHOULD prefer explicit transport bindings (agent+https://)
   where available, and fall back to resolution-based discovery
   (agent://) when agent transport metadata is reliably available.
   Explicit binding reduces resolution ambiguity and improves latency.

6.3.  Use Cases and Recommended Bindings

   The following table outlines some use cases and recommended bindings

      +=================================+==========================+
      | Use Case                        | Recommended Binding      |
      +=================================+==========================+
      | Agent with known HTTPS endpoint | agent+https://           |
      +---------------------------------+--------------------------+
      | Local runtime agent             | agent+local://           |
      +---------------------------------+--------------------------+
      | Dynamic/multi-transport agents  | agent:// with agent.json |
      +---------------------------------+--------------------------+
      | Inter-agent calls within a      | agent:// or              |
      | known context                   | agent+matrix://          |
      +---------------------------------+--------------------------+

            Table 3: Recommended Bindings for Common Use Cases

7.  Capability Framework

   Agents SHOULD expose a descriptor document at:

   <agent-base-path>/agent.json

   This descriptor MAY follow:

   *  The AgentCard structure (as defined by Google's Agent2Agent
      protocol as of April 2025), or another equivalent format

   *  Any format other than AgentCard SHOULD be expressed in [JSON-LD11]
      to enable semantic discovery

   Agent descriptors SHOULD include:

   *  Agent name and version





Narvaneni                 Expires 19 April 2026                [Page 11]

Internet-Draft                  agent-uri                   October 2025


      -  MAY include supportedVersions indicating the list of older
         versions and their end-points.

      -  Versioning should follow [SemVer] or later

      -  Clients SHOULD verify compatibility based on documented major,
         minor, and patch versions

   *  Human-readable description

   *  Input/output schemas (e.g., JSON Schema)

   *  Capability list with IDs, descriptions, tags, version

   *  Optional behavioral metadata (e.g., isDeterministic,
      expectedOutputVariability, requiresContext: boolean,
      memoryEnabled: boolean, responseLatency: "low" | "medium" |
      "high", confidenceEstimation: boolean)

      -  isDeterministic (boolean): Indicates whether repeated calls
         with identical inputs yield identical outputs.

      -  expectedOutputVariability: indicates typical variability in
         outputs, similar to temperature setting

      -  responseLatency: Expected response time.

      -  requiresContext (boolean): Indicates whether the input needs
         context or the agent can work on its own

      -  memoryEnabled (boolean): Indicates whether the agent will
         remember the interactions

   *  Optional transport or invocation hints

   *  Optional authentication or permission requirements

   *  Optional state management practices

   *  Optional interactionModel to indicate a way to interact (e.g.
      agent2agent, fipa-acl, kqml, contract-net, emergent etc).  If
      mentioned, the message payload SHOULD follow the model's defined
      parameters if any.

   Agents MAY expose inputFormats and outputFormats per capability using
   standard MIME types (e.g., application/json, application/ld+json,
   application/fipa-acl).




Narvaneni                 Expires 19 April 2026                [Page 12]

Internet-Draft                  agent-uri                   October 2025


   Agent descriptors SHOULD include input/output schemas (e.g., JSON
   Schema) and MAY document content negotiation support via the
   contentTypes field per capability.  This allows clients to understand
   and negotiate payload encoding, enabling interoperability across
   ecosystems that use JSON, [JSON-LD11], RDF/XML, [FIPA-ACL], or other
   formats.

   Clients MAY use standard negotiation mechanisms such as Content-Type
   and Accept headers (in HTTP), or envelope metadata (in protocols like
   [JSON-RPC], [Matrix], etc.).

   Implementations MAY advertise protocol compatility via metadata
   fields such as interactionModel, orchestration, or supported
   envelopeSchemas etc.  These metadata fields enable clients and agent
   runtimes to interoperate across heterogeneous ecosystems and
   communication models.

   This extensibility ensures agent:// can serve as a unifying
   addressing and invocation layer, bridging agents that follow
   established standards, platform-specific conventions, or learned
   behaviors in dynamic environments.

   If an agent.json is provided, it SHOULD contain at least: name,
   version, and one or more capabilities.

   Clients SHOULD explicitly specify the agent version either as a URI
   path segment, query parameter (?version=3.1.4), or HTTP header (X-
   Agent-Version).  If omitted, servers SHOULD assume the latest
   version.  Agents MUST document their preferred method for version
   negotiation clearly in their descriptor.  Major version increments
   indicate breaking changes; clients default only within same major.

   While .well-known/agents.json MAY be used to enumerate all available
   agents under a domain, the individual agent.json files serve as the
   canonical source of truth.

   All published descriptors MUST use media type application/agent+json
   (or JSON-LD profile).

   Expressing descriptors in [JSON-LD11] enables semantic
   interoperability and supports alignment with common web-based data
   models.

   Implementers MAY choose to embed, proxy, or map to other protocols
   within the agent.json descriptor or transport bindings, allowing for
   seamless orchestration and hybrid deployments.





Narvaneni                 Expires 19 April 2026                [Page 13]

Internet-Draft                  agent-uri                   October 2025


8.  Interaction Patterns {# interaction-patterns}

   Supported interaction types include:

   *  Request/Response (synchronous)

   *  Deferred response (polling or webhook) SHOULD include a taskId and
      polling interval hint.

   *  Streaming responses (e.g., Server-Sent Events, WebSocket).
      Streaming responses over agent+wss:// SHOULD use newline-delimited
      JSON (NDJSON)

   *  Delegated invocation (calling other agents on behalf of user)

   *  Asynchronous event notifications via HTTP webhooks or WebSockets.
      Event notifications if available SHOULD include event types,
      payloads, and identifiers.

   All interaction patterns (e.g., streaming, event-driven, polling) are
   transport-agnostic but MAY impose format constraints (e.g., NDJSON
   over WebSockets).

   Agents SHOULD include traceparent or X-Task-ID headers to correlate
   multi-agent workflows.

   Agents SHOULD include status and confidence metadata in responses
   where applicable.

8.1.  Stateful Interactions {# stateful-interactions}

   The agent:// protocol leverages HTTP's established mechanisms for
   state management.  Clients and agents SHOULD use standard HTTP
   headers or query parameters to pass identifiers such as sessionId or
   taskId.  Agents MAY maintain state across interactions using these
   identifiers.  Clients and agents SHOULD agree on session semantics
   via capability descriptors or invocation headers.

   Non-HTTP transports SHOULD include session or task identifiers within
   message envelopes (e.g., JSON-RPC headers, WebSocket message
   metadata, Matrix events).  These fields SHOULD follow naming
   conventions similar to sessionId, taskId, etc.

   When the transport lacks a native header mechanism, agents SHOULD
   extract session information from the body or envelope metadata.






Narvaneni                 Expires 19 April 2026                [Page 14]

Internet-Draft                  agent-uri                   October 2025


   When content negotiation fails or the requested format is not
   supported, agents SHOULD respond with a 406 Not Acceptable HTTP error
   or equivalent, and MAY include supported formats in the response
   metadata.

8.1.1.  Recommended practices:

   *  Use HTTP headers (e.g., X-Session-ID, X-Task-ID) or query
      parameters for session and task identifiers.

   *  Clearly document state identifiers and their expected lifecycle in
      the agent's descriptor (agent.json).

   *Example*:

   GET /tasks/1234 HTTP/1.1
   Host: planner.example.com
   X-Session-ID: abcde-12345

8.2.  Orchestration Patterns

   Agents MAY invoke other agents as part of delegated or composite
   tasks.  Agents SHOULD explicitly provide orchestration workflows,
   delegation chains, or composite interactions either in their
   agent.json or in their response metadata.

8.3.  Typical Interaction Flows

8.3.1.  Client-to-Agent Interaction

   A typical user-driven invocation of an agent using the agent://
   protocol follows these steps:



















Narvaneni                 Expires 19 April 2026                [Page 15]

Internet-Draft                  agent-uri                   October 2025


   +--------+       +-----------+       +-------------+
   |  User  |  -->  |  Client   |  -->  |  Agent Host |
   +--------+       +-----------+       +-------------+
        |                |                    |
        | Initiates      |                    |
        | intent (e.g.,  |                    |
        | "Plan my trip")|                    |
        |                |                    |
        |                | Resolves agent URI |
        |                | --> agents.json / agent.json
        |                | Retrieves capabilities
        |                |                    |
        |                | Constructs request |
        |                | --> agent://plan.example.com/gen-iti?city=Rio
        |                |                    |
        |                |                    | Validate input
        |                |                    | Process logic/call tools
        |                |                    | May call sub-agents
        |                |                    |
        |                | Receives response  |
        |                | <== itinerary JSON |
        | Presents result to user             |

                 Figure 5: Client-to-Agent Interaction Flow

   *Notes*:

   *  The client MAY handle fallback logic if the agent cannot be
      resolved initially.

   *  Authentication MAY be required before invocation.

   *  The invocation can be a simple GET or POST depending on input size
      and structure.

8.3.2.  Agent-to-Agent Interaction

   Agents MAY interact with each other using agent:// URIs to delegate
   tasks or compose workflows.

   *Example: A planning agent invoking a translation agent*:










Narvaneni                 Expires 19 April 2026                [Page 16]

Internet-Draft                  agent-uri                   October 2025


   +----------+       +----------+       +------------+
   |Planning  |------>|Resolver/ |------>|Translation |
   |Agent     |       |URI       |       |Agent       |
   +----------+       +----------+       +------------+
        |                  |                   |
        | Input:           |                   |
        | {"city":"Paris"} |                   |
        |                  |                   |
        | Needs translation|                   |
        |                  |                   |
        |                  | Resolves URI:     |
        |--agent://translator.example/translate?text=Bonjour-->|
        |                  |                   |
        |                  | --> Get           |
        |                  |     agent.json    |
        |                  | --> Determine     |
        |                  |     transport     |
        |                  |                   |
        |                  |                   | Process translation
        |                  |                   | Return translated JSON
        |<-----------------|<------------------|
        | Merge & return   |                   |
        | to user/client   |                   |
        | or continues     |                   |

                 Figure 6: Agent-to-Agent Interaction Flow

   *Chaining Behavior*:

   *  The invoking agent MAY include X-Task-ID, X-Delegation-Chain, or
      equivalent headers.

   *  The response MAY include intermediate metadata such as confidence,
      sourceAgent, taskTrace, or timeTaken.

9.  Error Handling {# error-handling}

   The agent:// protocol MAY leverage HTTP standard status codes for
   signaling errors.  Implementations MAY return errors using standard
   HTTP status codes along with structured JSON error responses
   conforming to [RFC9457] ("Problem Details for HTTP APIs").

   **Recommended HTTP status codes include (but are not limited to)








Narvaneni                 Expires 19 April 2026                [Page 17]

Internet-Draft                  agent-uri                   October 2025


         +=============+========================================+
         | Status Code | Meaning                                |
         +=============+========================================+
         | 400         | Bad Request (e.g., invalid parameters) |
         +-------------+----------------------------------------+
         | 401         | Unauthorized                           |
         +-------------+----------------------------------------+
         | 403         | Forbidden                              |
         +-------------+----------------------------------------+
         | 404         | Capability or resource not found       |
         +-------------+----------------------------------------+
         | 409         | Conflict (e.g., state mismatch)        |
         +-------------+----------------------------------------+
         | 429         | Too Many Requests (rate limiting)      |
         +-------------+----------------------------------------+
         | 500         | Internal Server Error                  |
         +-------------+----------------------------------------+
         | 503         | Service Unavailable                    |
         +-------------+----------------------------------------+

                  Table 4: Recommended HTTP status codes

   Example:

   HTTP/1.1 404 Not Found
   Content-Type: application/problem+json

   {
     "type": "https://example.com/errors/capability-not-found",
     "title": "Capability Not Found",
     "status": 404,
     "detail": "The requested capability 'gen-iti' was not found.",
     "instance": "/planner/gen-iti"
   }
   {: #fig-error-response title="Example HTTP Error Response"}

   This format is not prescriptive but aims to encourage consistency.
   Implementations MAY adapt the error schema based on their transport
   layer (e.g., JSON-RPC, HTTP status + body, WebSocket messages).

   For non-HTTP transports (e.g., WebSockets, Matrix), agents SHOULD
   still return structured errors using similar JSON structures (type,
   title, detail, status), encapsulated within the transport's native
   message envelope (e.g., JSON-RPC error objects, Matrix event content
   fields).  Implementers SHOULD document chosen structures clearly in
   their capability descriptors.





Narvaneni                 Expires 19 April 2026                [Page 18]

Internet-Draft                  agent-uri                   October 2025


   Where applicable, implementations SHOULD align with existing
   conventions such as:

   *  JSON-RPC error objects (code, message, data)

   *  [OpenAPI] or REST error payloads

   *  [GraphQL] errors array format

   Recommended error categories:

   *  CapabilityNotFound

   *  InvalidInput

   *  AmbiguousResponse

   *  Timeout

   *  PermissionDenied

   Clients SHOULD parse and utilize these structured responses to handle
   errors gracefully.

10.  Security and Privacy Considerations

   The agent:// protocol explicitly relies on widely-adopted HTTP
   authentication and authorization standards.  Agents SHOULD support
   standard authentication and authorization schemes such as OAuth2
   (Bearer tokens), API keys, or signed payloads.  When using HTTPS,
   mutual TLS MAY be employed.  JSON Web Tokens (JWT) are RECOMMENDED
   for conveying signed claims between agents.  For agent+local://,
   browsers and runtimes MUST enforce same-origin policy, token
   handshake, and user mediation before invoking a local agent.

   Security extensions MAY include:

   *  OAuth2 [RFC6750] Bearer Tokens

   *  JSON Web Tokens (JWT [RFC7519])

   *  Mutual TLS (mTLS [RFC8705]) authentication

   *  API Keys via HTTP headers (e.g., X-API-Key)

   *  Capability-based access control

   *  Delegation chains



Narvaneni                 Expires 19 April 2026                [Page 19]

Internet-Draft                  agent-uri                   October 2025


   For non-HTTP transports (e.g., WebSocket, Matrix), agents SHOULD
   leverage native authentication mechanisms, such as WebSocket
   protocol-level authentication tokens or Matrix homeserver
   authentication flows.  Agents MUST clearly document supported
   security mechanisms per transport binding.

   If OAuth 2.0 is used, authorization flows MUST conform to [RFC6749];
   bearer usage per [RFC6750].

   When using Decentralized Identifiers [DID-CORE] as authority, agent
   descriptors MAY be cryptographically signed.  Clients SHOULD verify
   such signatures against the corresponding DID Document.

   For agent-to-agent delegation, agents SHOULD include delegation
   metadata (e.g., X-Delegation-Chain) that identifies prior actors.
   These chains SHOULD be signed or verifiable via claims (e.g., using
   JWT, Verifiable Credentials, or DID-linked proofs).

   Resolvers SHOULD use HTTPS with certificate validation and SHOULD
   validate integrity using ETag/Last-Modified for caching; if signature
   metadata is present, SHOULD verify signature per the descriptor's
   signature scheme.

   Agents MUST minimize data retention and expose revoke/delete
   interfaces for user data.

   Privacy recommendations:

   Agents SHOULD adhere to privacy best practices, including:

   *  Data minimization (collect only necessary data)

   *  Explicit consent and revocation mechanisms

   *  Clear logging/audit trails

   *  Ethical AI guidelines, including bias detection and fairness
      assessments as they evolve

10.1.  Compliance and Regulatory Considerations

   Implementers SHOULD ensure compliance with relevant legal frameworks
   (e.g., GDPR, CCPA) of the jurisdictions where the agent is hosted.
   Agents processing sensitive data SHOULD provide audit trails and
   explicit consent mechanisms clearly documented in capability
   descriptors.





Narvaneni                 Expires 19 April 2026                [Page 20]

Internet-Draft                  agent-uri                   October 2025


11.  Extensibility

   The protocol supports extension via:

   *  Namespaced capability vocabularies

   *  Alternate transport bindings

   *  Extended agent descriptors

   *  Optional orchestration layers (task graphs, workflows)

   Extension proposals SHOULD be documented clearly, and ideally
   reviewed through established processes such as community forums,
   dedicated working groups, or public registries to ensure transparency
   and interoperability.

12.  IANA Considerations

   This document requests the registration of the agent URI scheme in
   the IANA "Uniform Resource Identifier (URI) Schemes" registry.

12.1.  URI Scheme Registration Template

   *  *Scheme Name*: agent

   *  *Status*: Provisional

   *  *Applications/Protocols That Use This Scheme*: The agent URI
      scheme identifies and invokes autonomous or semi-autonomous
      software agents across systems.  It provides transport-agnostic
      addressing layer supporting discovery, invocation and
      orchestration.  The scheme is compatible with existing schemes
      such as https, did and web+ schemes where appropriate.

   *  *Contact*: Yaswanth Narvaneni <yaswanth+ietf@gmail.com>

   *  *Change Controller*: The author or a relevant standards body such
      as the IETF if adopted.

   *  *References*: This document (Internet-Draft): _agent:// Protocol
      -- A URI-Based Framework for Interoperable Agents_ [RFC3986] -
      Uniform Resource Identifier (URI): Generic Syntax [RFC7595] -
      Guidelines and Registration Procedures for URI Schemes

   *  *URI Syntax*: The general form of an agent URI is:

   *  *Related Registrations:*



Narvaneni                 Expires 19 April 2026                [Page 21]

Internet-Draft                  agent-uri                   October 2025


      -  Well-Known URIs (Section 12.2): /.well-known/agent.json,
         /.well-known/agents.json

      -  Media Type (Section 12.3): application/agent+json

   agent:[+<protocol>]://<authority>/<path>[?<query>][#<fragment>]

   Where: - authority is typically a domain name or Decentralized
   Identifier (DID) - path is an opaque agent-specific capability or
   namespace - query includes serialized key-value parameters - fragment
   MAY reference a sub-capability or context - The optional +<protocol>
   segment indicates an explicit transport binding (e.g.,
   agent+https://)

   Detailed ABNF is specified in Section 4.2 of this document.

   *  *Security Considerations*: The agent scheme does not introduce new
      transport-layer vulnerabilities but inherits risks from underlying
      protocols such as HTTP, WebSocket, or local execution
      environments.  Implementers should apply standard authentication
      and authorization measures, such as OAuth2, JWTs, or mutual TLS.
      See Section 10 for security and privacy guidance.

12.2.  Well-Known URI Registrations

   This document registers the following Well-Known URIs under the
   "Well-Known URIs" registry established by RFC 8615:

   1.  *Name:* agent.json
       *Purpose:* Provides the self-describing metadata document
       (agent.json) for a single network-addressable agent.
       *Expected Content:* JSON object conforming to application/
       agent+json.
       *Reference:* This document.
       *Security Considerations:* Accessible only via HTTPS.  Agents
       SHOULD sign or ETag-pin the descriptor.

   2.  *Name:* agents.json
       *Purpose:* Provides a registry mapping of agent names to
       descriptor URLs for multi-agent domains.
       *Expected Content:* JSON object mapping agent identifiers to
       agent.json URLs.
       *Reference:* This document.
       *Security Considerations:* Same as above.







Narvaneni                 Expires 19 April 2026                [Page 22]

Internet-Draft                  agent-uri                   October 2025


12.3.  Media Type Registration for application/agent+json

   Type name: application
   Subtype name: agent+json
   Required parameters: none
   Optional parameters: profile (for JSON-LD contexts)
   Encoding considerations: 8bit; uses UTF-8 encoded JSON
   Security considerations: Carries metadata that can affect network
   routing and authorization; publishers SHOULD serve only over HTTPS
   and validate signatures or ETags.
   Interoperability considerations: Compatible with JSON-LD 1.1 and
   plain JSON processors.
   Published specification: This document
   Applications that use this media type: Agent resolvers and runtimes
   using the agent:// protocol.
   Additional information: None
   Person & email address to contact for further information: Yaswanth
   Narvaneni <yaswanth+ietf@gmail.com>
   Intended usage: COMMON
   Author/Change controller: IETF if standardized; author for
   independent submissions.

   The profile parameter usage follows the concept in RFC 6906 [RFC6906]
   (Profiles), and media type registration procedures follow RFC 6838
   [RFC6838].

13.  Appendix A.  Example Agent Descriptor

   Following is an example of agent.json.






















Narvaneni                 Expires 19 April 2026                [Page 23]

Internet-Draft                  agent-uri                   October 2025


   {
     "@context": "https://example.org/agent-context.jsonld",
     "name": "planner.example.com",
     "description": "Agent helps in researching & planning itineraries",
     "url": "agent://planner.example.com/",
     "provider": {
       "organization": "Example AI Org"
     },
     "documentationUrl": "https://planner.example.com/docs",
     "interactionModel": "agent2agent",
     "orchestration": "delegation",
     "envelopeSchemas": ["fipa-acl"],
     "version": "3.1.4",
     "supportedVersions": {
       "3.0.0": "/v3/",
       "2.1.2": "/olderversion/v2.1.2/",
       "1.0": "/version-1/"
     },
     "capabilities": [
       {
         "name": "gen-iti",
         "version": "2.1.5",
         "description": "Creates a travel itinerary for a given city.",
         "input": { "city": "string" },
         "output": { "itinerary": "array" },
         "isDeterministic": false,
         "expectedOutputVariability": "medium",
         "contentTypes": {
           "inputFormat": ["application/json", "application/ld+json"],
           "outputFormat": ["application/json"]
         }
       }
     ],
     "authentication": {
       "schemes": ["OAuth2"]
     },
     "skills": [
       {
           "id": "agent-skill-1",
           "name": "research-location"
       }
     ]
   }

               Figure 7: Example Agent Descriptor in JSON-LD

   A JSON-LD context is added to support semantic querying and graph-
   based processing.



Narvaneni                 Expires 19 April 2026                [Page 24]

Internet-Draft                  agent-uri                   October 2025


14.  Appendix B.  Use Cases

   *  Composing workflows with agents from different vendors

   *  Enabling discovery and invocation in agent marketplaces

   *  Facilitating human-in-the-loop workflows with agent transparency

   *  Building knowledge-based agents that invoke retrieval agents

   *  Real-time collaboration among specialized agents

   *  Browser-to-local-agent delegation for privileged operations and
      desktop automation

   *  Consistent addressing for agents across network boundaries and
      security contexts

15.  Appendix C.  Reference Implementation

   A reference implementation of the agent:// protocol is available to
   guide implementers, demonstrating the following functionalities:

   *  URI parsing and resolution (agent.json, .well-known endpoints)

   *  Transport bindings including HTTPS, WebSocket, Matrix, and Local
      IPC

   *  Capability descriptor discovery, caching, and semantic processing

   *  Orchestration and delegation chaining examples

   *  Error handling, payload negotiation, and versioning patterns

   *  Security examples covering OAuth2, JWT, and mutual TLS (mTLS)

   The implementation is open-source and maintained at:

   [AGENT-URI-REPO]

   Implementers are encouraged to use this as a starting point or
   reference during their implementation efforts.









Narvaneni                 Expires 19 April 2026                [Page 25]

Internet-Draft                  agent-uri                   October 2025


Acknowledgements

   This draft reflects observations and aspirations drawn from emerging
   agent ecosystems.  It builds on publicly available research,
   community discussions, and early experimentation with agent-oriented
   protocols.  It is intended as a foundation for future refinement and
   collaboration.

References

Normative References

   [DID-CORE] Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele,
              O., and C. Allen, "Decentralized Identifiers (DIDs) v1.0",
              W3C Recommendation, July 2022,
              <https://www.w3.org/TR/did-core/>.

   [JSON-LD11]
              Sporny, M., Longley, D., Kellogg, G., Lanthaler, M.,
              Champin, P., and N. Lindstrom, "JSON-LD 1.1: A JSON-based
              Serialization for Linked Data", W3C Recommendation, July
              2020, <https://www.w3.org/TR/json-ld11/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570,
              DOI 10.17487/RFC6570, March 2012,
              <https://www.rfc-editor.org/rfc/rfc6570>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750,
              DOI 10.17487/RFC6750, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6750>.





Narvaneni                 Expires 19 April 2026                [Page 26]

Internet-Draft                  agent-uri                   October 2025


   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
              and Registration Procedures for URI Schemes", BCP 35,
              RFC 7595, DOI 10.17487/RFC7595, June 2015,
              <https://www.rfc-editor.org/rfc/rfc7595>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8705]  Campbell, B., Bradley, J., Sakimura, N., and T.
              Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
              and Certificate-Bound Access Tokens", RFC 8705,
              DOI 10.17487/RFC8705, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8705>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [RFC9457]  Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
              for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
              <https://www.rfc-editor.org/rfc/rfc9457>.

Informative References

   [AGENT-URI-REPO]
              Narvaneni, Y., "Agent URI Protocol Reference
              Implementation", 2025,
              <https://github.com/agent-uri/agent-uri>.

   [Agent2Agent]
              Google LLC, "Agent2Agent Protocol", April 2025,
              <https://github.com/google/A2A>.

   [AgentCard]
              Google LLC, "Agent Card Schema from Agent2Agent Protocol",
              April 2025,
              <https://github.com/google/A2A/blob/main/specification/
              json/a2a.json>.

   [AutoGen]  Microsoft Research, "AutoGen: Enabling LLM Applications
              with Multi-Agent Conversations", 2024,
              <https://microsoft.github.io/autogen/>.



Narvaneni                 Expires 19 April 2026                [Page 27]

Internet-Draft                  agent-uri                   October 2025


   [FIPA-ACL] Foundation for Intelligent Physical Agents, "FIPA ACL
              Message Structure Specification", 2002,
              <http://www.fipa.org/specs/fipa00061/SC00061G.html>.

   [FIPA-CNP] Foundation for Intelligent Physical Agents, "FIPA Contract
              Net Interaction Protocol Specification", 2002,
              <http://www.fipa.org/specs/fipa00029/SC00029H.html>.

   [GraphQL]  GraphQL Foundation, "GraphQL: A Query Language for APIs",
              October 2021, <https://spec.graphql.org/October2021/>.

   [JSON-RPC] JSON-RPC Working Group, "JSON-RPC 2.0 Specification", 4
              January 2013, <https://www.jsonrpc.org/specification>.

   [LangChain]
              LangChain Team, "LangChain Documentation", 2024,
              <https://python.langchain.com/v0.3/docs/>.

   [Matrix]   The Matrix org Foundation, "Matrix Specification v1.14",
              2014, <https://spec.matrix.org/>.

   [MCP]      Anthropic PBC, "Model Context Protocol (MCP)", March 2025,
              <https://modelcontextprotocol.io/specification/>.

   [OpenAPI]  OpenAPI Initiative, "OpenAPI Specification v3.1.0",
              October 2024, <https://spec.openapis.org/oas/latest.html>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/rfc/rfc6838>.

   [RFC6906]  Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
              DOI 10.17487/RFC6906, March 2013,
              <https://www.rfc-editor.org/rfc/rfc6906>.

   [SemanticKernel]
              Microsoft, "Semantic Kernel SDK", 2024,
              <https://github.com/microsoft/semantic-kernel>.

   [SemVer]   Preston-Werner, T., "Semantic Versioning 2.0.0", 2013,
              <https://semver.org/>.

Author's Address







Narvaneni                 Expires 19 April 2026                [Page 28]

Internet-Draft                  agent-uri                   October 2025


   Yaswanth Narvaneni
   Independent Researcher
   London
   United Kingdom
   Email: yaswanth+ietf@gmail.com














































Narvaneni                 Expires 19 April 2026                [Page 29]

categories:
["Agent discovery / registration", "Agent-to-agent communication protocols", "Data formats / semantics for AI interop"]


name: draft-chen-agent-decoupled-authorization-model
rev: 00
title: A Decoupled Authorization Model for Agent2Agent
time: 2026-02-14T07:42:07Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-18T07:42:07Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420363+00:00
abstract:
This document proposes a framework for dynamic, intent-based
   authorization for AI Agents.  The primary goal is to enable fine-
   grained, Just-in-Time (JIT) permissions based on an agent's specific
   intent and behavioral trustworthiness, rather than a long-lived
   identity or role, achieve decoupling of authorization policies from
   business operations.

full_text:
Internet Engineering Task Force                                  M. Chen
Internet-Draft                                                     L. Su
Intended status: Informational                              China Mobile
Expires: 18 August 2026                                 14 February 2026


            A Decoupled Authorization Model for Agent2Agent
           draft-chen-agent-decoupled-authorization-model-00

Abstract

   This document proposes a framework for dynamic, intent-based
   authorization for AI Agents.  The primary goal is to enable fine-
   grained, Just-in-Time (JIT) permissions based on an agent's specific
   intent and behavioral trustworthiness, rather than a long-lived
   identity or role, achieve decoupling of authorization policies from
   business operations.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 18 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.



Chen & Su                Expires 18 August 2026                 [Page 1]

Internet-Draft           AI Agent Authorization            February 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Analysis of Oauth for Agent-to-Agent Authorization  . . . . .   4
     4.1.  What OAuth2.0 can do  . . . . . . . . . . . . . . . . . .   4
     4.2.  Remaining Challenges and Open Issues  . . . . . . . . . .   4
   5.  Decoupled Authorization Model . . . . . . . . . . . . . . . .   5
     5.1.  Architecture overview . . . . . . . . . . . . . . . . . .   5
     5.2.  Authorization Execution Point(AEP)  . . . . . . . . . . .   5
     5.3.  Authorization Decision Point(ADP) . . . . . . . . . . . .   6
     5.4.  Input . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   AI Agents, hereafter "agents" represent a significant evolution from
   traditional scripts or services.  They possess the ability to reason,
   plan, and execute multi-step tasks to achieve a high-level goal.
   This autonomy, however, creates a significant attack surface.  An
   agent granted broad permissions, if compromised via mechanisms like
   prompt injection, can cause widespread damage.

   Existing authorization models are ill-suited for this dynamic
   environment.  They typically bind permissions to stable, long-lived
   identities.  Agents, by contrast, are often ephemeral, created in
   large numbers for specific, short-lived tasks.

   This document proposes a model that decouples authorization decisions
   from the services themselves.  It leverages a Authorization Decision
   Point (ADP) that makes real-time, context-rich decisions for every
   action an agent attempts to take.  The core of this draft is a
   standardized "Input Contract" -- a structured data format that a
   Authorization Execution Point (AEP) MUST provide to the ADP to enable
   fine-grained, intent-based authorization.

2.  Terminology

   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 [RFC2119] [RFC8174].





Chen & Su                Expires 18 August 2026                 [Page 2]

Internet-Draft           AI Agent Authorization            February 2026


   *  AI Agent (Agent): An autonomous or semi-autonomous software entity
      that perceives its environment and takes actions to achieve goals.

   *  Intent: A declaration of the specific goal or task an agent
      intends to accomplish.  This is typically more granular than a
      broad scope.

   *  Ephemeral Identity: A short-lived, single-purpose identity
      assigned to an agent for the duration of its task.

   *  Authorization Decision Point (ADP): The logical component that
      evaluates policies and makes authorization decisions (e.g.,
      Permit/Deny).

   *  Authorization Execution Point (AEP): The logical component that
      intercepts an agent's action, requests a decision from the ADP,
      and enforces that decision.

3.  Problem Statement

   Traditional authorization mechanisms, often designed for human-to-
   machine interactions, are ill-suited for the dynamic and large-scale
   nature of agent-to-agent communication.  The key challenges are
   categorized as follows.  Traditional authorization mechanisms fail to
   address the unique characteristics of AI Agents in several key areas.

   Scale and Complexity Explosion: In a system with N agents and M
   resources, the number of potential authorization rules can grow
   combinatorially.  Managing these rules through static methods like
   Access Control Lists (ACLs) becomes untenable.

   Static Permissions vs Dynamic Intent: Assigning static roles or
   scopes (e.g., read:all, write:all) is overly permissive.  An agent's
   authority should be scoped precisely to its immediate intent (e.g.,
   "query flight from XX to XX under $500"), and this authority should
   be granted just-in-time.

   Identity Lifecycle Mismatch: The high cost and administrative
   overhead of managing traditional identities (e.g., user accounts,
   service accounts) are incompatible with the massive scale and
   ephemeral nature of agents.

   One-Time Trust vs Continuous Risk: An agent's behavior can be
   subverted at any point in its lifecycle.  A successful authentication
   at the beginning of a session provides no guarantee of trustworthy
   behavior throughout.  A continuous attestation of behavioral patterns
   is required.




Chen & Su                Expires 18 August 2026                 [Page 3]

Internet-Draft           AI Agent Authorization            February 2026


   Flat vs Hierarchical Authority: Agents often delegate tasks to sub-
   agents.  A robust framework must support hierarchical delegation of
   authority, ensuring a sub-agent's permissions are a strict subset of
   its parent's, and providing a clear chain of accountability.

   Governance and Auditability: When an undesirable action occurs,
   tracing the root cause across a chain of agent interactions is a
   formidable challenge.

4.  Analysis of Oauth for Agent-to-Agent Authorization

   The OAuth 2.0 Authorization Framework [RFC6749] and its related RFCs
   provide a strong foundation for secure, delegated access.

4.1.  What OAuth2.0 can do

   OAuth 2.0 effectively addresses the foundational aspects of secure
   delegation and credential management.  It provides:

   *  A standard mechanism for Delegated Authorization, allowing agents
      to act on behalf of a user.

   *  A standard for Credential Passing (Tokens) crucial for
      interoperability.

   *  A grant type for Machine-to-Machine Authentication (Client
      Credentials).

   *  A mechanism for Limited-Scope and Time-Bound Access via scopes and
      token expiration.

4.2.  Remaining Challenges and Open Issues

   While indispensable, OAuth 2.0 is primarily a framework for
   delegation and token issuance.  However, there are still some issues
   that need to be addressed on the AI agent internet.

   Fine-Grained Policy Decision: The parameter "scope" in OAuth 2.0 is
   often too coarse for complex authorization logic.  A resource server
   agent receiving a token with a read:data scope still needs to answer
   more detailed, context-specific questions (e.g., "Which specific
   record?", "Under what conditions?").

   Unified Policy Language and Governance: OAuth 2.0 does not define a
   language for expressing authorization policies or a methodology for
   managing them.  The interpretation of a scope is left to each agent's
   implementation.  This makes it difficult to centrally manage, audit,
   or reason about the authorization policies across the entire system.



Chen & Su                Expires 18 August 2026                 [Page 4]

Internet-Draft           AI Agent Authorization            February 2026


5.  Decoupled Authorization Model

   To address the open issues, this document proposes a Decoupled
   Authorization Model.  This model complements OAuth 2.0 by
   externalizing the fine-grained policy decision logic from the agent's
   service-specific business logic.

5.1.  Architecture overview

   The model is based on the separation of the Authorization Decision
   Point (ADP) from the Authorization Execution Point (AEP).  This
   decouples the "what" (the business logic) from the "if" (the
   authorization logic).

                      +---------------------+
                      |Resource Agent       |
                      |                     |
                      | +-------------+     |
                      | |Authorization|     |
   +------+           | | Execution   |     |
   |      |1.Request  | |  Point(AEP) |     |
   |  AI  |---------->| |             | 3.Authorization +-------------+
   | Agent|with Token | | 2.Intercept |    Query        |Authorization|
   |      |           | | &Construct  +-----+---------->|Decision     |
   |      |5.Response | |   Query     |<----+-----------+Point        |
   |      |<----------+ +------+------+  4.Decision     +-------------+
   +------+Allow/Deny |        |            |
                      | +------+-----------+|
                      | |Agent's Core Logic||
                      | +------------------+|
                      +---------------------+

         Figure 1: Decoupled Authorization Model Interaction Flow

5.2.  Authorization Execution Point(AEP)

   The AEP is a logical gateway protecting an agent's capabilities,
   responsible for constructing the complete context for the decision:

   *  Intercept an incoming request (Step 2).

   *  Perform initial validation of credentials (e.g., a JWT access
      token).

   *  Assemble a query for the ADP, containing all relevant context
      (e.g., token claims, request details).





Chen & Su                Expires 18 August 2026                 [Page 5]

Internet-Draft           AI Agent Authorization            February 2026


   *  Send the query to the ADP (Step 3) and receive a simple Allow or
      Deny decision (Step 4).

   *  Enforce the decision by either forwarding the request to the
      agent's core logic or rejecting it (Step 5).

5.3.  Authorization Decision Point(ADP)

   The ADP is the authorization "brain", responsible for evaluating the
   context against a set of policies:
   - Receive authorization queries from the AEP. - Maintain a current
   set of authorization policies written in an expressive, declarative
   language. - Evaluate the query against the policies and data to
   produce a definitive decision. - The ADP SHOULD be deployable in a
   decentralized manner to ensure low latency and high availability.

5.4.  Input

   TBD

6.  Security Considerations

   TBD

7.  IANA Considerations

   TBD

8.  Informative References

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.

Authors' Addresses

   Meiling Chen
   China Mobile
   BeiJing
   China
   Email: chenmeiling@chinamobile.com


   Li Su
   China Mobile
   BeiJing
   China
   Email: suli@chinamobile.com



Chen & Su                Expires 18 August 2026                 [Page 6]

categories:
["Identity / authentication for AI agents", "AI safety / guardrails / alignment", "Policy / governance / ethical frameworks"]


name: draft-huang-acme-scalable-agent-enrollment
rev: 00
title: Extending Certificate Enrollment Protocols for Scalable Agentic AI Identity
time: 2025-12-16T07:09:03Z
group_uri: /api/v1/group/group/1027/
expires: 2025-12-16T06:24:58Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Identity / authentication for AI agents", "Agent discovery / registration"]
tags: []
fetched_at: 2026-02-27T22:56:03.420366+00:00
abstract:
Agentic AI systems require robust, verifiable identities to operate
   securely.  While traditional certificate enrollment protocols like
   SCEP and EST can be extended to include remote attestation evidence,
   performing a full validation for every agent's certificate request
   presents significant scalability and privacy challenges.  This
   document proposes two distinct, scalable models for integrating
   attestation into the enrollment lifecycle.  The first model leverages
   Zero-Knowledge Proofs (ZKP) to provide private, efficient, and
   continuous attestation.  The second model uses a one-time, high-
   assurance bootstrapping process to establish a trusted host
   environment, which is then authorized to endorse certificate requests
   for the agents it runs.  Both models enable high-assurance identity
   for AI agents while addressing the performance bottlenecks of naive
   per-enrollment verification.

full_text:
RATS                                                            K. Huang
Internet-Draft                                        DistributedApps.ai
Intended status: Standards Track                                J. Huang
Expires: 16 December 2025                                Kleiner Perkins
                                                            14 June 2025


   Extending Certificate Enrollment Protocols for Scalable Agentic AI
                                Identity
             draft-huang-acme-scalable-agent-enrollment-00

Abstract

   Agentic AI systems require robust, verifiable identities to operate
   securely.  While traditional certificate enrollment protocols like
   SCEP and EST can be extended to include remote attestation evidence,
   performing a full validation for every agent's certificate request
   presents significant scalability and privacy challenges.  This
   document proposes two distinct, scalable models for integrating
   attestation into the enrollment lifecycle.  The first model leverages
   Zero-Knowledge Proofs (ZKP) to provide private, efficient, and
   continuous attestation.  The second model uses a one-time, high-
   assurance bootstrapping process to establish a trusted host
   environment, which is then authorized to endorse certificate requests
   for the agents it runs.  Both models enable high-assurance identity
   for AI agents while addressing the performance bottlenecks of naive
   per-enrollment verification.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 16 December 2025.







Huang & Huang           Expires 16 December 2025                [Page 1]

Internet-Draft          Scalable Agent Enrollment              June 2025


Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Conventions . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement: The Scalability Challenge of Per-Enrollment
           Attestation . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Proposed Scalable Enrollment Models . . . . . . . . . . . . .   4
     4.1.  Model 1: Auto-Enrollment with Zero-Knowledge Proof
           Attestation . . . . . . . . . . . . . . . . . . . . . . .   4
       Core Concept  . . . . . . . . . . . . . . . . . . . . . . . .   4
       Specification and Steps . . . . . . . . . . . . . . . . . . .   4
     4.2.  Model 2: Bootstrapped Trust via Host Endorsement  . . . .   5
       Core Concept  . . . . . . . . . . . . . . . . . . . . . . . .   6
       Specification and Steps . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The need for strong, verifiable identity for Agentic AI is well-
   established.  Our related work, "Capability Attestation Extensions
   for the Entity Attestation Token (EAT)"
   [I-D.huang-rats-agentic-eat-cap-attest], defines *what* an agent
   should attest to.  This document addresses *how* an agent can obtain
   a certificate reflecting that attestation in a scalable and privacy-
   preserving manner.

   The naive approach of sending full attestation evidence with every
   SCEP or EST enrollment request is computationally expensive for the
   verifying Registration Authority (RA) and can expose sensitive



Huang & Huang           Expires 16 December 2025                [Page 2]

Internet-Draft          Scalable Agent Enrollment              June 2025


   details about the agent's software stack.  This document reframes the
   problem to prioritize scalability, proposing two advanced enrollment
   models designed for large-scale, dynamic agent deployments.  These
   models allow enterprises to leverage the automation of SCEP [RFC8894]
   and EST [RFC7030] without creating a performance or management
   bottleneck.

2.  Terminology and Conventions

   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.

   Attestation-Aware RA:  A Registration Authority, acting as a SCEP or
      EST server, capable of functioning as a RATS Verifier.

   Capability Certificate:  An X.509 certificate containing extensions
      encoding verifiable claims about the subject's authorized
      capabilities.

   Host Endorser:  A software service running on a trusted host that is
      authorized to sign or endorse certificate requests on behalf of
      the agents it manages.

   Attestation Circuit:  A logical representation of a validation
      policy, encoded for use in a Zero-Knowledge Proof system.

3.  Problem Statement: The Scalability Challenge of Per-Enrollment
    Attestation

   A single enterprise or cloud environment may run thousands or even
   millions of ephemeral AI agents.  A centralized RA performing a full
   attestation validation for every single enrollment request faces
   three major, prohibitive issues:

   *  *Performance Bottleneck:* Validating complex evidence (e.g.,
      checking multiple software hashes, validating endorsement chains)
      for every request creates a centralized bottleneck that cripples
      the system's ability to scale for dynamic, short-lived agents.

   *  *Privacy Leakage:* Transmitting detailed evidence to a central RA
      reveals the exact software versions, configurations, and libraries
      used by every agent, which can be a significant and undesirable
      information leak.






Huang & Huang           Expires 16 December 2025                [Page 3]

Internet-Draft          Scalable Agent Enrollment              June 2025


   *  *Management Overhead:* The RA must be constantly updated with the
      "golden measurements" for every valid agent configuration, making
      the system brittle and difficult to manage in environments with
      rapid development cycles.

   To be viable, any solution MUST address these challenges.

4.  Proposed Scalable Enrollment Models

   We propose two distinct models that leverage SCEP's automation while
   providing high-assurance identity.  An implementation MAY support one
   or both models.

4.1.  Model 1: Auto-Enrollment with Zero-Knowledge Proof Attestation

   This model uses a Zero-Knowledge Proof (ZKP) to allow an agent to
   prove it meets all attestation requirements without revealing the
   evidence itself.  This provides an optimal balance of strong
   security, privacy, and performance.

Core Concept

   The RA does not validate the raw evidence.  Instead, it validates a
   small, mathematically-sound proof that the agent possesses valid
   evidence satisfying a pre-defined set of rules.

Specification and Steps

   *Phase 1: One-Time Trusted Setup (per Agent Fleet)*

   This phase is performed once by the entity deploying a fleet of
   similar agents.

   1.  *Define the Attestation Circuit:* A ZKP circuit is created.  This
       circuit is the formal specification of the validation policy.  It
       MUST encode rules such as:

       *  The private input is a valid Entity Attestation Token (EAT).

       *  The EAT is signed by a trusted Endorser Public Key.

       *  The EAT contains a specific, required software measurement
          hash.

       *  The EAT's claims are bound to a public input representing the
          CSR's public key hash.





Huang & Huang           Expires 16 December 2025                [Page 4]

Internet-Draft          Scalable Agent Enrollment              June 2025


   2.  *Generate Keys:* A trusted setup ceremony is performed on the
       circuit to generate a *Proving Key* and a *Verifying Key*.

       *  The *Proving Key* MUST be securely distributed to every AI
          agent in the fleet.

       *  The *Verifying Key* MUST be securely provisioned to the
          Attestation-Aware RA.

   *Phase 2: Automated Agent Enrollment (per Agent)*

   This is the fast, scalable, per-agent workflow.

   1.  *Agent Initialization:* The agent starts, generates a new key
       pair, and creates a CSR.

   2.  *Evidence Collection:* The agent collects its full attestation
       evidence (e.g., its EAT).  This evidence REMAINS LOCAL and is not
       transmitted.

   3.  *Proof Generation:* The agent uses its *Proving Key* to execute
       the ZKP circuit.  It provides its private evidence as private
       inputs and the hash of its CSR's public key as a public input.
       The output is a compact *ZK-Proof*.

   4.  *SCEP Request:* The agent initiates a SCEP request.  The payload
       is a `multipart/mixed` object containing the standard CSR, the
       generated ZK-Proof, and its public inputs.

   5.  *RA Verification:* The RA receives the request.  It performs a
       single, rapid ZKP verification using its *Verifying Key*. This
       validates that the agent possesses the correct private evidence
       without ever seeing it.

   6.  *Certificate Issuance:* If the proof is valid, the RA approves
       the request, and the CA issues the certificate.

4.2.  Model 2: Bootstrapped Trust via Host Endorsement

   This model amortizes the cost of attestation.  A full, heavyweight
   attestation is performed only **once** to enroll the host environment
   (e.g., a VM or server).  That trusted host is then empowered to issue
   lightweight endorsements for the agents it runs.








Huang & Huang           Expires 16 December 2025                [Page 5]

Internet-Draft          Scalable Agent Enrollment              June 2025


Core Concept

   Instead of each agent proving its own integrity from scratch, it asks
   its already-trusted host to vouch for it.  The RA's job is simplified
   to checking the host's "signature."

Specification and Steps

   *Phase 1: One-Time Host Environment Bootstrap*

   This is the high-assurance setup performed once per host machine.

   1.  *Initial Host Attestation:* The host environment performs a full
       remote attestation using its hardware root of trust (e.g., a
       TPM).  It sends its detailed evidence to a dedicated, high-
       security **Bootstrap RA**.

   2.  *Host Certificate Issuance:* The Bootstrap RA validates the
       host's integrity.  If successful, it instructs the CA to issue a
       special **Host Identity Certificate**. This certificate MUST have
       two key properties:

       *  A reasonably long lifetime (e.g., 1 year).

       *  A specific Extended Key Usage (EKU) OID, `id-kp-
          agentEnroller`, authorizing it to endorse agent certificate
          requests.

   3.  *Device-Bound Key Storage:* The private key corresponding to the
       Host Identity Certificate **MUST** be stored in the host's
       hardware-backed, non-exportable key store.

   *Phase 2: Automated Agent Enrollment (per Agent)*

   This is the highly scalable workflow that occurs on the trusted host.

   1.  *Agent Initialization:* An AI agent starts on the trusted host,
       generates a new key pair, and creates a CSR.

   2.  *Request for Endorsement:* The agent sends its CSR to a local
       **Host Endorser** service.

   3.  *Host Endorsement:* The Host Endorser service uses the device-
       bound private key from the Host Identity Certificate to create a
       detached signature (e.g., a PKCS#7 signature) over the agent's
       CSR.





Huang & Huang           Expires 16 December 2025                [Page 6]

Internet-Draft          Scalable Agent Enrollment              June 2025


   4.  *SCEP Request:* The agent initiates a SCEP request to the
       standard **Agent RA**. The request payload includes its own CSR,
       the detached signature from the Host Endorser, and the public
       Host Identity Certificate.

   5.  *RA Verification (Simplified):* The Agent RA performs two simple,
       fast checks:

       *  Does the provided signature over the CSR successfully verify
          using the public key from the Host Identity Certificate?

       *  Does the Host Identity Certificate contain the required `id-
          kp-agentEnroller` EKU and is it still valid?

   6.  *Certificate Issuance:* If both checks pass, the RA approves the
       request, and the CA issues a standard, short-lived certificate to
       the agent.

5.  Security Considerations

   The security of this system relies on several key factors:

   *  *Model 1 (ZKP):* The primary security dependency is the integrity
      of the trusted setup and the secrecy of the *Proving Key*. If a
      Proving Key is compromised, an adversary can generate valid proofs
      for a malicious agent.  Proving Keys MUST be protected as highly
      sensitive secrets.  The ZKP circuit itself MUST be audited to
      ensure it correctly and completely represents the security policy.

   *  *Model 2 (Host Endorsement):* The security of this model hinges on
      the integrity of the host environment *after* bootstrapping.  A
      compromise of the host could lead to the compromise of the *Host
      Endorser's private key*, allowing an attacker to endorse malicious
      agent CSRs.  This risk is mitigated by: 1) storing the key in
      hardware (TPM), 2) implementing continuous host-level monitoring,
      and 3) issuing very short-lived certificates to agents, forcing
      frequent re-endorsement and providing an opportunity to detect
      anomalies.

   *  *General:* In both models, it is critical to bind the identity
      being requested (the CSR's public key) to the proof or endorsement
      being provided.  This is handled explicitly as a public input in
      the ZKP model and by signing the full CSR in the Host Endorsement
      model.







Huang & Huang           Expires 16 December 2025                [Page 7]

Internet-Draft          Scalable Agent Enrollment              June 2025


6.  Privacy Considerations

   The two models presented have different privacy characteristics.

   *  The ZKP-based model (Model 1) offers strong privacy guarantees.
      The RA learns only that an agent has satisfied a specific policy,
      without learning any of the underlying evidence (e.g., software
      versions, configurations).  This is the recommended approach for
      multi-tenant or privacy-sensitive environments.

   *  The Host Endorsement model (Model 2) relies on the privacy of the
      host.  While agents do not reveal their details to the central RA,
      the Host Endorser service has visibility into every agent
      enrollment it endorses.  Implementers MUST ensure the host
      environment and the Endorser service are sufficiently hardened to
      protect this local information.

7.  IANA Considerations

   This document requests IANA to make the following allocations:

   1.  An Object Identifier (OID) for the `id-kp-agentEnroller` Extended
       Key Usage from the "SMI Security for PKIX Key Purpose" registry.
       This OID is required for Model 2 (Host Endorsement).

   2.  (Optional/Transitional) An OID for a SCEP CSR attribute to carry
       ZKP data, under the `pkcs-9-at` registry, for implementations
       that do not use a multipart message format.  TBD.

8.  Normative References

   [RFC7030]  Pritikin, M., Wouters, P., Richardson, D., Turner, T., and
              S. Boeyen, "Enrollment over Secure Transport", October
              2013, <https://www.rfc-editor.org/info/rfc7030>.

   [RFC8894]  Gutmann, P., "Simple Certificate Enrolment Protocol",
              September 2020, <https://www.rfc-editor.org/info/rfc8894>.

9.  Informative References

   [I-D.huang-rats-agentic-eat-cap-attest]
              Huang, K. and J. Huang, "Capability Attestation Extensions
              for the Entity Attestation Token (EAT) in Agentic AI
              Systems", June 2025.

Authors' Addresses





Huang & Huang           Expires 16 December 2025                [Page 8]

Internet-Draft          Scalable Agent Enrollment              June 2025


   Ken Huang
   DistributedApps.ai
   Email: ken.huang@DistributedApps.ai


   Jerry Huang
   Kleiner Perkins
   Email: huangjerry03@gmail.com











































Huang & Huang           Expires 16 December 2025                [Page 9]


name: draft-du-ai-agent-communication-6g-aspect
rev: 00
title: Use Cases and Requirements of AI Agent Communication from 6G Aspect
time: 2026-01-02T07:09:06Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-02T02:34:08Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420368+00:00
abstract:
AI Agent can do some tasks as an assistant to human beings.  During
   the task process, the Agent may need to connect to other Agents with
   different skills relative to the task.  The Agent to Agent
   communication is a new kind of traffic for Internet, and some new
   requirements for networking are proposed.  This document talks about
   the requirements and key issues of global AI agent communication
   towards 6G.  Some 6G related use cases from 3GPP documents are
   introduced.  After that, the related requirements for the AI Agent
   Communication Network (ACN) are proposed, and potential ACN
   frameworks and standardization works for the AI Agent Communication
   are also discussed.

full_text:
Network Working Group                                              Z. Du
Internet-Draft                                              China Mobile
Intended status: Informational                              30 June 2025
Expires: 1 January 2026


  Use Cases and Requirements of AI Agent Communication from 6G Aspect
              draft-du-ai-agent-communication-6g-aspect-00

Abstract

   AI Agent can do some tasks as an assistant to human beings.  During
   the task process, the Agent may need to connect to other Agents with
   different skills relative to the task.  The Agent to Agent
   communication is a new kind of traffic for Internet, and some new
   requirements for networking are proposed.  This document talks about
   the requirements and key issues of global AI agent communication
   towards 6G.  Some 6G related use cases from 3GPP documents are
   introduced.  After that, the related requirements for the AI Agent
   Communication Network (ACN) are proposed, and potential ACN
   frameworks and standardization works for the AI Agent Communication
   are also discussed.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 1 January 2026.






Du                       Expires 1 January 2026                 [Page 1]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Use Case on AI-agents Communication . . . . . . . . . . . . .   3
     2.1.  Grouping During Task Process  . . . . . . . . . . . . . .   3
     2.2.  Potential Requirements for ACN  . . . . . . . . . . . . .   5
   3.  Use Case on 6G System Assisted AI Agent Service . . . . . . .   5
     3.1.  Assistance of Network . . . . . . . . . . . . . . . . . .   5
     3.2.  Potential Requirements for ACN  . . . . . . . . . . . . .   6
   4.  Use Case on Collaborative AI Agents . . . . . . . . . . . . .   6
     4.1.  Collaboration of AI Agent . . . . . . . . . . . . . . . .   6
     4.2.  Potential Requirements for ACN  . . . . . . . . . . . . .   7
   5.  Cooperation Layer in Agent Communication  . . . . . . . . . .   7
   6.  Communication Modes of ACN  . . . . . . . . . . . . . . . . .   8
   7.  Framework of Centralized Agent Communication Platform . . . .  10
   8.  Framework of Decentralized Agent Cooperation  . . . . . . . .  12
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     12.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Appendix A.  Service Flows of AI-agents Communication . . . . . .  14
     A.1.  Pre-conditions  . . . . . . . . . . . . . . . . . . . . .  14
     A.2.  Service Flows . . . . . . . . . . . . . . . . . . . . . .  14
     A.3.  Post-conditions . . . . . . . . . . . . . . . . . . . . .  17
   Appendix B.  Service Flows of 6G System Assisted AI Agent
           Service . . . . . . . . . . . . . . . . . . . . . . . . .  17
     B.1.  Pre-conditions  . . . . . . . . . . . . . . . . . . . . .  17
     B.2.  Service Flows . . . . . . . . . . . . . . . . . . . . . .  18
     B.3.  Post-conditions . . . . . . . . . . . . . . . . . . . . .  18
   Appendix C.  Service Flows of Collaborative AI Agents . . . . . .  19
     C.1.  Pre-conditions  . . . . . . . . . . . . . . . . . . . . .  19
     C.2.  Service Flows . . . . . . . . . . . . . . . . . . . . . .  19



Du                       Expires 1 January 2026                 [Page 2]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


     C.3.  Post-conditions . . . . . . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   AI Agent can do some work instead of people leveraging the ability of
   LLM (Large Language Model).  Every Agent may have different
   abilities, and sometimes they need to cooperation to complete a task.
   During the task process, they need to communicate with each other.
   Nowadays, communication methods among the AI Agents across domains
   are still an open issue.  This document mainly focuses on the AI
   Agent communications across domains or among different organizations.

   The AI Agents mentioned in this document include the software ones
   and the embodied robot ones.  Examples of the first software mode
   include the AI assistants on mobile phones, and the AI Agent services
   provided on Internet by different organizations.  For the second
   embodied robot mode, the Agent may or may not have a SIM (Subscriber
   Identity Module) distributed by the 3GPP operators for identifying
   itself and authentication.

   In the section 6.6 to 6.8 of [TR22.870], which is still under
   working, some use cases and requirements of AI Agent communication
   from the 6G aspect are introduced.  It proposes that some
   standardization work may be needed for supporting interoperability.

   This document reviews the 6G AI Agent use cases, and discusses the
   potential work to enable the Agent Communication Network (ACN).  A
   referred analysis can be found in [I-D.rosenberg-ai-protocols], in
   which some use cases and requirements for AI Agent protocols are
   introduced.  Meanwhile, a framework is also described for the agent
   communications in that draft, and it includes the communications
   between AI agent and User, AI agent and API, AI agent and AI agent.
   By comparison, this document would mainly talk about the Agent to
   Agent (A2A) communications, and explore potential frameworks more
   detailedly.

2.  Use Case on AI-agents Communication


2.1.  Grouping During Task Process

   Grandpa Bob plans to clean the room and host a gathering at home with
   his daughter Alice's family and his son Charlie's family.  So, he
   issued the command "Clean the room and help me prepare for the family
   gathering tomorrow afternoon" to his AI-assistant.  The detailed
   service flows can be found in Appendix A.




Du                       Expires 1 January 2026                 [Page 3]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


      ..............................  ..................................
      .  Single User Group1        .  .  Food Delivery APP Group4      .
      .                            .  .                +---------+     .
      .                            .  .  +---------+   |         |     .
      .                            .  .  |FoodCom's|   |  Drone  |     .
      .                     +------.--.--+   AI    |   |         |     .
      .                     |      .  .  |Assistant|   +---------+     .
      . +---------+    +----+----+ .  .  +---------+                   .
      . |         |    |  Bob's  | .  ..................................
      . |   Bob   +----+    AI   +-.---------------------------+
      . |         |    |Assistant+-.----------+                |
      . +---------+    +--+-+----+ .          |                |
      .                   | |      .  ................  ................
      .      +------------+ |      .  . Single       .  .  Single      .
      .      |              |      .  . User Group2  .  .  User Group3 .
      . +----+----+    +----+----+ .  . +---------+  .  . +---------+  .
      . |  Home   |    |  Self   | .  . | Alice's |  .  . |Charlie's|  .
      . | Cleaning|    | Driving | .  . |   AI    |  .  . |   AI    |  .
      . |  Robot  |    |   Car   | .  . |Assistant|  .  . |Assistant|  .
      . +---------+    +---------+ .  . +---------+  .  . +---------+  .
      ..............................  ................  ................

   Figure 1: Static and Temp Grouping in Agent Communication Network


   As shown in Figure 1 for this use case, we have four groups
   relatively static, i.e., the Group 1 to 4.  Meanwhile, some temp
   groups are also needed in the service flows.

   1.  Bob's AI assistant needs to check the schedule of relatives, so a
       group including the AI assistants of Bob, Alice, and Charlie
       needs to be formed.

   2.  Bob's AI assistant and the food company's Agent need to form a
       group for discussing the food delivery location and time.

   3.  To delivery the food, the drone of the food company may visit
       Bob's house, and some A2A communications within a temp group may
       be needed.

   4.  The self driving car may need to go to the houses of Alice and
       Charlie to pick them up, and some A2A communications within a
       temp group may be needed.








Du                       Expires 1 January 2026                 [Page 4]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


2.2.  Potential Requirements for ACN

   To fulfill the task, the AI agent should be able to understand the
   user's intent and make a plan containing some task-oriented actions
   for the task.  To enable the cooperation, each agent should have an
   ID and some characteristics, which should be visible in the Agent
   Communication Network (ACN).  For the ACN, it needs to support the
   following requirements.

   1.  The ACN should support communications of AI Agents from different
       domains, and communications among the AI Agents need to be
       secured.

   2.  The ACN should support the discovery of AI Agents with specific
       skills for a task.

   3.  The ACN should support the flexible grouping of the task-related
       Agents, even when the Agents are from different domains.

   4.  The ACN should support the authentication and authorization of
       the AI Agents, when forming a temp group for a task.

   5.  The ACN should be aware of the roles, relationships, and
       permissions of the Agents in a task group.


3.  Use Case on 6G System Assisted AI Agent Service


3.1.  Assistance of Network

   Due to the limited ability of an AI Agent on device.  It is expected
   that the 6G system can assist AI agent device for awareness, decision
   making and actions in a couple of aspects.  Detailed service flows of
   this use case can be found in Appendix B.

   In the aspect of providing external environment information, 6G
   system can provide the sensing information to the Agent.  For
   example, the information surrounding objects is useful for a vehicle
   to realize the traffic situation in real time, and based on which the
   vehicle can do the corresponding actions such as changing lane and
   speed.  Additional, 6G system can provide the real time QoS change
   information.  For example, this planed QoS information can be used
   for vehicle to change autonomous mode to manual mode when the QoS
   cannot fulfill the expected latency.






Du                       Expires 1 January 2026                 [Page 5]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


   In the aspect of providing computing, 6G system can provide a more
   powerful AGI (Artificial General Intelligence) model than the light-
   weight one on the Agent.  Thus, task offloading will be needed to
   realize a "device-network collaboration", in order to make a suitable
   decision and action.  By doing so, 6G network needs to provide some
   3GPP services (e.g. sensing, positioning, text-voice converting,
   language translation) from 6G network.



3.2.  Potential Requirements for ACN

   To fulfill a task, the AI agent should be able to communicate with
   the 6G system to obtain environment information, computing service,
   etc.  For the ACN, it needs to support the following requirements.

   1.  The ACN should support exposing its services and tools to the
       Agents for invoking.

   2.  The ACN should support real time communications between the Agent
       on device and the service point on the ACN, if needed.

   3.  The ACN should be able to monitor the performance of the service,
       and report to the control point if service degeneration happens.
       The control point can be in the Agent or within the ACN.

   4.  The ACN should be aware of the network status and be able to
       expose the network information to the Agent.  Here, the network
       condition can be regarded as one of the environment information.

   5.  The ACN should be aware of the different SLA requirements of
       Agent interconnections, and apply proper policies.


4.  Use Case on Collaborative AI Agents


4.1.  Collaboration of AI Agent

   An AI agent can be implemented in the network, and it can perform
   tasks representing e.g. devices, persons, drones, or cars.  By
   offloading tasks to the network, devices can save on complexity and
   energy consumption.  Furthermore, an AI Agent in the network can
   still represent a device, person, drone or car, when that device,
   person, drone or car is not reachable, e.g. because of radio
   conditions or battery outage.  Offload can happen towards a local/
   edge network but can also be to a nearby other device with more
   processing capabilities.



Du                       Expires 1 January 2026                 [Page 6]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


   In this scenario, when the collaborating AI Agents are implemented in
   different networks, some basic functionality needs to be standardised
   to the collaboration between AI agents.  E.g. how to identify an AI
   Agent, how to authorise access to a different AI Agent and how to
   establish and maintain secure association between AI Agents.

   Detailed service flows of this use case can be found in Appendix C.


4.2.  Potential Requirements for ACN

   When the AI Agent is implemented in the network, the AI Agent
   applications need to be installed on the UE.  The ACN needs to
   support the following requirements.

   1.  The ACN should support hosting of large amounts of AI agent
       applications, and the invoking of the users.

   2.  The ACN should support the secure interoperability between AI
       Agents and between AI Agents and applications to achieve a
       collaborative task.


5.  Cooperation Layer in Agent Communication

   There are four layers to enable the Agent communication as shown in
   Figure 2.

                      +-------------------------------+
                      |          Task Layer           |
                      +-------------------------------+
                      |       Cooperation Layer       |
                      +-------------------------------+
                      |         Agent Layer           |
                      +-------------------------------+
                      |        Network Layer          |
                      +-------------------------------+

               Figure 2: Four Layers for Agent Communication

   1.  The first layer is the network layer.  It should provide the
       connection service needed between agents.

   2.  The second layer is the agent layer.  It should provide the agent
       service, and support some basic Agent to Agent communication
       functionality.





Du                       Expires 1 January 2026                 [Page 7]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


   3.  The third layer is the cooperation layer.  It should support the
       authentication of the agents, networking of the agents for a
       task, etc.  It is the main layer focused by this document.

   4.  The task layer is the fourth layer.  The task may come from a
       user or an Agent.  Some of the tasks need the involvement of the
       cooperation layer.

   There may be various tasks and various Agents, but the number of the
   realizations of the cooperation layer should be few.  With this new
   layer, flexible networking and authorization mechanisms for Agent
   Communication can be supported.


6.  Communication Modes of ACN

   There are four types of the cooperation modes for the Agent
   Communication.  It should be noted that we are talking about the A2A
   communication across domains, which is perhaps more complicated than
   the A2A communication within a group or within an organization.































Du                       Expires 1 January 2026                 [Page 8]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


      +------------------------------+  +------------------------------+
      | Cooperation Service in Cloud |  | Cooperation Service in Cloud |
      | +-------------------------+  |  | +-------------------------+  |
      | | Control & Data Message  |  |  | |     Control Message     |  |
      | ++--+-----------------+--++  |  | +--+--------------------+-+  |
      +--+--+-----------------+--+---+  +----+--------------------+----+
         |  |                 |  |           |                    |
         |  |                 |  |           |        Data        |
       +-+--+----+       +----+--+-+    +----+----+  Message +----+----+
       |         |       |         |    |         +----------+         |
       |  Agent1 |       |  Agent2 |    |  Agent3 |          |  Agent4 |
       |         |       |         |    |         |          |         |
       +---------+       +---------+    +---------+          +---------+
                    (a)                                (b)

                +---------+                       +---------+
                |         +----Control Message----+         |
                |  Agent5 |                       |  Agent6 |
                |         +------Data Message-----+         |
                +---------+                       +---------+
                                    (c)

       ............................       ..............  ..............
       .       Agent Group1       .       .   Agent    .  .   Agent    .
       .                          .       .   Group2   .  .   Group3   .
       ............................       ..............  ..............
                    |                          |              |
        +-----------+-------------+       +----+--------------+-----+
        |     Agent Gateway1      |-------|      Agent Gateway2     |
        +-----------+-------------+\     /+-----------+-------------+
                    |                \ /              |
                    |                / \              |
        +-----------+-------------+/     \+-----------+-------------+
        |     Agent Gateway3      |-------|     Agent Gateway4      |
        ++--+-----------------+--++       +--+--------------------+-+
         |  |                 |  |           |                    |
       +-+--+----+       +----+--+-+    +----+----+          +----+----+
       |         |       |         |    |         |          |         |
       |  Agent7 |       |  Agent8 |    |  Agent9 +----------+ Agent10 |
       |         |       |         |    |         |          |         |
       +---------+       +---------+    +---------+          +---------+
                                    (d)

           Figure 3: Four Types of Agent Communication Modes

   1.  In the type (a), Agent1 and Agent2 connect to the service in the
       cloud firstly, for example via an installed APP.  After that,
       they can communicate by using the service in the cloud.



Du                       Expires 1 January 2026                 [Page 9]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


   2.  In the type (b), Agent3 and Agent4 connect to the service in the
       cloud firstly, for example via an installed APP.  After that,
       they can communicate by using the service in the cloud.
       Optionally, they can establish a directly connected tunnel to
       transfer data messages.

   3.  In the type (c), where perhaps no Internet service is available,
       Agent5 and Agent6 need to authenticate each other, and establish
       a directly connected tunnel to transfer control and data
       messages.

   4.  In the type (d), Agents and Agent Groups are interconnected by
       Agent Gateways.  It is a decentralized structure.

   For the first and second mode, the Agents are connected via a
   relatively centralized way.  The advantages are that the realizations
   are easy to be extended, for example, though the APP software update.
   In Section 7, the framework and some related procedures of this mode
   is discussed.

   The third mode works like a self-organize network.  A basic
   communication channel and a common protocol are needed here.

   The Agent Gateways in the fourth mode work in a distributed way.  A
   gateway interconnection protocol is need here.  In Section 8, the
   framework and some related procedures of this mode would be talked
   about.


7.  Framework of Centralized Agent Communication Platform

   The framework of the centralized platform based Agent communication
   is shown in Figure 4.

   Some assumptions of the framework are listed as follows:

   1.  The organization A and B all have registered in the centralized
       platform P1.

   2.  The Agent A needs to fulfil a task T, which cannot be completed
       within the domain A.  Another agent with skill S is needed, and
       it is included in the centralized platform P1.

   3.  The ORG B or Agent B has registered with the skill S in the
       centralized platform P1, and Agent B supports public invocation.






Du                       Expires 1 January 2026                [Page 10]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


                         +-------------------------------+
                         |   Centralized Platform P1     |
                         +-------------------------------+
                                     |      |
                                     |      |
            Domain A of ORG A        |      |   Domain B of ORG B
      .............................. |      |    ..................
      . +---------+    +---------+ . |      |    .  +---------+   .
      . |         |    |         +-.-+      +----.--+         |   .
      . | User A  +----+AI Agent +-.-------------.--+AI Agent |   .
      . |         |    |    A    | .             .  |    B    |   .
      . +---------+    +-+--+----+ .             .  +----+----+   .
      .                  |  |      .             .       |        .
      .      +-----------+  |      .             .       |        .
      .      |              |      .             .       |        .
      . +----+----+    +----+----+ .             .  +----+----+   .
      . |         |    |         | .             .  |         |   .
      . | User C  |    | AI Agent| .             .  |  User B |   .
      . |         |    |    Z    | .             .  |         |   .
      . +---------+    +---------+ .             .  +---------+   .
      ..............................             ..................

      Figure 4: Centralized Platform based A2A Communication Framework

   A general procedure of the cooperation method is described as
   follows:

   1.  Agent A logs in the centralized platform P1, and searches for an
       Agent with skill S.  Agent B is found.

   2.  Platform P1 triggers the ORG B to notify the Agent B to log in
       the platform P1.

   3.  To complete the task T, Agent A and Agent B form a group to
       enable the communications between them.

   4.  After the task T is completed, Agent A can evaluate the service
       of Agent B, and the group may be deleted in the platform P1.

   Alternatively, after the trust relationship is established on the
   platform P1, Agent A and Agent B can also communicate directly.  Or,
   they can use the two paths for different kinds of data delivery.  For
   example, to transfer some files, they can use the directly connected
   tunnel, and to transfer some simple messages, they can use the
   overlay platform P1.






Du                       Expires 1 January 2026                [Page 11]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


   Figure 4 has shown a simple case with only two Agents to form a
   group.  If more agents are needed for the task T, a more complicated
   networking mechanism on the platform P1 can be supported.  Even the
   Agent A can delete or add some agents on the task process.

8.  Framework of Decentralized Agent Cooperation

   The framework of the gateway-based Agent communication is shown in
   Figure 5.

   Some assumptions of the framework are listed as follows:

   1.  The organization A has registered in the Gateway G1, and the
       organization B has registered in the Gateway G2.  Gateway G1 and
       G2 are in the same Agent Federation F1, which contains many agent
       gateways.

   2.  The Agent A needs to fulfil a task T, which cannot be completed
       within the domain A.  Another agent with skill S is needed, and
       it is included in the decentralized Agent Federation F1.

   3.  The ORG B or Agent B has registered with the skill S in the Agent
       Federation F1, and Agent B supports public invocation.

       +-------------------------+      +-------------------------+
       |   Agent Gateway G1      +------+   Agent Gateway G2      |
       +------------+------------+      +-------------+-----------+
                    |                                 |
      ..............................         ..................
      . +---------+    +---------+ .         .  +---------+   .
      . |         |    |         | .         .  |         |   .
      . | User A  +----+AI Agent | .         .  |AI Agent |   .
      . |         |    |    A    | .         .  |    B    |   .
      . +---------+    +-+--+----+ .         .  +----+----+   .
      .                  |  |      .         .       |        .
      .      +-----------+  |      .         .       |        .
      .      |              |      .         .       |        .
      . +----+----+    +----+----+ .         .  +----+----+   .
      . |         |    |         | .         .  |         |   .
      . | User C  |    | AI Agent| .         .  |  User B |   .
      . |         |    |    Z    | .         .  |         |   .
      . +---------+    +---------+ .         .  +---------+   .
      ..............................         ..................
            Domain A of ORG A                Domain B of ORG B

           Figure 5: Gateway-based Agent Communication Framework





Du                       Expires 1 January 2026                [Page 12]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


   A general procedure of the cooperation method is described as
   follows:

   1.  Agent A logs in the Gateway G1 of the Agent Federation F1, and
       searches for an active Agent with the skill S.  Agent B is found.

   2.  Gateway G1 and Gateway G2 form a temp group for the task.

   3.  To complete the task T, Agent A and Agent B in the group
       communicate by using the Gateway G1 and G2.

   4.  After the task T is completed, Agent A can evaluate the service
       of Agent B, and the group may be deleted.


   Figure 5 has shown a simple case with only two Agents.  If more
   agents are needed for the task T, a more complicated networking
   mechanism on the Gateways can be supported.  Even the Agent A can
   delete or add some agent on the task process.

   Some of the requirements of Gateways are introduced as follows.

   1.  Gateways should support the agent register and discovery.

   2.  Gateways should support cross-domain relays and state
       synchronizations.

   3.  Gateways should be able to notify the ACN of the information
       about the agent locally connected and related skills, and support
       the tunnel establishment for the cross domain traffic.

   4.  Gateways should support skill-based routing, where a Gateway
       works like an Agent Proxy to find the target Service Agents,
       after understanding the intent of the user or the Agent.

9.  IANA Considerations

   TBD.

10.  Security Considerations

   TBD.

11.  Acknowledgements

   TBD.

12.  References



Du                       Expires 1 January 2026                [Page 13]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

12.2.  Informative References

   [I-D.rosenberg-ai-protocols]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in
              Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
              5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

   [TR22.870] 3GPP TR 22.870, "Study on 6G Use Cases and Service
              Requirements", 2025.

Appendix A.  Service Flows of AI-agents Communication


A.1.  Pre-conditions

   Some assumptions for the service flows of this use case are listed as
   follows:

   1.  Bob has just purchased a home robot and has not connected to
       Internet.

   2.  Except for the home robot that Bob just bought, all other AI
       agents of users, have been assigned with digital identities
       associated with the user's identity.

   3.  The users' AI-agents involved in this scenario include AI
       assistant, drone and intelligent vehicle, etc.  Intelligent
       vehicles are connected through cellular networks, while other AI-
       agents are connected through home WiFi.

   4.  All AI-agents registered to 6G system, so that their attributes
       are visible for some of the members, based on permission and
       authorization.


A.2.  Service Flows

   The service flows are described as follows:




Du                       Expires 1 January 2026                [Page 14]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


   1.  Bob, Alice, and Charlie each request the operator to create AI
       agent groups for them.  They then invite their respective AI
       agents, such as their AI assistants, smart cars, drones, etc., to
       join their individual groups.  In other words, there are separate
       groups for Bob, Alice, and Charlie, allowing the AI agents within
       the same group to communicate with each other.  In addition to
       owner information (e.g. related user, etc.), examples attributes
       for Bob's AI agent in this use case are as Figure 6.

   2.  The newly purchased home robot joins to Bob's group after
       authentication, and is associated with Bob's identity.  Then, the
       home robot reports its capability to the group.

   3.  Bob sends the request to his AI-assistant, and request the AI-
       assistant to arrange the gathering as task coordinator.  The AI-
       assistant received Bob's request.  Based on the local or cloud-
       based knowledge base, Bob's AI-assistant retrieves the history of
       past family gatherings, determines the list of sub tasks and
       distributes the sub tasks to corresponding AI agents.

   4.  Bob's AI-assistant communicates with the discovered cleaning
       robot based on its capabilities and sends the request to the
       cleaning robot to carry out a full house cleaning.  When the
       cleaning robot needs collaboration from other robots, e.g. to
       move some heavy furniture, it will setup a cleaning group with
       others to enable efficient communication within the cleaning
       group.  After the cleaning, the communication group will be
       released accordingly.

   5.  Bob's AI-assistant communicates with the discovered and selected
       restaurant's AI assistant by matching the requirements and AI
       agents' attributes.  Bob's AI-assistant orders food for tomorrow
       and negotiate the food delivery time and location with
       restaurant's AI assistant.  The restaurant's AI assistant selects
       a drone based on its capabilities from restaurant's group, to do
       the food delivery.  Then the restaurant's AI assistant sends the
       determined time and location to the food delivery drone and sends
       the information of selected drone to Bob's AI-assistant, so that
       Bob's AI-assistant can communicate with drone.

   6.  During food delivery, the drone offloads a portion of the
       computational tasks to the network, to assist it in obstacle
       identification, by assisting in the process of modal
       transformation, for example, by pre-processing the images
       captured by drones, and obtaining alert data.  When drones arrive
       at the pick-up point, they will setup a temporary communication
       group with the home robot to enable secure and cooperative food
       delivery.  The communication is supported even if the drone and



Du                       Expires 1 January 2026                [Page 15]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


       home robot transmit different modality information, e.g.  video/
       text, etc.  The communication group will be released after the
       delivery.

   7.  Bob's AI-assistant communicates with Alice's AI assistant and
       intelligent vehicle.  Bob's AI-assistant negotiates with Alice's
       AI assistant for the time and place to pick up Alice's and sends
       the request to the intelligent vehicle to pick up Alice's with
       negotiation result (i.e. the pick-up time and place).

   8.  Bob's AI-assistant communicates with Charlie's AI assistant and
       intelligent vehicle.  Bob's AI-assistant negotiates with
       Charlie's AI assistant for the time and place to pick up
       Charlie's and sends the request to the intelligent vehicle to
       pick up Charlie's with negotiation result (i.e. the pick-up time
       and place).

+-----------+-------------------+------------------+-------------------+
|           | Service Features  |   Capabilities   |    Permission     |
+-----------+-------------------+------------------+-------------------+
| AI        | 1)Service         | 1)WiFi & cellular| InvitationAllowed:|
| assistant |   description:    |   connection;    |  true;            |
|           |   Voice and       | 2)Tools          | DiscoveryAllowed: |
|           |   Text-Based      |   (Perception +  |  true;            |
|           |   Interaction,    |   Action);       | ShareAllowed:     |
|           |   Information     | 3)Reasoning &    |  true;            |
|           |   Retrieval,      |   Decision       | CreatGroupAllowed:|
|           |   Personalized    |   making;        |  true             |
|           |   Recommendations | 4)Memory +       |                   |
|           | 2)Service area:   |   Reflection     |                   |
|           |   Wide            |                  |                   |
|           | 3)Moving speed:   |                  |                   |
|           |   N/A             |                  |                   |
+-----------+-------------------+------------------+-------------------+
| Drone     | 1)Service         | 1)WiFi & cellular| InvitationAllowed:|
|           |   description:    |   & V2V          |  true;            |
|           |   e.g. Radar,     |   connection;    | DiscoveryAllowed: |
|           |   Camera,         | 2)Tools          |  true;            |
|           |   Grasping,       |   (Perception +  | ShareAllowed:     |
|           |   Navigation      |   Action)        |  true;            |
|           | 2)Service area:   |                  | CreatGroupAllowed:|
|           |   Wide            |                  |  true             |
|           | 3)Moving speed:   |                  |                   |
|           |   Medium          |                  |                   |
+-----------+-------------------+------------------+-------------------+
|Intelligent| 1)Service         | 1)WiFi & cellular| InvitationAllowed:|
| vehicle   |   description:    |   connection;    |  true;            |
|           |   e.g. Radar,     | 2)Tools          | DiscoveryAllowed: |



Du                       Expires 1 January 2026                [Page 16]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


|           |   Camera, Driver  |   (Perception +  |  true;            |
|           |   Assistance, and |   Action);       | ShareAllowed:     |
|           |   improved        | 3)Reasoning &    |  true;            |
|           |   Navigation      |   Decision       | CreatGroupAllowed:|
|           | 2)Service area:   |   making;        |  false            |
|           |   Wide            | 4)Sensing        |                   |
|           | 3)Moving speed:   |                  |                   |
|           |   High            |                  |                   |
+-----------+-------------------+------------------+-------------------+
| Home      | 1)Service         | 1)WiFi           | InvitationAllowed:|
| robot     |   description:    |   connection;    |  true;            |
|           |   e.g. Voice      | 2)Tools          | DiscoveryAllowed: |
|           |   interaction,    |   (Perception +  |  true;            |
|           |   Cleaning,       |   Action)        | ShareAllowed:     |
|           |   Security        |                  |  true;            |
|           |   Monitoring,     |                  | CreatGroupAllowed:|
|           | 2)Service area:   |                  |  true             |
|           |   Local           |                  |                   |
|           | 3)Moving speed:   |                  |                   |
|           |   Low             |                  |                   |
+-----------+-------------------+------------------+-------------------+

            Figure 6: Illustrative attributes of AI agents

A.3.  Post-conditions

   The expected results are listed as follows:

   1.  The cleaning robot cleans Bob's house.

   2.  The drone sends the foods from the restaurant to Bob's house.

   3.  The intelligent vehicle picks up Alice's and Charlie's and sends
       them to Bob's house.

   4.  Alice, Charlie and Bob have a happy gathering party.


Appendix B.  Service Flows of 6G System Assisted AI Agent Service


B.1.  Pre-conditions

   Some assumptions for the service flows of this use case are as
   follows.






Du                       Expires 1 January 2026                [Page 17]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


   Bob has a robot nanny as his personal AI agent, bought from vendor-A.
   Bob's cell phone is his another personal AI agent bought from vendor-
   B.  Those AI agents on device, as personal assistant, can assist Bob
   with suggestions and actions based on information the AI agents are
   aware of.


B.2.  Service Flows

   The service flows are described as follows:

   1.  Bob, living in his home in Beijing, decided to go to Sanya for
       his winter vacation.  He asked his robot nanny (AI agent) to book
       a 5-star hotel with lowest price.

   2.  The personal assistant began to check the well-known brand hotels
       in Sanya.  As Bob is a VIP in some hotels and the AI agent needs
       to get the VIP price, when the robot nanny tried to login the
       hotel website, the application checked with 6G network that the
       AI agent (Robot nanny) is Bob's valid personal device and the
       application provided the VIP price to the Robot nanny.

   3.  By collecting a couple of 5-star hotels' price, the Robot nanny
       finally selected and booked a hotel room with the lowest price
       for Bob.

   4.  Later-on, when Bob has left home to the airport, he remembers
       there is a delivery at home that need to pick up.  Thus Bob asked
       the AI agent on cell phone, via 6G network, to notify robot nanny
       who is at home to pick up the delivery.  Given the two AI agents
       are from different vendors, they support different protocols and
       information modalities, the 6G network helped to interconnect the
       cell-phone agent with the robot nanny and then transform the
       "pick-up delivery" command from the cell phone to the pictures
       with guideline marks that the robot nanny can parse.

   5.  Robot nanny managed to pick up the delivery.


B.3.  Post-conditions

   The expected results are listed as follows.  Thanks to the 6G
   network, the AI agent on device can assist Bob to find the VIP price
   for booking hotel, and the AI agents can communicate with each other
   without "language" barrier.






Du                       Expires 1 January 2026                [Page 18]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


Appendix C.  Service Flows of Collaborative AI Agents


C.1.  Pre-conditions

   Some assumptions for the service flows of this use case are as
   follows.

   Husband and wife John and Ann own an electric car.  The electric car
   has an AI Agent that can organise various things for the car.  This
   includes that it can communicate with applications from the energy
   grid to optimise charging the car.  There is a "spot-price" for
   electricity that fluctuates with locally available electricity.  The
   price can even be negative if there is more renewable energy is
   produced than can be used.  The intelligent agent for the car is
   provided by the car company.  The local networks the AI Agent runs on
   are determined by contracts the car company has.

   John has a personal AI Agent that amongst others manages his
   calendar.  John gets the subscription for the AI Agent through his
   corporate employer.

   Also, Ann has a personal AI Agent that manages her calendar.  As Ann
   is a self-employed consultant, she obtains a subscription for her
   personal AI Agent from her telecommunications provider.

   The car AI Agent has been authorised by John and Ann to access their
   personal AI Agents to obtain information about their calendars.

C.2.  Service Flows

   The service flows are described as follows:

   1.  John is on a business trip abroad with his car.  While he is
       asleep in a hotel, the car is connected to a charger.  The AI
       Agent for the car runs in an edge network near the car.

   2.  The car AI Agent communicates with a local application for the
       local energy grid and notices that the price for electricity is
       particularly high that night in the area of the hotel.  There is
       the possibility to make a profit if the car can actually provide
       energy from its battery back to the grid.

   3.  To determine whether it is a good idea to provide energy from the
       car battery back to the grid, the car AI Agent needs to check
       whether the car needs to travel far next day.  Rather than
       calling John and Ann, and waking them up, to get that
       information, the AI Agent checks the AI Agents from John and Ann



Du                       Expires 1 January 2026                [Page 19]

Internet-Draft    6G AI Agent Usecases and Requirements        June 2025


       to see if any large trips are planned.  The AI Agent for John has
       ported to an edge location at the hotel.  The AI Agent for Ann
       runs in her telecommunications network back at home.

   4.  The personal AI Agent from John indicates that the next day John
       plans to travel back home, a 900 km journey.  It is not a good
       idea to use the car battery to sell energy back to the grid.

   5.  In the morning, John sees a message from a friend asking him to
       meet some friends in the pub.  The friends (or their personal AI
       Agents) are not authorised to access calendar information from
       his AI Agent.


C.3.  Post-conditions

   The expected results are listed as follows.  Information was
   exchanged between the car AI Agent and the personal AI Agents from
   John and Ann, even though these AI Agents at that time used computing
   resources from different providers in different countries.
   Information was protected against unauthorised access.



Author's Address

   Zongpeng Du
   China Mobile
   No.32 XuanWuMen West Street
   Beijing
   100053
   China
   Email: duzongpeng@foxmail.com


















Du                       Expires 1 January 2026                [Page 20]

categories:
["Agent-to-agent communication protocols", "Agent discovery / registration", "Identity / authentication for AI agents"]


name: draft-yl-agent-id-requirements
rev: 00
title: Digital Identity Management for AI Agent Communication Protocols
time: 2026-01-03T07:09:05Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-02T09:15:55Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420371+00:00
abstract:
AI agents are rapidly and massively transitioning from cutting-edge
   technology into real life.  The AI agent communication protocol will
   establishing a critical means to connect agents with different users,
   tools, and other agents.  Among all the features of AI agent
   communication protocol, digital identity is one of the most important
   components.  Developing a cross-industry, universal, flexible,
   interoperable, and secure AI agent digital identity protocol is the
   foundation for achieving communication between agents and other
   entities in future network.

full_text:
Network Working Group                                             K. Yao
Internet-Draft                                                    P. Liu
Intended status: Informational                              China Mobile
Expires: 2 January 2026                                      1 July 2025


    Digital Identity Management for AI Agent Communication Protocols
                   draft-yl-agent-id-requirements-00

Abstract

   AI agents are rapidly and massively transitioning from cutting-edge
   technology into real life.  The AI agent communication protocol will
   establishing a critical means to connect agents with different users,
   tools, and other agents.  Among all the features of AI agent
   communication protocol, digital identity is one of the most important
   components.  Developing a cross-industry, universal, flexible,
   interoperable, and secure AI agent digital identity protocol is the
   foundation for achieving communication between agents and other
   entities in future network.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 2 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components



Yao & Liu                Expires 2 January 2026                 [Page 1]

Internet-Draft     Agent Digital Identity Requirements         July 2025


   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Digital Identity Management Related Use Cases in the Context of
           AI Agent Communications . . . . . . . . . . . . . . . . .   3
     2.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Potential Digital Identity Management Requirements for AI Agent
           Communication . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Identifier  . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  Global Unique Identifier  . . . . . . . . . . . . . .   5
       3.2.2.  User Binding  . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Attribute . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.3.1.  Skill . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.3.2.  Capability  . . . . . . . . . . . . . . . . . . . . .   5
       3.3.3.  Service . . . . . . . . . . . . . . . . . . . . . . .   6
       3.3.4.  Key Credential  . . . . . . . . . . . . . . . . . . .   6
     3.4.  Security  . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.4.1.  Authentication  . . . . . . . . . . . . . . . . . . .   6
       3.4.2.  Authorization . . . . . . . . . . . . . . . . . . . .   6
     3.5.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.5.1.  Intra-domain  . . . . . . . . . . . . . . . . . . . .   7
       3.5.2.  Inter-domain  . . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   In recent years, large model-based generative AI is rapidly
   advancing, paving the way for the arrival of AGI.  Technically, the
   large model has evolved from the single-modal LLMs like ChatGPT to
   multi-modal Vision-Language Models (VLMs) such as DALL-E, SORA, and
   GPT-4o.  It now evolves to the Vision-Language-Action (VLA) models
   for robot control, like Google's RT-2 and RT-H.

   A large number of new intelligent terminals emerge, and embodied AI
   is poised to become the most valuable application of AI.  A plethora
   of traditional terminals are being upgraded to AI ones through
   embedded large models and AI agents, for example, AI phones, AI



Yao & Liu                Expires 2 January 2026                 [Page 2]

Internet-Draft     Agent Digital Identity Requirements         July 2025


   wearables, and AI PCs.  In addition, embodied AI comes in.  It refers
   to intelligent agents that can understand, reason, and interact with
   the physical world, such as intelligent robots, self-driving cars,
   and robot dogs.  Humanoid robots are one of the core scenarios of
   embodied AI.  According to the prediction of GGII, the global
   humanoid robot market is projected to grow from USD 1.017 billion in
   2024 to USD 15 billion in 2030, increasing at a compound annual
   growth rate (CAGR) of 56%. The global sales volume of humanoid robots
   will increase from 11,900 to 605,700.

   Everyone may have a virtual intelligent assistant.  AI agents
   understand user needs, schedule tasks, and invoke and combine massive
   applications autonomously.  AI agents will revolutionize application-
   centric development mode and Graphic User Interface (GUI)-based
   human-machine interaction.  This innovation leads to entries for
   super applications and super traffic.  Many relavant use cases have
   been mentioned in [I-D.rosenberg-ai-protocols].

   These AI agents are poised to be the "new citizens" of future network
   connections, heralding an economic boom and ushering human social
   life into a new era of collaboration between humans and AI agents, as
   well as among AI agents themselves.

2.  Digital Identity Management Related Use Cases in the Context of AI
    Agent Communications

2.1.  General

   According to ITU-T [Digital-identity], the digital identity is
   defined as follows:

   Digital Identity: The International Telecommunication Union (ITU)
   defines the concept of identity as a ‘representation of an entity in
   the form of one or more attributes that allow the entity or entities
   to be sufficiently distinguished within context’. Building on this
   definition, we might state that a digital identity is the digital
   representation of an entity detailed enough to make the individual
   distinguishable within a digital context.

   According to 3GPP [TR22.870], an AI agent is defined as follows:

   Al Agent: an automated intelligent entity capable of e.g. interacting
   with its environment, acquiring contextual information, reasoning,
   self-learning, decision-making, executing tasks (autonomously or in
   collaboration with other Al Agents) to achieve a specific goal.






Yao & Liu                Expires 2 January 2026                 [Page 3]

Internet-Draft     Agent Digital Identity Requirements         July 2025


   Thus the digital identity of an AI agent could be defined as “the
   digital representation of an AI agent detailed enough to make
   individual distinguishable within an AI agent communication context.”
   The digital identity contains mainly 3 parts: identifier, attribute
   and key credential.

2.2.  Use Cases

   According to 3GPP TR 22.870, there are some use cases discussing AI
   agent that communicate from/to terminal side with the support of
   digital identity.

   AI agents communication: - As communication serves as a common
   mechanism for sharing information, there will be more and more users
   and their AI agents that need to be supported in a near future.  A
   group could be established for users and their AI agents to
   communicate with each other.  To complete a complex task involving
   multiple users and triggered by a user, AI agent or application,
   communication domain for multiple groups could be established, the
   users and AI agents working for the same task can be explicitly
   identified by the task request or implicit identified based on
   location area or relative distance.  Communication domain could be
   dynamically created for users and AI agents from multiple groups to
   communicate with each other for a specific task during a specific
   time.  Only the AI agents in the same domain can communicate with
   each other.  If authenticated / authorized, users and AI agents could
   join this group via various access technologies, including the
   cellular network, Wi-Fi and Ethernet, etc.

   Intelligent Communication Assistants: - Overall, intelligent
   communication assistant provided by the operators natively is a
   customized service.  It can interact with end users through voice,
   text, gesture or other modalities to provide enhanced experience.
   The assistant can be customized for each particular user by accessing
   user data stored in the network.  With user’s consent, it can provide
   various communication services and support individual users based on
   user’s intention and requirement.  The provided services include
   intent-based search, personalized recommendations, voice-controlled
   smart home devices, and interaction with various services (including
   3rd party AI assistant or capabilities) or devices.  The
   customization can be achieved by providing different levels of the
   intelligent communication assistant service, based on the
   authorization from the user for user data.








Yao & Liu                Expires 2 January 2026                 [Page 4]

Internet-Draft     Agent Digital Identity Requirements         July 2025


3.  Potential Digital Identity Management Requirements for AI Agent
    Communication

3.1.  General

   Digital Identity in the context of AI agent communication involves
   several common requirements to ensure effective, efficient, and
   secure interactions.  Here is a list of potential key requirements
   derived from the illustrative use cases provided in the previous
   sections.  They are not yet formally approved by 3GPP and only
   provided for information/discussion.

3.2.  Identifier

3.2.1.  Global Unique Identifier

   AI agents SHOULD have a global unique identifier in an universal
   interoperable format to ensure the identifier can be used to
   dynamically identify and locate the AI agent.

3.2.2.  User Binding

   AI agents are designed to provide services for the human user,
   sometimes on behalf of the user.  The digital identity of an AI agent
   MUST support the description of its associated user, so that the AI
   agent communication protocol can further support user authorization
   when needed.

3.3.  Attribute

3.3.1.  Skill

   AI Agents can support multiple skills, and these skills may not be
   provided by a single manufacturer or provider.  Considering that
   skill is the nature of AI agent communication and one of the most
   important properties of an AI agent.  The definition of skills with
   different origins for an AI agent SHOULD be supported.

3.3.2.  Capability

   AI agent are able to communicate with other agents through multi-
   modal capabilities, e.g. text, image, voice, video, real-time
   communication.  These capabilities are pre-requisites for the
   communication channel establishment.  The definition of these multi-
   modal capabilities SHOULD be supported.






Yao & Liu                Expires 2 January 2026                 [Page 5]

Internet-Draft     Agent Digital Identity Requirements         July 2025


3.3.3.  Service

   AI Agent SHOULD be able to obtain long-term or short-term service
   verifiable credentials from different service providers, these
   credentials can be used for access control purposes.  The AI agent
   identity SHOULD support the definition of dynamic service attributes.

3.3.4.  Key Credential

   AI Agent SHOULD be able to support transmit, share, store its digital
   identity in a secure way.  Usually the public key credential is used
   to ensure the integrity of digital identity.  Also the key credential
   can be used by the target entity of the AI agent to verify its
   identity information.  The AI agent identity SHOULD support the usage
   of key credential.

3.4.  Security

3.4.1.  Authentication

   In addition to traditional user authentication, the authentication of
   the agent should also be considered in AI agent identity management.
   More AI agent authentication related considerations have been
   mentioned in [I-D.yao-agent-auth-considerations].  The digital
   identity SHOULD contain at least one corresponding credential for the
   unique identifier for the identification.

3.4.2.  Authorization

   According to different scenarios, there will be three different
   authorization requirements, the digital identity of AI agent SHOULD
   support these authorization requirements.

   *  Agent Authorization:

   The agent authorization is the common authorization that agent A
   provides authorized information from its own digital identity needed
   by agent B, and then agent B verifies and authorize the request.
   This is REQUIRED when an agent is on-behalf-of(OBO) itself or other
   agents.

   *  Delegation Authorization:

   The agent authorization is the common authorization that Agent A
   provides authorized information from its user’s and own digital
   identity needed by Agent B, and then Agent B verifies and authorize
   the request.  This is REQUIRED when an agent is OBO its user, itself,
   or other agents.



Yao & Liu                Expires 2 January 2026                 [Page 6]

Internet-Draft     Agent Digital Identity Requirements         July 2025


   *  User Authorization:

   The agent authorization is the common authorization that agent A
   provides authorized information from its user’s and own digital
   identity needed by agent B, and then agent B still thinks that it’s
   not sufficient, then agent B require agent A to help get a direct
   authorized information from the user to avoid risk.  This is REQUIRED
   when an agent is OBO its user.

3.5.  Discovery

3.5.1.  Intra-domain

   *  Registration: In order for a successful discovery, the AI agent
      SHOULD be able to register its digital identity in an intra-domain
      repository.  So that the AI agent can be discovered by the intra-
      domain entities (e.g. user/other agents).

3.5.2.  Inter-domain

   *  Discovery mechanism: AI agent should be able to find needed
      resource (user/tool/agent) dynamically through discovery mechanism
      depending on identifier or attribute, from intra-/inter-domain
      repositories to meet its task requirements.  The digital identity
      of AI agent should be the bearer of discovery information.

   *  Repository Update and Synchronization: In order for a successful
      discovery, different AI agent repositories SHOULD be able to
      update the digital identity information of AI agents that can be
      discovered.

4.  Security Considerations

   As discussed in previous sections, security plays a key roles in the
   definition of digital identity of AI agent.  A comprehensive
   consideration of the potential impact of the various specific
   technologies that may be involved on the overall AI agent
   communication protocol is required.

5.  Conclusions

   AI agent communication requires the participation of partners from
   the industry, academia, and research sectors, including terminal
   vendors, network service providers, cloud service suppliers, AI base
   model providers, and application developers.  Through technical
   workshops, project collaboration, and innovation pilots, all parties
   should join efforts to make AI agent communication an essential part
   of AI agent economic growth in the future.  Furthermore, the industry



Yao & Liu                Expires 2 January 2026                 [Page 7]

Internet-Draft     Agent Digital Identity Requirements         July 2025


   should advance the standardization progressively to formulate
   globally unified standards for the AI agent communication and prosper
   the industry ecosystem.

   In summary, while AI agents have impressive autonomy and
   intelligence, they are ultimately tools that serve the needs of
   individuals or organizations.  Each AI agent possesses a unique
   digital identity bound to the user identity they serve on the
   network.  After AI agents are authenticated and authorized, their
   autonomous communication activities can be supervised, controlled,
   and traced on the network by the user.  Also, diverse AI agents
   possess varying levels of sensing, decision-making, and operational
   capabilities.  Besides autonomy, these properties can be shared with
   other AI agents through discovery and orchestration, facilitating
   task collaboration and achieving the effect of collective
   intelligence.

   Standard solutions will be required to support the management of
   digital identity for AI agent communications.  To ensure the global
   interoperability between heterogeneous AI agents, a standardized AI
   agent communication protocol including the digital identity
   management needs to be introduced for the session establishment and
   multi-modal data transmission.  It is expected that IETF could be the
   place to develop such standard.

6.  IANA Considerations

   TBD.

7.  Acknowledgements

8.  Informative References

   [Digital-identity]
              ITU-T, "Digital Identity Roadmap Guide, D-STR-
              DIGITAL.01-2018-PDF-E.", n.d..

   [I-D.rosenberg-ai-protocols]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in
              Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
              5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

   [I-D.yao-agent-auth-considerations]
              Yao, K., "Further considerations on AI Agent
              Authentication and Authorization Based on OAuth 2.0
              Extension", Work in Progress, Internet-Draft, draft-yao-



Yao & Liu                Expires 2 January 2026                 [Page 8]

Internet-Draft     Agent Digital Identity Requirements         July 2025


              agent-auth-considerations-00, 30 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-yao-agent-
              auth-considerations-00>.

   [TR22.870] 3GPP, "Study on 6G Use Cases and Service Requirements",
              n.d..

Authors' Addresses

   Kehan Yao
   China Mobile
   Email: yaokehan@chinamobile.com


   Peng Liu
   China Mobile
   Email: liupengyjy@chinamobile.com


































Yao & Liu                Expires 2 January 2026                 [Page 9]

categories:
["Identity / authentication for AI agents", "Agent-to-agent communication protocols", "Agent discovery / registration"]


name: draft-song-oauth-ai-agent-authorization
rev: 00
title: OAuth2.0 Extention for AI Agent: Authorization on Target
time: 2026-01-06T07:09:06Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-05T09:47:05Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420373+00:00
abstract:
In this draft, we address to potential adapt authorization frameworks
   for the future AI agent.  An extension is proposed in the OAuth 2.0
   protocol with an optional field *target_id* for granular
   authorization.  It can be seen useful for the future virtual/physical
   AI agents.  By explicitly identifying the target during
   authorization, the draft aims to support precise permission
   management and enhance traceability.  Serveral risks can be mitigated
   through the proposed extension, such as potential unauthorized or
   malicious behavior of AI components in the netowrk, while the
   compatibility of existing OAuth 2.0 workflows is still maintained.

full_text:
Web Authorization Protocol                                       Y. Song
Internet-Draft                                                     L. Li
Intended status: Experimental                                     Huawei
Expires: 4 January 2026                                           F. Liu
                                                        Huawei Singapore
                                                             3 July 2025


        OAuth2.0 Extention for AI Agent: Authorization on Target
               draft-song-oauth-ai-agent-authorization-00

Abstract

   In this draft, we address to potential adapt authorization frameworks
   for the future AI agent.  An extension is proposed in the OAuth 2.0
   protocol with an optional field *target_id* for granular
   authorization.  It can be seen useful for the future virtual/physical
   AI agents.  By explicitly identifying the target during
   authorization, the draft aims to support precise permission
   management and enhance traceability.  Serveral risks can be mitigated
   through the proposed extension, such as potential unauthorized or
   malicious behavior of AI components in the netowrk, while the
   compatibility of existing OAuth 2.0 workflows is still maintained.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 4 January 2026.





Song, et al.             Expires 4 January 2026                 [Page 1]

Internet-Draft              Abbreviated-Title                  July 2025


Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Extention of Protocol Flow  . . . . . . . . . . . . . . . . .   4
     3.1.  Extension for Client Registration . . . . . . . . . . . .   5
     3.2.  Authorization Request & Response  . . . . . . . . . . . .   5
     3.3.  Access Token Request & Response . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  References  . . . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.3.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The rapid development of current AI agents necessitates urgent
   research in the field of AI agent security.  Specifically, based on
   the analysis in [I-D.rosenberg-ai-protocols], authorization stands as
   a key research direction within AI agent security, covering both
   intra-domain and inter-domain levels.  It involves various scenarios
   such as AI agents accessing APIs (e.g., scenarios under the MCP
   protocol) and mutual access between AI agents (e.g., scenarios under
   the A2A protocol).  However, AI agents possess the characteristics of
   autonomy, dynamics, and long-lived identities, making the direct
   application of procedures defined by existing standards (OAuth)
   significantly inadequate.  What's more, as specified in the EU GDPR,
   data subjects have the right to know how their data will be used.  In
   the context of authorization, the resource owner, as the provider of
   data, resources, or services to the AI agent, acts as a data subject.
   To better comply with regulation, the client should therefore
   disclose not only its own identity but also the identity of the



Song, et al.             Expires 4 January 2026                 [Page 2]

Internet-Draft              Abbreviated-Title                  July 2025


   specific AI agent executing the actions.

   Therefore, it is necessary to adapt OAuth scheme for full-scenario
   authorization of AI agents.  Nevertheless,
   [I-D.oauth-ai-agents-on-behalf-of-user] has designed a user-delegated
   authorization mechanism for AI agents based on "actor" to implement
   user-delegated authorization for AI agents.  It is observed in
   [I-D.yao-agent-auth-considerations] that AI agents can be devided
   into two categories: physical AI agent and vitual AI agent.  This
   draft will consider the scenario where the AI agent itself acts as a
   client, which includes the following two use cases based on the
   category.

   *  Use Case 1: The user deploys an AI model on a client that acts as
      a virtual AI agent.  In this case, the AI agent is a module on the
      client.  For example, the client could be a smartphone, where the
      user downloads a ChatGPT model and instantiates an AI agent
      locally.

   *  Use Case 2: The client is a physical AI agent equipped with
      multiple AI models differing in functionality, versions, or
      vendors.  In this case, the AI model is a module on the AI agent.
      For example, if developers provide only an AI agent framework with
      APIs and functional blocks, the user can select Model A for
      chatting and Model B for confidential work within their company,
      then install both into the agent.

   As previously noted, AI agents function differently from other
   modules.  Once authorized by the user, an AI agent can make
   independent decisions and execute tasks automatically.  While this
   brings convenience to daily life, it also introduces significant
   uncertainty due to unexplainable problem of AI.  Specifically, an AI
   agent or AI model could be compromised or trained to perform harmful
   tasks even as other client modules remain unaffected -- this risk is
   heightened when the client and the AI agent or AI model originate
   from different providers.  In such cases, failing to identify the
   specific AI agent or model involved would hinder root cause analysis.
   Moreover, authorizing at the client level might lead to accidental
   denial of authorization on the client, disrupting the client's normal
   operation.











Song, et al.             Expires 4 January 2026                 [Page 3]

Internet-Draft              Abbreviated-Title                  July 2025


   Therefore, for these use cases, authorization needs to clarify which
   specific module of the client is being authorized.  This draft
   proposes an authorization mechanism centered on a *target* -- role
   introduced to identify the client module requiring authorization.  To
   support this, an optional extension field named *target_id* is added
   to the OAuth 2.0 protocol flow.  The *target* may refer to virtual AI
   agents deployed on the client or AI models hosted on a physical AI
   agent.

   This solution clearly distinguishes between the client and its AI
   agents or models, preventing unintended disruptions.  Additionally,
   it allows users to select the appropriate AI agent or AI model on the
   client to grant consent to.  For example, in daily scenarios, they
   may authorize Model A, while in work scenarios, they may choose Model
   B in previous example.  Furthermore, users can clearly see which AI
   agent or model is requesting permission, enabling better management
   of local AI components.  For instance, if Model B requests access to
   the user's digital album, the user can reject the request and even
   revoke Model B's permission to access all files on a specific disk.

2.  Terminology

   Target: a module on the client that actually utilize the resource
   provided by resource owner, e.g. a virtual AI agent deployed on the
   client, or an AI model deployed on the client (physical AI agent).

   This draft uses the terms "authorization server", "client", "resource
   server" defined by OAuth 2.0 [RFC6749]

3.  Extention of Protocol Flow

   This protocol flow is modeled after [RFC6749] and extends it with a
   *target_id* field to enable authorization for the target.


















Song, et al.             Expires 4 January 2026                 [Page 4]

Internet-Draft              Abbreviated-Title                  July 2025


        +--------+                               +---------------+
        |        |--(A)- Authorization Request ->|   Resource    |
        |        |                               |     Owner     |
        |        |<-(B)-- Authorization Grant ---|               |
        |        |                               +---------------+
        |        |
        |        |                               +---------------+
        |        |--(C)-- Authorization Grant -->| Authorization |
        | Client |         *target_id*           |     Server    |
        |        |                               |               |
        |        |<-(D)----- Access Token -------|               |
        |        |         (*tar=target_id*)     +---------------+
        |        |
        |        |                               +---------------+
        |        |--(E)----- Access Token ------>|    Resource   |
        |        |                               |     Server    |
        |        |<-(F)--- Protected Resource ---|               |
        +--------+                               +---------------+

3.1.  Extension for Client Registration

   Before initiating the protocol, the client registers with the
   authorization server, as defined in [RFC6749].

   In this draft, information about the AI agent or AI model is included
   as part of the client registration process, including details such as
   identity and capabilities.  For instance, when a client registers
   using a profile, if it is deployed with an AI agent or AI model, the
   profile will incorporate relevant information about them.
   Additionally, the client itself maintains awareness of the AI agent
   or AI model information.

3.2.  Authorization Request & Response

   At first the client requests authorization from the resource owner
   and receives an authorization grant, as defined in [RFC6749].

   When the client needs to execute a task, it selects the AI agent or
   AI model capable of performing the task.  Selection methods may
   include:

   *  Semantic matching based on the capabilities of the AI agent or AI
      model and the task description.  The task description may be
      received from other entities or determined by the client.  For
      example, if a model's capability is "image recognition" and the
      task description is "identify geographical location from an
      image", a match is established.




Song, et al.             Expires 4 January 2026                 [Page 5]

Internet-Draft              Abbreviated-Title                  July 2025


   *  Selecting an available AI agent or model based on operational
      status.  For example, both Model A and Model B support image
      recognition, but Model A is in use while Model B is idle, so Model
      B is chosen.

   *  Choosing the appropriate AI agent or AI model based on the
      availability of computing resources and the resource consumption
      of each option.

   *  The client acts as an "entry point" to uniformly receive user
      requirements and then internally selects models according to
      preset rules.  For instance, after the user authorizes the "office
      scenario," the client automatically selects Model B.

   Following this step, the chosen AI agent or AI model is designated as
   the *target*.

3.3.  Access Token Request & Response

   The client requests an access token by authenticating with the
   authorization server and presenting the authorization grant, as
   defined in [RFC6749], and the message includes the following
   parameters:

   target_id

      OPTIONAL.  The identifier of the target which is determined to
      utilize the requested resource.

   code

      REQUIRED.  The authorization code received from the authorization
      server, as defined in [RFC6749].

   client_id

      REQUIRED, if the client is not authenticating with the
      authorization server, as defined in [RFC6749].

   The authorization server authenticates the client and validates the
   authorization grant, as defined in [RFC6749].  Then, the
   authorization server further validates whether the target identified
   by the target_id in the message is successfully registered and
   whether the target is bound to the client.  For example, the client's
   profile includes the target_id.  If valid, the authorization server
   issues an access token containing a claim indicating that the target
   is authorized.




Song, et al.             Expires 4 January 2026                 [Page 6]

Internet-Draft              Abbreviated-Title                  July 2025


   If the validation is successful, the access token response message
   includes an access token.  The acess token is similar to OAuth2.0,
   except that it consists of an additional claim to specify the target.

   tar

      OPTIONAL.  The identifier of the target which is authorized to
      utilize the requested resource.

   If the validation fails, the access token response message includes
   the reason for failure.  [RFC6749] has defined types of error
   response.  In this case, if the target validation fails, the
   authorization server may reuse the unauthorized_client message and
   indicate that the target is not registered.

   The client requests the protected resource from the resource server
   and authenticates by presenting the access token, as defined in
   [RFC6749].  Additionally, it should send the target_id to the
   resource server to indicate that the requested resource will be used
   by the target.  The resource server validates the access token, as
   defined in [RFC6749] and also validates whether the received
   target_id is included in the access token.  If the validation
   succeeds, the resource server provides the resource to the client,
   which then passes the resource to the AI agent or AI model identified
   by the target_id.

4.  Security Considerations

   TBD

5.  IANA Considerations

   TBD.

6.  References

6.1.  References

6.2.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC6749]  Hardt, Dick., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.



Song, et al.             Expires 4 January 2026                 [Page 7]

Internet-Draft              Abbreviated-Title                  July 2025


6.3.  Informative References

   [I-D.oauth-ai-agents-on-behalf-of-user]
              Senarath, T. S. and A. Dissanayaka, "Further
              considerations on AI Agent Authentication and
              Authorization Based on OAuth 2.0 Extension", Work in
              Progress, Internet-Draft, draft-oauth-ai-agents-on-behalf-
              of-user-01, 8 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-oauth-ai-
              agents-on-behalf-of-user-01>.

   [I-D.rosenberg-ai-protocols]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in
              Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
              5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

   [I-D.yao-agent-auth-considerations]
              Yao, K., "Further considerations on AI Agent
              Authentication and Authorization Based on OAuth 2.0
              Extension", Work in Progress, Internet-Draft, draft-yao-
              agent-auth-considerations-00, 30 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-yao-agent-
              auth-considerations-00>.

Authors' Addresses

   Yurong Song
   Huawei
   Email: songyurong1@huawei.com


   Lun Li
   Huawei
   Email: lilun20@huawei.com


   Faye Liu
   Huawei Singapore
   Email: liufei19@huawei.com










Song, et al.             Expires 4 January 2026                 [Page 8]

categories:
["Identity / authentication for AI agents", "Policy / governance / ethical frameworks", "Agent discovery / registration"]


name: draft-wang-nmrg-magent-im
rev: 00
title: A Protocol-agnostic Multiple Agents Interaction Model for Autonomous Network
time: 2026-01-09T07:09:46Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T12:01:57Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420376+00:00
abstract:
In the push toward Level 4 Autonomous Networks, CSPs must to adopt
   new processes and organizational changes, along with function-centric
   building blocks for higher autonomy.  As intelligent agents evolve,
   network autonomy increasingly relies on deploying these agents,
   enabling self-management, self-healing, and adaptation with minimal
   human intervention.  These agents facilitate the transition toward
   fully autonomous network operations across multiple layers, including
   services and resources.  However, achieving Level 4 autonomy, where
   networks independently handle tasks across various domains, presents
   significant challenges, notably secure, efficient, and accurate
   multi-agent interactions.  This document introduces a protocol-
   agnostic data model that enables multiple intelligent agents to
   communicate effectively using the model, ensuring end-to-end task
   execution and closed-loop operations in autonomous networks.

full_text:
Network Management Research Group                                M. Wang
Internet-Draft                                                    Y. Xie
Intended status: Informational                                     Q. Wu
Expires: 8 January 2026                                           Huawei
                                                             7 July 2025


  A Protocol-agnostic Multiple Agents Interaction Model for Autonomous
                                Network
                      draft-wang-nmrg-magent-im-00

Abstract

   In the push toward Level 4 Autonomous Networks, CSPs must to adopt
   new processes and organizational changes, along with function-centric
   building blocks for higher autonomy.  As intelligent agents evolve,
   network autonomy increasingly relies on deploying these agents,
   enabling self-management, self-healing, and adaptation with minimal
   human intervention.  These agents facilitate the transition toward
   fully autonomous network operations across multiple layers, including
   services and resources.  However, achieving Level 4 autonomy, where
   networks independently handle tasks across various domains, presents
   significant challenges, notably secure, efficient, and accurate
   multi-agent interactions.  This document introduces a protocol-
   agnostic data model that enables multiple intelligent agents to
   communicate effectively using the model, ensuring end-to-end task
   execution and closed-loop operations in autonomous networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 January 2026.







Wang, et al.             Expires 8 January 2026                 [Page 1]

Internet-Draft                   MAgent                        July 2025


Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Scenario’s description  . . . . . . . . . . . . . . . . . . .   4
     2.1.  Use Case 1: Fault management for large-scale batch out of
           service of mobile network base stations.  . . . . . . . .   4
     2.2.  Fault, experience, and energy-saving agents collaborate
           across multiple scenarios and service flows in an
           interconnected and coordinated manner . . . . . . . . . .   6
     2.3.  User Complaints Handling  . . . . . . . . . . . . . . . .   8
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .  10
   4.  Functional Design . . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  Agent register, discovery, and capability negotiation . .  12
     4.2.  Task dispatch . . . . . . . . . . . . . . . . . . . . . .  13
     4.3.  Multiple rounds of negotiation of the task  . . . . . . .  13
     4.4.  Support structured and unstructured interaction of
           tasks . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.5.  Task execution result negotiation . . . . . . . . . . . .  14
   5.  Model design  . . . . . . . . . . . . . . . . . . . . . . . .  14
     5.1.  Agent profile . . . . . . . . . . . . . . . . . . . . . .  14
     5.2.  Task  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     5.3.  Task negotiation  . . . . . . . . . . . . . . . . . . . .  19
     5.4.  Task notification . . . . . . . . . . . . . . . . . . . .  20
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  21
   Appendix A.  appendix: YANG DATA Model  . . . . . . . . . . . . .  22
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  33
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  33
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33




Wang, et al.             Expires 8 January 2026                 [Page 2]

Internet-Draft                   MAgent                        July 2025


1.  Introduction

   One of the main drivers for automation in communications service
   providers’ (CSPs’) networks is the urgent need to reduce complexity
   so that they can lower operating costs.  Using artificial
   intelligence (AI) and machine learning, CSPs are aiming to fully
   automate the lifecycle of the services they deliver to end customers
   and of internal network services, which are chains of technical
   components.  The idea is to abstract the network as a set of software
   services and then use intent, automated closed control loops, and
   machine learning to make networks and operations self-configuring,
   self-optimizing, self-organizing, self-healing, and self-evolving.
   TMfourm defines the development of an AN network as five levels.  The
   fourth level requires that the system be used to process network
   services in four dimensions: perception, analysis, decision-making,
   and execution.  [TMF IG1230]

   With the advancement of LLM and intelligent agent technologies, the
   development of Autonomous Networks (AN) increasingly depends on
   deploying intelligent agents.  However, unlike general-purpose
   intelligent agents, AN has distinct characteristics.  Firstly, the
   application scenarios are relatively fixed, focusing on the
   automation and intelligentization of network management services.
   For example, TMF has defined 20 high-value scenarios in this area.
   Secondly, AN follows a logical framework of single-domain autonomy
   and cross-domain collaboration.  It also encompasses multi-task
   collaboration and supports both proactive (self-managed) and reactive
   (complaint and trouble ticket handling) interaction modes, these
   tasks and operations still involve some ambiguity and uncertainty.
   Thirdly, in the field of network operation and management, widely
   deployed protocols such as Netconf and RestConf are in use.  This
   requires AN agents to communicate in a way that ensures both the
   accuracy and efficiency of structured data for deterministic tasks,
   and also supports natural language interactions for understanding and
   handling uncertain or ambiguous tasks.  Additionally, compatibility
   with existing network protocols is essential for seamless integration
   and operation.

   This document presents a protocol independent data model that enables
   multiple intelligent agents to communicate and interact effectively.
   This facilitates collaboration among agents, allowing them to work
   together seamlessly to accomplish autonomous network (AN) tasks.  The
   proposed data model ensures flexible, accurate, and efficient data
   exchange, supporting coordinated decision-making and execution within
   the autonomous network ecosystem.






Wang, et al.             Expires 8 January 2026                 [Page 3]

Internet-Draft                   MAgent                        July 2025


1.1.  Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Scenario’s description

2.1.  Use Case 1: Fault management for large-scale batch out of service
      of mobile network base stations.

   In this scenario, the fault management process requires coordination
   between different domains, such as the wireless network and the
   transport network.  The operation typically takes over one hour to
   complete and is prone to triggering fault escalations due to the
   complex, cross-domain interactions and potential network disruptions
   during the shutdown process.  To address this issue, TMForum has
   defined [IG1501], a standard solution package designed to handle
   autonomous network fault management processes across cross-operation
   and maintenance management domains.  This framework facilitates
   coordinated and efficient fault detection, diagnosis, and resolution,
   helping to minimize operational risks and downtime during large-scale
   batch out of service activities.  The AN L4 fault management flow for
   this scenario is excerpted as follows:

























Wang, et al.             Expires 8 January 2026                 [Page 4]

Internet-Draft                   MAgent                        July 2025


     +-------------------OSS FAULT MGMT. AGENT-----------+
     | +----------------+             +----------------+ |
     | |                |             |                | |
     | | EVENT ANALYSIS --------------- CROSS-DOMAIN   | |
     | |                |             |    ANALYSIS    | |
     | |                |             |                | |
     | +-------.-----,--+             +-----,./--------+ |
     |         |      `'.,              ,-'`  |          |
     |         |          '.,       ,-'`      |          |
     +---------|-------------`-,,-'`----------\----------+
                |           ,-'``'.,           |
                |       ,-'`        `-,        |
                |   ,-'`               `',     |
     +----------|-'`-------+        +-----`'.,-\---------+
     | +--------\--------+ |        | +-------`--------+ |
     | |                 | |        | |                | |
     | |  Wireless Network |        | | IP Network fault |
     | |   fault agent   | |        | |     agent      | |
     | |                 | |        | |                | |
     | +-----------------+ |        | +----------------+ |
     |                     |        |                    |
     |   Wireless network  |        |   IP Network Domain|
     |       domain        |        |                    |
     +---------------------+        +--------------------+


         Figure 1: Work flow of AN L4 Cross Domain fault management

   Step 1-2: represent the fault occurrence phase.  As above example, in
   the IP network AN domain, a line interruption fault occurs.  In the
   mobile network AN domain, a mass base station outage fault occurs.

   Steps 3-4 represent the fault awareness phase.  For example, in the
   above figure, the service layer fault agent receives various types of
   information, including (3a) incident actively sent by the mobile
   network agent, (3b) incident actively sent by the IP network agent,
   and (3c) user complaints.  The service layer cross-domain agent
   performs cross-domain correlation analysis on this information (4).

   Step 5 is the analysis and decision phase of fault management.  In
   the above example, the service layer cross-domain identifies the
   fault as a cross-domain fault and determines the site where the fault
   occurred and the return link.  It then sends diagnostic information
   to the corresponding resource layer fault agent (IP network fault
   agent).  The resource layer fault agent performs self-diagnosis and
   returns the fault information and handling recommendations to the
   cross-domain agent.




Wang, et al.             Expires 8 January 2026                 [Page 5]

Internet-Draft                   MAgent                        July 2025


   Steps 6-8 represent the execution and repair phase of fault
   management.  In the above example, the cross-domain agent receives
   fault information and repair suggestions sent by the resource layer
   agent and determines that automatic repair is not possible, prompting
   the initiation of a trouble ticket system to assign the repair
   trouble ticket to the FME (6).  The FME interacts with the service
   layer’s FME Copilot through an app to query relevant information
   about the faulty device (7).  The service layer FME Copilot
   collaborates with the resource layer FME Copilot, which provides the
   FME with natural language-based operational guidance to assist in
   completing the fault repair (8).

   In this scenario, the fault types and interaction processes are
   typically deterministic and qualitative.  Utilizing structured
   language for communication between agents enhances reliability and
   efficiency.

2.2.  Fault, experience, and energy-saving agents collaborate across
      multiple scenarios and service flows in an interconnected and
      coordinated manner




       +----------------------------------------------+
       |                                              |
       |    OSS service intent: fault management      |
       |         performance optimization,            |
       |                  energy-saving               |
       +--------------------,.--/-----,---------------+
                        _.'`    |      `.,
                     ,-`        |         '.
                 ,-``           |           `',
       +-------'`--+      +-----|-----+    +---`'-----+
       |           |      |     \     |    |          |
       |           |      |           |    |          |
       |           |      |           |    |          |
       | Energy saving    | peformance|    |  fault   |
       |   agent   -------|  optimization---  management
       |           |      |  agent    |    |  agent   |
       |           |      |           |    |          |
       |           |      |           |    |          |
       |           |      |           |    |          |
       +-----------+      +-----------+    +----------+


               Figure 2: Multi-service agent collaboration t




Wang, et al.             Expires 8 January 2026                 [Page 6]

Internet-Draft                   MAgent                        July 2025


   Currently, fault management, performance optimization, and energy-
   saving workflows are operated separately, with each stream managed
   independently.  The fault management, performance optimization, and
   energy-saving processes are not interconnected, leading to a lack of
   coordination.  When a base station encounters a fault, manual
   intervention is required to optimize service performance for local
   coverage restoration and to adjust energy-saving strategies, in order
   to ensure a consistent user experience.  This disconnected approach
   can cause delays and inefficiencies in resolving issues and
   maintaining service quality.  To address this issue, in AN Level 4,
   the fault management, experience optimization, and energy-saving
   agents can autonomously collaborate and interact without human
   intervention.  The process begins with negotiating to compensate user
   experience and adjust energy-saving strategies before locating the
   fault, thereby ensuring a seamless user experience.  The workflow may
   proceed as follows:

   The mobile network fault agent initiates collaboration with the
   mobile network optimization agent, prompting the optimization agent
   to adjust neighboring cell base station power to compensate for user
   experience.

   The experience optimization agent collaborates with the energy-saving
   agent to reduce energy-saving targets or temporarily disable energy-
   saving functions.

   The mobile network fault agent starts diagnosis by checking
   configurations and other parameters, then initiates a diagnostic
   collaboration request.  The IP network fault agent conducts the
   analysis and returns diagnostic results.  The mobile network agent
   performs checks and proceeds with fault repair, such as restoring the
   base station.

   Once the issue is resolved, mobile network fault agent initiates a
   final collaboration, instructing the optimization agent to cancel the
   compensation, while the energy-saving agent resumes normal energy-
   saving operations.

   In this scenario, multi-agent systems need to understand various
   tasks; however, it is impossible to exhaustively enumerate all
   arrangements and relationships among different operations.
   Understanding these tasks involves natural language processing, while
   executing specific tasks requires structured language, representing
   an intermediate state between unstructured comprehension and formal
   execution.






Wang, et al.             Expires 8 January 2026                 [Page 7]

Internet-Draft                   MAgent                        July 2025


2.3.  User Complaints Handling

   Customer complaints are usually expressed directly in natural
   language, requiring intelligent agents to parse, analyze, and respond
   to them.  A typical scenario involves complaints related to the
   Internet of Vehicle.  The Internet of Vehicles (IoV) is an
   interactive wireless network built based on vehicle information such
   as location, speed, and routes.  By utilizing devices like GPS, RFID,
   sensors, and camera image processing, vehicle networking enables the
   collection of environmental and status information of the vehicles
   themselves.  Subsequently, through the Internet and computer
   technologies, this information is analyzed and processed to determine
   the optimal routes for different vehicles, provide real-time traffic
   and weather updates, and coordinate traffic signal cycles.
   Ultimately, it achieves organic interaction between cars, roads, and
   people, realizing intelligent transportation and vehicle systems.  It
   may concern wireless communication, data transmission, cloud
   verification, and integration with upper-layer systems.  The
   complaint handling interface utilizes trouble tickets information
   described in natural language.  The workflow may proceed as follows:































Wang, et al.             Expires 8 January 2026                 [Page 8]

Internet-Draft                   MAgent                        July 2025


           +------------------------+
           |  Automobile Manufacturer
           |     complaints         |
           |                        |
           +-----------/------------+
                       |
           +-----------\------------+
           |  BSS trouble ticket    |
           |      system            |
           |                        |
           +-----------/------------+
        +--------------|----------------------------------------------+
        |              |         OSS                                  |
        |  +-----------\------------+         +----------------------+|
        |  |                        |         |                      ||
        |  |  Domain A complain     |         |  Domain B complain   ||
        |  |     handling agent     -----------    handling agent    ||
        |  |                        |         |                      ||
        |  +-----------,------------+         +----------------------+|
        +-------------/--`.-------------------------------------------+
                     '     \
       +-------------------------------+
       |   +-----------+ +----'-----+  |
       |   | Mobile    | |  IP network |
       |   | network   | |  agent   |  |
       |   |  agent    | |          |  |
       |   +-----------+ +----------+  |
       |         NETWORK               |
       |                               |
       +-------------------------------+


                   Figure 3: IOV User Complaints Handling

   In this scenario, automotive companies centrally collect complaints
   from their customers (drivers) and use the operator’s complaint
   system to feedback issues to the operator.  The operator's BSS
   trouble ticket system generates tickets from these complaints and
   dispatches them to the OSS.  The integrated vehicle networking
   complaint handling agent within the OSS analyzes the trouble tickets
   and performs boundary localization.

   Typically, boundary localization involves two situations: one within
   the current management and maintenance domain, such as within the
   same province or city; and the other across management and
   maintenance domains, such as when a vehicle moves to another province
   or city at a certain time and encounters an issue.




Wang, et al.             Expires 8 January 2026                 [Page 9]

Internet-Draft                   MAgent                        July 2025


   For the first case, the vehicle networking trouble ticket agent
   within the OSS will parse the ticket into multiple sub-tickets and
   interact with the transmission network agent and mobile network agent
   within its management domain to resolve the problem.

   For the second case, the management and maintenance domain A's agent
   analyzes the ticket and forwards the relevant information pertaining
   to domain B to the agent responsible for domain B.  Upon receiving
   the trouble ticket, the domain B agent follows a process similar to
   that of the first situation to address the issue.

   Since the content of complaints from automotive companies is usually
   described in natural language, the interactions of the intelligent
   agents in the above scenario are triggered by natural language
   inputs.  And because of complaint content is unpredictable and the
   involved domains cannot be anticipated, it represents an uncertain
   environment.  Natural language interaction is employed to effectively
   address and manage these ambiguous tasks.

3.  Architecture

   The prominent characteristic of these scenarios, which was introduced
   in section 2, is that the implementation of AN Level depends on the
   deployment of agents and the interaction among multiple agents.  In
   response to this, TMF [IG1251C] has defined a reference architecture
   for AN Level 4, providing guidance on how to structure and coordinate
   multi-agent systems to achieve the desired levels of performance and
   automation.  The architecture is excerpted as follows:























Wang, et al.             Expires 8 January 2026                [Page 10]

Internet-Draft                   MAgent                        July 2025


   +-------------------------------------------------------+
   |                                                       |
   |      Business management                              |
   |                                                       |
   |    Billing Agent,  Sales Copilt, etc                  |
   +-------------------------------------------------------+

   +-------------------------------------------------------------------+
   |                       Service layer                               |
   |  +-----------------------------------------------+                |
   |  |         service intent                        |                |
   |  |                                               |                |
   |  +-----------------------------------------------+                |
   |                                                                   |
   |  +------------+      +---------------+    +------------+          |
   |  |            |      |               |    |            |          |
   |  |  service delivery | fault mgmt,   |    | quality assurance  ...|
   |  |    agent   |      |    agent      |    |    agent   |          |
   |  +------------+      +---------------+    +------------+          |
   |                                                                   |
   |                                                                   |
   +-------------------------------------------------------------------+
   +--------------------------------+  +-------------------------------+
   |  +---------------------------+ |  |                               |
   |  |  network intent           | |  |                               |
   |  |                           | |  |                               |
   |  +---------------------------+ |  |                               |
   |  +-----------+ +---------+     |  |                               |
   |  |           | |quality  |     |  |   ..........                  |
   |  | fault mgmt| | assurance ... |  |                               |
   |  |   agent   | |  agent  |     |  |                               |
   |  +-----------+ +---------+     |  |                               |
   |                                |  |                               |
   |   Autonomous domain X          |  |     Autonomous domain Y       |
   +--------------------------------+  +-------------------------------+


                  Figure 4: AN Agentic Architecture













Wang, et al.             Expires 8 January 2026                [Page 11]

Internet-Draft                   MAgent                        July 2025


   Functional capabilities define what a network must do; agentic
   realization defines how it is done autonomously.  Agentic realization
   transforms abstract functional requirements into real-time, adaptive
   behaviors through intelligent agents and copilots.  Each agent
   continuously monitors its environment, makes decisions using AI-
   driven logic, and acts autonomously within defined operational
   domains.  These agents operate across Business, Service, and Network
   layers, each guided by its own Operations Intelligence block.  These
   blocks embed AI inference, govern agent behavior, and align decisions
   with domain-specific objectives.  Copilots, meanwhile, assist human
   roles with context-aware insights and automated task execution.

   In Business Operations, agents automate customer interactions, sales
   processes, and billing.  In Service Operations, agents manage
   provisioning, assurance, and quality supervision.  At the Resource
   level, agents optimize configurations, diagnose faults, and tune
   performance parameters dynamically.

   Based on the above architecture, we can observe that the AN Level 4
   network inherently involves multi-agent interactions during the
   autonomous closed-loop processing of tasks.  For example, the
   interactions between agents at the business layer, service layer, and
   resource layer within the architecture are integral.  Additionally,
   within the same layer, such as the resource layer, interactions occur
   across multiple domains or functions.

4.  Functional Design

   To achieve efficient interaction among agents within the AN network,
   this section discusses the fundamental functionalities required for
   AN agent interactions.

4.1.  Agent register, discovery, and capability negotiation

   As introduced in Chapter 2, these tasks involve interaction and
   cooperation among multiple agents.  This raises an important issue:
   how do upper-layer or peer-layer agents identify which agents they
   should collaborate with, determine where to find these agents, and
   understand what capabilities these potential partners can offer to
   jointly complete a task?  To address this, key capabilities such as
   agent capability description, registration and discovery, capability
   negotiation, and task-oriented agent team formation are essential.
   These functionalities facilitate efficient and effective multi-agent
   collaboration, ensuring that the involved agents can coordinate
   seamlessly to accomplish complex tasks.






Wang, et al.             Expires 8 January 2026                [Page 12]

Internet-Draft                   MAgent                        July 2025


4.2.  Task dispatch

   After completing the registration, discovery, and capability
   negotiation processes, a task typically involves activating one or
   multiple agents to carry out task allocation.  Task allocation
   generally comprises two main parts: firstly, the description of the
   task and the expected outcomes; secondly, the feedback from task
   processing.  The feedback can be categorized into two scenarios:
   synchronous feedback and asynchronous feedback.  Synchronous feedback
   refers to tasks, usually with relatively short execution processes,
   where the agent handling the task provides feedback within the same
   session.  In contrast, asynchronous feedback applies to tasks with
   longer, more complex execution processes.  In this case, the task
   assigner subscribes to the task execution agents, awaiting updates on
   task status changes, such as completion or inability to complete.
   The executing agents then push the results and status updates back to
   the task publisher accordingly.

4.3.  Multiple rounds of negotiation of the task

   After the task is published to the agents, the task publisher should
   be able to engage in multi-round negotiations with the task
   recipients.  This collaborative dialogue allows both parties to
   better understand the task requirements, clarify any uncertainties,
   and collaboratively refine the task execution plan.  Such iterative
   negotiations help ensure that the task is comprehensively understood
   and effectively carried out, ultimately leading to improved task
   success and optimal outcomes.

4.4.  Support structured and unstructured interaction of tasks

   Unlike general multi-agent interactions that may serve a wide range
   of activities in the natural world, multi-agent interactions in
   autonomous network management have several distinct characteristics.
   Firstly, these scenarios are relatively well-defined and focused,
   dedicated solely to network management and operation tasks.  For
   example, the TMF has identified twenty high-value scenarios
   specifically prioritized for AN Level 4 development.  Under
   conditions where the scenarios and tasks are clearly defined,
   structured language enables more effective and accurate interaction
   between agents.  Secondly, interactions among agents in autonomous
   network management often involve ambiguous or fuzzy tasks.  This
   includes coordinating across multiple domains and dealing with multi-
   task collaboration, as well as handling user-initiated complaints
   that are typically expressed in natural language.  In such cases,
   network agents need to understand user needs expressed in natural
   language and translate them into actionable tasks.  Therefore, multi-
   agent interactions in autonomous networks require an “interaction



Wang, et al.             Expires 8 January 2026                [Page 13]

Internet-Draft                   MAgent                        July 2025


   language” capable of balancing the ambiguity and expressiveness of
   natural language with the precision of structured languages.  This
   enables agents to communicate efficiently and accurately, ensuring
   effective execution of complex, often fuzzy, tasks.

4.5.  Task execution result negotiation

   As described above, the multi-agent interactions in AN Level 4
   networks are centered around tasks, which serve as the main framework
   for task assignment, interaction, and execution.  The outcomes of
   these tasks require bidirectional validation, where both the task
   publisher and the task executor collaborate to confirm the results.
   Specifically, the task publisher evaluates the execution results
   reported by the task executor, verifying whether the outcomes meet
   the expected objectives.  This process ensures accuracy and
   reliability in the network's management and operation.

5.  Model design

   To achieve the aforementioned functionality, this chapter designs a
   protocol-independent information model for multi-agent interactions.

5.1.  Agent profile

   Agent profile description information used in the agent registration
   and capability negotiation.  It should described the Agent’s details
   such as agent description, manufacturer, capability set, version,
   management domain, and authentication information, etc.  The
   following tree structure described the Agent profile model design
   information:





                             +--------------------------------------------+
                             |             agent                          |
                             |                                            |
                             |---------------------------------------------
                             | name:string {mandatory} {config:false}     |
                             | alias:string {config:false}                |
                             | type:string {config:false}                 |
                             | version:string {mandatory} {config:false}  |
                             | provider:string {mandatory} {config:false} |
                             | domain:string {config:false}               |
                             | management-object:string {config:false}    |
                             +--------------,,-.-----------------.--------+
                                      ,,-'``   |                 |



Wang, et al.             Expires 8 January 2026                [Page 14]

Internet-Draft                   MAgent                        July 2025


               1                ,.-'``         |1                |
                         _,.-'``               |                  \
                   _,.-'`                      |                  |
  +--------------``+                     +-----\----+             |
  |authentication  |                     |  skills  |             |
  +-----------.----+                     +-----.----+             |
              | 0...n                          | 0...n            |
              |                                |                   \
  +-----------\---------------+    +-----------\---------------+   |
  |methods                    |    |   skill                   |   |
  |----------------------------    -----------------------------   |
  |accessinfo-id:string {key} |    | skill-name:string {key}   |   |
  |scheme:string              |    | skill-description:string  |   |
  |jwtinfo:string             |    | skill-tags[]:string       |    \
  |oauth:string               |    | input-modes[]:string      |    |
  +---------------------------+    | output-modes[]:string     |    |
                                   +---------------------------+    |
                                                                    |
                                                                    | 1
                                                                     \
                                                                     |
                                                                     |
                                 +-----------------------------------\------+
                                 |   capability                             |
                                 |                                          |
                                 |-------------------------------------------
                                 |                                          |
                                 | streaming:boolean {config:false}         |
                                 | push-notifications:boolean {config:false}|
                                 | negotiate:string {config:false}          |
                                 |                                          |
                                 +------------------------------------------+

              Figure 5: UML Screenshot for agent profile

   Since this model is used to describe the objective capabilities of
   the agent, thereby supporting agent registration, discovery,
   capability negotiation, and capability querying, this module should
   be read-only.  The key node definitions and their usage are as
   follows:

   * Name: Agent name, which should remain unique within the namespace,
   is recommended to be defined as follows: {Standard
   Organization}-{Provider}-{Transmit}-{Version Number}.

   * Skills: A list to describe the Agent's business skill capabilities,
   that including skill name, skill description, supported input and
   output types, and examples.



Wang, et al.             Expires 8 January 2026                [Page 15]

Internet-Draft                   MAgent                        July 2025


   * Input-models: a list within the skills list, it is used to describe
   the input types supported by the agent, such as image, text, audio,
   or video.

   * output-models: a list within the skills list, it is used to
   describe the output types returned after the agent's execution, such
   as image, text, audio, or video.

   * Capability: The capability container is used to describe whether
   the agent supports specific interaction mechanisms.  It includes the
   following leaf nodes:

   ** streaming, which indicates support for streaming transmission.

   ** pushNotifications, which indicates support for subscription
   reporting mechanisms.

   ** negotiate, which indicates support for capability negotiation
   mechanisms.

   * authentication-methods: a list used to describe the authentication
   methods supported by the agent.  In addition to the necessary ID,
   this list includes the following parameters: 1) scheme: the
   authentication scheme, which can be JWT, OAuth 2.0, API Key, etc.; 2)
   jwtInfo: parameters required for JWT authentication; 3) OAuth:
   parameters required for OAuth 2.0 authentication.

   * In addition to the aforementioned modeling, the agent profile
   should also describe the software version of the agent, the
   manufacturer's information, and the domains it can serve, such as
   Wireless, Transmit, Core Network domains defined in the AN.  These
   details are provided and described by ‘version’ leaf, ‘provider’
   leaf, and ‘domain’ leaf.

5.2.  Task

   As described above, in the AN, interactions between agents are all
   extended through tasks.  Therefore, this chapter introduces how to
   model tasks.  Taking a generic task as an example, a task is usually
   initiated by the initiating agent, which sends an instantiated task
   to the receiving or executing agent.  The receiving or executing
   agent performs the task operations and returns the execution results
   to the initiating agent.  To facilitate efficient interaction and to
   help both agents understand the specific task, the sending agent
   typically provides basic information about the task, such as the task
   type, description, expected outcome, and terminology explanations.
   Additionally, it should include prompt-like information similar to
   natural language interactions, which enables the initiating agent and



Wang, et al.             Expires 8 January 2026                [Page 16]

Internet-Draft                   MAgent                        July 2025


   the receiving/executing agent to negotiate and discuss any issues
   that arise during the specific execution process of the task.  The
   following UML described the Agent task model design information:

                  +---------------------------------------------------+
                  |   tasks                                           |
                  -----------------------------------------------------
                  |content:string {pattern = .##task description ...} |
                  |task-async:boolean                                 |
                  |task-status:string                                 |
                  +---,.-----------.------------.---------------------+
                   ,-` 1           |            | 1
     +-----------'`-------------+  |  +---------\-----------+
     |task-subscription         |  |  |msg-header           |
     |---------------------------  |  -----------------------
     |subscript-protocol:string |  |  |task-sendfrom:string |
     |subscript-method:string   |  |1 |task-sendto:string   |
     |subscript-url:string      |  |  |commutype:string     |
     +--------------------------+  |  |task-id:string       |
                                   |  +---------------------+
                          +--------\----------------+
                          |    msg-tail             |
                          ---------------------------
                          | expected-response:sting |
                          | msg-data:id             |
                          | context:id              |
                          +-----------.-------------+
                                      |
                                      |0...n
                                      |
                           +----------\------------+
                           |  term-explains        |
                           -------------------------
                           |  term:string          |
                           |  explaintion:string   |
                           +-----------------------+



               +---------------------------+
               |context                    |
               |                           |
               |id:string {key}            |
               |sendfrom:string {mandatory}|
               |sendto:string {mandatory}  |
               +-----_.------------,-------+
                  _-`               `.
               _-` 1                  `. 1



Wang, et al.             Expires 8 January 2026                [Page 17]

Internet-Draft                   MAgent                        July 2025


     +--------`-------+        +--------'--------+
     | request-info   |        | response-info   |
     ------------------        -------------------
     |content:string  |        | dataParam:id    |
     |dataparam:id    |        | time:timestamptz|
     |time:timestamptz|        |                 |
     +----------------+        +-----------------+





           +--------------------+
           |     data-params    |
           ----------------------
           | id:string {Key}    |
           | dataType:stirng    |
           | description:string |
           | dataSize:string    |
           | format:string      |
           | url:string         |
           | data:string        |
           | chucked:boolean    |
           | finished:boolean   |
           +--------------------+



                         Figure 6: UML for AN task

   In this model, the leaf nodes task-sendFrom and task-sendTo are used
   to describe the sending agent and the receiving/executing agent
   respectively.  The commuType leaf node is used to specify the actual
   operation type of the task, such as task assignment, cancellation,
   status query, or status subscription, etc.

   "The content node within the task should be able to provide prompt-
   like information.  The current conventional approach is to use ## to
   indicate that the following content belongs to the prompt.  A typical
   example is as follows:"

                       <content namespace=\"prompt\">
                   ##target object
                   <object">xxx</object">
                   ##task description
                   <description">xxx</description">
                   ##environmental infomation
                   <environmentInput">xxx</environmentInput">



Wang, et al.             Expires 8 January 2026                [Page 18]

Internet-Draft                   MAgent                        July 2025


                         Figure 7: content example

   At the same time, this model supports a subscription mode for tasks,
   allowing users to subscribe to the status of a task and receive real-
   time updates on its execution.  This subscription mode is
   particularly effective for tasks that require long-term or continuous
   execution.

   In AN agent interactions, tasks are classified into synchronous and
   asynchronous tasks.  For synchronous tasks, the receiving agent
   returns the task status in the response to the task assignment
   interface.  For asynchronous tasks, the receiving agent pushes task
   status updates to the client whenever there are changes, providing
   real-time progress and task results.  The corresponding modes are
   indicated in task modeling using the leaf node task-async, while the
   task status is stored in task-status.

   In addition, the expected results required for task interaction are
   described using the expected-response leaf node in this model.  Term
   explanations are provided using the term-explains list.  The data
   exchanged between the initiating agent and the receiving agent is
   stored in data-param, which can include alerts, warnings, case
   knowledge, and other information.  These data types can be files,
   structured data, text, and more.

   Additionally, this model provides context retrieval capabilities by
   recording all agent communication records in list form, which can
   prevent agents from losing the original objectives or forgetting
   historical information, thereby maintaining the coherence of the
   agents' collaborative behavior.  This capability is described in the
   model using the context element.

5.3.  Task negotiation

   As described above, agents should be allowed to engage in multi-turn
   interactions and dialogues regarding the same task.  The involved
   processes may include:

   1) Before one agent assigns a task to another, the former requests
   the latter to conduct a feasibility check to determine whether the
   task can be accomplished.  If not, both agents negotiate to arrive at
   a feasible alternative task.









Wang, et al.             Expires 8 January 2026                [Page 19]

Internet-Draft                   MAgent                        July 2025


   2) When one agent assigns a task to another, the former requires the
   latter to actively initiate negotiation during the execution process.
   The latter summarizes and generates outputs (such as proposed
   decisions) and requests the former to evaluate and negotiate.  If the
   outcomes do not meet the requirements, the two agents continue
   negotiating to produce a result that satisfies the conditions.

   In the model defined in this draft, multi-turn interactions for tasks
   are described using RPC, and its hierarchical structure is depicted
   as follows:

                  +----------------+
                  . task-negotiate -,
             1 ,-`+----------------+ `'., 1
     +--------`--------------+      +----`------+
     |  input                |      |   output  |
     -------------------------      -------------
     |  task-sendfrom string |      |   data    |
     |  task-sendto   string |      |           |
     |  type          string |      +-----------+
     |  task-id       string |
     |  type          string |
     +------.----------------+
            |
            |0...n
     +------\------+
     |  content    |
     +-------------+


                     Figure 8: UML for task negotation

5.4.  Task notification

   As described above, agent interactions should support a task status
   notification mechanism, where the receiving agent pushes TaskStatus
   updates to the sending agent, providing real-time progress, task
   status, and execution results.  The triggering conditions for such
   notifications can include any change in the task’s state, such as
   transitioning from create to processing, from processing to blocking,
   or from processing to failed.  These events proactively trigger the
   task status notification interface.  The hierarchical structure of
   the task notification module defined in this paper is illustrated in
   the diagram below.







Wang, et al.             Expires 8 January 2026                [Page 20]

Internet-Draft                   MAgent                        July 2025


       +--------------------------+
       | condition-notifications  |
       |---------------------------
       |                          |
       | task-sendFrom     string |
       | task-sendTo       string |
       | commuType         string |
       | task-id           string |
       |                          |
       +------------.-------------+
                    |0...n
                    |
       +------------\-------------+
       |       input-required     |
       ----------------------------
       |                          |
       | task-async    boolean    |
       | status        string     |
       | start-time    timestamptz|
       | required      string     |
       |                          |
       +--------------------------+


                    Figure 9: UML for task notification

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   This document should not affect the security of the Internet.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References



Wang, et al.             Expires 8 January 2026                [Page 21]

Internet-Draft                   MAgent                        July 2025


   [IG1251C]  TM Forum, "IG1251 Autonomous Networks – Reference
              Architecture v1.0.0", 2025,
              <https://www.tmforum.org/resources/introductory-guide/
              ig1251-autonomous-networks-reference-architecture-
              v1-0-0/>.

   [IG1501]   TM Forum, "IG1501 AN L4 Fault Management Solution Package
              v1.0.0", 2025,
              <https://www.tmforum.org/resources/guidebook/ig1501-an-l4-
              fault-management-solution-package-v1-0-0/>.

Appendix A.  appendix: YANG DATA Model

   This section models the agent discussed in this document following
   the YANG data modeling approach adopted by the IETF.  The provided
   code is for reference only.

   <CODE BEGINS> file "irtf-agent@2025-07-01.yang"

module irtf-agent {
  namespace "urn:ietf:params:xml:ns:yang:irtf-agent";
  prefix agtask;

  import agent-message {
    prefix agtmsg;
  }



  organization "Example Organization";
  contact "support@example.com";
  description "header YANG Model";

  revision 2025-06-01 {
    description
      "Initial revision";
    reference
      "RFC 6241: Network Configuration Protocol";
  }


  typedef timestamptz {
    type string {
      pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
            + '(Z|[\+\-]\d{2}:\d{2})';
    }
  }




Wang, et al.             Expires 8 January 2026                [Page 22]

Internet-Draft                   MAgent                        July 2025


  typedef uuid {
    type string {
      pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
            + '(Z|[\+\-]\d{2}:\d{2})';
    }
  }

  typedef task-status {
        type enumeration {
           enum finished {
                 description
                   "The task is executed.";
           }
           enum blocked {
                 description
                   "The task is blocked.";
           }
         }
  }

  typedef datatype-enum {
        type enumeration {
           enum text {
                 description
                   "The request requires a resource that already is in use.";
           }
           enum image {
                 description
                   "The request requires a resource that already is in use.";
           }
           enum audio {
                 description
                   "The request requires a resource that already is in use.";
           }
           enum video {
                 description
                   "The request requires a resource that already is in use.";
           }
         }
  }

  container agent {
    config false;
    description "Agent configuration";

    leaf name {
      type string;
          config false;



Wang, et al.             Expires 8 January 2026                [Page 23]

Internet-Draft                   MAgent                        July 2025


      description "Agent name";
      mandatory true;
    }

    leaf alias {
      type string;
          config false;
      description "Agent alias";
    }

    leaf description {
      type string;
          config false;
      description "Agent description";
      mandatory true;
    }

    leaf type {
      type string;
          config false;
      description "Agent type";
    }
    container skills {
      description "abilities";
          config false;

      list skill {
            key "skill-name";
        leaf skill-name {
          type string;
          description "agent skill name";
        }
        leaf skill-description {
          type string;
          description "agent skill description";
        }
                leaf-list skill-tags {
          type string;
          description "agent skill tags";
        }
                leaf-list input-modes {
          type string;
          description "agent skill input-mode: image, text, audio, video";
        }
                leaf-list output-modes {
          type string;
          description "agent skill output-mode: image, text, audio, video";
        }



Wang, et al.             Expires 8 January 2026                [Page 24]

Internet-Draft                   MAgent                        July 2025


      }
    }

    leaf version {
      type string;
          config false;
      description "Agent version, comply sematics version 2.0";
      mandatory true;
    }

    leaf provider {
      type string;
          config false;
      description "vendor";
      mandatory true;
    }

    leaf domain {
      type string;
          config false;
      description "supported domain, such as: Wireless, Optical, IP, Core Network";
    }

    container capability {
      description "agent support capabilities";
          leaf streaming {
            type boolean;
                config false;
            description "if support streaming";
          }
          leaf push-notifications {
            type boolean;
                config false;
            description "if support streaming notification";
          }
          leaf negotiate {
            type string;
                config false;
            description "supported negotiate type, such as: acp-task-feasibility-negotiation-v1.0,
acp-task-fulfillment-negotiation-v1.0";
          }
    }

    leaf management-object {
      type string;
          config false;
      description "Agent management domain, such as:xx subnet";
    }



Wang, et al.             Expires 8 January 2026                [Page 25]

Internet-Draft                   MAgent                        July 2025


    /*leaf location {
      type string;
      description "Agent belongs to";
    }*/

    /*leaf-list llms {
      type string;
      description "LLMs Agent used";
    }*/

    container authentication {
      description "Agent authentication information";

      list authentication-methods {
            key "accessinfo-id";
        leaf accessinfo-id {
          type string;
          description "unique accessinfo id";
        }

                leaf scheme {
                  type string;
                  description "scheme authentification method";
                }
                leaf jwtInfo {
                  type string;
                  description "jwt authentification method";
                }
                leaf oauth {
                  type string;
                  description "scheme authentification method";
                }
      }
    }
  }

  list context {
    description "context configuration";
        key "id";
        leaf id {
           type string;
        }

    leaf sendFrom {
      type string;
      description "Agent name of sender";
      mandatory true;
    }



Wang, et al.             Expires 8 January 2026                [Page 26]

Internet-Draft                   MAgent                        July 2025


    leaf sendTo {
      type string;
      description "Agent name of receiver";
      mandatory true;
    }
    container request-info {
                description "request-info configuration";
                leaf content {
                  type string;
                  description "request message";
                  mandatory true;
                }

                leaf dataParam {
                  type leafref {
                        path "/data-params/id";
                  }
                  description "data information";
                }

                leaf time {
                  type timestamptz;
                  description "UTC time: e.g., 2025-04-21 14:19:00+0";
                  mandatory true;
                }
        }
    container response-info {
          description "response-info configuration";

          leaf dataParam {
            type leafref {
                        path "/data-params/id";
                  }
            description "data information";
            mandatory true;
          }

          leaf time {
            type timestamptz;
            description "UTC time: e.g., 2025-04-21 14:19:00+0";
            mandatory true;
          }
    }

  }

   container msg-base {
    uses msg-header;



Wang, et al.             Expires 8 January 2026                [Page 27]

Internet-Draft                   MAgent                        July 2025


        leaf content {
                type string;
        }
        uses msg-tail;
  }

  grouping msg-header {
    description "header configuration";

        leaf task-sendFrom {
          type string;
          description "the agent which send this task";
        }
        leaf task-sendTo {
          type string;
          description "the agent which recieve this task";
        }
        leaf commuType {
      type string;
      description "communication type, which related to task type
                CapabilityRequest: request capabilities of Agent
                taskAssgin: assign task by Agent consumer
                taskCancel: cancel task by Agent consumer
                FeasibilityNegotiate/FulfillmentNegotiate: Negotiate task
                taskResultQuery: query task result
                taskResultSubscribe: subscribe task result
                taskResultNotify:notify task result";
    }

    leaf task-id {
      type string;
      description "The task id.";
    }
   }

   grouping msg-tail {
    leaf expected-response {
          description "";
          type string;
        }
        list term-explains {
            key "term";
            leaf term {
                    type string;
                }
                leaf explaination {
                    type string;
                }



Wang, et al.             Expires 8 January 2026                [Page 28]

Internet-Draft                   MAgent                        July 2025


        }
        leaf msg-data {
      type leafref {
             path "/data-params/id";
          }
      description "msg convey data.";
    }
    leaf context {
                description "history information";
                type leafref {
                 path "/context/id";
          }
        }
  }

  list data-params {
    description "DataParams configuration";
        key "id";

        leaf id {
          type string;
        }
    leaf dataType {
      type datatype-enum;
      description "datatype??optional value: text, image, audio, video";
      mandatory true;
    }

    leaf description {
      type string;
      description "data description";
    }

    leaf dataSize {
      type string;
      description "data size";
    }

    leaf format {
      type string;
      description "data format
                dataType = text, value:text/plain, application/json, etc.
                dataType = image, value:jpg, png, etc.
                dataType = audio, value: mp3, WAV, etc.
                dataType = video, value:mp4,avi, etc.";
    }

    leaf url {



Wang, et al.             Expires 8 January 2026                [Page 29]

Internet-Draft                   MAgent                        July 2025


      type string;
      description "resource url, for large data";
    }

    leaf data {
      type string;
      description "data content";
    }

    leaf chunked {
      type boolean;
      description "if data is too large, it can be chunked to several pieces";
    }

    leaf finished {
      type boolean;
      description "last piece of chunked data: true";
    }
  }

  container tasks {

          uses agtmsg:msg-header;
          leaf content {
                description
                  "You are a task executor. please execute the task based on the target object, task description, and environmental information. For example.";
                type string {
                    pattern '.*##task description\s*\S+.*';
                  }
                }
          container task-subscription {
                description "";
                leaf subscript-protocol {
                        type string;
                        }
                leaf subscript-method {
                        type string;
                        }
                leaf subscript-url {
                        type string;
                        }
                }
          leaf task-async {
                  type boolean;
                  description "";
          }

          leaf task-status {



Wang, et al.             Expires 8 January 2026                [Page 30]

Internet-Draft                   MAgent                        July 2025


                  type string;
          }
          uses agtmsg:msg-tail;
        }

  rpc task-negotiate {
    description
      "The task-negotiate ....";

    reference "RFC xxxx, Section 7.2";

    input {
          uses agtmsg:msg-header;
      leaf-list content {
        description "You are a task executor. please execute the task based on the target object, task description, and environmental information. For example,
                // <anydata>
                <content namespace=\"prompt\">
                ##target object
                <object>xxx</object>
                ##task description
                <description>xxx</description>
                ##environmental infomation
                <environmentInput>xxx</environmentInput>";
        type string {
           pattern '.*## target object\s*\S+.*';
           pattern '.*## task description\s*\S+.*';
                }
      }

          leaf type {
                type enumeration {
          enum FEASIBILITY {
            value 1;
            description
              "check if task is feasibility.";
          }
          enum FULFILLMENT {
            value 2;
            description
              "check if task can be fulfillment.";
          }
                }
          }
        }
    output {
      anyxml data {
        description
          "Copy of the source datastore subset that matched



Wang, et al.             Expires 8 January 2026                [Page 31]

Internet-Draft                   MAgent                        July 2025


           the filter criteria (if any).  An empty data container
           indicates that the request did not produce any results.";
      }
    }
  }
   notification condition-notifications {
    description
      "When the tesk condition is met, this notification is sent.";

    uses msg-header;

    list input-required {
          key "required";

          leaf task-async {
                  type boolean;
                  description "";
          }
          leaf status {
                  type string;
                  description
                        "Indicate the status of the task, such as suspended, finished, etc.";
          }
          leaf start-time {
            type timestamptz;
            description "UTC time: e.g., 2025-04-21 14:19:00+0";
            mandatory true;
          }
          leaf required
          {
        type string {
           pattern '.*## target object\s*\S+.*';
           pattern '.*## task description\s*\S+.*';
                   }
                 }
          }
   }
   anyxml data {
    description
    "provide another information.";
    }

}



                              Figure 10




Wang, et al.             Expires 8 January 2026                [Page 32]

Internet-Draft                   MAgent                        July 2025


   <CODE ENDS>

Acknowledgements

   The authors of this document would like to thank Yijun Yu, Fei Guo,
   Jinjin Chen, and others for their substantive review and comments,
   and proposals to stabilize and improve the document.

Contributors

   The authors would like to thank Yijun Yu, Fei Guo, Jinjin Chen for
   their major contributions to the initial modeling and use cases.

Authors' Addresses

   Michael Wang
   Huawei Technologies, Co., Ltd
   101 Software Avenue, Yuhua District
   Nanjing
   210012
   China
   Email: wangzitao@huawei.com


   Yuan Xie
   Huawei Technologies, Co., Ltd
   101 Software Avenue, Yuhua District
   Nanjing
   210012
   China
   Email: yuan.xie@huawei.com


   Qin Wu
   Huawei Technologies, Co., Ltd
   101 Software Avenue, Yuhua District
   Nanjing
   210012
   China
   Email: bill.wu@huawei.com











Wang, et al.             Expires 8 January 2026                [Page 33]

categories:
["Agent-to-agent communication protocols", "Autonomous network operations", "Agent discovery / registration"]


name: draft-yu-ai-agent-use-cases-in-6g
rev: 02
title: AI Agent Use Cases and Requirements in 6G Network
time: 2026-01-05T07:59:02Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-09T07:59:02Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420378+00:00
abstract:
This draft introduces use cases related to AI Agents in 6G networks,
   primarily referencing the technical report of 3GPP SA1 R20 Study on
   6G Use Cases and Service Requirements (TR 22.870).  It also
   elaborates on some of the requirements for introducing AI Agents into
   6G networks from the perspective of operators.

full_text:
Network Working Group                                              M. Yu
Internet-Draft                                                   A. Wang
Intended status: Informational                                     J. Li
Expires: 9 July 2026                                               Z. Li
                                                           China Telecom
                                                          5 January 2026


           AI Agent Use Cases and Requirements in 6G Network
                  draft-yu-ai-agent-use-cases-in-6g-02

Abstract

   This draft introduces use cases related to AI Agents in 6G networks,
   primarily referencing the technical report of 3GPP SA1 R20 Study on
   6G Use Cases and Service Requirements (TR 22.870).  It also
   elaborates on some of the requirements for introducing AI Agents into
   6G networks from the perspective of operators.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Yu, et al.                 Expires 9 July 2026                  [Page 1]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Intent-based 6G Services Enabled by Network AI Agents . .   4
       2.1.1.  Use Case On 6G Network Providing On-demand Networking
               with AI Agent . . . . . . . . . . . . . . . . . . . .   4
       2.1.2.  Use Case On Intelligent Calling Services  . . . . . .   5
       2.1.3.  Use Case On Disaster Rescue Planning Enabled By Network
               AI Agents . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.4.  Use Case On AI Agent For Network Performance
               Assurance . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.5.  Use Case On Customized Service Provisioning Based On AI
               Agents  . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.6.  Use Case On Network-based Intelligent Assistance (e.g.
               for autonomous driving) By a Network-native AI Agent    6
       2.1.7.  Use Case On AI-optimized Smart Call Assistance For
               Telecom Networks  . . . . . . . . . . . . . . . . . .   7
     2.2.  Device-Network Collaboration  . . . . . . . . . . . . . .   7
       2.2.1.  Use Case On 6G System Assisted AI Agent Service . . .   7
       2.2.2.  Use Case On Smart Housekeeping  . . . . . . . . . . .   8
       2.2.3.  Use Case On Child Health Management Assistant . . . .   8
       2.2.4.  Use Case On Flexible UE-Network Coordination Through AI
               Agent(s)  . . . . . . . . . . . . . . . . . . . . . .   8
       2.2.5.  Use Case On Proactive AI Agent For Personal Safety  .   9
       2.2.6.  Use Case On Shared Embodied AI Agents . . . . . . . .   9
     2.3.  Multiple Devices Collaboration  . . . . . . . . . . . . .   9
       2.3.1.  Use Case On Collaborative AI Agents . . . . . . . . .  10
       2.3.2.  Use Case On AI Agents Communication . . . . . . . . .  10
       2.3.3.  Use Case On Authentication And Authorization For AI
               Agents  . . . . . . . . . . . . . . . . . . . . . . .  10
       2.3.4.  Use Case On Smart Support For Data Collection And
               Fusion In Multi-agent Scenarios . . . . . . . . . . .  11
     2.4.  Network-Application Collaboration . . . . . . . . . . . .  11
       2.4.1.  Use Case On Intelligent Communication Assistant . . .  11
       2.4.2.  Use Case On 6G AI Agents Collaboration With Third-party
               AI Using LLM  . . . . . . . . . . . . . . . . . . . .  11
       2.4.3.  Use Case On Network Knowledge As Part of Retrieval
               Augmented Generation For Generative AI  . . . . . . .  12



Yu, et al.                 Expires 9 July 2026                  [Page 2]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


       2.4.4.  Use Case On AI Agent Management . . . . . . . . . . .  12
   3.  Potential Requirements for 6G Network . . . . . . . . . . . .  12
     3.1.  The Identity of AI Agents . . . . . . . . . . . . . . . .  13
     3.2.  Efficient Collaboration . . . . . . . . . . . . . . . . .  13
     3.3.  Cross-Domain Collaboration  . . . . . . . . . . . . . . .  13
     3.4.  Registration and Discovery  . . . . . . . . . . . . . . .  13
     3.5.  Service and Data Exposure . . . . . . . . . . . . . . . .  13
     3.6.  Reliability Assurance . . . . . . . . . . . . . . . . . .  14
     3.7.  High-performance Communication  . . . . . . . . . . . . .  14
     3.8.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  14
     3.9.  Energy Efficiency . . . . . . . . . . . . . . . . . . . .  14
   4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   5.  Informative References  . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Currently, with breakthroughs in large language models and multimodal
   technologies, AI Agent has emerged as a major research focus in the
   industry.  Equipped with capabilities such as intent understanding,
   action planning, decision-making, task execution, and self-awareness,
   AI Agents can integrate environmental perception, memory, tool
   invocation, and multi-agent collaboration to accomplish complex
   tasks.  They have already demonstrated significant value in key
   fields like autonomous driving, intelligent customer service, and
   smart home systems.  In the 6G era, the introduction of AI Agent
   technology will enable operators to fully leverage the potential of
   mobile communication networks, significantly improving network
   operational efficiency and user experience.  As a result, AI Agents
   are expected to become a key research focus in future 6G networks,
   leading to deep integration between 6G and AI Agent technologies.

   In the 3GPP R20 standardization research for 6G, AI Agent has been
   one of the most discussed and debated topics, whether in SA1's study
   on 6G scenarios and requirements or SA2's research on network
   architecture.  In the SA1#109 meeting, 19 contributions related to AI
   Agents were submitted, which include 16 new use cases, with 4 use
   cases ultimately agreed.  And a preliminary definition of AI Agent
   from a capability perspective was adopted: "an automated intelligent
   entity capable of e.g interacting with its environment, acquiring
   contextual information, reasoning, self-learning, decision-making,
   executing tasks (autonomously or in collaboration with other Al
   Agents) to achieve a specific goal."  In the SA1#110 meeting, more
   than 30 contributions related to AI Agents were submitted, which
   include 22 new use cases, with 7 ultimately agreed.






Yu, et al.                 Expires 9 July 2026                  [Page 3]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


   This draft summarizes and categorizes the AI Agent-related use cases
   in 6G networks, with a brief introduction provided in Section 2.  In
   Section 3, from an operator's perspective, we elaborate on the
   potential requirements for introducing AI Agents into 6G networks,
   which should be considered when designing the agent communication
   related protocol in mobile communication network.  In Section 4, we
   conclude this draft.

2.  Use Cases

   AI Agents can be deployed at various locations within the 6G system.
   Depending on their deployment positions, AI Agents in 6G can be
   classified into On-device AI Agents (deployed on user devices),
   application AI Agents, network AI Agents (deployed within the future
   6G network), operation management AI Agents, etc.  For instance,
   terminal AI Agents refer to those implemented on end-user devices,
   while network AI Agents are those embedded within the 6G network.

   This section summarizes and categorizes AI Agent-related use cases in
   6G networks.  Unlike AI Agents in the internet domain, use cases
   involving AI Agents in mobile communication networks place greater
   emphasis on how network AI Agents can deliver 6G services to users,
   as well as how different AI Agents within the 6G system coordinate
   with each other.

2.1.  Intent-based 6G Services Enabled by Network AI Agents

   By deploying AI Agents within 6G network, the 6G network can provide
   users with intent-based services.  These intelligent services may
   represent combinations of multiple network capabilities, such as
   communication services, sensing services, AI/ML services, computing
   services, and more.  Users only need to express their intent to the
   6G network, without requiring specialized technical knowledge to
   decompose the intent into technical requirements.  In this context,
   3GPP SA1 has formally defined network intent as: Expectations
   including requirements, goals and constraints without specifying how
   to achieve them.

2.1.1.  Use Case On 6G Network Providing On-demand Networking with AI
        Agent

   User Harry owns a smart robot named Ron and has a lovely pet dog
   called Bob. Bob needs to be walked twice daily.  While away on a
   business trip, Harry sends his request through an operator portal
   (which could be an app, a mobile webpage, etc.) to the 6G network's
   AI Agent, expressing his intention for robot Ron to ensure Bob's
   safety during walks.  The network AI Agent processes this request,
   determines that the task requires perception services and QoS-



Yu, et al.                 Expires 9 July 2026                  [Page 4]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


   guaranteed services, and then distributes these services to the
   relevant network entities.

2.1.2.  Use Case On Intelligent Calling Services

   The network delivers AI Agents enabled intelligent calling services
   that revolutionize traditional voice communications.  By integrating
   recognition and perception capabilities of AI Agents, it offers two
   key functionalities: 24/7 Intelligent Answering (handling calls
   during unreachability, e.g., flight/power-off modes with contextual
   responses) and Intelligent Answering Machine (managing calls during
   user unavailability, e.g., meetings, with call logging).  These
   services operate under strict user authorization, allowing
   customization of voice tones, trigger conditions (e.g., flight mode
   activation), and data permissions (call records/summaries).  For
   instance, when a subscriber enables the service, the network
   autonomously answers calls based on predefined preferences and
   provides post-call analytics.

2.1.3.  Use Case On Disaster Rescue Planning Enabled By Network AI
        Agents

   When a disaster strikes, unpredictable challenges such as collapsed
   buildings, deformed roads, and communication outages make the rescue
   extremely complex.  By leveraging 6G network AI Agents for rescue
   planning, the rescue efficiency can be significantly improved,
   maximizing the protection of victims‘ lives and personal property.
   In this case, the intent may be “execute the rescue mission with
   multiple rescue robots in a certain area”. Upon receiving the intent,
   the network AI agents initiate the rescue planning and decompose the
   rescue into multiple operations and other standardized 3GPP service.
   This may specifically include: road obstacle sensing (sensing
   service), multi-robot rescue route planning (AI inference service),
   training obstacle avoidance models (AI training service), real-time
   optimal route computation for rescue robots (computing service) and
   communication resource allocation for disaster zones (communication
   service).

2.1.4.  Use Case On AI Agent For Network Performance Assurance

   AI agents are artificial entities that can perceive environments,
   make decisions, and act.  The AI Agents have evolved to LLM-based
   versions, leveraging LLMs’ strengths in knowledge acquisition,
   reasoning, and planning to decompose complex tasks into collaborative
   sub-tasks via perception, intent understanding, and plan reflection
   (with feedback and human interaction for robustness).  In 6G network,
   multi-agent systems address strict network demands of big events
   (e.g., national games with millions of participants over 15 days),



Yu, et al.                 Expires 9 July 2026                  [Page 5]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


   where Operator A deploys AI agents for performance assurance.  The
   workflow involves organizers submitting intent-based requirements
   (e.g., bandwidth, VIP service), AI agents decomposing tasks into
   network configuration, resource allocation, and real-time monitoring,
   service agents creating and refining action plans through reflection,
   and action agents executing via tools.  During the event, agents
   collaborate to ensure VIP QoE, monitor KPIs, and auto-adjust networks
   upon warnings.  This multi-agent collaboration fulfills 6G’s big-
   event needs while reducing labor, surpassing 5G’s limitations in
   real-time dynamic planning, frequent KPI collection, and plan
   reflection.

2.1.5.  Use Case On Customized Service Provisioning Based On AI Agents

   With telecom industries prioritizing personalized services, AI agents
   integrate with 6G network to boost efficiency and innovation.  This
   use case involves Bob (a 6G user), who needs high-quality 6G network
   support for a 2 pm online meeting during his tomorrow’s Beijing-
   Chengdu train trip (departing 9 am).  Assume that Operator A’s 6G-
   deployed AI agent enabling intent-based services, user-agent
   interaction, and third-party resource access via tool invocations.
   Bob sends his intent; the AI agent validates the intent, and fetches
   third-party data (e.g., train schedules) if needed, identifies
   possible routes and covering base stations, predicts meeting QoE, and
   pushes fee-included assurance packages.  After Bob’s selection, the
   agent pre-configures the network, ensuring his optimal meeting
   experience during the journey.

2.1.6.  Use Case On Network-based Intelligent Assistance (e.g. for
        autonomous driving) By a Network-native AI Agent

   The rapidly growing market for AI-driven traffic navigation/
   assistance (e.g., ADAS, autonomous vehicles) presents significant
   opportunities for 3GPP operators. 3GPP networks offer unique
   advantages: access to exclusive wide-area environmental/network data,
   distributed AI capabilities, low latency via edge computing, and the
   integration of communication-AI-sensing.  They provide three service
   categories: Category 1 (local inferencing with vehicle/network data,
   low cost), Category 2 (added network sensing, moderate cost), and
   Category 3 (external data integration, comprehensive assistance).
   Core components include the AI Toolbox (pre-trained models/
   algorithms), network-based intelligent assistant (AI Agent
   interpreting intents and orchestrating services), and UE-side
   Intelligent Assistance Application Entity.  The service flow involves
   UE registration, subscriber intent submission (e.g., safe
   navigation), AI Agent recommending customized services, subscriber
   selection, and real-time network service activation/monitoring to
   fulfill the intent (e.g., safe travel to destination).



Yu, et al.                 Expires 9 July 2026                  [Page 6]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


2.1.7.  Use Case On AI-optimized Smart Call Assistance For Telecom
        Networks

   A telecom operator integrates an AI-powered smart call assistance
   service into 6G network, leveraging in-network AI Agents to
   dynamically optimize voice/video call quality based on real-time
   network conditions, user intent, and historical data.  Assume that
   the network AI capabilities (e.g., AI Agents), UE (smartphones/VoIP
   devices) with AI for real-time call condition/QoE monitoring,
   privacy-compliant user data sharing, and pre-trained AI models are
   deployed.  The service flow starts with a user initiating a call; the
   UE’s AI monitors metrics like jitter and packet loss, requesting
   network adjustments if quality degrades.  The 6G AI Agent generates
   optimizations (e.g., codec adjustments, bandwidth allocation) and
   validates effects (e.g., via digital twin).  The UE provides QoE
   feedback, and the AI Agent continuously analyzes aggregated data,
   updating models if persistent issues (affecting single/multiple
   users) arise.

2.2.  Device-Network Collaboration

   With the rapid advancement of technologies like smartphones and
   lightweight large-scale AI models, capabilities of user devices have
   significantly expanded, enabling autonomous execution of certain AI
   tasks and independent decision-making.  However, due to inherent
   device limitations - including constrained computational resources
   and battery capacity - deploying complex AI agents or performing
   sophisticated AI tasks locally on devices remains challenging.
   Consequently, investigating optimal collaboration mechanisms between
   UE-based AI agents and network-based AI agents to accomplish complex
   tasks represents a critical research direction for 6G networks.

2.2.1.  Use Case On 6G System Assisted AI Agent Service

   AI-powered devices can interact with their environment—collecting
   data, making autonomous decisions, and executing actions.  The 6G
   system will enhance AI agents by providing supplementary
   environmental data (e.g., real-time sensing for traffic awareness)
   and dynamic QoS updates for adaptive decision-making.Additionally, 6G
   must support secure AI agent authentication and inter-agent
   communication, as traditional identifiers like SUPI/IMSI may not
   suffice for dynamic AI functionalities.  The rise of AI agents will
   also increase "horizontal traffic" between devices, enabling
   collaboration within agent groups and with third-party applications.







Yu, et al.                 Expires 9 July 2026                  [Page 7]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


2.2.2.  Use Case On Smart Housekeeping

   6G system could help to keep the family daily care and security,
   requiring advanced automation and management capabilities to maintain
   a comfortable and efficient living space.  There will be more AI
   related applications and intelligent devices (e.g. robots, UAVs,
   autonomous vehicles) in the 6G era.  Users will be able to express
   their requirements through natural language to convey their needs.
   In certain scenarios, multiple devices will need to collaborate to
   complete complex tasks.  The 6G system can dynamically coordinate
   devices based on user's supply and demand requirements.

2.2.3.  Use Case On Child Health Management Assistant

   Lily's smartwatch AI agent continuously tracks her vital signs (heart
   rate, body temperature) during school hours.  When detecting abnormal
   readings (elevated heart rate and temperature), the system
   automatically escalates monitoring frequency and initiates an
   emergency protocol by: (1) verifying authorization through the
   network, (2) selecting the optimal emergency contact (mother Emma,
   based on real-time proximity and availability data), and (3)
   coordinating with Emma's AI agent by sharing Lily's health metrics,
   location data, and environmental conditions.  The network facilitates
   this process by providing positioning services, environmental sensing
   data, and secure data transmission between authorized AI agents.
   Emma's AI agent then calculates the fastest route to Lily's location
   while receiving continuous health updates, enabling prompt medical
   intervention.  This scenario showcases the seamless integration of
   UE-based and network-based AI capabilities, including cross-domain
   data analysis, dynamic service invocation, and privacy-preserving
   emergency response mechanisms, ultimately delivering timely
   healthcare intervention while maintaining strict data security
   protocols.

2.2.4.  Use Case On Flexible UE-Network Coordination Through AI Agent(s)

   6G aims to support diverse terminals (cars, AR glasses, etc.) with
   advanced services beyond connectivity, but current service
   interaction faces fragmentation and reliance on user pre-knowledge of
   available services.  To address this, Operator O deploys AI agents in
   its 6G network for generic UE-network coordination.  When user A
   drives into city X, the service access AI Agent proactively
   recommends a regional sensing service to enhance driving safety,
   which A accepts—receiving beyond-line-of-sight sensing data.  After
   checking into a hotel, A’s connected AR glasses are notified of a
   regional computing service; with A’s permission, the AI agent
   coordinates application offloading/acceleration.  The AI agent
   dynamically adjusts: warning of potential downgrades in poor network



Yu, et al.                 Expires 9 July 2026                  [Page 8]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


   areas (advising local app execution) and providing communication
   quality maps/path recommendations in crowded spots, plus optional VIP
   QoS prioritization.

2.2.5.  Use Case On Proactive AI Agent For Personal Safety

   This use case presents a network-hosted personal safety AI agent in
   6G network, dedicated to proactively safeguarding users by
   integrating real-time data (location, wearable biometrics like heart
   rate/accelerometer, calendar) and environmental data (e.g., area
   crime statistics) to build user risk profiles.  Assume that Alex has
   subscribed to the service, granting explicit data access consent,
   configuring safety policies (emergency contacts, distress triggers),
   and 6G ensuring secure, low-latency agent hosting.  When Alex walks
   through an unfamiliar, high-crime area after dark, the agent monitors
   his data, detects a sudden spike in heart rate and sprinting, and
   activates a high-alert state.  It sends Alex a safety confirmation
   prompt and alerts his emergency contact Chloe.  Unresponsive after 30
   seconds, the agent auto-contacts emergency services with Alex’s real-
   time location and context.

2.2.6.  Use Case On Shared Embodied AI Agents

   A future shared embodied AI agent model will emerge, with entities
   like humanoid robots, robot dogs, and Automated Guided Vehicles
   (AGVs) deployed across cities for rental.  This boosts their
   utilization and makes AI tech more accessible, requiring 6G’s high-
   speed, low-latency network for real-time status reporting, location
   sharing, and interactions.  Assume that ShareRobot deploys such
   agents (with IDs, communication modules) registered to Operator A.
   Bob’s (AGV) Sam (registered to Operator B) can’t carry a mattress, so
   he rents a ShareRobot shared AGV via QR code—logging in, authorizing
   access to Sam, and binding them.  The two AGVs connect, share
   attributes, and collaborate to move the mattress.  Finally, Bob
   successfully transports the mattress, returns the shared AGV, pays
   for usage; ShareRobot pays Operator B for data traffic and related
   services.

2.3.  Multiple Devices Collaboration

   Under the powerful communication capabilities of 6G network, multiple
   on-device AI Agents can collaborate with each other to accomplish
   complex AI tasks.  These AI Agents may from either the same
   application or different applications.







Yu, et al.                 Expires 9 July 2026                  [Page 9]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


2.3.1.  Use Case On Collaborative AI Agents

   John and Ann's electric vehicle (EV) uses an AI Agent to optimize
   charging based on dynamic energy prices and travel plans.  While John
   sleeps during a business trip, his EV's AI Agent detects high
   electricity prices at the hotel location and considers selling
   battery power back to the grid.  To verify feasibility, it securely
   accesses both John and Ann's calendar AI Agents (hosted by different
   providers) without waking them.  Learning of John's planned 900km
   return trip, the AI Agent cancels the energy sale.  All cross-border
   data exchanges maintain strict privacy, blocking unauthorized access
   (e.g., from friends' AI Agents).  This demonstrates how standardized
   AI Agent interoperability enables intelligent, user-authorized
   decisions across distributed systems.

2.3.2.  Use Case On AI Agents Communication

   A group could be established for users and their AI agents to
   communicate with each other.  To complete a complex task involving
   multiple users and triggered by a user, AI agent or application,
   communication domain for multiple groups could be established,
   Communication domain could be dynamically created for users and AI
   agents from multiple groups to communicate with each other for a
   specific task during a specific time.  Only the AI agents in the same
   domain can communicate with each other.  If authenticated /
   authorized, users and AI agents could join this group via various
   access technologies, including the cellular network, WiFi and
   Ethernet, etc.

2.3.3.  Use Case On Authentication And Authorization For AI Agents

   The security risks (malicious intent, intent misinterpretation) of AI
   Agents are critical.  Thus, authentication (verifying AI agent/user
   identity) and authorization (limiting access to subscribed services)
   are essential, with distinct policies for UEs and on-device AI
   agents.  A case in point: an invite-only AR exhibition, where
   authorized AI agents in smart glasses enable personalized AR content
   via the operator’s ultra-low-latency, high-bandwidth network.  Alice
   and Bob (invited, registered) and Cindy (impersonating Dale via his
   glasses) launched the AR app.  The network authenticated all AI
   agents but failed Cindy’s user authentication; only Alice and Bob got
   approved, accessing dedicated data paths for real-time AR rendering.
   Cindy was rejected, and the network mitigated threats through dual
   authentication/authorization.







Yu, et al.                 Expires 9 July 2026                 [Page 10]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


2.3.4.  Use Case On Smart Support For Data Collection And Fusion In
        Multi-agent Scenarios

   This use case describes a smart collaboration scenario where several
   robots (UEs) with data collection and processing capabilities and
   direct/indirect network access collaboratively build an information
   set via data/sensor fusion.  Emphasizing energy, resource efficiency,
   and situation-aware communication, the robots generate diverse,
   dynamically changing AI traffic with varying QoS requirements.  They
   share real-time traffic demands with the 6G network and a fusion
   center; an AS (trusted third party) centrally coordinates, e.g.,
   instructing pre-processing or task splitting.  The 6G network adapts
   to dynamic traffic changes (e.g., robot/object distance) to ensure
   reliable communication.

2.4.  Network-Application Collaboration

   The 6G network AI Agents and application AI Agents can fully
   collaborate to accomplish network tasks.  On one hand, AI agents
   within the 6G network can invoke appropriate application AI Agents
   based on service characteristics.  On the other hand, the network AI
   Agents can share network data and domain expertise with application
   AI Agents, providing crucial data support for application AI Agents.

2.4.1.  Use Case On Intelligent Communication Assistant

   Currently, most of the personal AI assistants are provided on the
   devices (e.g. smart phones).  However, the limitation of the power
   and thermal factors are the bottlenecks of the AI assistant
   development on devices.  Operators are highly possible to provide the
   Intelligent Communication Assistant services leveraging 6G network AI
   Agents.  For example, Alice is a business traveler, and her personal
   assistant in 6G network automatically monitors flight status, books a
   taxi upon landing by interfacing with the taxi company's registered
   AI service, and guides her to the vehicle using real-time location
   data - all without taxing her smartphone's resources.  This includes
   collaboration with AI Agents for applications such as taxi booking
   and real-time navigation.

2.4.2.  Use Case On 6G AI Agents Collaboration With Third-party AI Using
        LLM

   A 3rd party application (e.g. a smart city traffic management system)
   AI Agent sends a text-based request or query to the 6G network.  The
   request is processed by an AI agent in the 6G network that leverages
   LLMs and the network's advanced capabilities (e.g.  sensing, real-
   time data processing, telemetry, analytics, and others) to provide a
   response or perform an action.  The 6G network AI agent acts as an



Yu, et al.                 Expires 9 July 2026                 [Page 11]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


   intelligent intermediary, interpreting the text-based request,
   gathering necessary data, and returning a response or executing a
   task.

2.4.3.  Use Case On Network Knowledge As Part of Retrieval Augmented
        Generation For Generative AI

   Generative AI (including LLMs and multi-modal models) combined with
   Retrieval Augmented Generation (RAG)—which retrieves external
   knowledge to augment prompts before generation—enhances output
   quality with up-to-date information while reducing model retraining
   energy costs.  In 6G, MNOs deploy diverse network knowledge sources
   (static/dynamic data like roaming conditions, coverage, performance
   predictions) to support RAG-powered services such as XR city
   sightseeing.  Subscribed user Alice invoke XR apps, prompting
   Generative AI to use RAG for accessing relevant network knowledge.
   The app selects suitable knowledge sources, retrieves data, and
   generates optimized outputs (e.g., XR previews adapting to roaming/
   coverage constraints).  Benefits include improved user experience,
   energy savings, and digital inclusion, though retrieval may introduce
   delays.  Existing 5G lacks full RAG support, making 6G’s timely
   multi-source knowledge provision critical.

2.4.4.  Use Case On AI Agent Management

   To address global elderly care challenges amid aging populations, 6G
   network enable cross-ecosystem collaboration of third-party AI agents
   on smart devices (e.g., cameras, bracelets, TVs) via operator-managed
   registration and invocation mechanisms.  Operator A provides AI agent
   management for 70-year-old Mary, whose devices register capabilities
   (fall detection, heartbeat monitoring, video call) to the 6G network.
   When Mary’s smart camera detects a fall, it triggers emergency
   services directly or via the network.  The emergency center requests
   real-time data; the 6G network invokes her bracelet’s AI agent for
   heartbeat monitoring and the camera’s agent for live video (with
   consent).  It further activates the TV’s AI agent for a video
   call—featuring volume amplification, dialect translation, and
   instructional videos—to guide Mary.  Finally, Mary handles injuries
   correctly while awaiting paramedics.  Existing 5G features partially
   support this, but 6G’s cross-ecosystem coordination are critical.

3.  Potential Requirements for 6G Network

   In this section, we present potential requirements to 6G network that
   may arise from the introduction of AI Agents in 6G mobile
   communication network from an operator's perspective.  Some of these
   potential requirements have already been agreed by 3GPP, while others
   have not yet been adopted by 3GPP.



Yu, et al.                 Expires 9 July 2026                 [Page 12]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


3.1.  The Identity of AI Agents

   The 6G network shall support secure authentication, authorization,
   and management mechanisms for AI Agents' digital identities.  These
   AI Agents include on-device AI Agents, 3rd party AI Agents, network
   AI Agents, etc.  A robust identity management mechanism is the
   prerequisite for interactions between users and AI Agents, as well as
   between different AI Agents.

3.2.  Efficient Collaboration

   The 6G network shall support efficient collaboration between
   different AI Agents and between AI Agents and the tools.  This
   include: developing agent communication protocols better suited for
   6G network characteristics, supporting multimodal data (such as text,
   audio, video, etc.) interactions, enabling rapid transmission of
   massive data volumes, etc.

3.3.  Cross-Domain Collaboration

   Future AI agents will be ubiquitous, forming a device-network-
   industry end-to-end ecosystem. 6G network shall support the cross-
   domain collaboration of AI agents, including the device domain, RAN
   domain, core network domain, operation and management domain,
   application domain, etc.

3.4.  Registration and Discovery

   The 6G network shall support mechanisms for on-device AI Agents, 3rd
   party AI Agent, network AI Agents and tools to register their
   attributes to 6G network, which enables efficient, cross-platforms
   and cross-domain AI Agents and tools discovery.  This may different
   from the discovery mechanism in existing agent communication related
   protocol (e.g. NRF discovery mechanism).

3.5.  Service and Data Exposure

   The 6G network shall support secure mechanisms to expose the 6G
   services (e.g. sensing service, computing service, AI/ML service,
   etc.) and network data (e.g. sensing data, positioning data, etc.) to
   3rd party AI Agents.










Yu, et al.                 Expires 9 July 2026                 [Page 13]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


3.6.  Reliability Assurance

   The 6G network shall be able to provide mechanisms (e.g. network
   digital twin) to ensure the reliability and the validity of the
   decisions made by the AI Agents.  The decisions made by the AI Agents
   in 6G network may directly change the network status, parameters,
   configurations.  Only decisions that have been verified for
   reliability can be executed to change the network environment.

3.7.  High-performance Communication

   The 6G network shall enable high-performance communication, which may
   include low latency, high band-width, ultra-high data rate, etc.
   This is crucial for numerous scenarios such as device-network
   collaboration, network-application collaboration.

3.8.  Security

   The security of AI Agents communication in 6G includes the data
   protection and user consent.  Data pravacy means tha 6G network shall
   support end-to-end encryption for the interactions between AI Agents
   to ensure robust data protection and privacy security for sensitive
   information.  Besides, 6G network shall be able to provide mechanisms
   to collect the user consent for the local data collection.

3.9.  Energy Efficiency

   The 6G network shall be able to provide mechanisms to optimize the
   communication between AI Agents (especially for the on-device AI
   Agents) to reduce energy consumption.

4.  Conclusion

   AI Agents are expected to represent a critical innovation vector for
   6G.  This draft explores the transformative potential of AI Agents in
   6G network, outlining key use cases and operational requirements from
   an operator’s perspective.  When designing agent communication
   related protocols for 6G network, the aforementioned requirements
   should be thoroughly considered and incorporated into the protocol
   architecture.

5.  Informative References

   [TR_22.870]
              "3GPP TR 22.870, "Study on 6G Use Cases and Service
              Requirements", 2025.".





Yu, et al.                 Expires 9 July 2026                 [Page 14]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


Authors' Addresses

   Menghan Yu
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: yumh1@chinatelecom.cn


   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: wangaj3@chinatelecom.cn


   Jinyan Li
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: lijinyan@chinatelecom.cn


   Zhen Li
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: liz779@chinatelecom.cn















Yu, et al.                 Expires 9 July 2026                 [Page 15]

categories:
["Agent-to-agent communication protocols", "Identity / authentication for AI agents", "Agent discovery / registration"]


