# 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/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604025+00:00
source: ietf
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]


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/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604060+00:00
source: ietf
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]


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: []
tags: []
fetched_at: 2026-05-22T09:24:40.604073+00:00
source: ietf
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: 2026-05-07T07:09:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-07T09:24:50Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604086+00:00
source: ietf
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]


name: draft-zhang-rtgwg-ai-agents-troubleshooting
rev: 00
title: Use Cases and Requirements of Communication Protocol for Troubleshooting Agents on Network Devices
time: 2026-05-06T07:09:16Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-07T01:48:49Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604098+00:00
source: ietf
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/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604104+00:00
source: ietf
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]


name: draft-narvaneni-agent-uri
rev: 03
title: The agent:// Protocol -- A URI-Based Framework for Interoperable Agents
time: 2026-04-18T17:11:11Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-20T17:11:11Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604108+00:00
source: ietf
abstract:
  This document defines the agent:// protocol, a URI-based addressing
     scheme for identifying, discovering, and invoking autonomous and
     semi-autonomous software agents.  The agent:// scheme provides a
     semantic layer that signals "this resource is an agent" and enables
     agent-specific discovery via standardized descriptors.  It introduces
     a layered architecture with four conformance levels, allowing
     implementations to adopt minimal addressing (Level 0) or full
     descriptor-based discovery with authentication and versioning (Level
     3).  The protocol complements existing agent communication protocols
     such as Agent2Agent (A2A), Model Context Protocol (MCP), and Agent
     Communication Protocol (ACP) by providing the addressing and
     discovery layer they lack.

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]


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/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604113+00:00
source: ietf
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]


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: []
tags: []
fetched_at: 2026-05-22T09:24:40.604118+00:00
source: ietf
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/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604127+00:00
source: ietf
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]


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/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604131+00:00
source: ietf
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]


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/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604135+00:00
source: ietf
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]


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/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604141+00:00
source: ietf
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]


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/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604146+00:00
source: ietf
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]


