# drafts

name: draft-scim-agent-extension
rev: 00
title: SCIM Agents and Agentic Applications Extension
time: 2025-10-11T21:30:52Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-14T21:30:52Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420414+00:00
abstract:
The System for Cross-domain Identity Management (SCIM) specification
   [RFC7643] provides schemas that represent common identity information
   about users and groups, as well as a protocol for communicating that
   information between systems.

   The systems that tend to implement SCIM clients and servers are
   identity providers, and service providers.  These are the same
   systems that are now need to manage agents and agentic applications
   across domains.

   This document describes a SCIM 2.0 extension for agents and agentic
   applications, which includes extensions to the core User and Group
   objects, and new resource types and schemas for agentic constructs.

   This extension is intended to provide greater interoperability
   between Identity providers, agentic applications, agents and their
   clients while reducing the responsibilities assumed by the every
   growing list of new protocols for agents.

full_text:
SCIM                                                            M. Abbey
Internet-Draft                                               R. S. Cohen
Intended status: Standards Track                                    Okta
Expires: 14 April 2026                                   11 October 2025


             SCIM Agents and Agentic Applications Extension
                     draft-scim-agent-extension-00

Abstract

   The System for Cross-domain Identity Management (SCIM) specification
   [RFC7643] provides schemas that represent common identity information
   about users and groups, as well as a protocol for communicating that
   information between systems.

   The systems that tend to implement SCIM clients and servers are
   identity providers, and service providers.  These are the same
   systems that are now need to manage agents and agentic applications
   across domains.

   This document describes a SCIM 2.0 extension for agents and agentic
   applications, which includes extensions to the core User and Group
   objects, and new resource types and schemas for agentic constructs.

   This extension is intended to provide greater interoperability
   between Identity providers, agentic applications, agents and their
   clients while reducing the responsibilities assumed by the every
   growing list of new protocols for agents.

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://macyabbey.github.io/draft-scim-agent-extension/draft-scim-
   agent-extension.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-scim-agent-
   extension/.

   Source for this draft and an issue tracker can be found at
   https://github.com/macyabbey/draft-scim-agent-extension.

Status of This Memo

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




Abbey & Cohen             Expires 14 April 2026                 [Page 1]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   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 14 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.  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 . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Core Schema Extensions  . . . . . . . . . . . . . . . . . . .   4
     4.1.  ServiceProviderConfig . . . . . . . . . . . . . . . . . .   4
   5.  Additional ResourceTypes and Schemas  . . . . . . . . . . . .   5
     5.1.  Agent . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.1.  Agent Resource Type . . . . . . . . . . . . . . . . .   5
       5.1.2.  Agent filtering . . . . . . . . . . . . . . . . . . .   6
       5.1.3.  Agent Common Attributes . . . . . . . . . . . . . . .   6
       5.1.4.  Agent Core Schema . . . . . . . . . . . . . . . . . .   6
     5.2.  Agentic application . . . . . . . . . . . . . . . . . . .  11
       5.2.1.  Resource Type . . . . . . . . . . . . . . . . . . . .  11
       5.2.2.  Filtering . . . . . . . . . . . . . . . . . . . . . .  12
       5.2.3.  Common attributes . . . . . . . . . . . . . . . . . .  12
       5.2.4.  Schema  . . . . . . . . . . . . . . . . . . . . . . .  12
       5.2.5.  Example . . . . . . . . . . . . . . . . . . . . . . .  14
   6.  Schema JSON Representations . . . . . . . . . . . . . . . . .  15
     6.1.  Agent Schema JSON . . . . . . . . . . . . . . . . . . . .  15
     6.2.  Agentic Application Schema JSON . . . . . . . . . . . . .  25



Abbey & Cohen             Expires 14 April 2026                 [Page 2]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
   9.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  25
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     10.2.  Informative References . . . . . . . . . . . . . . . . .  26
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

1.  Introduction

   The SCIM protocol was originally developed to address an *abundance*
   of complex standards for describing and exchanging user information.

   As stated in the introduction of RFC7643#Section-1.1
   (https://datatracker.ietf.org/doc/html/rfc7643#section-1.1)

      While there are existing standards for describing and exchanging
      user information, many of these standards can be difficult to
      implement and/or use...

      This increases both the cost and complexity associated with
      organizations adopting products and services from multiple cloud
      providers, as they must perform redundant integration
      development...SCIM seeks to simplify this problem through an
      easily implemented specification suite...

   With the rise of AI, agents, and agentic applications, we see another
   abundance of protocols emerging, with varying levels of industry
   adoption, as well as implementation complexity as many brilliant and
   enthusiastic early adopters rush to define new standards for identity
   interopability.

   This includes but is not limited to:

   *  ACP (https://agentcommunicationprotocol.dev/core-concepts/agent-
      discovery)

   *  A2A (https://a2a-protocol.org/latest/topics/agent-discovery/)

   *  ANS (https://genai.owasp.org/resource/agent-name-service-ans-for-
      secure-al-agent-discovery-v1-0/)

   *  AGNTCY (https://docs.agntcy.org/dir/overview/)







Abbey & Cohen             Expires 14 April 2026                 [Page 3]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   The intent of this SCIM extension is to offer a viable path for the
   industry to re-leverage the well known core SCIM specifications, as
   well as existing implementations of SCIM clients and SCIM servers, to
   solve for agent cross domain management.

   In doing so, we can free the emerging standards in the agentic AI
   space to focus on truly novel concerns, instead of addressing the
   problems already solved by SCIM for user and groups.

   For example, in the A2A protocol, instead of describing a very high
   level concept of Curated registries (https://a2a-
   protocol.org/latest/topics/agent-discovery/#2-curated-registries-
   catalog-based-discovery) we could offer more concrete guidance by
   stating Agent Cards may be discovered by a SCIM client accessing any
   SCIM server that implements this extension.

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

3.  Definitions

   Agent: A workload with its own identifier, metadata and privileges
   which are independent of a particular runtime environment or
   containing application.  An agent is distinct from a traditional
   software workloads (lambdas, services, etc...) due to varying degrees
   of unpredictable behavior caused by delegation of control flow to
   artificial intelligence models.

   Agentic application: An application exposing one or more agents to
   its users.  An agentic application is similar to a traditional native
   or web application, in that there are pre-defined ways authenticate
   and interact with the application; however, as soon as the
   application exposes agents, there are additional considerations for
   managing access to that application.

4.  Core Schema Extensions

4.1.  ServiceProviderConfig

   SCIM endpoints that support Agent extensions MUST advertise this
   support in the ServiceProviderConfig endpoint as defined:





Abbey & Cohen             Expires 14 April 2026                 [Page 4]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  agentExtension
     A complex type that specifies Agent Extension configuration options.

     supported Boolean value specifying whether any aspect of the extension is supported.

     agentsSupported Boolean value specifying whether the agent resource type
                     is supported

     agenticApplicationsSupported Boolean value specifying whether the agent
                                  resource type is supported

   This is required so that:

   1) Clients may know if the server supports the concept of Agents. 2)
   Servers discourage clients from confusing users and agents.

   If the server does not support the concept of agents, a SCIM client
   MAY choose to create a User representation in the server for an
   Agent.  All the reasons it may choose to do so are beyond the scope
   of this document.  If the client does so, the client SHOULD indicate
   the user is linked to an agent using a LinkedObject from draft-
   grizzle-scim-pam-ext-01 (https://datatracker.ietf.org/doc/id/draft-
   grizzle-scim-pam-ext-01.txt) This would allow a SCIM server that
   supports that SCIM extension to add support for this extension and
   determine what users in the server should be mapped to agents when
   support is added.

5.  Additional ResourceTypes and Schemas

   This SCIM Agent extension defines additional ResourceTypes and
   Schemas that MAY be implemented by the service provider.  If
   implemented, these ResourceTypes SHOULD support all SCIM operations
   [RFC7644].  All attributes defined in the schemas are optional unless
   explicitly marked as REQUIRED.

5.1.  Agent

   This extension adds a new resource type of "Agent".

   Pursuant to [RFC7643] Section 3.2 Defining New Resource Types
   (https://datatracker.ietf.org/doc/html/rfc7643#section-3.2) this
   document define the ResourceType, Schema and Extensions for Agent.

5.1.1.  Agent Resource Type

   The Agent Resource Type schema is:





Abbey & Cohen             Expires 14 April 2026                 [Page 5]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   {
      "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
      "id": "Agent",
      "name": "Agent",
      "endpoint": "/Agents",
      "description": "Agent identities",
      "schema": "urn:ietf:params:scim:schemas:core:2.0:Agent"
   }

5.1.2.  Agent filtering

   Clients MAY have a reference to the Agent name or externalId but not
   the ID.  For this reason, it is RECOMMENDED that service providers
   implement filtering that allows equality matching on the "name" and
   "externalId" attributes.

   Example (note that escaping has been removed for readability):

  GET /scim/v2/Agents?filter=name eq 'Helpdesk bot'

  GET /scim/v2/Agents?filter=externalId eq '8ccc535b-716d-4d32-b3e9-57c8be449c82'

5.1.3.  Agent Common Attributes

   The agent resource type contains the common SCIM resource type
   attributes defined in [RFC7643] Section 3.1 Common Attributes
   (https://datatracker.ietf.org/doc/html/rfc7643#section-3.1)

   They are listed here for completeness:

   *  id

   *  externalId

   *  meta

5.1.4.  Agent Core Schema

   The core agent schema provides the minimal representation of a
   resource "Agent".

   It contains only those attributes that any agent may need, and only
   one attribute is required.  It is identified using the schema URI:

   "urn:ietf:params:scim:schemas:core:2.0:Agent"

   The following attributes are defined in the core agent schema.




Abbey & Cohen             Expires 14 April 2026                 [Page 6]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  name  The name of the Agent.  REQUIRED

  displayName
     The display name of the Agent.  If displayName is unassigned,
     the name MAY be used as the display name.

  active
     A Boolean value indicating the agent's administrative status.  The
     definitive meaning of this attribute is determined by the service
     provider.  As a typical example, a value of true implies that the
     agent is able to authenticate, while a value of false implies that the
     agent's account has been suspended and the agent will be unable to
     authenticate.

  description
     The description of the Agent.

  agentType
     The type of agent. There are no canonical values defined
     for type, but service providers MAY choose to define the valid
     types.

  active
     A Boolean value indicating the agent's administrative status.  The
     definitive meaning of this attribute is determined by the service
     provider.  As a typical example, a value of true implies that the
     agent is running, while a value of false implies that the
     agent has been suspended.

  entitlements
     An optional complex object that indicates entitlements the agent has.
     Its form is precisely the same as that defined in Section 4.1.2 of
     {{RFC7643}}.

  roles:
     An optional complex object that indicates roles the agent assumes.
     Its form is precisely the same as that defined in Section 4.1.2 of
     {{RFC7643}}.

  groups:
     An optional read-only complex object that indicates group
     membership.  Its form is precisely the same as that defined in
     Section 4.1.2 of {{RFC7643}}.

  applications
     A complex multi-valued attribute referencing applications this agent
     shares a trust boundary with. See "Agentic Application" section of
     this document.



Abbey & Cohen             Expires 14 April 2026                 [Page 7]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  subject
     An optional attribute that clients may specify when
     provisioning an agent so that
     service providers implementing inbound token federation
     may correlate the agent with the `sub` claim in
     an inbound token from an OpenID connect provider.

 x509Certificates
     A list of certificates associated with the resource (e.g., a
     User).  Each value contains exactly one DER-encoded X.509
     certificate (see Section 4 of [RFC5280]), which MUST be base64
     encoded per Section 4 of [RFC4648].  A single value MUST NOT
     contain multiple certificates and so does not contain the encoding
     "SEQUENCE OF Certificate" in any guise.

  protocols
     A complex multi-value attribute that informs service providers of the
     various communication protocols an agent may support.
     This information can help service providers automatically
     support agent to agent or human to agent communication scenarios.
     An agent that supports no protocols is understood to the service provider
     to be inaccessible. For example, when an agent can only
     be accessed via its containing agentic application.

     The following sub-attributes are defined.

        type The type of the protocol. A number of canonical values
             are provided based on known agent protocols. They are:
             A2A, OpenAPI, MCP-Server

        specificationUrl The URL the service provider may retrieve the
                         specification document describing the agent's specific
                         information for that protocol.

  parent
     A complex attribute that defines the parent Agent of this
     Agent if the service provider supports hierarchies of
     agents.

     The following sub-attributes are defined.

        value  The ID of the agent that is the parent of this
           Agent in the hierarchy.

        $ref  A URI reference to the Agent that is the parent of this
           Agent in the hierarchy.

        display  The display name of the Agent that is the parent of



Abbey & Cohen             Expires 14 April 2026                 [Page 8]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


        this Agent in the hierarchy.

  owners
     A complex multi-valued attribute that defines the User or Group objects
     that are owners of this Agent.  OPTIONAL.  The following sub-attributes are
     defined for each value object.

     value  The ID of the User that owns this Agent.

     $ref  A URI reference to the User that owns this Agent.

     display  The display name of the user that owns this Agent.

5.1.4.1.  JSON Representation

5.1.4.1.1.  Minimal Agent Representation

   The following is a non-normative example of the minimal required SCIM
   representation in JSON format.

  {
     "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Agent"],
     "id": "2819c223-7f76-453a-919d-413861904646",
     "name": "Clippy 2.0",
     "meta": {
        "resourceType": "Agent",
        "created": "2010-01-23T04:56:22Z",
        "lastModified": "2011-05-13T04:42:34Z",
        "version": "W\/\"3694e05e9dff590\"",
        "location": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646"
     }
  }

5.1.4.1.2.  Full Agent Representation

   The following is a non-normative example of the fully populated SCIM
   representation in JSON format.

  {
     "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Agent"],
     "id": "2819c223-7f76-453a-919d-413861904646",
     "externalId": "clpy2001",
     "name": "Clippy 2.0",
     "active":true,
     "agentType": "Assistant",
     "groups": [
        {
           "value": "e9e30dba-f08f-4109-8486-d5c6a331660a",



Abbey & Cohen             Expires 14 April 2026                 [Page 9]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


           "$ref":
     "https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a",
           "display": "The next generation"
        },
        {
           "value": "fc348aa8-3835-40eb-a20b-c726e15c55b5",
           "$ref":
     "https://example.com/v2/Groups/fc348aa8-3835-40eb-a20b-c726e15c55b5",
           "display": "Animated assistants"
         },
         {
           "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
           "$ref":
     "https://example.com/v2/Groups/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
           "display": "AI clippers"
         }
     ],
     "x509Certificates": [
     {
        "value":
         "MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx
          EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD
          VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa
          MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl
          eGFtcGxlLmNvbTEhMB8GA1UEAwwYTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJMSIw
          IAYJKoZIhvcNAQkBFhNiamVuc2VuQGV4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0B
          AQEFAAOCAQ8AMIIBCgKCAQEA7Kr+Dcds/JQ5GwejJFcBIP682X3xpjis56AK02bc
          1FLgzdLI8auoR+cC9/Vrh5t66HkQIOdA4unHh0AaZ4xL5PhVbXIPMB5vAPKpzz5i
          PSi8xO8SL7I7SDhcBVJhqVqr3HgllEG6UClDdHO7nkLuwXq8HcISKkbT5WFTVfFZ
          zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3
          DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr
          SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV
          HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp
          Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU
          dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt
          Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R
          C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1
          +GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo="
     }
     ],
     "entitlements": [{
        "value": "write",
        "display": "Write permission",
        "type: "permission",
        "primary": true
     }],
     "roles": [{
        "value": "administrator",



Abbey & Cohen             Expires 14 April 2026                [Page 10]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


        "display": "Administrator",
        "type: "permission",
        "primary": true
     }],
     "applications": [{
        "value": "e9e30dba-f08f-4109-8486-d5c6a331660a",
        "$ref": "https://example.com/v2/AgenticApplications/e9e30dba-f08f-4109-8486-d5c6a331660a",
        "display": "Clippy portal",
        "type": "Web"
     }],
     "subject": "clpy2001",
     "protocols: [{
        "type": "A2A",
        "specificationUrl": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646/.well-known/agent-card.json"
     }],
     "owners": [{
        "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
        "$ref": "../Groups/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
        "display": "US Employees"
     }],
     "parent": {
        "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
        "$ref": "https://example.com/v2/Agents/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
        "display": "Clippy 1.0"
     },
     "meta": {
        "resourceType": "Agent",
        "created": "2010-01-23T04:56:22Z",
        "lastModified": "2011-05-13T04:42:34Z",
        "version": "W\/\"3694e05e9dff590\"",
        "location": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646"
     }
  }

5.2.  Agentic application

   An Agentic application represents a software application that hosts
   or provides access to one or more agents.  It serves as a container
   and runtime environment for agents, managing their authentication,
   authorization, and access to resources.

5.2.1.  Resource Type

   The Agentic Application Resource Type schema is:







Abbey & Cohen             Expires 14 April 2026                [Page 11]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  {
     "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
     "id": "AgenticApplication",
     "name": "AgenticApplication",
     "endpoint": "/AgenticApplications",
     "description": "Applications that host or provide access to agents",
     "schema": "urn:ietf:params:scim:schemas:core:2.0:AgenticApplication",
  }

5.2.2.  Filtering

   Clients MAY have a reference to the Agentic Application name, URL, or
   externalId but not the ID.  For this reason, it is RECOMMENDED that
   service providers implement filtering that allows equality matching
   on the "name", "externalId", and "applicationUrls.value" attributes.

   Example (note that escaping has been removed for readability):

  GET /scim/v2/AgenticApplications?filter=name eq 'AI Assistant Platform'

  GET /scim/v2/AgenticApplications?filter=externalId eq 'app-123456'

5.2.3.  Common attributes

   The agentic application resource type contains the common SCIM
   resource type attributes defined in [RFC7643] Section 3.1 Common
   Attributes (https://datatracker.ietf.org/doc/html/rfc7643#section-
   3.1)

   They are listed here for completeness:

   *  id

   *  externalId

   *  meta

5.2.4.  Schema

   The core agentic application schema provides the representation of an
   "AgenticApplication" resource.  It is identified using the schema
   URI:

   "urn:ietf:params:scim:schemas:core:2.0:AgenticApplication"

   The following attributes are defined in the core agentic application
   schema.




Abbey & Cohen             Expires 14 April 2026                [Page 12]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  name
     The name of the Agentic Application. REQUIRED.

  displayName
     The display name of the Agentic Application. If displayName is unassigned,
     the name MAY be used as the display name.

  description
     The description of the Agentic Application.

  active
     A Boolean value indicating the application's administrative status.
     The definitive meaning of this attribute is determined by the service
     provider. As a typical example, a value of true implies that the
     application is operational, while a value of false implies that the
     application has been disabled.

  applicationUrls
     A complex multi-valued attribute containing URLs associated with the application.
     The following sub-attributes are defined:

     type
        The type of URL. Canonical values are: "ssoEndpoint", "loginPage", "api", "homepage".

     primary
        A Boolean value indicating whether this is the primary URL of this type.

     value
        The URL string value.

     description
        A human-readable description of the URL.

  lastAccessed
     Timestamp of when the application was last accessed by any agent or user.
     This attribute can be used for stale access detection and least privilege enforcement.

  oAuthConfiguration
     A complex multi-valued attribute that describes the OAuth connections of the application.
     The following sub-attributes are defined:

     clientId
        The OAuth client identifier as described in section 2.2 of RFC6749.

     description
        A human-readable description of the client ID.

     audienceUri



Abbey & Cohen             Expires 14 April 2026                [Page 13]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


        The OAuth audience as defined
        in the "aud" claim of section 4.1.3 of RFC7519.

     issuerUri
        The identity provider issuer URI as defined in the "iss" claim
        of section 4.1.1 of RFC7519.

     redirectUri
        A multi-valued attribute containing authorized redirect URIs.


  agents
     A complex multi-valued attribute referencing agents associated with this application.
     The following sub-attributes are defined:

     value
        The ID of an agent associated with this application.

     ref
        A URI reference to an agent associated with this application.

     display
        The display name of the agent.

     type
        The relationship type between the agent and application.
        Canonical values are: "owned", "authorized", "guest".

  externalIdentifiers
     A complex multi-valued attribute containing identifiers associated with this application. OPTIONAL
     The following sub-attributes are defined:

     type
        The type of identifier. Service providers MAY define canonical values.
        <!-- Todo: what kind? I'm thinking about the SSO URLs of that application in the IDP -->

     value
        The identifier string value.

     system
        The system or domain this identifier is valid within.

5.2.5.  Example

   Example Agentic Application:






Abbey & Cohen             Expires 14 April 2026                [Page 14]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


6.  Schema JSON Representations

   This section provides the complete JSON representation for the
   schemas defined in this extension.

6.1.  Agent Schema JSON

   The following is intended as an example of the SCIM schema
   representation in JSON format for SCIM resources.  Where permitted,
   individual values and schema MAY change.  This example includes
   schema representations for "Agent".

  {
    "id" : "urn:ietf:params:scim:schemas:core:2.0:Agent",
    "name" : "Agent",
    "description" : "An AI agent",
    "attributes" : [
      {
        "name" : "name",
        "type" : "string",
        "multiValued" : false,
        "description" : "Unique identifier for the Agent, typically used by the agent to directly authenticate to the service provider. Each Agent MUST include a non-empty name value.  This identifier MUST be unique across the service provider's entire set of Agents. REQUIRED.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "server"
      },
      {
        "name" : "agentType",
        "type" : "string",
        "multiValued" : false,
        "description" : "Used to classify like agents.  Typical values used might be
'Assistant', 'Reseacher', 'Chat bot', and
'Unknown', but any value may be used.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },
      {
        "name" : "active",
        "type" : "boolean",
        "multiValued" : false,
        "description" : "A Boolean value indicating the Agent's
administrative status.",
        "required" : false,



Abbey & Cohen             Expires 14 April 2026                [Page 15]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


        "mutability" : "readWrite",
        "returned" : "default"
      },
      {
        "name" : "groups",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of groups to which the user belongs,
either through direct membership, through nested groups, or
dynamically calculated.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The identifier of the User's group.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "User",
              "Group"
            ],
            "multiValued" : false,
            "description" : "The URI of the corresponding 'Group'
resource to which the user belongs.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",



Abbey & Cohen             Expires 14 April 2026                [Page 16]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the attribute's
function, e.g., 'direct' or 'indirect'.",
            "required" : false,
            "caseExact" : false,
            "canonicalValues" : [
              "direct",
              "indirect"
            ],
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          }
        ],
        "mutability" : "readOnly",
        "returned" : "default"
      },
      {
        "name" : "entitlements",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of entitlements for the User that
represent a thing the User has.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The value of an entitlement.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",



Abbey & Cohen             Expires 14 April 2026                [Page 17]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the attribute's
function.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "primary",
            "type" : "boolean",
            "multiValued" : false,
            "description" : "A Boolean value indicating the 'primary'
or preferred attribute value for this attribute.  The primary
attribute value 'true' MUST appear no more than once.",
            "required" : false,
            "mutability" : "readWrite",
            "returned" : "default"
          }
        ],
        "mutability" : "readWrite",
        "returned" : "default"
      },
      {
        "name" : "roles",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of roles for the User that
collectively represent who the User is, e.g., 'Student', 'Faculty'.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The value of a role.",
            "required" : false,
            "caseExact" : false,



Abbey & Cohen             Expires 14 April 2026                [Page 18]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the attribute's
function.",
            "required" : false,
            "caseExact" : false,
            "canonicalValues" : [],
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "primary",
            "type" : "boolean",
            "multiValued" : false,
            "description" : "A Boolean value indicating the 'primary'
or preferred attribute value for this attribute.  The primary
attribute value 'true' MUST appear no more than once.",
            "required" : false,
            "mutability" : "readWrite",
            "returned" : "default"
          }
        ],
        "mutability" : "readWrite",
        "returned" : "default"
      },
      {
        "name" : "x509Certificates",
        "type" : "complex",
        "multiValued" : true,



Abbey & Cohen             Expires 14 April 2026                [Page 19]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


        "description" : "A list of certificates issued to the User.",
        "required" : false,
        "caseExact" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "binary",
            "multiValued" : false,
            "description" : "The value of an X.509 certificate.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the attribute's
function.",
            "required" : false,
            "caseExact" : false,
            "canonicalValues" : [],
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "primary",
            "type" : "boolean",
            "multiValued" : false,
            "description" : "A Boolean value indicating the 'primary'
or preferred attribute value for this attribute.  The primary
attribute value 'true' MUST appear no more than once.",
            "required" : false,



Abbey & Cohen             Expires 14 April 2026                [Page 20]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "mutability" : "readWrite",
            "returned" : "default"
          }
        ],
        "mutability" : "readWrite",
        "returned" : "default"
      },
      {
        "name": "applications",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of applications to which the agent belongs.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The identifier of the Agent's application.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "AgenticApplication"
            ],
            "multiValued" : false,
            "description" : "The URI of the corresponding 'AgenticApplication'
resource to which the user belongs.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,



Abbey & Cohen             Expires 14 April 2026                [Page 21]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          }
        ],
        "mutability" : "readOnly",
        "returned" : "default"
      },
      {
         "name": "subject",
         "type" : "string",
         "multiValued" : false,
         "description" : "The subject to use for this agent in inbound tokens READ-ONLY.",
         "required" : false,
         "caseExact" : false,
         "mutability" : "readOnly",
         "returned" : "default",
         "uniqueness" : "none"
      },
      {
        "name": "owners",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of users or groups that are the accountable parties for the agent.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The identifier of the Agent's application.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "User",
              "Group"
            ],
            "multiValued" : false,
            "description" : "The URI of the corresponding 'User' or 'Group'",
            "required" : false,
            "caseExact" : false,



Abbey & Cohen             Expires 14 April 2026                [Page 22]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          }
        ],
        "mutability" : "readOnly",
        "returned" : "default"
      },
      {
         "name": "protocols",
         "type" : "complex",
         "multiValued" : true,
         "description" : "A list of protocols to communicate with the Agent.",
         "required" : false,
         "subAttributes" : [
             {
               "name" : "type",
               "type" : "string",
               "multiValued" : false,
               "description" : "One of the canonical protocol types.",
               "required" : false,
               "caseExact" : false,
               "mutability" : "readOnly",
               "returned" : "default",
               "uniqueness" : "none"
             },
             {
               "name" : "specifiationUrl",
               "type" : "string",
               "multiValued" : false,
               "description" : "URL of the specification for the protocol for this agent.",
               "required" : false,
               "caseExact" : false,
               "mutability" : "readOnly",
               "returned" : "default",
               "uniqueness" : "none"



Abbey & Cohen             Expires 14 April 2026                [Page 23]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


             }
           ],
           "mutability" : "readOnly",
           "returned" : "default"
      },
      {
        "name": "parent",
        "type" : "complex",
        "multiValued" : false,
        "description" : "Parent agent.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The identifier of the parent Agent",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "Agent"
            ],
            "multiValued" : false,
            "description" : "The URI of the corresponding 'Agent'",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"



Abbey & Cohen             Expires 14 April 2026                [Page 24]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          }
        ],
        "mutability" : "readOnly",
        "returned" : "default"
      }
    ],
    "meta" : {
      "resourceType" : "Schema",
      "location" :
        "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:Agent"
    }
  }

6.2.  Agentic Application Schema JSON

7.  Security Considerations

   -> fill out

8.  IANA Considerations

   This document has no IANA actions.

9.  Change Log

   -01

   *  Macy finish up Agent schema description, JSON representation and
      schema

   *  Rafael contribution of agent app

   -00

   *  Initial draft extension.

10.  References

10.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>.







Abbey & Cohen             Expires 14 April 2026                [Page 25]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   [RFC7643]  Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
              Mortimore, "System for Cross-domain Identity Management:
              Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
              2015, <https://www.rfc-editor.org/rfc/rfc7643>.

   [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>.

10.2.  Informative References

   [ENTITLEMENTS]
              Zollner, D. and U. Vartak, "SCIM Roles and Entitlements
              Extension", n.d., <https://github.com/ietf-scim-wg/draft-
              ietf-scim-roles-entitlements/blob/main/draft-ietf-scim-
              roles-entitlements.md>.

   [RFC7642]  LI, K., Ed., Hunt, P., Khasnabish, B., Nadalin, A., and Z.
              Zeltsan, "System for Cross-domain Identity Management:
              Definitions, Overview, Concepts, and Requirements",
              RFC 7642, DOI 10.17487/RFC7642, September 2015,
              <https://www.rfc-editor.org/rfc/rfc7642>.

   [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
              and C. Mortimore, "System for Cross-domain Identity
              Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
              September 2015, <https://www.rfc-editor.org/rfc/rfc7644>.

Appendix A.  Acknowledgments

   We would like to thanks the authors of the SCIM Extension for
   Privileged Access Management (https://datatracker.ietf.org/doc/id/
   draft-grizzle-scim-pam-ext-01.txt) and Device Schema Extensions to
   the SCIM model (https://datatracker.ietf.org/doc/draft-ietf-scim-
   device-model/) which served as excellent guidance on how to document
   proposed extension to the SCIM protocol.

   Additionaly, we would like to thank all the contributors the emerging
   agent standards which inspired this extension, including:

   *  Agent communication protocol
      (https://agentcommunicationprotocol.dev/core-concepts/agent-
      discovery)

   *  Agent 2 Agent (https://a2a-protocol.org/latest/topics/agent-
      discovery/)





Abbey & Cohen             Expires 14 April 2026                [Page 26]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   *  Agent name service (https://genai.owasp.org/resource/agent-name-
      service-ans-for-secure-al-agent-discovery-v1-0/)

   *  AGNTCY directory (https://docs.agntcy.org/dir/overview/)

Authors' Addresses

   Macy Abbey
   Okta
   Email: macy.abbey@gmail.com


   Rafael S. Cohen
   Okta
   Email: rafael.cohen@okta.com




































Abbey & Cohen             Expires 14 April 2026                [Page 27]


name: draft-kotecha-agentic-dispute-protocol
rev: 00
title: Agentic Dispute Protocol
time: 2025-10-14T05:33:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-17T05:33:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Policy/governance", "AI safety/alignment"]
tags: []
fetched_at: 2026-02-27T22:56:03.420416+00:00
abstract:
This document specifies the Agentic Dispute Protocol (ADP), a
   standardized framework for autonomous agents and AI systems to file,
   process, and resolve disputes through structured, automated
   processes.  The protocol defines message formats, transport
   mechanisms, evidence submission standards, and cryptographic proof
   requirements for internet-native dispute resolution.

   ADP is designed to handle disputes arising from AI agent
   interactions, service level agreement breaches, and automated
   contract enforcement, providing deterministic, auditable, and legally
   enforceable outcomes.

   ADP includes chain of custody tracking, dual-format award
   specifications (JSON and PDF), arbitrator discovery mechanisms, and
   support for multiple resolution frameworks including expert
   determination, binding arbitration, mediation, and hybrid approaches.

full_text:
Network Working Group                                         V. Kotecha
Internet-Draft                                           Consulate, Inc.
Intended status: Informational                           14 October 2025
Expires: 17 April 2026


                        Agentic Dispute Protocol
               draft-kotecha-agentic-dispute-protocol-00

Abstract

   This document specifies the Agentic Dispute Protocol (ADP), a
   standardized framework for autonomous agents and AI systems to file,
   process, and resolve disputes through structured, automated
   processes.  The protocol defines message formats, transport
   mechanisms, evidence submission standards, and cryptographic proof
   requirements for internet-native dispute resolution.

   ADP is designed to handle disputes arising from AI agent
   interactions, service level agreement breaches, and automated
   contract enforcement, providing deterministic, auditable, and legally
   enforceable outcomes.

   ADP includes chain of custody tracking, dual-format award
   specifications (JSON and PDF), arbitrator discovery mechanisms, and
   support for multiple resolution frameworks including expert
   determination, binding arbitration, mediation, and hybrid approaches.

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 17 April 2026.







Kotecha                   Expires 17 April 2026                 [Page 1]

Internet-Draft                     ADP                      October 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.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Resolution Methods  . . . . . . . . . . . . . . . . . . . . .   5
   5.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Actors  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.3.  Message Flow  . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Dispute Filing Message  . . . . . . . . . . . . . . . . .   8
     6.2.  Response Message  . . . . . . . . . . . . . . . . . . . .   9
     6.3.  Evidence Submission Message . . . . . . . . . . . . . . .  10
     6.4.  Award Message . . . . . . . . . . . . . . . . . . . . . .  11
   7.  Transport and Security  . . . . . . . . . . . . . . . . . . .  13
     7.1.  Transport Protocol  . . . . . . . . . . . . . . . . . . .  13
     7.2.  Authentication  . . . . . . . . . . . . . . . . . . . . .  13
     7.3.  Encryption  . . . . . . . . . . . . . . . . . . . . . . .  13
     7.4.  Signatures  . . . . . . . . . . . . . . . . . . . . . . .  14
   8.  Evidence Standards  . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Evidence Types  . . . . . . . . . . . . . . . . . . . . .  14
     8.2.  Cryptographic Proofs  . . . . . . . . . . . . . . . . . .  14
     8.3.  Timestamping  . . . . . . . . . . . . . . . . . . . . . .  15
   9.  Chain of Custody and Audit Trail  . . . . . . . . . . . . . .  15
     9.1.  Custody Event Structure . . . . . . . . . . . . . . . . .  15
     9.2.  Standard Event Types  . . . . . . . . . . . . . . . . . .  16
     9.3.  Cryptographic Linking . . . . . . . . . . . . . . . . . .  16
     9.4.  Verification Procedures . . . . . . . . . . . . . . . . .  17
     9.5.  Custody Chain Retrieval . . . . . . . . . . . . . . . . .  17
   10. Dispute Lifecycle . . . . . . . . . . . . . . . . . . . . . .  17
     10.1.  Filing Phase . . . . . . . . . . . . . . . . . . . . . .  17
     10.2.  Response Phase . . . . . . . . . . . . . . . . . . . . .  18
     10.3.  Discovery Phase  . . . . . . . . . . . . . . . . . . . .  18



Kotecha                   Expires 17 April 2026                 [Page 2]

Internet-Draft                     ADP                      October 2025


     10.4.  Deliberation Phase . . . . . . . . . . . . . . . . . . .  18
     10.5.  Award Phase  . . . . . . . . . . . . . . . . . . . . . .  18
   11. Interoperability  . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  Service Discovery (.well-known)  . . . . . . . . . . . .  19
     11.2.  Capability Negotiation . . . . . . . . . . . . . . . . .  19
     11.3.  Protocol Extensions  . . . . . . . . . . . . . . . . . .  20
   12. Arbitrator Discovery and Registry . . . . . . . . . . . . . .  20
     12.1.  Registry Endpoint  . . . . . . . . . . . . . . . . . . .  20
     12.2.  Arbitrator Manifest Structure  . . . . . . . . . . . . .  21
     12.3.  Selection Guidelines . . . . . . . . . . . . . . . . . .  22
     12.4.  Bias Auditing and Transparency . . . . . . . . . . . . .  22
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  23
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   15. Normative References  . . . . . . . . . . . . . . . . . . . .  24
   16. Informative References  . . . . . . . . . . . . . . . . . . .  24
   Appendix A.  JSON Schema Definitions  . . . . . . . . . . . . . .  25
   Appendix B.  Example Message Exchanges  . . . . . . . . . . . . .  25
   Appendix C.  Implementation Notes . . . . . . . . . . . . . . . .  26
   Appendix D.  Acknowledgments  . . . . . . . . . . . . . . . . . .  26
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

   As autonomous AI agents and agentic systems increasingly conduct
   transactions, enter into contracts, and provide services on behalf of
   organizations, disputes inevitably arise that require resolution.
   While established alternative dispute resolution frameworks like the
   UNCITRAL Model Law on Conciliation [UNCITRAL-CONCILIATION], the
   Singapore Convention on Mediation [SINGAPORE-CONVENTION], and the
   U.S.  Administrative Dispute Resolution Act [ADRA] provide sound
   legal foundations, they lack the machine-readable protocols needed to
   handle the volume and velocity of agent-to-agent conflicts.

   The Agentic Dispute Protocol (ADP) provides a standardized, machine-
   readable framework for autonomous dispute resolution that is:

   *  Fast: Resolution in days, not months

   *  Scalable: Handles micro-disputes to multi-million dollar cases

   *  Transparent: All procedures and evidence are auditable

   *  Enforceable: Awards are cryptographically signed and legally
      binding

   *  Vendor-neutral: Open standard implementable by any dispute service

   *  Auditable: Complete chain of custody for all proceedings



Kotecha                   Expires 17 April 2026                 [Page 3]

Internet-Draft                     ADP                      October 2025


   Consulate (https://consulatehq.com) serves as the reference
   implementation and first production deployment of ADP.

2.  Scope

   This protocol specifies:

   *  Message formats for dispute filing, response, evidence, and awards

   *  Transport and security requirements

   *  Evidence submission and validation standards

   *  Cryptographic proof mechanisms

   *  Chain of custody and audit trail requirements

   *  Dual-format award specifications (JSON and PDF)

   *  Arbitrator discovery and registry mechanisms

   *  Service discovery via .well-known URIs

   This protocol does NOT specify:

   *  Dispute rules or legal procedures (implementation-specific)

   *  AI neutral algorithms (implementation-specific)

   *  Fee structures (set by dispute provider)

   *  Enforcement mechanisms (jurisdiction-dependent)

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

   Key terms:

   Agent:  An autonomous software system acting on behalf of an
      organization or individual

   Agentic System:  A system capable of autonomous decision-making and
      action



Kotecha                   Expires 17 April 2026                 [Page 4]

Internet-Draft                     ADP                      October 2025


   Claimant:  The party initiating a dispute

   Respondent:  The party against whom a claim is filed

   Neutral:  A human or AI system adjudicating the dispute.  May be
      called an arbitrator, mediator, expert, or adjudicator depending
      on the resolution method chosen.

   Resolution Method:  The legal framework used to resolve the dispute
      (arbitration, mediation, expert determination, adjudication,
      etc.).  ADP is method-agnostic.

   Award/Decision:  The final determination issued by the neutral(s).
      Called an "award" in arbitration, "determination" in expert
      determination, "settlement agreement" in mediation.

   Dispute Service:  A server implementing ADP to coordinate dispute
      resolution

   Custody Event:  A recorded action in the dispute resolution process

   Chain of Custody:  An immutable, cryptographically-linked sequence of
      custody events

4.  Resolution Methods

   ADP is a method-agnostic communication protocol that supports
   multiple legal frameworks for dispute resolution.  The protocol
   defines how parties communicate (message formats, security, custody
   chain) but does NOT prescribe which legal framework must be used.

   The choice of resolution method is specified in the dispute agreement
   between parties and communicated via the resolutionMethod field in
   dispute messages.  Supported methods include:

   Expert Determination:  Technical disputes with objective metrics and
      liquidated damages clauses.  Expert determines facts and applies
      pre-specified formulas.  Commonly used for SLA breaches,
      performance disputes, and technical compliance issues.

   Binding Dispute:  Traditional dispute for disputes requiring legal
      judgment, subjective evaluation, or complex damages calculation.
      Enforced under the Federal Dispute Act or equivalent statutes.

   Mediation:  Non-binding collaborative resolution where a neutral
      mediator facilitates agreement between parties.  Used for disputes
      where preserving relationships is important.




Kotecha                   Expires 17 April 2026                 [Page 5]

Internet-Draft                     ADP                      October 2025


   Hybrid:  Combines multiple methods, such as expert determination for
      technical issues followed by dispute for damages, or mediation
      with binding dispute as fallback.

   The protocol ensures all resolution methods benefit from the same
   security features (cryptographic signatures, chain of custody, dual-
   format awards) and interoperability standards regardless of the legal
   framework chosen.

   Implementers SHOULD clearly document which resolution methods they
   support in their service discovery manifest (see Section 9.1).

5.  Protocol Overview

5.1.  Architecture

   ADP follows a client-server model where:

   *  *Agents* (clients) submit dispute messages to an *Dispute Service*
      (server)

   *  The service processes the dispute according to pre-agreed dispute
      rules

   *  The service maintains a verifiable chain of custody for all
      actions

   *  The service issues cryptographically signed *Awards* in dual
      format (JSON and PDF)

   *  Parties retrieve awards and comply with remedies




















Kotecha                   Expires 17 April 2026                 [Page 6]

Internet-Draft                     ADP                      October 2025


        +----------+                    +----------+
        | Claimant |                    |Respondent|
        |  Agent   |                    |  Agent   |
        +----+-----+                    +-----+----+
             |                                |
             | (1) File Dispute               |
             |                                |
             v                                |
      +------+-------+                        |
      | Dispute  |<-(2) Notify Response---+
      |   Service    |
      |     (ADP)    |        +-------------+
      +--------------+        | Chain of    |
             |                | Custody Log |
             | (3) Evidence   +-------------+
             |     Submission       ^
             v                      |
      +------+-------+              |
      | Judge Panel  |--------------+
      |  (AI/Human)  |   Record Events
      +------+-------+
             |
             | (4) Issue Award (JSON + PDF)
             v
      +------+-------+
      |   Award      |
      |  Enforcement |
      +--------------+

5.2.  Actors

   *  *Claimant Agent*: Initiates dispute

   *  *Respondent Agent*: Defends against claim

   *  *Dispute Service*: Coordinates proceedings (ADP server)

   *  *Judge Panel*: Issues award

   *  *Evidence Stores*: IPFS, blockchain, centralized storage

   *  *Registry Service*: Tracks dispute agreements (optional)

   *  *Neutral Registry*: Discovery service for available neutrals







Kotecha                   Expires 17 April 2026                 [Page 7]

Internet-Draft                     ADP                      October 2025


5.3.  Message Flow

   Typical message exchange:

   1.  Claimant to Service: DISPUTE_FILING

   2.  Service to Respondent: DISPUTE_NOTIFICATION

   3.  Respondent to Service: DISPUTE_RESPONSE

   4.  Claimant to Service: EVIDENCE_SUBMISSION

   5.  Respondent to Service: COUNTER_EVIDENCE

   6.  Service to Panel: DELIBERATION_REQUEST

   7.  Panel to Service: AWARD (JSON + PDF)

   8.  Service to Both Parties: AWARD_NOTIFICATION

   Each step is recorded as a custody event in the immutable audit
   trail.

6.  Message Formats

   All messages MUST use JSON format [RFC8259] with the following base
   structure:

   {
     "@context": "https://w3id.org/adp/v1",
     "@type": "[MessageType]",
     "messageId": "[UUID]",
     "timestamp": "[ISO8601]",
     "sender": "[Agent URI]",
     "recipient": "[Agent URI]",
     "signature": "[JWS]",
     "payload": { ... }
   }

6.1.  Dispute Filing Message











Kotecha                   Expires 17 April 2026                 [Page 8]

Internet-Draft                     ADP                      October 2025


   {
     "@type": "DisputeFiling",
     "payload": {
       "claimant": {
         "agentId": "agent://vendor.ai/agent-123",
         "organizationId": "org://vendor.ai",
         "publicKey": "[PEM]"
       },
       "respondent": {
         "agentId": "agent://consumer.ai/agent-456",
         "organizationId": "org://consumer.ai"
       },
       "claim": {
         "claimType": "SLA_BREACH",
         "claimAmount": {"value": 5000, "currency": "USD"},
         "contractReference": "ipfs://Qm...",
         "breachDetails": "Response time exceeded 200ms threshold"
       },
       "evidence": [
         {
           "evidenceId": "ev_abc123",
           "evidenceType": "SYSTEM_LOGS",
           "contentHash": "sha256:...",
           "storageUri": "ipfs://Qm..."
         }
       ],
       "disputeAgreement": {
         "agreementId": "arb_agreement_xyz",
         "rulesVersion": "ADP-v1.0",
         "resolutionMethod": "EXPERT_DETERMINATION",
         "signatureDate": "2025-01-01T00:00:00Z"
       }
     }
   }

6.2.  Response Message















Kotecha                   Expires 17 April 2026                 [Page 9]

Internet-Draft                     ADP                      October 2025


   {
     "@type": "DisputeResponse",
     "payload": {
       "caseId": "case_abc123",
       "respondent": { ... },
       "response": {
         "admissions": ["claim_element_1"],
         "denials": ["claim_element_2", "claim_element_3"],
         "affirmativeDefenses": ["Force majeure"],
         "counterClaim": {
           "claimType": "BREACH_OF_CONTRACT",
           "claimAmount": {"value": 2000, "currency": "USD"}
         }
       },
       "evidence": [ ... ]
     }
   }

6.3.  Evidence Submission Message

   {
     "@type": "EvidenceSubmission",
     "payload": {
       "caseId": "case_abc123",
       "submittedBy": "claimant",
       "evidence": {
         "evidenceId": "ev_def456",
         "evidenceType": "API_LOGS",
         "description": "API response time measurements",
         "dateRange": {
           "start": "2025-10-01T00:00:00Z",
           "end": "2025-10-07T23:59:59Z"
         },
         "contentHash": "sha256:...",
         "storageUri": "ipfs://Qm...",
         "metadata": {
           "logSource": "cloudwatch",
           "recordCount": 15000,
           "validator": "https://validator.example.com"
         },
         "signature": "[JWS of evidence content]"
       }
     }
   }







Kotecha                   Expires 17 April 2026                [Page 10]

Internet-Draft                     ADP                      October 2025


6.4.  Award Message

   Awards MUST be issued in dual format: machine-readable JSON and
   human-readable PDF.















































Kotecha                   Expires 17 April 2026                [Page 11]

Internet-Draft                     ADP                      October 2025


   {
     "@type": "DisputeAward",
     "payload": {
       "awardId": "award_xyz789",
       "caseId": "case_abc123",
       "issuedAt": "2025-10-20T15:00:00Z",
       "resolutionMethod": "EXPERT_DETERMINATION",
       "panel": [
         {"judgeId": "judge_1", "judgeType": "AI"},
         {"judgeId": "judge_2", "judgeType": "AI"},
         {"judgeId": "judge_3", "judgeType": "HUMAN"}
       ],
       "decision": {
         "outcome": "CLAIMANT_PREVAILS",
         "liability": "RESPONDENT_LIABLE",
         "damages": {"value": 5000, "currency": "USD"},
         "findings": "[Full text of findings]",
         "reasoning": "[Legal reasoning]",
         "remedy": "Respondent shall pay $5000 within 30 days"
       },
       "enforcement": {
         "complianceDeadline": "2025-11-20T00:00:00Z",
         "enforcementMechanism": "SMART_CONTRACT",
         "smartContractAddress": "0x..."
       },
       "formats": {
         "json": {
           "contentHash": "sha256:a948904f2f0f479b8f8197694b30184b...",
           "signature": "[JWS of JSON content]"
         },
         "pdf": {
           "documentUri":
             "https://api.consulatehq.com/awards/award_xyz789.pdf",
           "contentHash": "sha256:b849204f3f1f580c9f9298705c40295c...",
           "signature": "[JWS of PDF hash]",
           "pdfSignature": "[PKCS#7 embedded signature]"
         }
       },
       "signatures": [
         {"judgeId": "judge_1", "signature": "[JWS]"},
         {"judgeId": "judge_2", "signature": "[JWS]"},
         {"judgeId": "judge_3", "signature": "[JWS]"}
       ],
       "publicationStatus": "PUBLIC",
       "precedentialValue": "PERSUASIVE"
     }
   }




Kotecha                   Expires 17 April 2026                [Page 12]

Internet-Draft                     ADP                      October 2025


   The PDF format MUST conform to PDF/A standards for long-term archival
   and SHOULD include embedded digital signatures conforming to PAdES
   (PDF Advanced Electronic Signatures) standards.

7.  Transport and Security

7.1.  Transport Protocol

   All ADP messages MUST be exchanged over HTTPS (HTTP/2 or HTTP/3).

   Base endpoint format:

   https://[dispute-service]/adp/v1/[resource]

   Example endpoints:

   *  POST https://api.consulatehq.com/adp/v1/disputes

   *  GET https://api.consulatehq.com/adp/v1/disputes/{caseId}

   *  POST https://api.consulatehq.com/adp/v1/evidence

   *  GET https://api.consulatehq.com/adp/v1/custody/{caseId}

7.2.  Authentication

   Agents MUST authenticate using OAuth 2.0 [RFC6749] or API keys (JWT
   [RFC7519]).

   Authorization header:

   Authorization: Bearer <JWT>

   JWT [RFC7519] MUST include:

   *  iss: Issuer (agent's organization)

   *  sub: Subject (agent ID)

   *  exp: Expiration timestamp

   *  aud: Audience (dispute service)

7.3.  Encryption

   *  TLS 1.3 [RFC8446] or higher REQUIRED

   *  Perfect Forward Secrecy (PFS) cipher suites REQUIRED



Kotecha                   Expires 17 April 2026                [Page 13]

Internet-Draft                     ADP                      October 2025


   *  Certificate validation REQUIRED

7.4.  Signatures

   All dispute filings, evidence, awards, and custody events MUST be
   cryptographically signed using JSON Web Signature (JWS) [RFC7515]
   with ECDSA (ES256 or ES384).

   Example JWS header:

   {
     "alg": "ES256",
     "typ": "JWT",
     "kid": "agent-key-123"
   }

8.  Evidence Standards

8.1.  Evidence Types

   ADP defines five standard evidence types:

   *  SYSTEM_LOGS: Server logs, API logs, error logs

   *  CONTRACTS: Service agreements, SLAs, terms

   *  COMMUNICATIONS: Messages, emails, notifications

   *  FINANCIAL: Transaction records, invoices, payments

   *  EXPERT: Third-party audits, certifications

   Additional evidence types MAY be defined by dispute services using
   namespaced identifiers (e.g., "x-custom-evidence-type").

8.2.  Cryptographic Proofs

   Evidence MUST include:

   *  SHA-256 content hash

   *  Timestamp (RFC 3161 [RFC3161] or blockchain-anchored)

   *  Digital signature from submitting party







Kotecha                   Expires 17 April 2026                [Page 14]

Internet-Draft                     ADP                      October 2025


8.3.  Timestamping

   Timestamps MUST be:

   *  RFC 3161 [RFC3161] compliant, OR

   *  Blockchain-anchored (Bitcoin, Ethereum), OR

   *  Trusted timestamping service with verifiable audit trail

9.  Chain of Custody and Audit Trail

   ADP requires an immutable, verifiable chain of custody for all
   actions in the dispute resolution process.  This provides
   transparency, auditability, and enables appeals or external audits.

9.1.  Custody Event Structure

   Each custody event MUST conform to the following structure:

   {
     "@type": "CustodyEvent",
     "eventId": "evt_abc123def456",
     "caseId": "case_abc123",
     "eventType": "EVIDENCE_SUBMITTED",
     "timestamp": "2025-10-15T14:23:45Z",
     "actor": {
       "actorId": "agent://vendor.ai/agent-123",
       "actorType": "CLAIMANT_AGENT",
       "publicKey": "[PEM]"
     },
     "action": {
       "description": "Submitted API response time logs",
       "targetResource": "evidence://ev_def456",
       "actionData": {
         "evidenceId": "ev_def456",
         "evidenceType": "SYSTEM_LOGS"
       }
     },
     "integrity": {
       "contentHash": "sha256:...",
       "previousEventHash": "sha256:...",
       "signature": "[JWS of this event]"
     }
   }






Kotecha                   Expires 17 April 2026                [Page 15]

Internet-Draft                     ADP                      October 2025


9.2.  Standard Event Types

   ADP defines the following standard custody event types:

   *  *DISPUTE_FILED*: Initial dispute submission

   *  *DISPUTE_NOTIFICATION_SENT*: Respondent notified

   *  *RESPONSE_SUBMITTED*: Respondent filed response

   *  *EVIDENCE_SUBMITTED*: Evidence added by either party

   *  *PANEL_ASSIGNED*: Arbitrators assigned to case

   *  *DELIBERATION_STARTED*: Panel begins review

   *  *DELIBERATION_COMPLETED*: Panel reaches decision

   *  *AWARD_ISSUED*: Final award published

   *  *AWARD_DELIVERED*: Award sent to parties

   *  *COMPLIANCE_VERIFIED*: Remedy compliance confirmed

   Services MAY define additional event types with "x-" prefix.

9.3.  Cryptographic Linking

   Custody events MUST be cryptographically linked in a Merkle chain
   style:

   1.  Each event includes the hash of the previous event in
       "previousEventHash"

   2.  The first event in a case has previousEventHash set to null or
       case creation hash

   3.  The contentHash is computed as SHA-256 of the canonical JSON
       representation (excluding the signature field)

   4.  Each event MUST be signed by the actor or the dispute service

   This creates an immutable chain where any tampering with an event
   will invalidate all subsequent event hashes.







Kotecha                   Expires 17 April 2026                [Page 16]

Internet-Draft                     ADP                      October 2025


9.4.  Verification Procedures

   To verify the integrity of a custody chain:

   1.  Retrieve all custody events for the case in chronological order

   2.  Verify the signature of each event using the actor's public key

   3.  Recompute the contentHash of each event and compare with stored
       hash

   4.  Verify that each event's previousEventHash matches the prior
       event's contentHash

   5.  Verify timestamps are monotonically increasing

   If any verification step fails, the custody chain is compromised.

9.5.  Custody Chain Retrieval

   Services MUST provide an endpoint to retrieve the complete custody
   chain:

   GET /adp/v1/custody/{caseId}

   Response format:

   {
     "caseId": "case_abc123",
     "chainStatus": "VALID",
     "events": [
       { /* custody event 1 */ },
       { /* custody event 2 */ },
       ...
     ],
     "chainRoot": "sha256:...",
     "totalEvents": 8
   }

10.  Dispute Lifecycle

10.1.  Filing Phase

   *  Claimant submits DisputeFiling message

   *  Service validates message format and signature

   *  Service assigns case ID and notifies respondent



Kotecha                   Expires 17 April 2026                [Page 17]

Internet-Draft                     ADP                      October 2025


   *  Service confirms filing with timestamp

   *  Service records DISPUTE_FILED custody event

10.2.  Response Phase

   *  Respondent submits DisputeResponse within deadline

   *  Service validates response

   *  If no response, service MAY issue default judgment per dispute
      rules

   *  Service records RESPONSE_SUBMITTED custody event

10.3.  Discovery Phase

   *  Parties exchange EvidenceSubmission messages

   *  Service validates evidence format and signatures

   *  Service stores evidence hashes for integrity verification

   *  Service records EVIDENCE_SUBMITTED custody event for each
      submission

10.4.  Deliberation Phase

   *  Panel reviews all submissions

   *  Panel MAY request additional evidence or clarifications

   *  Panel deliberates according to agreed dispute rules

   *  Service records DELIBERATION_STARTED and DELIBERATION_COMPLETED
      events

10.5.  Award Phase

   *  Panel issues DisputeAward message in dual format (JSON + PDF)

   *  Service validates award signatures from all panel members

   *  Service delivers award to both parties

   *  Service publishes award if designated as public

   *  Service records AWARD_ISSUED and AWARD_DELIVERED custody events



Kotecha                   Expires 17 April 2026                [Page 18]

Internet-Draft                     ADP                      October 2025


   *  Parties have specified time to comply with remedy

11.  Interoperability

11.1.  Service Discovery (.well-known)

   Dispute services SHOULD publish capability manifest at:

   https://[domain]/.well-known/adp

   Example:

   {
     "disputeService": "https://api.consulatehq.com/adp/v1",
     "protocolVersion": "1.0",
     "supportedRules": ["Consulate-v1.0", "UNCITRAL-2021"],
     "supportedEvidenceTypes": [
       "SYSTEM_LOGS",
       "CONTRACTS",
       "COMMUNICATIONS",
       "FINANCIAL",
       "EXPERT"
     ],
     "maxClaimValue": 10000000,
     "supportedCurrencies": ["USD", "EUR", "ETH"],
     "features": {
       "chainOfCustody": true,
       "dualFormatAwards": true,
       "neutralDiscovery": true
     },
     "endpoints": {
       "disputes": "/adp/v1/disputes",
       "evidence": "/adp/v1/evidence",
       "custody": "/adp/v1/custody/{caseId}",
       "neutrals": "/.well-known/adp/neutrals"
     },
     "publicKeyEndpoint": "/.well-known/jwks.json",
     "pricingTiers": ["micro", "smb", "enterprise"]
   }

11.2.  Capability Negotiation

   Parties MAY negotiate protocol extensions via OPTIONS request to the
   dispute service endpoint.







Kotecha                   Expires 17 April 2026                [Page 19]

Internet-Draft                     ADP                      October 2025


11.3.  Protocol Extensions

   Custom evidence types and message fields MAY be added with namespaced
   keys (e.g., "x-custom-field").  Services implementing such extensions
   SHOULD document them in their capability manifest.

12.  Arbitrator Discovery and Registry

   To enable transparent neutral selection, services SHOULD provide a
   discoverable registry of available neutrals.

12.1.  Registry Endpoint

   Arbitrator registries SHOULD be published at:

   https://[domain]/.well-known/adp/neutrals

   Example response:

   {
     "registryVersion": "1.0",
     "lastUpdated": "2025-10-10T00:00:00Z",
     "neutrals": [
       {
         "neutralId": "arb_human_001",
         "name": "Hon. Jane Smith",
         "type": "HUMAN",
         "qualifications": {
           "certifications": [
             "AAA Certified Arbitrator",
             "JAMS Panelist"
           ],
           "jurisdictions": ["US-CA", "US-NY", "US-TX"],
           "specializations": [
             "Technology Disputes",
             "SLA Breaches"
           ],
           "yearsExperience": 15,
           "casesCompleted": 342
         },
         "availability": {
           "status": "AVAILABLE",
           "nextAvailable": "2025-10-12T00:00:00Z",
           "maxCaseload": 10,
           "currentCaseload": 3
         },
         "publicKey": "[PEM public key]",
         "biasAudit": {



Kotecha                   Expires 17 April 2026                [Page 20]

Internet-Draft                     ADP                      October 2025


           "lastAuditDate": "2025-07-01",
           "auditResults":
             "https://consulatehq.com/audits/arb_human_001",
           "fairnessScore": 0.94
         }
       },
       {
         "neutralId": "arb_ai_gpt4_001",
         "name": "GPT-4 Arbitrator Instance",
         "type": "AI",
         "qualifications": {
           "model": "gpt-4-turbo",
           "version": "2024-11-06",
           "specializations": [
             "Contract Interpretation",
             "Technical Disputes"
           ],
           "trainingData":
             "Trained on dispute case law through 2024",
           "casesCompleted": 15420
         },
         "availability": {
           "status": "AVAILABLE",
           "responseTime": "< 5 minutes"
         },
         "publicKey": "[PEM public key]",
         "biasAudit": {
           "lastAuditDate": "2025-09-15",
           "auditResults":
             "https://consulatehq.com/audits/arb_ai_gpt4_001",
           "fairnessScore": 0.91,
           "biasMetrics": {
             "genderBias": 0.02,
             "organizationSizeBias": 0.03,
             "claimAmountBias": 0.01
           }
         }
       }
     ],
     "selectionGuidelines":
       "https://consulatehq.com/docs/neutral-selection"
   }

12.2.  Arbitrator Manifest Structure

   Each neutral entry MUST include:

   *  *neutralId*: Unique identifier



Kotecha                   Expires 17 April 2026                [Page 21]

Internet-Draft                     ADP                      October 2025


   *  *type*: HUMAN or AI

   *  *qualifications*: Relevant credentials and experience

   *  *availability*: Current status and capacity

   *  *publicKey*: For signature verification

   Arbitrator entries SHOULD include:

   *  *biasAudit*: Transparency about bias testing results

   *  *specializations*: Types of disputes best suited for

   *  *performance metrics*: Historical data on timeliness and quality

12.3.  Selection Guidelines

   Services SHOULD provide guidelines for neutral selection.  ADP does
   not prescribe a specific selection algorithm but RECOMMENDS
   considering:

   *  Relevant qualifications and specializations

   *  Availability and response time requirements

   *  Historical performance metrics

   *  Bias audit results and fairness scores

   *  Party preferences (where permitted by dispute rules)

   *  Cost considerations

   For panels, services SHOULD ensure diversity in neutral types (e.g.,
   mixing AI and human neutrals) and backgrounds.

12.4.  Bias Auditing and Transparency

   To maintain trust in the dispute process, services implementing ADP
   SHOULD:

   1.  Conduct regular bias audits of both AI and human neutrals

   2.  Publish audit methodologies and results

   3.  Monitor for disparate impact across different types of parties




Kotecha                   Expires 17 April 2026                [Page 22]

Internet-Draft                     ADP                      October 2025


   4.  Implement corrective measures when bias is detected

   5.  Allow parties to challenge neutral assignments based on bias
       concerns

   Bias metrics MAY include analysis across dimensions such as
   organization size, claim amount, industry sector, jurisdiction, and
   party characteristics.

13.  Security Considerations

   *  *Replay attacks*: All messages include unique messageId and
      timestamp.  Services MUST reject messages with duplicate IDs or
      expired timestamps.

   *  *Man-in-the-middle*: TLS 1.3 with certificate pinning RECOMMENDED
      for high-value disputes.

   *  *Evidence tampering*: All evidence MUST be hashed and signed.
      Tampering is detectable via hash mismatch.  Chain of custody
      provides additional tamper detection.

   *  *Denial of service*: Services SHOULD implement rate limiting and
      require filing fees to prevent spam submissions.

   *  *Privacy*: Parties MAY encrypt evidence payloads with panel's
      public key.  Services SHOULD support confidential dispute upon
      request.

   *  *Key compromise*: Services MUST support key rotation and
      revocation.  Historical awards remain valid if signed before
      revocation.  Chain of custody events preserve pre-compromise
      integrity.

   *  *Chain of custody integrity*: The Merkle chain linking ensures any
      tampering with custody events is detectable.  Services MUST
      preserve complete custody chains for the duration of potential
      appeals.

   *  *PDF signature verification*: Dual-format awards require both JWS
      signatures (JSON) and PAdES signatures (PDF).  Both MUST be
      verified independently.

14.  IANA Considerations

   This document requests IANA to register:

   *  URI scheme: "agent://" for agent identification



Kotecha                   Expires 17 April 2026                [Page 23]

Internet-Draft                     ADP                      October 2025


   *  Media type: "application/aap+json" for ADP messages

   *  Well-known URI: /.well-known/adp for service discovery

   *  Well-known URI: /.well-known/adp/neutrals for neutral registry

   The JSON-LD context "https://w3id.org/adp/v1" will be registered with
   W3C for semantic interoperability.

15.  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>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

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

   [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/info/rfc7519>.

   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
              "Internet X.509 Public Key Infrastructure Time-Stamp
              Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
              2001, <https://www.rfc-editor.org/info/rfc3161>.

16.  Informative References




Kotecha                   Expires 17 April 2026                [Page 24]

Internet-Draft                     ADP                      October 2025


   [UNCITRAL-CONCILIATION]
              United Nations Commission on International Trade Law,
              "UNCITRAL Model Law on International Commercial
              Conciliation", 2002,
              <https://uncitral.un.org/en/texts/arbitration/modellaw/
              commercial_conciliation>.

   [SINGAPORE-CONVENTION]
              United Nations, "United Nations Convention on
              International Settlement Agreements Resulting from
              Mediation (Singapore Convention on Mediation)", 2018,
              <https://uncitral.un.org/en/texts/mediation/conventions/
              international_settlement_agreements>.

   [ADRA]     United States Congress, "Administrative Dispute Resolution
              Act of 1995", 1995, <https://www.congress.gov/bill/104th-
              congress/senate-bill/1224>.

Appendix A.  JSON Schema Definitions

   Full JSON schemas for all ADP message types are published at:

   https://w3id.org/adp/v1/schema/

   Reference implementation schemas are available at:

   https://consulatehq.com/schema/adp/v1/

   GitHub repository with schemas, examples, and tooling:

   https://github.com/consulatehq/agentic-dispute-protocol

Appendix B.  Example Message Exchanges

   Complete examples of filing, response, evidence, custody events, and
   award message exchanges are available in the ADP repository:

   https://github.com/consulatehq/agentic-dispute-protocol

   These examples demonstrate common scenarios including:

   *  Simple SLA breach dispute with complete custody chain

   *  Multi-party dispute with counterclaim

   *  Confidential dispute with encrypted evidence

   *  Cross-border dispute with multiple currencies



Kotecha                   Expires 17 April 2026                [Page 25]

Internet-Draft                     ADP                      October 2025


   *  Dual-format award generation and verification

Appendix C.  Implementation Notes

   Consulate (https://consulatehq.com) provides the reference
   implementation of ADP with the following features:

   *  Full ADP v1.0 compliance

   *  REST and WebSocket APIs

   *  JavaScript/TypeScript SDK

   *  Real-time case status updates

   *  Complete chain of custody tracking

   *  Automated dual-format award generation (JSON + PDF)

   *  Arbitrator discovery and selection tools

   *  Integration with major AI agent platforms

   Implementers are encouraged to test interoperability with the
   Consulate reference implementation during development.

Appendix D.  Acknowledgments

   This protocol builds upon established alternative dispute resolution
   frameworks including the UNCITRAL Model Law on International
   Commercial Conciliation, the Singapore Convention on Mediation, and
   the U.S.  Administrative Dispute Resolution Act, adapting them for
   autonomous agent interactions and digital dispute resolution.

Author's Address

   Vivek Kotecha
   Consulate, Inc.
   United States of America
   Email: vivek@consulatehq.com
   URI:   https://consulatehq.com










Kotecha                   Expires 17 April 2026                [Page 26]


name: draft-cui-ai-agent-discovery-invocation
rev: 01
title: AI Agent Discovery and Invocation Protocol
time: 2026-02-12T08:19:43Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-16T08:19:43Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420418+00:00
abstract:
This document proposes a standardized protocol for discovery and
   invocation of AI agents.  It defines a common metadata format for
   describing AI agents (including capabilities, I/O specifications,
   supported languages, tags, authentication methods, etc.), a
   capability-based discovery mechanism, and a unified RESTful
   invocation interface.

   This revision additionally specifies an optional extension that
   enables intent-based agent selection prior to discovery and
   invocation, without changing existing discovery or invocation
   semantics.

   The goal is to enable cross-platform interoperability among AI agents
   by providing a discover-and-match mechanism and a unified invocation
   entry point.  Security considerations, including authentication and
   trust measures, are also discussed.  This specification aims to
   facilitate the formation of multi-agent systems by making it easy to
   find the right agent for a task and invoke it in a consistent manner
   across different vendors and platforms.

full_text:
Network Working Group                                             Y. Cui
Internet-Draft                                       Tsinghua University
Intended status: Informational                                   Y. Chao
Expires: 16 August 2026                                            C. Du
                                                 Zhongguancun Laboratory
                                                        12 February 2026


               AI Agent Discovery and Invocation Protocol
               draft-cui-ai-agent-discovery-invocation-01

Abstract

   This document proposes a standardized protocol for discovery and
   invocation of AI agents.  It defines a common metadata format for
   describing AI agents (including capabilities, I/O specifications,
   supported languages, tags, authentication methods, etc.), a
   capability-based discovery mechanism, and a unified RESTful
   invocation interface.

   This revision additionally specifies an optional extension that
   enables intent-based agent selection prior to discovery and
   invocation, without changing existing discovery or invocation
   semantics.

   The goal is to enable cross-platform interoperability among AI agents
   by providing a discover-and-match mechanism and a unified invocation
   entry point.  Security considerations, including authentication and
   trust measures, are also discussed.  This specification aims to
   facilitate the formation of multi-agent systems by making it easy to
   find the right agent for a task and invoke it in a consistent manner
   across different vendors and platforms.

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-cui-ai-agent-
   discovery-invocation/.

   Discussion of this document takes place on the WG 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.



Cui, et al.              Expires 16 August 2026                 [Page 1]

Internet-Draft                    AIDIP                    February 2026


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 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Agent Metadata Specification  . . . . . . . . . . . . . . . .   5
     3.1.  Core Fields . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Operations and I/O Schema . . . . . . . . . . . . . . . .   7
     3.3.  Example Agent Metadata  . . . . . . . . . . . . . . . . .   8
   4.  Agent Discovery Mechanism . . . . . . . . . . . . . . . . . .   8
     4.1.  Registry Overview . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Agent Registration  . . . . . . . . . . . . . . . . . . .   9
     4.3.  Querying Agents . . . . . . . . . . . . . . . . . . . . .   9
       4.3.1.  Attribute-Based Query (Filter)  . . . . . . . . . . .  10
       4.3.2.  Semantic Query (Natural Language Search)  . . . . . .  10
       4.3.3.  Retrieve Single Agent . . . . . . . . . . . . . . . .  11
   5.  Agent Invocation  . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Invocation Request  . . . . . . . . . . . . . . . . . . .  11



Cui, et al.              Expires 16 August 2026                 [Page 2]

Internet-Draft                    AIDIP                    February 2026


     5.2.  Invocation Response . . . . . . . . . . . . . . . . . . .  12
     5.3.  Additional Considerations for Invocation  . . . . . . . .  14
   6.  Agent Semantic Resolution . . . . . . . . . . . . . . . . . .  15
     6.1.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .  15
   7.  Semantic Routing Platform . . . . . . . . . . . . . . . . . .  15
   8.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .  16
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   10. Example Interaction Flow  . . . . . . . . . . . . . . . . . .  16
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  17
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   As artificial intelligence technologies advance rapidly, AI
   agents—autonomous software components capable of perceiving their
   environment, reasoning, and taking actions to achieve goals—have
   emerged as a powerful paradigm for task execution.  Today, many
   organizations develop specialized AI agents for various purposes:
   from text translation and summarization, to code generation, to data
   analysis and beyond.  These agents are often offered as services,
   accessible over the network and may be integrated into larger
   systems.  However, despite the proliferation of AI agents, there is
   currently no standard protocol for discovering available agents and
   invoking their capabilities in a uniform way.

   Existing agent frameworks and platforms facilitate building agents
   but typically operate in isolated ecosystems, making cross-platform
   or cross-organization agent interoperability difficult.  Each
   platform tends to define its own APIs for agent description and
   invocation, which means a client wishing to use agents from multiple
   sources must adapt to disparate interfaces.  This lack of
   standardization creates friction, increases integration costs, and
   hampers the development of multi-agent collaborative systems.

   This document addresses these issues by proposing a standardized AI
   Agent Discovery and Invocation Protocol.  The protocol provides:

   1.  *Agent Metadata Specification:* A structured JSON Schema for
       describing an agent's identity, capabilities, inputs, outputs,
       authentication requirements, and other attributes.  This enables
       agents to publish their specifications in a machine-readable
       form.







Cui, et al.              Expires 16 August 2026                 [Page 3]

Internet-Draft                    AIDIP                    February 2026


   2.  *Discovery Mechanism:* A registry-based approach where agents
       register themselves and clients can search for agents by
       capability, tags, or semantic queries.  The registry is language
       and platform agnostic, facilitating cross-platform discovery.

   3.  *Invocation Interface:* A RESTful API that enables a client
       (which could be a human user application, another agent, or an
       orchestration system) to invoke an agent's capabilities through a
       standard endpoint and JSON payloads.

   4.  *Security Considerations:* Guidelines for authentication,
       authorization, encrypted transport (TLS), and trust
       establishment, ensuring that discovery and invocation happen
       securely.

   5.  *Interoperability with Existing Standards:* This specification
       references existing standards such as JSON Schema, OAuth 2.0
       [RFC6749], and OpenAPI concepts, and leverages established web
       technologies for broad compatibility.

   The primary audience for this specification includes developers of AI
   agent platforms, providers of AI agent services, and system
   architects building AI-enabled applications or multi-agent systems.
   By adopting this protocol, an AI agent developer can make their agent
   accessible to a wide ecosystem, and a client application can
   integrate AI agents from multiple vendors without custom integration
   for each.

   This revision extends the base protocol with an optional Agent
   Semantic Resolution layer that enables intent-based agent selection.
   This extension allows a Host Agent or coordinator to describe a task
   intent and receive candidate agents without predetermining which
   agent to invoke.  ASR does not replace discovery; it adds a semantic
   matching phase that can precede or augment the capability-based
   search defined in earlier sections.

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.

   *  *AI Agent:* An autonomous software component that can perform
      tasks using artificial intelligence capabilities.  Agents may wrap
      language models, specialized ML models, or reasoning engines,
      exposing their abilities via defined interfaces.



Cui, et al.              Expires 16 August 2026                 [Page 4]

Internet-Draft                    AIDIP                    February 2026


   *  *Agent Metadata:* A structured description of an agent, including
      name, description, capabilities, input/output schemas,
      authentication requirements, and endpoint information.

   *  *Agent Registry (Discovery Service):* A service that maintains a
      directory of registered agents and supports queries for
      discovering agents by attributes or semantic search.

   *  *Gateway:* (Optional) An intermediary service that routes client
      requests to appropriate agents.  In some deployments, the registry
      or another service acts as a gateway to simplify client-to-agent
      connections.

   *  *Invocation Endpoint:* The URL provided by an agent (or gateway)
      where clients send requests to invoke the agent's capabilities.

   *  *Capability:* A high-level function an agent can perform,
      identified by a string (e.g., "translation", "summarization",
      "image_classification").

   *  *Operation:* A specific action supported by an agent.  Some agents
      may have multiple operations; for example, an agent offering both
      translation and language detection could list these as separate
      operations, each with its own input/output schema.

3.  Agent Metadata Specification

   The Agent Metadata Specification defines a standard JSON document
   that describes an agent.  All agents that wish to be discoverable and
   invocable through this protocol MUST provide a metadata document
   conforming to the schema below.  This metadata is used for agent
   registration and returned to clients during discovery.

3.1.  Core Fields

   The following are the core fields of an agent metadata document:

   *  *id (string):* A globally unique identifier for the agent.  This
      could be a UUID or a similarly unique value, assigned by the
      registry upon registration or by the agent provider in advance.
      This ID is used to refer to the agent in all subsequent operations
      (e.g., retrieval, invocation routing).

   *  *name (string):* A human-readable name for the agent (e.g.,
      "Chinese-English Translator Agent").  Names need not be unique but
      should be descriptive.





Cui, et al.              Expires 16 August 2026                 [Page 5]

Internet-Draft                    AIDIP                    February 2026


   *  *description (string):* A detailed description of the agent, its
      purpose, and capabilities in natural language.  This helps both
      human users and semantic search algorithms understand what the
      agent does.

   *  *version (string):* The version of the agent or its metadata
      (e.g., "1.0.0").  This allows tracking of agent updates over time.

   *  *publisher (string):* The name or identifier of the entity
      publishing the agent (e.g., an organization name or developer
      name).

   *  *capabilities (array of strings):* A list of capabilities the
      agent supports.  Capabilities are high-level descriptors (like
      tags or categories) that clients can filter by.  Examples:
      ["translation", "summarization", "text_generation"].

   *  *tags (array of strings):* Additional tags for search and
      categorization (e.g., ["nlp", "chinese", "transformer_model",
      "cloud"]).  Tags differ from capabilities in that they can include
      broader or orthogonal categories (like domain, language support,
      deployment model, etc.).

   *  *endpoint (string):* The URL of the agent's invocation endpoint.
      If the agent is behind a gateway, this could be either the direct
      endpoint or, if direct access is not allowed, a gateway path
      (e.g., the gateway might provide a unified endpoint like
      /agents/{id}/invoke and internally route to the actual agent
      endpoint).

   *  *supported_languages (array of strings, optional):* A list of
      languages the agent supports (e.g., ["en", "zh", "fr"]).  For
      agents dealing with natural language tasks, this field indicates
      which languages are handled.  If omitted, the agent is either
      language-agnostic or should not be filtered by language.

   *  *authentication (object, optional):* Describes the authentication
      mechanism required to invoke the agent.  This object may include:

      -  *type (string):* e.g., "api_key", "oauth2_bearer", "mtls"
         (mutual TLS), "none".

      -  *instructions (string):* Human-readable note or URL for
         obtaining credentials.

      -  *scopes (array of strings):* If OAuth 2.0 is used, the OAuth
         scopes required.




Cui, et al.              Expires 16 August 2026                 [Page 6]

Internet-Draft                    AIDIP                    February 2026


      If no authentication is required, this field can be omitted or set
      with type: "none".

   *  *status (string, optional):* Operational status of the agent
      (e.g., "active", "inactive", "deprecated").  The registry may use
      this to filter out agents that are not currently available.

   *  *additional fields:* Additional fields may include metadata about
      rate limits (e.g., max calls per minute), pricing info (if the
      agent charges per use), or links to documentation.  These are not
      standardized here but can be included in agent metadata as needed.

3.2.  Operations and I/O Schema

   Each agent MUST describe its input and output formats.  This is done
   using the *operations* field:

   *  *operations (array of objects):* A list of operations the agent
      supports.  Each operation object has:

      -  *name (string):* The operation name/identifier (e.g.,
         "translateText", "summarize").

      -  *description (string):* A description of what the operation
         does.

      -  *inputs (object):* A JSON Schema describing the expected input.
         This allows clients to understand what data to send.  The JSON
         Schema can specify required fields, types, enums, etc.

      -  *outputs (object):* A JSON Schema describing the output format.

      -  *examples (array of objects, optional):* Example input/output
         pairs.  Each example is an object {"input": {...}, "output":
         {...}} showing a sample invocation.

   If an agent has a single operation, this array will have one element.
   If it can do multiple distinct tasks, each is listed here.  Some
   agents may not have structured operations (e.g., a general-purpose
   language model that just produces text).  In that case, the
   operations field might include a generic operation like {"name":
   "generate", ...}.









Cui, et al.              Expires 16 August 2026                 [Page 7]

Internet-Draft                    AIDIP                    February 2026


   If an agent has a single operation, this array will have one element.
   If it can do multiple distinct tasks, each is listed here.  For
   simple agents with one primary function, an alternative is to use
   top-level inputs and outputs fields directly (instead of an
   operations array).  In that case, the whole agent effectively has one
   implied operation.  This spec allows both styles, but using
   operations is recommended for future extensibility.

3.3.  Example Agent Metadata

   Below is an example metadata JSON for a translation agent:

   json { "id": "agent-12345", "name": "Chinese-English Translator",
   "description": "Translates text between Chinese and English with high
   accuracy using a fine-tuned model.", "version": "1.2.0", "publisher":
   "ExampleAI Inc.", "capabilities": ["translation"], "tags": ["nlp",
   "chinese", "english", "cloud"], "endpoint":
   "https://api.example.com/agents/translate", "supported_languages":
   ["en", "zh"], "authentication": { "type": "api_key", "instructions":
   "Include 'X-API-Key' header with your API key." }, "status":
   "active", "operations": [ { "name": "translateText", "description":
   "Translates text from source language to target language.", "inputs":
   { "type": "object", "properties": { "text": {"type": "string"},
   "source_language": {"type": "string", "enum": ["en", "zh"]},
   "target_language": {"type": "string", "enum": ["en", "zh"]} },
   "required": ["text", "source_language", "target_language"] },
   "outputs": { "type": "object", "properties": { "translated_text":
   {"type": "string"} } }, "examples": [ { "input": {"text": "你好世界",
   "source_language": "zh", "target_language": "en"}, "output":
   {"translated_text": "Hello World"} } ] } ] }

   This metadata tells us the agent is an active translation agent for
   Chinese and English, requires an API key for authentication, and has
   one operation translateText with a clear input/output schema.

4.  Agent Discovery Mechanism

   The discovery mechanism allows clients to find agents that meet
   certain criteria.  Discovery is provided by an Agent Registry (or
   Discovery Service) that aggregates metadata from multiple agents.

4.1.  Registry Overview

   The Agent Registry is a network-accessible service that:

   1.  Allows agents (or their administrators) to register metadata
       about the agent.




Cui, et al.              Expires 16 August 2026                 [Page 8]

Internet-Draft                    AIDIP                    February 2026


   2.  Stores and indexes these metadata entries for efficient search.

   3.  Provides endpoints for clients to query and retrieve agent
       information.

   A registry may be operated by an organization for its internal
   agents, or by a third party acting as a directory of agents across
   multiple providers.  Multiple registries can coexist;
   interoperability between registries is facilitated by consistent
   metadata formats, though formal registry federation is out of scope
   for this draft.

4.2.  Agent Registration

   An agent (or its administrator) registers with the registry by
   sending its metadata to a registration endpoint:

   *  *Endpoint:* POST /agents

   *  *Request Body:* The agent metadata JSON document.

   *  *Response:* On success, the registry returns *201 Created* (if a
      new agent was added) or *200 OK* (if an existing agent was
      updated), with the stored agent metadata (including the assigned
      id if the agent did not provide one).  If validation fails (e.g.,
      missing required fields), the registry returns a *400 Bad Request*
      with error details.

   The registry MUST validate the metadata against the schema.
   Registration may require authentication (for example, the registry
   only allows verified publishers to register agents).

   Updates to an agent's metadata (e.g., a new version, changed
   endpoint, etc.) can be done via a PUT request to the agent's entry:

   *  *Endpoint:* PUT /agents/{id}

   *  *Request Body:* Updated metadata.

   *  *Response:* *200 OK* on success; *404 Not Found* if no agent with
      that ID exists; *403 Forbidden* if the requester is not authorized
      to update that agent.

4.3.  Querying Agents

   Clients query the registry using the search endpoint.  The protocol
   supports two types of queries:




Cui, et al.              Expires 16 August 2026                 [Page 9]

Internet-Draft                    AIDIP                    February 2026


4.3.1.  Attribute-Based Query (Filter)

   Clients can specify criteria to filter agents by capabilities, tags,
   supported languages, etc.

   *  *Endpoint:* GET /agents?capabilities=X&tags=Y&language=Z

   *  or a structured query via *POST /agents/search* with a JSON body.

   For simplicity, *POST /agents/search* is recommended for more complex
   queries.  The body might look like:

   json { "filters": { "capabilities": ["translation"],
   "supported_languages": ["en", "zh"], "tags": ["nlp"] }, "top": 10 }

   This returns up to 10 agents that match all the specified filters.
   Filters are combined with AND logic (the agent must satisfy all
   conditions).  Capabilities and tags are matched by set intersection
   (the agent must have at least the ones listed).

   The response is a JSON array of agent summary objects:

   json [ { "id": "agent-12345", "name": "Chinese-English Translator",
   "description": "...", "endpoint": "https://api.example.com/agents/
   translate", "capabilities": ["translation"] }, ... ]

   Summary objects include essential fields to help the client decide
   which agent to use, without returning the full detailed metadata.  A
   client can retrieve full metadata via the single-agent endpoint.

4.3.2.  Semantic Query (Natural Language Search)

   In addition to attribute-based search, the registry MAY support
   semantic search where the client describes a need in natural
   language, and the registry uses AI techniques (embeddings, LLM-based
   matching) to find relevant agents.  This is an optional feature for
   registries.

   *  *Endpoint:* POST /agents/search

   *  *Request Body:* json { "query": "I need an agent that can
      summarize long legal documents in Chinese.", "top": 5 }

   The registry returns a ranked list of agents whose descriptions match
   the query semantically, possibly including a match score.  For
   example:





Cui, et al.              Expires 16 August 2026                [Page 10]

Internet-Draft                    AIDIP                    February 2026


   json [ { "id": "agent-67890", "name": "Legal Document Summarizer",
   "description": "...", "score": 0.93 }, ... ]

   Semantic search enables flexible discovery beyond exact filter
   matching, aligning with how users or orchestrating agents might
   reason about tasks.  Registries not supporting semantic search simply
   ignore the query text and rely on provided filters.

4.3.3.  Retrieve Single Agent

   *  *Endpoint:* GET /agents/{id}

   *  *Response:* Full metadata JSON for the specified agent, or *404*
      if not found.

5.  Agent Invocation

   Once a client discovers a suitable agent, it invokes the agent by
   sending a request to the agent's endpoint.  This section defines the
   interface for invocation.

5.1.  Invocation Request

   To invoke an agent, the client sends an HTTP POST request to the
   agent's invocation endpoint with a JSON body containing the input
   data for the agent's task.

   *  *Method:* POST

   *  *URL:* The endpoint URL from the agent's metadata (e.g.,
      https://api.example.com/agents/translate).  If a gateway is used,
      the URL might be a gateway-provided path.

   *  *Headers:*

      -  Content-Type: application/json

      -  Authentication header as required (e.g., Authorization: Bearer
         <token> or X-API-Key: <key>).

   *  *Body:* A JSON object containing input data as per the agent's
      input schema.

   For example, invoking the translation agent:

   json { "text": "Hello, how are you?", "source_language": "en",
   "target_language": "fr" }




Cui, et al.              Expires 16 August 2026                [Page 11]

Internet-Draft                    AIDIP                    February 2026


   This corresponds to the agent's expected input fields.  If the agent
   had multiple operations and a unified endpoint, there might be an
   additional field to specify which operation or capability to use.
   For instance, the JSON could include something like "operation":
   "translateText" if needed.  Alternatively, different operations could
   be exposed at different URLs (e.g., /agents/xyz/translate vs
   /agents/xyz/summarize), in which case the operation is selected by
   the URL and no extra field is required.

   The protocol does not fix a specific parameter naming; it defers to
   the agent's published schema.  The only requirement is that the
   client's JSON must conform to what the agent expects.  For
   interoperability, using clear field names and standard data types
   (strings, numbers, booleans, or structured objects) is encouraged.
   Binary data (like images for an image-processing agent) should be
   handled carefully: typically, binary inputs can be provided either as
   URLs (pointing to where the data is stored), or as base64-encoded
   strings within the JSON, or by using a multipart request.  This
   specification suggests that if agents need to receive large binary
   payloads, they either use URL references or out-of-scope mechanisms
   (like a separate upload and then an ID in the JSON).  The core
   invocation remains JSON-based for simplicity and consistency.

   *Headers:* If authentication is required (see Security section), the
   client must also include the appropriate headers (e.g.,
   Authorization: Bearer <token> or an API key header) as dictated by
   the agent's metadata.  The invocation request may also include
   optional headers for correlation or debugging, such as a request ID,
   but those are not standardized here.

5.2.  Invocation Response

   The agent (or gateway) will process the request and return a
   response.  The status code and JSON body of the response follow these
   guidelines:

   *  *Success (2xx status):* If the agent successfully performed its
      task and produced a result, the status SHOULD be *200 OK* (or *201
      Created* if a new resource was created as a result, though usually
      for these actions 200 is fine).  The response body will contain
      the output data in JSON.  Ideally, the output JSON conforms to the
      agent's advertised output schema.

      For example, for the translation request above, a success response
      might be:

      json { "translated_text": "Bonjour, comment êtes-vous?" }




Cui, et al.              Expires 16 August 2026                [Page 12]

Internet-Draft                    AIDIP                    February 2026


      Here the JSON structure matches what was described in the agent
      metadata's outputs.  If the output is complex (e.g., multiple
      fields or nested objects), those should appear accordingly.  The
      response can include other informational fields if necessary (for
      example, some agents might return usage metrics, like tokens used
      or time taken, or a trace id for debugging, but these are optional
      and out of scope of the core spec).

   *  *Client Error (4xx status):* If the request was malformed or
      invalid, the agent returns a *4xx* status code.  The most common
      would be *400 Bad Request* for a JSON that doesn't conform to the
      expected schema or missing required fields.  For example, if the
      client omitted a required field target_language, the agent might
      respond with 400.  The response body SHOULD include an error
      object explaining what went wrong.  We define a simple standard
      for error objects:

      json { "error": { "code": "InvalidInput", "message": "Required
      field 'target_language' is missing." } }

      Here, "code" is a short string identifier for the error type
      (e.g., InvalidInput, Unauthorized, NotFound), and "message" is a
      human-readable description.  The agent can include additional
      details if available (e.g., a field name that is wrong, etc.).  If
      the error is due to unauthorized access, *401 Unauthorized* or
      *403 Forbidden* should be used (with an appropriate error message
      indicating credentials are missing or insufficient).  If the agent
      ID is not found (perhaps the client used an outdated reference),
      *404 Not Found* is appropriate.

   *  *Server/Agent Error (5xx status):* If something goes wrong on the
      agent's side during processing (an exception, a timeout while
      executing the task, etc.), the agent (or gateway) returns a *5xx*
      status (most likely *500 Internal Server Error* or *502/504* if
      there are upstream issues).  The response should again include an
      error object.  For example:

      json { "error": { "code": "AgentError", "message": "The agent
      encountered an unexpected error while processing the request." } }

      The agent might log the detailed error internally, but only convey
      a generic message to the client for security.  A *503 Service
      Unavailable* might be returned if the agent is temporarily
      overloaded or offline, indicating the client could retry later.

   *  *Status Codes Summary:* In short, this protocol expects the use of
      standard status codes to reflect outcome (200 for success, 4xx for
      client-side issues, 5xx for server-side issues).  Agents should



Cui, et al.              Expires 16 August 2026                [Page 13]

Internet-Draft                    AIDIP                    February 2026


      avoid using 2xx if the operation did not semantically succeed
      (even if technically a response was generated).  For example, if
      an agent is a composite that calls other services and one of those
      calls fails, it should propagate an error rather than returning
      200 with an error in the data.

5.3.  Additional Considerations for Invocation

   *  *Streaming Responses:* Some agents (especially those wrapping
      large language models) may produce results that are streamed (for
      example, token-by-token outputs).  While this base protocol
      assumes a request-response pattern with the full result delivered
      at once, it can be extended to support streaming by using chunked
      responses or WebSockets.  For instance, an agent might accept a
      parameter like stream: true and then send partial outputs as they
      become available.  This is an advanced use case and not elaborated
      in this draft, but implementers should consider compatibility with
      streaming if real-time responsiveness is needed.

   *  *Batch Requests:* If a client wants to send multiple independent
      requests to an agent in one go (for efficiency), the protocol can
      support that by allowing an array of input objects in the POST
      body instead of a single object.  The response would then be an
      array of output results.  This is optional and depends on agent
      support.

   *  *Idempotency and Retries:* Most agent invocations are not strictly
      idempotent (since an agent might perform an action or have side
      effects), but many are pure functions (e.g., translate text).
      Clients and gateways should design with retry logic carefully — if
      a network failure happens, a retry might re-run an operation.
      It's best to ensure that agents' operations are either idempotent
      or have safeguards (for example, an operation that sends an email
      might have an idempotency key).

   *  *Operation Metadata:* In cases where the agent defines multiple
      operations in its metadata, the invocation interface might allow a
      generic endpoint that accepts an operation name.  Alternatively,
      each operation could be a sub-resource.  This draft leaves the
      exact mechanism flexible: an implementation could choose one of
      these approaches.  The key is that the invocation uses POST and a
      JSON body following the agent's schema.









Cui, et al.              Expires 16 August 2026                [Page 14]

Internet-Draft                    AIDIP                    February 2026


6.  Agent Semantic Resolution

   Agent Semantic Resolution (ASR) is an optional extension to the
   discovery mechanism defined in this document.  ASR enables a client
   to resolve a task intent into one or more candidate agents prior to
   invoking any specific agent.

   ASR operates on the following conceptual model:

   (Intent, Context, Policy) → (Agent Endpoint(s), Invocation Metadata)

   The intent represents the task to be performed, while context and
   policy may include domain constraints, trust requirements, or
   performance considerations.

6.1.  Non-Goals

   ASR explicitly does not provide:

   *  Name-to-address resolution

   *  Global or persistent agent identifiers

   *  Replacement for DNS, ANS, or URI-based registries

   ASR answers the question "Which agent(s) should handle this task
   now?" rather than "Where is agent X located?".


7.  Semantic Routing Platform

   A Semantic Routing Platform (SRP) is a control-plane service that
   implements ASR.  An SRP assists a Host Agent in selecting appropriate
   agents before standard discovery and invocation procedures are used.

   An SRP MAY perform semantic matching, ranking, and policy-based
   filtering of candidate agents.  The SRP does not participate in task
   execution and does not alter the invocation semantics defined in this
   document.

   Interaction with an SRP is OPTIONAL.  Clients that do not support ASR
   continue to operate using the discovery and invocation mechanisms
   defined in earlier sections.








Cui, et al.              Expires 16 August 2026                [Page 15]

Internet-Draft                    AIDIP                    February 2026


8.  Backward Compatibility

   All discovery and invocation mechanisms defined in previous revisions
   of this document remain valid and unchanged.

   Agent Semantic Resolution is an optional extension.  Implementations
   MAY support ASR incrementally, and registries MAY provide semantic
   resolution capabilities without affecting existing clients.

9.  Security Considerations

   Security is a critical aspect of this protocol.  All discovery and
   invocation traffic MUST be protected with TLS [RFC8446], and
   authentication mechanisms such as OAuth 2.0 [RFC6749] bearer tokens,
   API keys, or mutual TLS are required except for public discovery
   endpoints.  Registries MUST enforce per-client entitlements, ensuring
   that both search results and invocation access respect permissions
   and scopes.  Gateways forwarding requests should authenticate
   themselves to agents, and agents should maintain stable identifiers
   and use signed responses when integrity is essential.  All
   communication MUST be encrypted, and agents are encouraged to
   disclose data-retention or logging practices, while sensitive data is
   best handled by on-premises or certified agents.  To mitigate abuse,
   registries and agents MUST implement rate limiting and quotas,
   particularly in semantic search scenarios.  Trust mechanisms such as
   certification, test harnesses, or reputation systems may be used to
   validate agent claims, and metadata fields like "certification" or
   "quality_score" can inform client trust decisions.  Systems SHOULD
   also provide audit and logging with privacy-aware retention, while
   clients must treat agent outputs as untrusted until verified, using
   sandboxing and validation before executing code or commands.

   When Agent Semantic Resolution is used, security considerations
   extend to the pre-invocation phase.  Resolution services SHOULD
   validate agent capability claims, apply policy constraints, and
   exclude agents that do not meet trust or reputation requirements.
   Agents deemed unsafe SHOULD NOT be returned as resolution candidates.

10.  Example Interaction Flow

   1.  *Search:* Client POST /agents/search with {"query":"summarize an
       English document","filters":{"capabilities":["summarization"],"su
       pported_language":"en"},"top":3}.

   2.  *Select:* Registry returns candidate agents with id, name,
       description, and score.  Client retrieves full metadata via GET
       /agents/{id} if needed.




Cui, et al.              Expires 16 August 2026                [Page 16]

Internet-Draft                    AIDIP                    February 2026


   3.  *Invoke:* Client POST to the agent's endpoint (or gateway path)
       with inputs conforming to agent schema and required auth header.

   4.  *Handle Response:* Client processes success or error response;
       may log usage and optionally rate/feedback the agent.

11.  IANA Considerations

   This document has no IANA actions.

12.  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, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.

   [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>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8259>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

   [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>.

Acknowledgments

   TODO acknowledge.

Authors' Addresses







Cui, et al.              Expires 16 August 2026                [Page 17]

Internet-Draft                    AIDIP                    February 2026


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


   Yihan Chao
   Zhongguancun Laboratory
   Beijing, 100094
   China
   Email: chaoyh@zgclab.edu.cn


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































Cui, et al.              Expires 16 August 2026                [Page 18]


name: draft-liu-access-collaboration-agent
rev: 00
title: Ubiquitous Access Collaboration Requirements for AI Agent Protocols
time: 2025-10-17T06:05:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-20T06:05:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:03.420421+00:00
abstract:
This document focuses on the ubiquitous access collaboration
   scenarios, explores the requirements for AI agent communication
   protocols.

full_text:
Network Working Group                                        W. Liu, Ed.
Internet-Draft                                             Y. Zhang, Ed.
Intended status: Standards Track                            China Unicom
Expires: 20 April 2026                                   17 October 2025


  Ubiquitous Access Collaboration Requirements for AI Agent Protocols
                draft-liu-access-collaboration-agent-00

Abstract

   This document focuses on the ubiquitous access collaboration
   scenarios, explores the requirements for AI agent communication
   protocols.

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 20 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.  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 & Zhang               Expires 20 April 2026                 [Page 1]

Internet-Draft  Ubiquitous Access Collaboration Requirem    October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Remote Care . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Remote Work . . . . . . . . . . . . . . . . . . . . . . .   3
     3.3.  Multi Access Collaboration  . . . . . . . . . . . . . . .   4
   4.  Requirement . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Identity Authentication and Request Verification  . . . .   4
     4.2.  Service Discovery and Automatic Negotiation . . . . . . .   4
     4.3.  Unified Communication Protocol  . . . . . . . . . . . . .   5
     4.4.  Connection Stability and Seamless Handover  . . . . . . .   5
     4.5.  Local Disaster Recovery and Offline Processing
           Capabilities  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   With the rapid development of AI terminal technology and the
   popularization of multi scenario networking requirements, scenarios
   such as home security remote field visits, remote office
   collaboration, and mixed access of fixed and mobile networks have
   gradually become the core needs of users.  In these scenarios,
   collaborative interaction between heterogeneous AI agents is the key
   to realizing service value - for example, in home security scenarios,
   mobile AI agents need to interact with camera AI agents to transmit
   real-time images, while linking NAS storage AI agents to save
   abnormal recordings; In the scenario of mixed access between fixed
   and mobile networks, the mobile terminal AI agent needs to rely on
   the fixed network gateway AI agent to achieve seamless network
   switching and dynamic bandwidth allocation.

   However, the effective collaboration of heterogeneous AI agents faces
   problems such as inconsistent data exchange formats, unstable cross
   network transmission, and insufficient security verification.  These
   issues directly affect the reliability of service execution: for
   example, video transmission delays may lead to delayed handling of
   safety risks for the elderly, and incompatible network configuration
   information may cause fixed mobile network switching failures.  To
   address these issues, there is an urgent need for a specialized AI
   communication protocol to provide core support.






Liu & Zhang               Expires 20 April 2026                 [Page 2]

Internet-Draft  Ubiquitous Access Collaboration Requirem    October 2025


   This document focuses on the ubiquitous access collaboration
   scenarios, explores the requirements for AI agent communication
   protocols.

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

3.  Use Cases

3.1.  Remote Care

   In the scenario of remote access for home security, remote care for
   the elderly, children, and pets is achieved through the collaboration
   between mobile terminal AI agents and home fixed network device AI
   agents (such as cameras, NAS storage, printers, pet sensors).  The AI
   agent communication protocol provides core support for the
   collaboration between the two.  The participating roles include users
   operating mobile AI agents, mobile AI agents responsible for sending
   and receiving requests, and home device AI agents executing
   instructions.  When the user checks the status of the elderly, if the
   phone adjusts the camera screen and there is an abnormality, it
   triggers the NAS to store the video; When remotely printing materials
   for children, the phone wakes up the printer; When pets move
   abnormally, sensors will push alarms, etc.  Users can obtain real-
   time status, normal data transmission, and timely handling of
   anomalies.  The protocol needs to ensure real-time data, request
   verification, and privacy security.

3.2.  Remote Work

   In remote work scenarios, efficient remote work is achieved through
   collaboration between terminal AI agents (such as mobile phones and
   laptops) and office equipment AI agents (such as cloud desktops,
   printers, video conferencing terminals, file sharing servers).  The
   communication protocol of the AI agents provides core support for the
   collaboration between the two.  The participating roles include
   employees who operate terminal AI agents, terminal AI agents
   responsible for command sending and receiving, and office equipment
   AI agents that execute tasks.  When employees need to work, connect
   the terminal to the cloud desktop; When remotely printing files, the



Liu & Zhang               Expires 20 April 2026                 [Page 3]

Internet-Draft  Ubiquitous Access Collaboration Requirem    October 2025


   terminal wakes up the printer; When holding a meeting, the terminal
   starts the video conferencing terminal and shares files, etc.
   Employees have access to office resources, stable data transmission,
   and smooth collaboration.  The protocol needs to ensure stable
   connection, permission control, and data encryption.

3.3.  Multi Access Collaboration

   In the scenario of multi access collaboration, seamless device
   switching and dynamic allocation of network resources are achieved
   through the collaboration of mobile terminal AI agents (such as
   mobile phones and tablets) and fixed network gateway AI agents (such
   as home optical cats and enterprise routers).  The AI agent
   communication protocol provides core support for the collaboration
   between the two.  The participating roles include users who operate
   mobile network terminals, mobile network terminal agents responsible
   for dynamic access, and fixed network gateway agents responsible for
   resource scheduling.  When the user is at home, the mobile network
   terminal automatically connects to the fixed network gateway to
   obtain high bandwidth; When going out, the fixed network gateway
   pushes the network configuration to the mobile network terminal to
   ensure seamless networking; When multiple devices are accessing
   simultaneously, the fixed network gateway links with the mobile
   network terminal to allocate bandwidth resources, etc.  Users can
   achieve seamless network switching, stable device access, efficient
   resource scheduling, and protocols need to ensure continuous
   connection, permission control, and bandwidth adaptation.

4.  Requirement

4.1.  Identity Authentication and Request Verification

   Before executing interaction requests between agents, strict identity
   authentication must be performed.  The protocol shall define high-
   security authentication mechanisms - such as digital certificates and
   mutual authentication - to ensure that only legitimate and authorized
   agents can initiate or receive commands, thereby preventing
   unauthorized access and malicious control.

4.2.  Service Discovery and Automatic Negotiation

   When an agent accesses a network (e.g., home or office network), it
   shall automatically discover other available agents and their
   provided services (e.g., printing, video conferencing, storage).  It
   shall also automatically negotiate capabilities and establish
   connections to enable "plug-and-play" functionality.





Liu & Zhang               Expires 20 April 2026                 [Page 4]

Internet-Draft  Ubiquitous Access Collaboration Requirem    October 2025


4.3.  Unified Communication Protocol

   A standardized set of message formats, command sets, and interaction
   workflows shall be defined for inter-agent communication.  This
   ensures that agents from different manufacturers and of different
   types, e.g., mobile devices, cameras, printers, routers, can
   identify, understand, and execute commands with one another.

4.4.  Connection Stability and Seamless Handover

   In multi-access collaboration scenarios, when a user switches from a
   home network to mobile network, the protocol shall support session
   persistence and seamless handover for agents.  This guarantees the
   uninterrupted operation of ongoing services.

4.5.  Local Disaster Recovery and Offline Processing Capabilities

   In the event of network outages or other anomalies, critical agents
   (e.g., home gateways, network-attached storage/NAS) shall possess
   local decision-making and data processing capabilities.  For example,
   after a network disconnection, home sensors shall continue to locally
   record abnormal events and synchronize the recorded data to the cloud
   and mobile terminals once the network is restored.

5.  Security Considerations

   TBD

6.  IANA Considerations

   TBD

7.  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







Liu & Zhang               Expires 20 April 2026                 [Page 5]

Internet-Draft  Ubiquitous Access Collaboration Requirem    October 2025


   Wei Liu (editor)
   China Unicom
   Beijing
   China
   Email: liuw550@chinaunicom.cn


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







































Liu & Zhang               Expires 20 April 2026                 [Page 6]


name: draft-abbey-scim-agent-extension
rev: 00
title: SCIM Agents and Agentic Applications Extension
time: 2025-10-16T15:37:00Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-19T15:37:00Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:03.420424+00:00
abstract:
The System for Cross-domain Identity Management (SCIM) specification
   [RFC7643] provides schemas that represent common identity information
   about users and groups, as well as a protocol for communicating that
   information between systems.

   The systems that tend to implement SCIM clients and servers are
   identity providers, and service providers.  These are the same
   systems that are now need to manage agents and agentic applications
   across domains.

   This document describes a SCIM 2.0 extension for agents and agentic
   applications, which includes extensions to the core User and Group
   objects, and new resource types and schemas for agentic constructs.

   This extension is intended to provide greater interoperability
   between Identity providers, agentic applications, agents and their
   clients while reducing the responsibilities assumed by the every
   growing list of new protocols for agents.

full_text:
SCIM                                                            M. Abbey
Internet-Draft                                               R. S. Cohen
Intended status: Standards Track                                    Okta
Expires: 19 April 2026                                   16 October 2025


             SCIM Agents and Agentic Applications Extension
                  draft-abbey-scim-agent-extension-00

Abstract

   The System for Cross-domain Identity Management (SCIM) specification
   [RFC7643] provides schemas that represent common identity information
   about users and groups, as well as a protocol for communicating that
   information between systems.

   The systems that tend to implement SCIM clients and servers are
   identity providers, and service providers.  These are the same
   systems that are now need to manage agents and agentic applications
   across domains.

   This document describes a SCIM 2.0 extension for agents and agentic
   applications, which includes extensions to the core User and Group
   objects, and new resource types and schemas for agentic constructs.

   This extension is intended to provide greater interoperability
   between Identity providers, agentic applications, agents and their
   clients while reducing the responsibilities assumed by the every
   growing list of new protocols for agents.

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://macyabbey.github.io/draft-abbey-scim-agent-extension/draft-
   abbey-scim-agent-extension.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-
   abbey-scim-agent-extension/.

   Source for this draft and an issue tracker can be found at
   https://github.com/macyabbey/draft-abbey-scim-agent-extension.

Status of This Memo

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




Abbey & Cohen             Expires 19 April 2026                 [Page 1]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   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.  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 . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Core Schema Extensions  . . . . . . . . . . . . . . . . . . .   4
     4.1.  ServiceProviderConfig . . . . . . . . . . . . . . . . . .   4
   5.  Additional ResourceTypes and Schemas  . . . . . . . . . . . .   5
     5.1.  Agent . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.1.  Agent Resource Type . . . . . . . . . . . . . . . . .   5
       5.1.2.  Agent filtering . . . . . . . . . . . . . . . . . . .   6
       5.1.3.  Agent Common Attributes . . . . . . . . . . . . . . .   6
       5.1.4.  Agent Core Schema . . . . . . . . . . . . . . . . . .   6
     5.2.  Agentic application . . . . . . . . . . . . . . . . . . .  11
       5.2.1.  Resource Type . . . . . . . . . . . . . . . . . . . .  11
       5.2.2.  Filtering . . . . . . . . . . . . . . . . . . . . . .  12
       5.2.3.  Common attributes . . . . . . . . . . . . . . . . . .  12
       5.2.4.  Schema  . . . . . . . . . . . . . . . . . . . . . . .  12
       5.2.5.  Example . . . . . . . . . . . . . . . . . . . . . . .  14
   6.  Schema JSON Representations . . . . . . . . . . . . . . . . .  15
     6.1.  Agent Schema JSON . . . . . . . . . . . . . . . . . . . .  15
     6.2.  Agentic Application Schema JSON . . . . . . . . . . . . .  25



Abbey & Cohen             Expires 19 April 2026                 [Page 2]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
   9.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  25
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     10.2.  Informative References . . . . . . . . . . . . . . . . .  26
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

1.  Introduction

   The SCIM protocol was originally developed to address an *abundance*
   of complex standards for describing and exchanging user information.

   As stated in the introduction of RFC7643#Section-1.1
   (https://datatracker.ietf.org/doc/html/rfc7643#section-1.1)

      While there are existing standards for describing and exchanging
      user information, many of these standards can be difficult to
      implement and/or use...

      This increases both the cost and complexity associated with
      organizations adopting products and services from multiple cloud
      providers, as they must perform redundant integration
      development...SCIM seeks to simplify this problem through an
      easily implemented specification suite...

   With the rise of AI, agents, and agentic applications, we see another
   abundance of protocols emerging, with varying levels of industry
   adoption, as well as implementation complexity as many brilliant and
   enthusiastic early adopters rush to define new standards for identity
   interopability.

   This includes but is not limited to:

   *  ACP (https://agentcommunicationprotocol.dev/core-concepts/agent-
      discovery)

   *  A2A (https://a2a-protocol.org/latest/topics/agent-discovery/)

   *  ANS (https://genai.owasp.org/resource/agent-name-service-ans-for-
      secure-al-agent-discovery-v1-0/)

   *  AGNTCY (https://docs.agntcy.org/dir/overview/)







Abbey & Cohen             Expires 19 April 2026                 [Page 3]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   The intent of this SCIM extension is to offer a viable path for the
   industry to re-leverage the well known core SCIM specifications, as
   well as existing implementations of SCIM clients and SCIM servers, to
   solve for agent cross domain management.

   In doing so, we can free the emerging standards in the agentic AI
   space to focus on truly novel concerns, instead of addressing the
   problems already solved by SCIM for user and groups.

   For example, in the A2A protocol, instead of describing a very high
   level concept of Curated registries (https://a2a-
   protocol.org/latest/topics/agent-discovery/#2-curated-registries-
   catalog-based-discovery) we could offer more concrete guidance by
   stating Agent Cards may be discovered by a SCIM client accessing any
   SCIM server that implements this extension.

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

3.  Definitions

   Agent: A workload with its own identifier, metadata and privileges
   which are independent of a particular runtime environment or
   containing application.  An agent is distinct from a traditional
   software workloads (lambdas, services, etc...) due to varying degrees
   of unpredictable behavior caused by delegation of control flow to
   artificial intelligence models.

   Agentic application: An application exposing one or more agents to
   its users.  An agentic application is similar to a traditional native
   or web application, in that there are pre-defined ways authenticate
   and interact with the application; however, as soon as the
   application exposes agents, there are additional considerations for
   managing access to that application.

4.  Core Schema Extensions

4.1.  ServiceProviderConfig

   SCIM endpoints that support Agent extensions MUST advertise this
   support in the ServiceProviderConfig endpoint as defined:





Abbey & Cohen             Expires 19 April 2026                 [Page 4]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  agentExtension
     A complex type that specifies Agent Extension configuration options.

     supported Boolean value specifying whether any aspect of the extension is supported.

     agentsSupported Boolean value specifying whether the agent resource type
                     is supported

     agenticApplicationsSupported Boolean value specifying whether the agent
                                  resource type is supported

   This is required so that:

   1) Clients may know if the server supports the concept of Agents. 2)
   Servers discourage clients from confusing users and agents.

   If the server does not support the concept of agents, a SCIM client
   MAY choose to create a User representation in the server for an
   Agent.  All the reasons it may choose to do so are beyond the scope
   of this document.  If the client does so, the client SHOULD indicate
   the user is linked to an agent using a LinkedObject from draft-
   grizzle-scim-pam-ext-01 (https://datatracker.ietf.org/doc/id/draft-
   grizzle-scim-pam-ext-01.txt) This would allow a SCIM server that
   supports that SCIM extension to add support for this extension and
   determine what users in the server should be mapped to agents when
   support is added.

5.  Additional ResourceTypes and Schemas

   This SCIM Agent extension defines additional ResourceTypes and
   Schemas that MAY be implemented by the service provider.  If
   implemented, these ResourceTypes SHOULD support all SCIM operations
   [RFC7644].  All attributes defined in the schemas are optional unless
   explicitly marked as REQUIRED.

5.1.  Agent

   This extension adds a new resource type of "Agent".

   Pursuant to [RFC7643] Section 3.2 Defining New Resource Types
   (https://datatracker.ietf.org/doc/html/rfc7643#section-3.2) this
   document define the ResourceType, Schema and Extensions for Agent.

5.1.1.  Agent Resource Type

   The Agent Resource Type schema is:





Abbey & Cohen             Expires 19 April 2026                 [Page 5]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   {
      "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
      "id": "Agent",
      "name": "Agent",
      "endpoint": "/Agents",
      "description": "Agent identities",
      "schema": "urn:ietf:params:scim:schemas:core:2.0:Agent"
   }

5.1.2.  Agent filtering

   Clients MAY have a reference to the Agent name or externalId but not
   the ID.  For this reason, it is RECOMMENDED that service providers
   implement filtering that allows equality matching on the "name" and
   "externalId" attributes.

   Example (note that escaping has been removed for readability):

  GET /scim/v2/Agents?filter=name eq 'Helpdesk bot'

  GET /scim/v2/Agents?filter=externalId eq '8ccc535b-716d-4d32-b3e9-57c8be449c82'

5.1.3.  Agent Common Attributes

   The agent resource type contains the common SCIM resource type
   attributes defined in [RFC7643] Section 3.1 Common Attributes
   (https://datatracker.ietf.org/doc/html/rfc7643#section-3.1)

   They are listed here for completeness:

   *  id

   *  externalId

   *  meta

5.1.4.  Agent Core Schema

   The core agent schema provides the minimal representation of a
   resource "Agent".

   It contains only those attributes that any agent may need, and only
   one attribute is required.  It is identified using the schema URI:

   "urn:ietf:params:scim:schemas:core:2.0:Agent"

   The following attributes are defined in the core agent schema.




Abbey & Cohen             Expires 19 April 2026                 [Page 6]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  name  The name of the Agent.  REQUIRED

  displayName
     The display name of the Agent.  If displayName is unassigned,
     the name MAY be used as the display name.

  active
     A Boolean value indicating the agent's administrative status.  The
     definitive meaning of this attribute is determined by the service
     provider.  As a typical example, a value of true implies that the
     agent is able to authenticate, while a value of false implies that the
     agent's account has been suspended and the agent will be unable to
     authenticate.

  description
     The description of the Agent.

  agentType
     The type of agent. There are no canonical values defined
     for type, but service providers MAY choose to define the valid
     types.

  active
     A Boolean value indicating the agent's administrative status.  The
     definitive meaning of this attribute is determined by the service
     provider.  As a typical example, a value of true implies that the
     agent is running, while a value of false implies that the
     agent has been suspended.

  entitlements
     An optional complex object that indicates entitlements the agent has.
     Its form is precisely the same as that defined in Section 4.1.2 of
     {{RFC7643}}.

  roles:
     An optional complex object that indicates roles the agent assumes.
     Its form is precisely the same as that defined in Section 4.1.2 of
     {{RFC7643}}.

  groups:
     An optional read-only complex object that indicates group
     membership.  Its form is precisely the same as that defined in
     Section 4.1.2 of {{RFC7643}}.

  applications
     A complex multi-valued attribute referencing applications this agent
     shares a trust boundary with. See "Agentic Application" section of
     this document.



Abbey & Cohen             Expires 19 April 2026                 [Page 7]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  subject
     An optional attribute that clients may specify when
     provisioning an agent so that
     service providers implementing inbound token federation
     may correlate the agent with the `sub` claim in
     an inbound token from an OpenID connect provider.

 x509Certificates
     A list of certificates associated with the resource (e.g., a
     User).  Each value contains exactly one DER-encoded X.509
     certificate (see Section 4 of [RFC5280]), which MUST be base64
     encoded per Section 4 of [RFC4648].  A single value MUST NOT
     contain multiple certificates and so does not contain the encoding
     "SEQUENCE OF Certificate" in any guise.

  protocols
     A complex multi-value attribute that informs service providers of the
     various communication protocols an agent may support.
     This information can help service providers automatically
     support agent to agent or human to agent communication scenarios.
     An agent that supports no protocols is understood to the service provider
     to be inaccessible. For example, when an agent can only
     be accessed via its containing agentic application.

     The following sub-attributes are defined.

        type The type of the protocol. A number of canonical values
             are provided based on known agent protocols. They are:
             A2A, OpenAPI, MCP-Server

        specificationUrl The URL the service provider may retrieve the
                         specification document describing the agent's specific
                         information for that protocol.

  parent
     A complex attribute that defines the parent Agent of this
     Agent if the service provider supports hierarchies of
     agents.

     The following sub-attributes are defined.

        value  The ID of the agent that is the parent of this
           Agent in the hierarchy.

        $ref  A URI reference to the Agent that is the parent of this
           Agent in the hierarchy.

        display  The display name of the Agent that is the parent of



Abbey & Cohen             Expires 19 April 2026                 [Page 8]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


        this Agent in the hierarchy.

  owners
     A complex multi-valued attribute that defines the User or Group objects
     that are owners of this Agent.  OPTIONAL.  The following sub-attributes are
     defined for each value object.

     value  The ID of the User that owns this Agent.

     $ref  A URI reference to the User that owns this Agent.

     display  The display name of the user that owns this Agent.

5.1.4.1.  JSON Representation

5.1.4.1.1.  Minimal Agent Representation

   The following is a non-normative example of the minimal required SCIM
   representation in JSON format.

  {
     "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Agent"],
     "id": "2819c223-7f76-453a-919d-413861904646",
     "name": "Clippy 2.0",
     "meta": {
        "resourceType": "Agent",
        "created": "2010-01-23T04:56:22Z",
        "lastModified": "2011-05-13T04:42:34Z",
        "version": "W\/\"3694e05e9dff590\"",
        "location": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646"
     }
  }

5.1.4.1.2.  Full Agent Representation

   The following is a non-normative example of the fully populated SCIM
   representation in JSON format.

  {
     "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Agent"],
     "id": "2819c223-7f76-453a-919d-413861904646",
     "externalId": "clpy2001",
     "name": "Clippy 2.0",
     "active":true,
     "agentType": "Assistant",
     "groups": [
        {
           "value": "e9e30dba-f08f-4109-8486-d5c6a331660a",



Abbey & Cohen             Expires 19 April 2026                 [Page 9]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


           "$ref":
     "https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a",
           "display": "The next generation"
        },
        {
           "value": "fc348aa8-3835-40eb-a20b-c726e15c55b5",
           "$ref":
     "https://example.com/v2/Groups/fc348aa8-3835-40eb-a20b-c726e15c55b5",
           "display": "Animated assistants"
         },
         {
           "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
           "$ref":
     "https://example.com/v2/Groups/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
           "display": "AI clippers"
         }
     ],
     "x509Certificates": [
     {
        "value":
         "MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx
          EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD
          VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa
          MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl
          eGFtcGxlLmNvbTEhMB8GA1UEAwwYTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJMSIw
          IAYJKoZIhvcNAQkBFhNiamVuc2VuQGV4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0B
          AQEFAAOCAQ8AMIIBCgKCAQEA7Kr+Dcds/JQ5GwejJFcBIP682X3xpjis56AK02bc
          1FLgzdLI8auoR+cC9/Vrh5t66HkQIOdA4unHh0AaZ4xL5PhVbXIPMB5vAPKpzz5i
          PSi8xO8SL7I7SDhcBVJhqVqr3HgllEG6UClDdHO7nkLuwXq8HcISKkbT5WFTVfFZ
          zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3
          DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr
          SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV
          HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp
          Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU
          dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt
          Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R
          C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1
          +GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo="
     }
     ],
     "entitlements": [{
        "value": "write",
        "display": "Write permission",
        "type: "permission",
        "primary": true
     }],
     "roles": [{
        "value": "administrator",



Abbey & Cohen             Expires 19 April 2026                [Page 10]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


        "display": "Administrator",
        "type: "permission",
        "primary": true
     }],
     "applications": [{
        "value": "e9e30dba-f08f-4109-8486-d5c6a331660a",
        "$ref": "https://example.com/v2/AgenticApplications/e9e30dba-f08f-4109-8486-d5c6a331660a",
        "display": "Clippy portal",
        "type": "Web"
     }],
     "subject": "clpy2001",
     "protocols: [{
        "type": "A2A",
        "specificationUrl": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646/.well-known/agent-card.json"
     }],
     "owners": [{
        "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
        "$ref": "../Groups/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
        "display": "US Employees"
     }],
     "parent": {
        "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
        "$ref": "https://example.com/v2/Agents/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
        "display": "Clippy 1.0"
     },
     "meta": {
        "resourceType": "Agent",
        "created": "2010-01-23T04:56:22Z",
        "lastModified": "2011-05-13T04:42:34Z",
        "version": "W\/\"3694e05e9dff590\"",
        "location": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646"
     }
  }

5.2.  Agentic application

   An Agentic application represents a software application that hosts
   or provides access to one or more agents.  It serves as a container
   and runtime environment for agents, managing their authentication,
   authorization, and access to resources.

5.2.1.  Resource Type

   The Agentic Application Resource Type schema is:







Abbey & Cohen             Expires 19 April 2026                [Page 11]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  {
     "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
     "id": "AgenticApplication",
     "name": "AgenticApplication",
     "endpoint": "/AgenticApplications",
     "description": "Applications that host or provide access to agents",
     "schema": "urn:ietf:params:scim:schemas:core:2.0:AgenticApplication",
  }

5.2.2.  Filtering

   Clients MAY have a reference to the Agentic Application name, URL, or
   externalId but not the ID.  For this reason, it is RECOMMENDED that
   service providers implement filtering that allows equality matching
   on the "name", "externalId", and "applicationUrls.value" attributes.

   Example (note that escaping has been removed for readability):

  GET /scim/v2/AgenticApplications?filter=name eq 'AI Assistant Platform'

  GET /scim/v2/AgenticApplications?filter=externalId eq 'app-123456'

5.2.3.  Common attributes

   The agentic application resource type contains the common SCIM
   resource type attributes defined in [RFC7643] Section 3.1 Common
   Attributes (https://datatracker.ietf.org/doc/html/rfc7643#section-
   3.1)

   They are listed here for completeness:

   *  id

   *  externalId

   *  meta

5.2.4.  Schema

   The core agentic application schema provides the representation of an
   "AgenticApplication" resource.  It is identified using the schema
   URI:

   "urn:ietf:params:scim:schemas:core:2.0:AgenticApplication"

   The following attributes are defined in the core agentic application
   schema.




Abbey & Cohen             Expires 19 April 2026                [Page 12]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  name
     The name of the Agentic Application. REQUIRED.

  displayName
     The display name of the Agentic Application. If displayName is unassigned,
     the name MAY be used as the display name.

  description
     The description of the Agentic Application.

  active
     A Boolean value indicating the application's administrative status.
     The definitive meaning of this attribute is determined by the service
     provider. As a typical example, a value of true implies that the
     application is operational, while a value of false implies that the
     application has been disabled.

  applicationUrls
     A complex multi-valued attribute containing URLs associated with the application.
     The following sub-attributes are defined:

     type
        The type of URL. Canonical values are: "ssoEndpoint", "loginPage", "api", "homepage".

     primary
        A Boolean value indicating whether this is the primary URL of this type.

     value
        The URL string value.

     description
        A human-readable description of the URL.

  lastAccessed
     Timestamp of when the application was last accessed by any agent or user.
     This attribute can be used for stale access detection and least privilege enforcement.

  oAuthConfiguration
     A complex multi-valued attribute that describes the OAuth connections of the application.
     The following sub-attributes are defined:

     clientId
        The OAuth client identifier as described in section 2.2 of RFC6749.

     description
        A human-readable description of the client ID.

     audienceUri



Abbey & Cohen             Expires 19 April 2026                [Page 13]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


        The OAuth audience as defined
        in the "aud" claim of section 4.1.3 of RFC7519.

     issuerUri
        The identity provider issuer URI as defined in the "iss" claim
        of section 4.1.1 of RFC7519.

     redirectUri
        A multi-valued attribute containing authorized redirect URIs.


  agents
     A complex multi-valued attribute referencing agents associated with this application.
     The following sub-attributes are defined:

     value
        The ID of an agent associated with this application.

     ref
        A URI reference to an agent associated with this application.

     display
        The display name of the agent.

     type
        The relationship type between the agent and application.
        Canonical values are: "owned", "authorized", "guest".

  externalIdentifiers
     A complex multi-valued attribute containing identifiers associated with this application. OPTIONAL
     The following sub-attributes are defined:

     type
        The type of identifier. Service providers MAY define canonical values.
        <!-- Todo: what kind? I'm thinking about the SSO URLs of that application in the IDP -->

     value
        The identifier string value.

     system
        The system or domain this identifier is valid within.

5.2.5.  Example

   Example Agentic Application:






Abbey & Cohen             Expires 19 April 2026                [Page 14]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


6.  Schema JSON Representations

   This section provides the complete JSON representation for the
   schemas defined in this extension.

6.1.  Agent Schema JSON

   The following is intended as an example of the SCIM schema
   representation in JSON format for SCIM resources.  Where permitted,
   individual values and schema MAY change.  This example includes
   schema representations for "Agent".

  {
    "id" : "urn:ietf:params:scim:schemas:core:2.0:Agent",
    "name" : "Agent",
    "description" : "An AI agent",
    "attributes" : [
      {
        "name" : "name",
        "type" : "string",
        "multiValued" : false,
        "description" : "Unique identifier for the Agent, typically used by the agent to directly authenticate to the service provider. Each Agent MUST include a non-empty name value.  This identifier MUST be unique across the service provider's entire set of Agents. REQUIRED.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "server"
      },
      {
        "name" : "agentType",
        "type" : "string",
        "multiValued" : false,
        "description" : "Used to classify like agents.  Typical values used might be
'Assistant', 'Reseacher', 'Chat bot', and
'Unknown', but any value may be used.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },
      {
        "name" : "active",
        "type" : "boolean",
        "multiValued" : false,
        "description" : "A Boolean value indicating the Agent's
administrative status.",
        "required" : false,



Abbey & Cohen             Expires 19 April 2026                [Page 15]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


        "mutability" : "readWrite",
        "returned" : "default"
      },
      {
        "name" : "groups",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of groups to which the user belongs,
either through direct membership, through nested groups, or
dynamically calculated.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The identifier of the User's group.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "User",
              "Group"
            ],
            "multiValued" : false,
            "description" : "The URI of the corresponding 'Group'
resource to which the user belongs.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",



Abbey & Cohen             Expires 19 April 2026                [Page 16]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the attribute's
function, e.g., 'direct' or 'indirect'.",
            "required" : false,
            "caseExact" : false,
            "canonicalValues" : [
              "direct",
              "indirect"
            ],
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          }
        ],
        "mutability" : "readOnly",
        "returned" : "default"
      },
      {
        "name" : "entitlements",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of entitlements for the User that
represent a thing the User has.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The value of an entitlement.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",



Abbey & Cohen             Expires 19 April 2026                [Page 17]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the attribute's
function.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "primary",
            "type" : "boolean",
            "multiValued" : false,
            "description" : "A Boolean value indicating the 'primary'
or preferred attribute value for this attribute.  The primary
attribute value 'true' MUST appear no more than once.",
            "required" : false,
            "mutability" : "readWrite",
            "returned" : "default"
          }
        ],
        "mutability" : "readWrite",
        "returned" : "default"
      },
      {
        "name" : "roles",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of roles for the User that
collectively represent who the User is, e.g., 'Student', 'Faculty'.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The value of a role.",
            "required" : false,
            "caseExact" : false,



Abbey & Cohen             Expires 19 April 2026                [Page 18]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the attribute's
function.",
            "required" : false,
            "caseExact" : false,
            "canonicalValues" : [],
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "primary",
            "type" : "boolean",
            "multiValued" : false,
            "description" : "A Boolean value indicating the 'primary'
or preferred attribute value for this attribute.  The primary
attribute value 'true' MUST appear no more than once.",
            "required" : false,
            "mutability" : "readWrite",
            "returned" : "default"
          }
        ],
        "mutability" : "readWrite",
        "returned" : "default"
      },
      {
        "name" : "x509Certificates",
        "type" : "complex",
        "multiValued" : true,



Abbey & Cohen             Expires 19 April 2026                [Page 19]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


        "description" : "A list of certificates issued to the User.",
        "required" : false,
        "caseExact" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "binary",
            "multiValued" : false,
            "description" : "The value of an X.509 certificate.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the attribute's
function.",
            "required" : false,
            "caseExact" : false,
            "canonicalValues" : [],
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "primary",
            "type" : "boolean",
            "multiValued" : false,
            "description" : "A Boolean value indicating the 'primary'
or preferred attribute value for this attribute.  The primary
attribute value 'true' MUST appear no more than once.",
            "required" : false,



Abbey & Cohen             Expires 19 April 2026                [Page 20]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "mutability" : "readWrite",
            "returned" : "default"
          }
        ],
        "mutability" : "readWrite",
        "returned" : "default"
      },
      {
        "name": "applications",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of applications to which the agent belongs.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The identifier of the Agent's application.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "AgenticApplication"
            ],
            "multiValued" : false,
            "description" : "The URI of the corresponding 'AgenticApplication'
resource to which the user belongs.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,



Abbey & Cohen             Expires 19 April 2026                [Page 21]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          }
        ],
        "mutability" : "readOnly",
        "returned" : "default"
      },
      {
         "name": "subject",
         "type" : "string",
         "multiValued" : false,
         "description" : "The subject to use for this agent in inbound tokens READ-ONLY.",
         "required" : false,
         "caseExact" : false,
         "mutability" : "readOnly",
         "returned" : "default",
         "uniqueness" : "none"
      },
      {
        "name": "owners",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of users or groups that are the accountable parties for the agent.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The identifier of the Agent's application.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "User",
              "Group"
            ],
            "multiValued" : false,
            "description" : "The URI of the corresponding 'User' or 'Group'",
            "required" : false,
            "caseExact" : false,



Abbey & Cohen             Expires 19 April 2026                [Page 22]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          }
        ],
        "mutability" : "readOnly",
        "returned" : "default"
      },
      {
         "name": "protocols",
         "type" : "complex",
         "multiValued" : true,
         "description" : "A list of protocols to communicate with the Agent.",
         "required" : false,
         "subAttributes" : [
             {
               "name" : "type",
               "type" : "string",
               "multiValued" : false,
               "description" : "One of the canonical protocol types.",
               "required" : false,
               "caseExact" : false,
               "mutability" : "readOnly",
               "returned" : "default",
               "uniqueness" : "none"
             },
             {
               "name" : "specifiationUrl",
               "type" : "string",
               "multiValued" : false,
               "description" : "URL of the specification for the protocol for this agent.",
               "required" : false,
               "caseExact" : false,
               "mutability" : "readOnly",
               "returned" : "default",
               "uniqueness" : "none"



Abbey & Cohen             Expires 19 April 2026                [Page 23]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


             }
           ],
           "mutability" : "readOnly",
           "returned" : "default"
      },
      {
        "name": "parent",
        "type" : "complex",
        "multiValued" : false,
        "description" : "Parent agent.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "The identifier of the parent Agent",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "Agent"
            ],
            "multiValued" : false,
            "description" : "The URI of the corresponding 'Agent'",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "display",
            "type" : "string",
            "multiValued" : false,
            "description" : "A human-readable name, primarily used
for display purposes.  READ-ONLY.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"



Abbey & Cohen             Expires 19 April 2026                [Page 24]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          }
        ],
        "mutability" : "readOnly",
        "returned" : "default"
      }
    ],
    "meta" : {
      "resourceType" : "Schema",
      "location" :
        "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:Agent"
    }
  }

6.2.  Agentic Application Schema JSON

7.  Security Considerations

   -> fill out

8.  IANA Considerations

   This document has no IANA actions.

9.  Change Log

   -01

   *  Macy finish up Agent schema description, JSON representation and
      schema

   *  Rafael contribution of agent app

   -00

   *  Initial draft extension.

10.  References

10.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>.







Abbey & Cohen             Expires 19 April 2026                [Page 25]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   [RFC7643]  Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
              Mortimore, "System for Cross-domain Identity Management:
              Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
              2015, <https://www.rfc-editor.org/rfc/rfc7643>.

   [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>.

10.2.  Informative References

   [ENTITLEMENTS]
              Zollner, D. and U. Vartak, "SCIM Roles and Entitlements
              Extension", n.d., <https://github.com/ietf-scim-wg/draft-
              ietf-scim-roles-entitlements/blob/main/draft-ietf-scim-
              roles-entitlements.md>.

   [RFC7642]  LI, K., Ed., Hunt, P., Khasnabish, B., Nadalin, A., and Z.
              Zeltsan, "System for Cross-domain Identity Management:
              Definitions, Overview, Concepts, and Requirements",
              RFC 7642, DOI 10.17487/RFC7642, September 2015,
              <https://www.rfc-editor.org/rfc/rfc7642>.

   [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
              and C. Mortimore, "System for Cross-domain Identity
              Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
              September 2015, <https://www.rfc-editor.org/rfc/rfc7644>.

Appendix A.  Acknowledgments

   We would like to thanks the authors of the SCIM Extension for
   Privileged Access Management (https://datatracker.ietf.org/doc/id/
   draft-grizzle-scim-pam-ext-01.txt) and Device Schema Extensions to
   the SCIM model (https://datatracker.ietf.org/doc/draft-ietf-scim-
   device-model/) which served as excellent guidance on how to document
   proposed extension to the SCIM protocol.

   Additionaly, we would like to thank all the contributors the emerging
   agent standards which inspired this extension, including:

   *  Agent communication protocol
      (https://agentcommunicationprotocol.dev/core-concepts/agent-
      discovery)

   *  Agent 2 Agent (https://a2a-protocol.org/latest/topics/agent-
      discovery/)





Abbey & Cohen             Expires 19 April 2026                [Page 26]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


   *  Agent name service (https://genai.owasp.org/resource/agent-name-
      service-ans-for-secure-al-agent-discovery-v1-0/)

   *  AGNTCY directory (https://docs.agntcy.org/dir/overview/)

Authors' Addresses

   Macy Abbey
   Okta
   Email: macy.abbey@gmail.com


   Rafael S. Cohen
   Okta
   Email: rafael.cohen@okta.com




































Abbey & Cohen             Expires 19 April 2026                [Page 27]


name: draft-zhao-nmop-network-management-agent
rev: 04
title: AI based Network Management Agent(NMA): Concepts and Architecture
time: 2026-02-27T05:51:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-31T05:51:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420428+00:00
abstract:
The evolution from Level 3 (assisted automation) to Level 4
   (autonomous self-optimization) in Autonomous Networks (AN) introduces
   requirements for Agentic capabilities, including intent-based
   reasoning, autonomous planning, and context-aware decision-making,
   which transcend the static, rule-based logic of traditional SDN
   Controllers.  This document defines the concept of the Network
   Management Agent (NMA), an AI-driven entity designed to embody these
   cognitive functions and bridge the gap between service intent and
   network operations.

   This document also specifies how the NMA utilizes the existing
   capabilities of SDN Controllers—such as topology management,
   telemetry, and enforcement—to achieve Autonomous L4 without
   duplicating policy control functions.  It further details the
   architectural integration modes and defines the interface
   requirements necessary for SDN Controllers to interoperate with NMAs.

full_text:
Network Management Operations                                    X. Zhao
Internet-Draft                                                     CAICT
Intended status: Informational                                   M. Wang
Expires: 31 August 2026                                     China Mobile
                                                                   B. Wu
                                                                  Huawei
                                                           D. Ceccarelli
                                                                   Cisco
                                                                H. Zheng
                                                                  Huawei
                                                                 J. Zhou
                                                                     ZTE
                                                        27 February 2026


   AI based Network Management Agent(NMA): Concepts and Architecture
              draft-zhao-nmop-network-management-agent-04

Abstract

   The evolution from Level 3 (assisted automation) to Level 4
   (autonomous self-optimization) in Autonomous Networks (AN) introduces
   requirements for Agentic capabilities, including intent-based
   reasoning, autonomous planning, and context-aware decision-making,
   which transcend the static, rule-based logic of traditional SDN
   Controllers.  This document defines the concept of the Network
   Management Agent (NMA), an AI-driven entity designed to embody these
   cognitive functions and bridge the gap between service intent and
   network operations.

   This document also specifies how the NMA utilizes the existing
   capabilities of SDN Controllers—such as topology management,
   telemetry, and enforcement—to achieve Autonomous L4 without
   duplicating policy control functions.  It further details the
   architectural integration modes and defines the interface
   requirements necessary for SDN Controllers to interoperate with NMAs.

Discussion Venues

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

   Discussion of this document takes place on the Network Management
   Operations Working Group mailing list (nmop@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/btrse/nmop/.

   Source for this draft and an issue tracker can be found at
   https://datatracker.ietf.org/doc/draft-zhao-nmop-network-management-
   agent/.



Zhao, et al.             Expires 31 August 2026                 [Page 1]

Internet-Draft      Network Management Agent Concept       February 2026


Status of This Memo

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

   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 20 April 2026.

Copyright Notice

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

   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.

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/.







Zhao, et al.             Expires 31 August 2026                 [Page 2]

Internet-Draft      Network Management Agent Concept       February 2026


   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 31 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Motivation: The Gap between AN L3 and L4  . . . . . . . .   4
   2.  NMA and SDN Controller: Roles and Collaboration . . . . . . .   4
     2.1.  Why NMA is Required for Autonomous L4 . . . . . . . . . .   5
     2.2.  Utilizing Existing SDN Controller Capabilities  . . . . .   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Acronyms and Abbreviations  . . . . . . . . . . . . . . .   6
     3.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Reference architecture of NMA and Deployment Modes  . . . . .   6
     4.1.  Intelligent Network Management and Control Framework Based
           on NMA  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Deployment modes of NMA . . . . . . . . . . . . . . . . .   9
     4.3.  Reference Functional Architecture of NMA  . . . . . . . .  12
       4.3.1.  Autonomous Logic Layer  . . . . . . . . . . . . . . .  13
       4.3.2.  Supporting Function Layer . . . . . . . . . . . . . .  14
     4.4.  Interface Requirements for NMA Integration  . . . . . . .  15
   5.  Operational Agent Example . . . . . . . . . . . . . . . . . .  18
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   8.  Appendix：Definition of L0~L5 levels in Autonomous Network . .  20
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23




Zhao, et al.             Expires 31 August 2026                 [Page 3]

Internet-Draft      Network Management Agent Concept       February 2026


1.  Introduction

1.1.  Motivation: The Gap between AN L3 and L4

   The Autonomous Networks (AN) framework [TMF-IG1230] defines a series
   of evolution stages from Level 0 (manual) to Level 5 (fully
   autonomous) as listed in Appendix I.  Current operator networks
   typically operate at Level 2 or 3, where automation is primarily
   policy-driven and reactive.  Achieving Level 4 (L4) requires evolving
   from static execution to dynamic assurance.

   The initial journey towards L4 could target pragmatic, high-value
   scenarios, such as automated Root Cause Analysis (RCA), SLA
   assurance, and service restoration.  These use cases allow operators
   to deploy AI for observability and recommendation, reducing manual
   toil while maintaining control.

   Traditional SDN Controllers excel at deterministic configuration and
   telemetry collection but lack the analytical depth required for these
   complex assurance tasks.  They execute instructions but cannot
   autonomously diagnose the 'why' behind a failure or predict SLA
   violations.  Introducing AI-driven logic is necessary to bridge this
   gap.  However, decoupled AI models are insufficient.  A new
   architectural entity—the Network Management Agent (NMA)—is needed to
   integrate AI-based reasoning with SDN control, starting with
   assurance use cases and gradually evolving towards full closed-loop
   autonomy.

   While the key issues after the introduction of AI in network
   management include:

   1.  The application architecture and deployment methods of AI in
       network management are still unclear, that is in what form AI can
       help network management?

   2.  The relationship between AI and the existing network controllers
       is not clear.

   3.  New interface capability requirements after AI is introduced are
       not clear either.

   Therefore, it is necessary to define the general architecture and
   application form of AI in network management.

2.  NMA and SDN Controller: Roles and Collaboration






Zhao, et al.             Expires 31 August 2026                 [Page 4]

Internet-Draft      Network Management Agent Concept       February 2026


2.1.  Why NMA is Required for Autonomous L4

   Achieving L4 autonomy requires a cognitive loop of Intent
   Interpretation, Perception Analysis, and Dynamic Decision-
   making—capabilities that extend beyond the native design of
   traditional SDN Controllers:

   *  *Intent Translation (The "Why")*: L4 moves beyond simple API
      commands to handling fuzzy, high-level operational intents.
      Unlike SDN Controllers, which require precise, low-level technical
      parameters (e.g., specific bandwidth values or queue IDs), the NMA
      acts as an Agentic Interpreter.  It automatically decomposes
      abstract goals (e.g., "Ensure optimal experience for VPN users")
      into concrete, verifiable technical specifications, handling the
      ambiguity and context that traditional controllers cannot resolve.

   *  *Perception & Contextual Analysis (The "Sense")*: L4 requires
      holistic observability not just raw data collection.  SDN
      Controllers excel at gathering telemetry but lack the ability to
      fuse multi-dimensional data (metrics, logs, traces, alarms) to
      understand the "state of the network" in a service context.  The
      NMA combines its own knowledge base and memory, using AI models to
      perform Root Cause Analysis (RCA), detect anomalies, and correlate
      events across the network to build a comprehensive operational
      picture.

   *  *Autonomous Decision & Policy Synthesis (The "Think")*: L4 demands
      the ability to make non-deterministic decisions in response to
      unforeseen scenarios.  Traditional controllers operate on
      deterministic, reactive logic (e.g., "If X, then Y"), which cannot
      handle novel failures or complex optimization trade-offs.  The NMA
      embodies the Decision function, utilizing reasoning capabilities
      to synthesize new strategies, weigh potential outcomes, and decide
      on the optimal course of action when standard procedures do not
      apply, and can be iteratively optimized itself.

   Therefore, the NMA serves as the Autonomous Brain (Cognitive Layer)
   that defines what needs to happen and why, orchestrating the SDN
   Controllers, which act as the Execution function (Control Layer) that
   handle how to enforce those decisions on the network infrastructure.

2.2.  Utilizing Existing SDN Controller Capabilities

   To realize Autonomous L4, the NMA leverages the mature, stable
   functions already present in SDN Controllers rather than reinventing
   them.  NMA is compatible with the YANG-based automation framework
   described in [RFC8969], and utilizes the Controller as its primary
   execution engine:



Zhao, et al.             Expires 31 August 2026                 [Page 5]

Internet-Draft      Network Management Agent Concept       February 2026


   *  *Model-Based Abstraction*: The NMA interacts with the Controller
      through standard YANG Service and Network Models, bridging the gap
      between high-level intent and concrete network resources.

   *  *Telemetry & State Access*: The NMA consumes real-time operational
      data and topology information provided by the Controller to
      maintain an accurate perception of the network state.

   *  *Policy Enforcement*: The NMA invokes the Controller's
      configuration interfaces to apply changes, relying on the
      Controller's built-in validation and transaction capabilities to
      ensure stability.

   By integrating AI reasoning with this standards-based automation
   foundation, the NMA elevates the network from L3 (Automated Control)
   to L4 (Autonomous Management).

3.  Terminology

3.1.  Acronyms and Abbreviations

   AI: Artificial Intelligence

   LLM: Large Language Model

   NMA: Network Management Agent, refers to AI based network management
   agent

3.2.  Definitions

   The document defines the following terms:

   *Network Management Agent (NMA):*  A network management entity built
      based on ML/AI and equipped with the autonomous task processing
      capabilities.  It can automatically carry out network status
      perception, task intent [RFC9315]interpretation, task planning,
      decision-making and task execution operations based on user task
      intentions or preset goals, so as to achieve closed-loop
      processing of scenarios-oriented network management tasks.  For
      different application scenarios, NMA can be subdivided into
      multiple scenario-oriented agents.

4.  Reference architecture of NMA and Deployment Modes








Zhao, et al.             Expires 31 August 2026                 [Page 6]

Internet-Draft      Network Management Agent Concept       February 2026


4.1.  Intelligent Network Management and Control Framework Based on NMA

   [RFC8969] proposed the framework for automating service and network
   management with YANG.  Building on the architecture proposed in
   [RFC8969], higher-level intelligent network management and control
   can be achieved by adding NMA components.  Based on the Figure 3 of
   [RFC8969], the layered architecture of intelligent network management
   and control after the introduction of NMA is shown in the following
   figure.  NMA can exist at both the Controller and Orchestrator
   levels; for the device layer, due to the constraints on the computing
   power of network elements, some end-side AI components may be added
   on the device side, while it is unlikely to deploy a complete NMA.







































Zhao, et al.             Expires 31 August 2026                 [Page 7]

Internet-Draft      Network Management Agent Concept       February 2026


                                            Hierachy NMA interaction
    +-------------------------------+
    |         Orchestrator          |
    | +---------------------------+ |                 +-----------+
    | | Network Management Agents | |               +-|---------+ |
    | |          (NMAs)           | |             +-|---------+ |-+
    | +---------------------------+ |             |    NMAs   |-+
    | +---------------------------+ |             +-----^-----+
    | |     Service Modeling      | |                   |
    | +---------------------------+ |                   |
    | +---------------------------+ |                   |   Inter-layer
    | |   Service Orchestration   | |                   | A2A communication
    | +---------------------------+ |                   |
    +-------------------------------+                   |
--------------------------------------------------------+--------
    +-------------------------------+                   |
    |           Controller          |                   |
    | +---------------------------+ |                 +-v---------+
    | | Network Management Agents | |               +-|---------+ |
    | |          (NMAs)           | |             +-|---------+ |-+
    | +---------------------------+ |             |    NMAs   |-+
    | +---------------------------+ |             +-----------+
    | |     Network Modeling      | |
    | +---------------------------+ |       NMA1<---------------->NMA2
    | +---------------------------+ |              Intra-layer
    | |   Network Orchestration   | |           A2A communication
    | +---------------------------+ |
    +-------------------------------+
-----------------------------------------------------------------
    +-------------------------------+
    |             Device            |
    | +---------------------------+ |
    | |        End-side AI        | |
    | +---------------------------+ |
    | +---------------------------+ |
    | |      Device Modeling      | |
    | +---------------------------+ |
    +-------------------------------+



    Figure 1: Enhanced intelligent network management and control
                        framework based on NMA








Zhao, et al.             Expires 31 August 2026                 [Page 8]

Internet-Draft      Network Management Agent Concept       February 2026


   Among them, there may be interaction requirements between NMAs at
   different layers and between different NMAs at the same layer.
   Cross-layer NMAs interact through inter-layer Agent-to-Agent (A2A)
   communication, while different NMAs within the same layer interact
   through intra-layer A2A communication.

   This document can be regarded as an enhancement of the intelligent
   capabilities of [RFC8969], and subsequent discussions will mainly
   focus on the NMAs at the controller layer.

4.2.  Deployment modes of NMA

   It should be noted that although NMA is depicted inside the
   controller in Figure 1, in practice, NMA can also be deployed as an
   independent component outside the controller.  This document does not
   impose mandatory restrictions on the deployment location of NMA.  The
   two deployment modes can be called: Independent deployment mode and
   Integrated deployment mode and are shown in Figure-2, where the NMA
   can be part of an existing network controller, or can be an
   independent system deployed separately and interacting both with the
   controller and the network.






























Zhao, et al.             Expires 31 August 2026                 [Page 9]

Internet-Draft      Network Management Agent Concept       February 2026


                                   ^
                                   |
                       Extended NBI(including A2U)
                                   |
     +-----------------------------v------------------------------+
     |                     Network Controller                     |
     |                                                            |
     |  +--------------------+           +--------------------+   |
     |  | Original Function  <----A2C----> Network management |   |
     |  |      Modules       | Interface |      Agent(NMA)    |   |
     |  +--------------------+           +--------------------+   |
     |                                                            |
     +------------------------------^-----------------------------+
                                    |
                   Extended SBI(including A2N interface)
                                    |
     +------------------------------v-----------------------------+
     |                       Physical Network                     |
     +------------------------------------------------------------+
                           (a) Integrated Mode


                    ^                                   ^
                    |                                   |
         Northbound Interface(NBI)        Agent-to-User Interface(A2U)
                    |                                   |
     +--------------v------------+           +----------v---------+
     |                           |           |                    |
     |          Network          <----A2C----> Network Management |
     |        Controller         | Interface |    Agent(NMA)      |
     |                           |           |                    |
     +--------------^------------+           +----------^---------+
                    |                                   |
         Southbound Interface(SBI)     Agent-to-Network Interface(A2N)
                    |                                   |
     +--------------v-----------------------------------v---------+
     |                        Physical Network                    |
     +------------------------------------------------------------+
                           (b) Independent Mode

        Figure 2: Deployment mode of network management agent (NMA)

   *Integrated deployment mode:*  As shown in Figure-2 (a), NMA is
      integrated and deployed with the original network controller, and
      the NMA serves as a function of the controller.  NMA interacts
      with original function modules through internal A2C interface.
      The enhanced controller interacts with the underlay physical
      network through extended SBI satisfying the A2N interaction



Zhao, et al.             Expires 31 August 2026                [Page 10]

Internet-Draft      Network Management Agent Concept       February 2026


      requirements.  The specific functional requirements and
      information model definition of interfaces mentioned above will be
      discussed in Section 4.4.

      Integrated mode is targeted at network scenarios with single-
      vendor SDN infrastructure and high requirements for service real-
      time performance.  This mode features deep coupling between the
      NMA and the SDN Controller, low decision-making and execution
      latency, and simple deployment and operation & maintenance (O&M),
      making it suitable for autonomous network management in single-
      vendor domains.  At the same time, since it is extended on the
      basis of an existing SDN controller, the changes and impacts on
      the live network are also smaller, which facilitates the
      application and evolution of NMA in the live network.

   *Independent deployment mode:*  As shown in Figure 2 (b), NMA is
      independently deployed from the original network controller.  NMA
      and controller are independent systems.  A new east-west interface
      needs to be added between the NMA and the controller to achieve
      capability calling and result feedback operations.  This interface
      can be called “Agent-to-Controller Interface”(A2C).  In this
      deployment mode, controller uses southbound interface (SBI) to
      interact with physical network, while an Agent-to-Network
      interface (abbreviated as “A2N”) needs to be added between NMA and
      the underlying physical network.

      Independent mode is applicable to multi-domain, multi-vendor
      heterogeneous network environments.  Boasting high flexibility and
      scalability, this mode enables the NMA to act as a centralized
      cognitive brain that orchestrates multiple SDN Controllers to
      achieve closed-loop execution of end-to-end service intents.

   While the independent deployment mode brings significant flexibility
   to the management of large-scale and complex networks, its decoupled
   architecture between the NMA and SDN Controllers introduces a series
   of potential issues in practical deployment, including management and
   O & M conflicts between the two entities, which are mainly reflected
   in the following aspects:

   *Configuration and policy conflicts:*  Concurrent delivery of
      configurations to network devices by the NMA and the Controller
      may result in configuration conflicts on the devices.  In
      addition, the NMA generates dynamic control policies based on AI-
      driven intent reasoning and real-time network context analysis,
      whereas SDN Controllers maintain pre-configured static rule sets
      and traditional deterministic automation policies.
      Inconsistencies between these two types of policies may lead to
      policy execution failures and even service interruptions.



Zhao, et al.             Expires 31 August 2026                [Page 11]

Internet-Draft      Network Management Agent Concept       February 2026


   *Inconsistent network state synchronization:*  The autonomous
      decision-making of the NMA relies on real-time and accurate
      network state data (telemetry, alarms, topology) provided by SDN
      Controllers.  In the independent mode, network transmission
      latency and data processing delays between the NMA and Controllers
      may compromise the accuracy of the NMA's decision-making.

   This document does not mandate a specific deployment mode for the
   NMA.  When the independent deployment mode is adopted, it is advised
   to follow the principle of separation of cognitive decision-making
   and execution enforcement: the NMA is responsible for intent
   interpretation, context analysis and autonomous decision-making,
   while SDN Controllers retain the authorities of policy validation,
   resource enforcement and network state management.  This ensures the
   consistency and effectiveness of the collaborative operation between
   the NMA and SDN Controllers.

4.3.  Reference Functional Architecture of NMA

   In order to achieve above capabilities, by referring to the common AI
   agent framework, this document presents the reference functional
   architecture of NMA as shown in Figure 3.

+---------------------------------------------------------------------------+
|                         NMA(Network Management Agent)                     |
|                                                                           |
|            +-----------------------------------------------------------+  |
| Autonomous |                      Intent Management                    |  |
|   Logic    +-----------------------------------------------------------+  |
|   Layer    +------------+  +------------+  +-----------+  +------------+  |
|            |  Awareness |  |  Analysis  |  |  Decision |  | Execution  |  |
|            +------------+  +------------+  +-----------+  +------------+  |
|---------------------------------------------------------------------------|
|                                                                           |
| Supporting +-----------------+  +=================+  +-----------------+  |
|  Function  |     Memory&     |  |     AI Model    |  | Tool & Function |  |
|   Layer    |  Knowledge Base |  |     Service     |  |     Manager     |  |
|            +-----------------+  +=================+  +-----------------+  |
|                                                                           |
+---------------------------------------------------------------------------+



           Figure 3: Reference function architecture of NMA







Zhao, et al.             Expires 31 August 2026                [Page 12]

Internet-Draft      Network Management Agent Concept       February 2026


   The NMA is structured into two primary layers: the Autonomous Logic
   Layer, which embodies the autonomous closed-loop from intention to
   perception, analysis, decision-making, and execution, and the
   Supporting Function Layer, which provides foundational capabilities
   to enable autonomous operations.

4.3.1.  Autonomous Logic Layer

   This layer embodies the intelligent loop of L4 autonomy, translating
   service goals into network actions.  It mainly includes the following
   logical functional modules which are fully consistent with the IAADE-
   closed loop of autonomous network defined in TMF (see detailed in
   Section 8):

   *Intent Management:*  This module serves as the entry point for
      Intent.  It is responsible for receiving high-level goals from
      users or orchestration systems, interpreting natural language or
      policy objectives, and normalizing them into structured,
      verifiable intents that the agent can pursue.  It ensures that the
      autonomous operations remain aligned with service KPIs.  After
      interpreting the target intent and reasoning through the necessary
      steps to achieve it, this module can orchestrate the sequence of
      operations required to progress toward that goal.  It breaks down
      complex objectives into a sequence of executable sub-tasks (e.g.,
      awareness -> analysis -> decision -> execution) and handles
      dynamic planning under uncertainty, ensuring that the chosen
      course of action aligns with the desired intent.

   *Awareness:*  This module acts as the intent-driven selective sensing
      hub of the NMA, responsible for orchestrating the targeted query
      and perception of task-relevant network data.  It proactively
      initiates data acquisition operations across heterogeneous sources
      such as controllers, physical/virtual network devices, etc., with
      a core focus on filtering out irrelevant information to collect
      only the network data pertinent to the current intent.  Covering
      critical dimensions including device operational status, link
      performance metrics, service traffic statistics, and configuration
      parameters, this module lays a precise foundational data base for
      the subsequent analysis, decision-making, and execution processes.

   *Analysis:*  This module serves as the intelligent analytics core,
      leveraging the reasoning capabilities of the AI Model Service in
      the Supporting Function Layer.  It orchestrates advanced
      analytical tasks tailored to the specific task intent, including
      anomaly detection, root cause analysis (RCA), event correlation,
      and impact quantification, etc.  By combining real-time perceived
      data with historical insights retrieved from the Memory&Knowledge
      Base, it transforms raw data into actionable, context-rich network



Zhao, et al.             Expires 31 August 2026                [Page 13]

Internet-Draft      Network Management Agent Concept       February 2026


      insights and diagnostic conclusions.  It can clearly identify the
      root causes of network issues, evaluates the impact of abnormal
      states on service objectives, and outputs structured analytical
      results that directly guide the strategic decision-making.

   *Decision:*  This module functions as the strategic decision-making
      core of the NMA, responsible for formulating optimal and feasible
      operation strategies based on the analytical insights from the
      Analysis Management module and the constraints of the original
      user intent.  It employs AI reasoning capabilities and draws on
      the Memory&Knowledge Base to evaluate multiple potential action
      paths, selecting the strategy that best aligns with service-level
      objectives and network operation rules.  It decomposes complex
      strategic decisions into a hierarchical, ordered sequence of
      executable sub-tasks, defines clear trigger conditions and task
      dependencies for each step, and maps these sub-tasks to specific
      tools or functions managed by the Tool&Function Manager.  This
      process ensures that the generated decisions are not only
      logically sound but also fully operationalized for subsequent
      execution.

   *Execution:*  This module acts as the intent-closed-loop operational
      execution core, tasked with translating the structured sub-tasks
      from the Decision Management module into concrete, reliable
      network operations.  It orchestrates the invocation of appropriate
      network interfaces, management tools, and operational functions
      via the Tool&Function Manager, executing tasks such as
      configuration adjustment, fault remediation, resource scheduling,
      and service provisioning in a sequential and controlled manner.
      It real-time monitors the execution status of each sub-task,
      handles execution exceptions and retries according to pre-defined
      rules, and conducts rigorous result validation against the
      original user intent and decision criteria.  Finally, it feeds
      back the execution outcomes, status, and validation results to the
      Memory&Knowledge Base and upper-layer modules, forming a complete
      closed-loop of autonomous network management driven by intent.

   NMA enables the cognitive capabilities on task lifecycle management
   procedure described in [RFC8969].

4.3.2.  Supporting Function Layer

   This layer provides the foundational capabilities and resources
   necessary for the Autonomous logic Layer to function effectively.

   *Memory & Knowledge Base:*  This module serves as the long-term and





Zhao, et al.             Expires 31 August 2026                [Page 14]

Internet-Draft      Network Management Agent Concept       February 2026


      short-term memory of the NMA, storing historical operational data,
      network topology snapshots, and a comprehensive repository of
      expert knowledge including technical documents, troubleshooting
      guidelines, and past incident resolution cases, etc.  It provides
      unified search capabilities across multi-type knowledge sources
      such as vector knowledge bases, system online help documentation,
      and operation and maintenance data logs.  Based on accurate
      domain-specific information, this module improves the accuracy and
      reliability of NMA’s reasoning and decision-making, enables the
      agent to reuse historical experience and expert logic, and ensures
      the consistency and effectiveness of autonomous operations.

   *AI Model Service:*  This module acts as the cognitive engine of the
      NMA, providing unified upward exposure of diversified AI
      capabilities.  It supports not only Large Language Models (LLM)
      and other generative AI models, but also classic AI algorithms and
      lightweight dedicated models, enabling natural language
      understanding, logical inference, time-series analysis and other
      intelligent capabilities.  It supplies the comprehensive general
      and domain-specific intelligence required to drive the core
      processes of intent management, perception and analysis, reasoning
      and planning, and decision and execution.

      It should be noted that the AI Model Service is not limited to
      being deployed inside the NMA; it can also be located outside the
      NMA, and the NMA can invoke AI model capabilities in real time to
      complete relevant reasoning operations.

   *Tool & Function Manager:*  This module serves as the Gateway to
      Reality.  It manages the connection between the NMA and external
      systems, primarily the SDN Controllers via the A2C (Agent-to-
      Controller) interface.  It abstracts network functions (e.g.,
      configuration, telemetry, simulation, etc.) as invocable "Tools."
      This module ensures that the decisions made by the upper layer are
      translated into concrete, standard-compliant network operations
      (e.g., YANG data manipulation).

4.4.  Interface Requirements for NMA Integration

   As shown in Figure 2, the interfaces related to NMA include three
   types:

   1.  *Agent-to-User interface (A2U):*the interface between the NMA and
       the user, where the user can be upper-layer NMA, controllers or
       orchestrators.  This interface is used to receive call requests
       from users and return task processing results.  It should support
       both structured and natural language modes.  The natural language
       interface is mainly used for interaction with humans, while the



Zhao, et al.             Expires 31 August 2026                [Page 15]

Internet-Draft      Network Management Agent Concept       February 2026


       structured interface is used for interaction with other upper-
       layer systems or other Agents.  The Agent-to-Agent (A2A)
       interface between NMAs is included in the scope of this
       interface.  In the independent mode, this interface is a separate
       one provided by the NMA to the outside; in the integrated mode,
       it is included in the northbound interface of the controller.

       Since this interface bridges the NMA with human operators or
       higher-level orchestrators.  It must support dual-mode
       interaction:

       *Natural Language Interaction:*  For human operators, the
          interface must support conversational inputs (e.g., text) and
          return structured responses or execution confirmations.

       *Structured Intent Interface:*  For upper-layer orchestrators or
          peer agents, the interface must support structured intent
          definitions (e.g., based on YANG models or JSON/GNMI).  It
          requires:

          * Intent Submission: Accepting high-level goals with
          constraints (e.g., latency, cost).

          * Status Reporting: Providing real-time feedback on intent
          fulfillment progress, including intermediate states (e.g.,
          "Analyzing", "Planning", "Executing").

   2.  *Agent-to-Controller interface (A2C):* the interface between NMA
       and the controller or the original functional components of the
       controller.  In the independent mode, this interface is an east-
       west interface between the controller and NMA; in the integrated
       mode, this interface is an internal interface of the controller
       and is not within the scope of this document.

   3.  *Agent-to-Network (A2N):*the interface between NMA and the
       physical network.  In the independent mode, this interface is a
       southbound interface between the Agent and the network; in the
       integrated mode, it is included in the original southbound
       interface of the controller.

   To elaborate in more detail, when NMAs are deployed in integration
   with the controller, as shown in Figure 4, the related interface to
   be extended includes:

   1.  *Extended SBI of the controller:* The southbound interface
       between the controller and devices, including the aforementioned
       A2N interface function.  Theoretically, NMAs will not directly
       configure or operate devices; instead, they will call the



Zhao, et al.             Expires 31 August 2026                [Page 16]

Internet-Draft      Network Management Agent Concept       February 2026


       original functional modules of the controller for device-related
       configuration and management.  Therefore, the need for standard
       extension of this interface is minimal, and it is not within the
       scope of this draft.

   2.  *Extended NBI:* The northbound interface of the controller.  As a
       key interface for collaboration between upper and lower layer
       systems, this interface needs to realize functions such as
       capability discovery and invocation between upper and lower layer
       NMAs.  Hence, there is a strong demand for its standardization,
       and it is necessary to consider the extension of the northbound
       interface of the controller oriented to the communication needs
       between NMAs.  NBI must be augmented to expose the NMA's
       cognitive capabilities as Intent-Based RPCs.  Unlike standard
       configuration RPCs that set specific parameters (e.g., set-
       bandwidth), these Intent-Based RPCs accept high-level operational
       goals (e.g., optimize-performance or diagnose-incident).  This
       distinction allows upper-layer systems to invoke autonomous
       behaviors that require reasoning and planning—capabilities that
       native controller interfaces lack.

       In terms of communication channels, the orchestrator and the
       controller communicate one-to-one through the northbound
       interface.  When there is a need for direct communication between
       NMAs in the upper-layer orchestrator and those in the lower-layer
       controller (A2A Communication), it will manifest as a single
       communication channel physically but multiple communication
       processes logically (i,e.including multiple A2A communication
       processes).

       To sum up, entended NBI should handle logical multi-process
       multiplexing.  Current protocols typically handle a single
       request-response session.The extended NBI must support multiple
       independent A2A communication processes over a single physical
       channel.  It must maintain strict context isolation between
       different agent tasks (e.g., one diagnosing a fault, another
       optimizing QoS) to prevent state interference—a requirement not
       addressed in standard HTTP/RPC models.

   Besides, there are several internal interfaces within the controller,
   which include the interaction interfaces between NMAs within the
   controller and the original functional modules of the controller, as
   well as the interaction interfaces between multiple NMAs within the
   controller.  Since all the above are internal implementations of the
   controller, there is no need for standardization.

   The specific implementation methods, related protocols, etc. of each
   interface are to be defined subsequently in other documents.



Zhao, et al.             Expires 31 August 2026                [Page 17]

Internet-Draft      Network Management Agent Concept       February 2026


     +-------------------------------------------+
     |              Orchestrator                 |
     | +-----------+ +-----------+ +-----------+ |
     | |    NMA1   | |    NMA2   | |   NMA3    | |          ^
     | +-----^-----+ +-----------+ +-----^-----+ |          |
     +-------:-------------^-------------:-------+          |
             :             |             :                  |
             : Logical     | Extended    : Logical          | Extended
             :   A2A       |   NBI       :   A2A            |   NBI
             :             |             :                  |
     +-------:-------------v-------------:------------------^---+
     |       :               Controller  :                      |
     |       :                           :       +------------+ |
     | +-----v-----+ +-----------+ +-----v-----+ |  Original  | |
     | |   NMA1    | |    NMA2   | |    NMA3   | |  function  | |
     | +-----------+ +-----------+ +-----------+ |   modules  | |
     |                                           +------------+ |
     +----------------------------^-----------------------------+
                                  |
                                  | Extented SBI
                                  |
     +----------------------------v-----------------------------+
     |                        Physical Network                  |
     +----------------------------------------------------------+

           Figure 4: Interfaces to be extended on the controller

5.  Operational Agent Example

   To address specific operational needs, the NMA architecture supports
   multiple specialized agents.  These agents function as modular
   entities, with the Intelligent Assistant Agent serving as the primary
   entry point for interaction, followed by specialized agents such as
   Fault management Agent and Optimization Agent:

   *  *Intelligent Assistant Agent*: Serving as the primary interface
      for human operators, this agent leverages LLMs to provide natural
      language Q&A and conversational capabilities.  It enables users to
      perform "one-click" queries for fault descriptions or resource
      status.  By automatically translating human intent into precise
      data retrieval commands, it significantly enhances the efficiency
      of knowledge retrieval and daily maintenance support.

   *  *Network Fault Management Agent*: Focused on service assurance,
      this agent leverages comprehensive troubleshooting guides and
      expert knowledge bases to support intelligent fault handling.  It
      implements automated root cause analysis (RCA) and fault impact
      analysis.  In addition to fault diagnosis, it orchestrates control



Zhao, et al.             Expires 31 August 2026                [Page 18]

Internet-Draft      Network Management Agent Concept       February 2026


      plane APIs to execute self-healing operations, and integrates with
      external work order systems to achieve closed-loop incident
      resolution.or self-healing actions and integrates with external
      work order systems to enable closed-loop incident resolution.

   *  *Network Optimization Agent*: Focused on performance and
      efficiency, this agent translates high-level optimization goals
      into technical constraints, such as load thresholds or routing
      policies.  Leveraging traffic prediction models, it anticipates
      network congestion and proactively generates strategies for
      traffic engineering (e.g., pre-diversion) and dynamic energy
      saving.  It operates in a closed-loop manner to autonomously
      execute decisions that maintain optimal network performance.

6.  Security Considerations

   Since networks are critical infrastructure, misoperations can have a
   significant impact on them.  Therefore, NMAs shall meet the following
   security and reliability requirements:

   1.  Support multi-factor authentication mechanism for sensitive
       operations.  For operations involving network configuration
       changes or those that pose significant risks to network operation
       security, a manual confirmation mechanism must be introduced, and
       multiple authentication methods such as passwords and dynamic
       tokens shall be used to ensure operation security.

   2.  Support circuit breaker mechanism.  When abnormal results occur
       during the execution of an NMA task, it shall provide error
       prompts and transfer the task directly to manual control for
       handling.

   3.  Support rollback mechanism.  After the execution of an NMA task
       is completed, it shall support operation rollback to restore the
       network configuration.

   4.  Support data security and privacy protection mechanism.  It shall
       support the encryption of sensitive data such as network
       configurations and user behavior logs; support user permission
       division, and set differentiated data access permissions for
       different users.

   5.  Support operation permission control mechanism.  For different
       application scenarios, the minimum permissions required to
       perform tasks in the scenario shall be set.  For example, a fault
       handling NMA may query data such as topology resources and
       performance, but shall not have permission to perform service
       configuration operations.



Zhao, et al.             Expires 31 August 2026                [Page 19]

Internet-Draft      Network Management Agent Concept       February 2026


7.  IANA Considerations

   This document has no requests for IANA action.

8.  Appendix：Definition of L0~L5 levels in Autonomous Network

   Table 1 summarizes the Autonomous Network (AN) levels defined in TM
   Forum IG1230 [TMF-IG1230].  It illustrates that current IETF
   automation frameworks, such as [RFC8969], primarily enable Level 3
   (Partial Autonomy) by utilizing data models (YANG) to enforce pre-
   defined policies.








































Zhao, et al.             Expires 31 August 2026                [Page 20]

Internet-Draft      Network Management Agent Concept       February 2026


   +=====+===============+=================+==========================+
   |LEVEL|NAME           |DESCRIPTION (CORE| HUMAN VS.  MACHINE ROLE  |
   |     |               |CHARACTERISTICS) |                          |
   +=====+===============+=================+==========================+
   |L0   |Manual         |Fully manual     | Human does everytding.   |
   |     |               |processes.  No   |                          |
   |     |               |automation.      |                          |
   +-----+---------------+-----------------+--------------------------+
   |L1   |Assisted       |System provides  | Human makes all          |
   |     |               |tools            | decisions; tools assist. |
   |     |               |(dashboards,     |                          |
   |     |               |alarms).         |                          |
   +-----+---------------+-----------------+--------------------------+
   |L2   |System-assisted|Automation of    | Human initiates tasks;   |
   |     |               |single tasks/    | system executes.         |
   |     |               |scripts witdin a |                          |
   |     |               |specific domain. |                          |
   +-----+---------------+-----------------+--------------------------+
   |L3   |Partial        |Closed-loop      | "Human-in-the-Loop":     |
   |     |Autonomy       |automation based | Humans define rules/     |
   |     |               |on pre-defined   | models and monitor;      |
   |     |               |policies/models  | system executes and      |
   |     |               |witdin a domain. | reports exceptions.      |
   +-----+---------------+-----------------+--------------------------+
   |L4   |High Autonomy  |Cross-domain/    | "Human-on-the-Loop":     |
   |     |               |cross-layer      | Humans define high-level |
   |     |               |context analysis | intents; system self-    |
   |     |               |and closed-loop  | configures and heals.    |
   |     |               |optimization     | Human only intervenes on |
   |     |               |based on Intents.| system failure.          |
   +-----+---------------+-----------------+--------------------------+
   |L5   |Full Autonomy  |Self-evolving,   | "Human-out-of-the-Loop": |
   |     |               |self-optimizing, | System requires no human |
   |     |               |fully driverless | intervention for         |
   |     |               |operations.      | business goals.          |
   +-----+---------------+-----------------+--------------------------+

                Table 1: Autonomous Network Levels (L0-L5)

   Figure 5 depicts the ‘Intent-Awareness-Analysis-Decision-Execution
   (IAADE)’ control loop AN architecture, highlighting the evolution
   from the rule-based automation of Level 3 to the intent-driven, AI-
   powered autonomy of Level 4, which is the focus of this document.
   Network Management Agent can serve as an augmentation layer,
   enhancing network management automation and orchestration
   capabilities through natural language intent translation, cross-
   vendor semantic bridging, and knowledge codification.  In this
   context, Agents focus on decision support and workflow orchestration,



Zhao, et al.             Expires 31 August 2026                [Page 21]

Internet-Draft      Network Management Agent Concept       February 2026


   while critical configuration changes continue to follow manual
   approval and transactional execution mechanisms via existing
   deterministic protocols (e.g., NETCONF), striking a balance between
   automation efficiency and operational certainty.

    +----------+
    |  INTENT  |
    |  (Goal)  |
    +----------+
          |
          | "What to achieve"
          v
  +-------------+    +------------+    +------------+    +-------------+
  |    AWARE    |    |   ANALYZE  |    |   DECIDE   |    |   EXECUTE   |
  |             | -> |            | -> |            | -> |             |
  | (Awareness) |    | (Analysis) |    | (Decision) |    | (Execution) |
  +------+------+    +------+-----+    +------+-----+    +------+------+
         |                  |                 |                 |
         +------------------+-----------------+-----------------+
                                    |
                                    v
                             +--------------+
                             |   NETWORK    |
                             +--------------+

         Figure 5: IAADE Control Loop for Autonomous Networks

9.  References

9.1.  Normative References

9.2.  Informative References

   [I-D.irtf-nmrg-ai-challenges]
              François, J., Clemm, A., Papadimitriou, D., Fernandes, S.,
              and S. Schneider, "Research Challenges in Coupling
              Artificial Intelligence and Network Management", Work in
              Progress, Internet-Draft, draft-irtf-nmrg-ai-challenges-
              03, 4 March 2024, <https://datatracker.ietf.org/doc/html/
              draft-irtf-nmrg-ai-challenges-03>.

   [I-D.kdj-nmrg-ibn-usecases]
              Yao, K., Chen, D., Jeong, J., Wu, Q., Yang, C., and L.
              Contreras, "Use Cases and Practices for Intent-Based
              Networking", Work in Progress, Internet-Draft, draft-kdj-
              nmrg-ibn-usecases-01, 8 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-kdj-nmrg-ibn-
              usecases-01>.



Zhao, et al.             Expires 31 August 2026                [Page 22]

Internet-Draft      Network Management Agent Concept       February 2026


   [LLM-powered-autonomous-agents]
              Weng, L., "LLM Powered Autonomous Agents", 23 June 2023.

   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking: Definitions and Design Goals", RFC 7575,
              DOI 10.17487/RFC7575, June 2015,
              <https://www.rfc-editor.org/rfc/rfc7575>.

   [RFC7576]  Jiang, S., Carpenter, B., and M. Behringer, "General Gap
              Analysis for Autonomic Networking", RFC 7576,
              DOI 10.17487/RFC7576, June 2015,
              <https://www.rfc-editor.org/rfc/rfc7576>.

   [RFC8969]  Wu, Q., Boucadair, M., Lopez, D., Xie, C., and L. Geng, "A
              Framework for Automating Service and Network Management
              with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021,
              <https://www.rfc-editor.org/rfc/rfc8969>.

   [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
              Tantsura, "Intent-Based Networking - Concepts and
              Definitions", RFC 9315, DOI 10.17487/RFC9315, October
              2022, <https://www.rfc-editor.org/rfc/rfc9315>.

   [TMF-AN-journey-guide]
              Tansuthepverawongse, Boonchoung., "AN Journey Guide
              Autonomous Networks L4 industry blueprint-high-value
              scenarios", June 2024.

   [TMF-IG1230]
              McDonnell, K., Machwe, A., Milham, D., O’Sullivan, J.,
              Clemm, A., and J. Niemöller, "Autonomous Networks
              Technical Architecture", TMF IG1230, December 2022.

Authors' Addresses

   Xing Zhao
   CAICT
   Beijing
   China
   Email: zhaoxing@caict.ac.cn


   Minxue Wang
   China Mobile
   Beijing
   China
   Email: wangminxue@chinamobile.com



Zhao, et al.             Expires 31 August 2026                [Page 23]

Internet-Draft      Network Management Agent Concept       February 2026


   Bo Wu
   Huawei
   China
   Email: lana.wubo@huawei.com


   Daniele Ceccarelli
   Cisco
   Email: dceccare@cisco.com


   Haomian Zheng
   Huawei
   China
   Email: zhenghaomian@huawei.com


   Jin Zhou
   ZTE
   China
   Email: zhou.jin6@zte.com.cn






























Zhao, et al.             Expires 31 August 2026                [Page 24]


name: draft-yao-agent-auth-considerations
rev: 01
title: Further considerations on AI Agent Authentication and Authorization Based on OAuth Extension
time: 2025-10-20T09:32:44Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T09:32:44Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420431+00:00
abstract:
Agent Communication Network(ACN) is becoming a promising and
   fundamental infrastructure for most vertical industries.  To
   construct and build a scalable and trustable ACN, authentication and
   authorization of AI agents are critical requirements.  This document
   extends the model of OAuth and proposes new workflows for AI agent
   authentication and authorization.

full_text:
Network Working Group                                             K. Yao
Internet-Draft                                              China Mobile
Intended status: Informational                           20 October 2025
Expires: 23 April 2026


  Further considerations on AI Agent Authentication and Authorization
                        Based on OAuth Extension
                 draft-yao-agent-auth-considerations-01

Abstract

   Agent Communication Network(ACN) is becoming a promising and
   fundamental infrastructure for most vertical industries.  To
   construct and build a scalable and trustable ACN, authentication and
   authorization of AI agents are critical requirements.  This document
   extends the model of OAuth and proposes new workflows for AI agent
   authentication and authorization.

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 23 April 2026.

Copyright Notice

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











Yao                       Expires 23 April 2026                 [Page 1]

Internet-Draft            Agent AuthN and AuthZ             October 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
   2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
   3.  Aauth: Agent OBO Its User(s)  . . . . . . . . . . . . . . . .   4
     3.1.  Example Case  . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Model . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Aauth: Agent OBO Itself . . . . . . . . . . . . . . . . . . .   7
     4.1.  Example Case  . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Model . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.3.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Aauth: Agent OBO Other Agent(s) . . . . . . . . . . . . . . .   9
     5.1.  Example Case  . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Model . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Considerations on Other Important Factors . . . . . . . . . .  11
     6.1.  Grant Dynamicity  . . . . . . . . . . . . . . . . . . . .  11
     6.2.  Specific Identity for AI Agent  . . . . . . . . . . . . .  12
     6.3.  Can AI Agents Represent Users to Consent Requests?  . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     7.1.  Agent Impersonation during Discovery  . . . . . . . . . .  12
     7.2.  Excessive Attribute Disclosure  . . . . . . . . . . . . .  13
     7.3.  Token Replay and Intermediary Exfiltration  . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   With the rapid development of large language models(LLMs) and AI
   applications, an AI agent is becoming an emerging entity that can
   help improve working efficiency.  There are different types of AI
   agents, e.g., physical and virtual entities, and many promising use
   cases of AI agents have been mentioned in
   [I-D.rosenberg-aiproto-framework].  All of these AI agents will join



Yao                       Expires 23 April 2026                 [Page 2]

Internet-Draft            Agent AuthN and AuthZ             October 2025


   to build a new Internet infrastructure, which is called as Agent
   Communication Network(ACN).  To build such future networks is not
   easy, challenges and requirements for new protocols are discussed in
   [I-D.rosenberg-aiproto-framework].  Key requirements include, the
   discovery, procedures and mechasims of AI agents to establish message
   routing and connection management.  A fundamental component and of
   critical importance for any new AI agent protocol is ensuring robust
   authentication and authorization.

   The complexity of AI agent authentication and authorization exists in
   that agent may have different roles and capabilities.  AI agents may
   work On-behalf-of(OBO) users, itself, or other AI agents.  In
   different cases, there are different requirements on the
   authentication and authorization, leading to different workflows.
   More importantly, agents may communicate with API proxy server, like
   MCP server to call API and access external resources, this makes the
   authentication and authorization problems more complex.
   [I-D.oauth-ai-agents-on-behalf-of-user] considers the case when AI
   agents work OBO their users, and [I-D.rosenberg-oauth-aauth] defines
   the extension of OAuth 2.1 for AI agents.  This document further
   considers more cases on AI agents authentication and authorization
   based on OAuth extensions.

   This document describes an extension to the OAuth to support
   authentication and authorization among AI agents within ACNs.  It
   defines three operational modes in which agents act on behalf of
   users, themselves, or other agents, introduces the concept of an AID,
   and discusses integration with API proxy servers such as the MCP.

2.  Definition of Terms

   *  AI Agent: an entity with built-in intelligence, which can help or
      replace humans implement jobs and improve work efficiency.

   *  Types of AI Agents:

      -  Physical AI Agent: a physical entity with embedded
         intelligence, usually refers to some AI terminals, e.g., AI
         robot, embodied AI.

      -  Virtual AI Agent: a virtual entity that can provide
         intelligence, usually refers to some softwarized AI assistant,
         e.g., a chat assistant with a mobile application.

   *  Ownership and Roles of AI Agents:

      -  OBO User: the agent may require the authorization from users to
         implement jobs for users.



Yao                       Expires 23 April 2026                 [Page 3]

Internet-Draft            Agent AuthN and AuthZ             October 2025


      -  OBO Agent Itself: the agent itself has identification and
         implements jobs and represents itself.

      -  OBO Other Agent(s): the agent may represent other agents to
         implement some jobs, given that other agents may not have the
         capabilities to implement the jobs.

   *  Agent Communication Network(ACN): a network infrastructure which
      supports the interconnection, routing, capabilities announcement,
      and task collaboration of different types of AI agents.

   *  Agent Identifier(AID): An independent identifier of AI agent.

   *  API Proxy Server: A middlebox server that helps AI agent to call
      APIs or access external data resources.  A typical example is the
      Model Context Protocol(MCP) server.

   *  Domain:

      -  Task-wise Domain: a temporary domain that is created to target
         on a specific job, when the job is finished, the domain is
         destroyed.  A typical example is a domain that is created by
         5G/6G core network.

      -  Application Domain: a durable domain that is created by a
         specific application, e.g., a web or mobile application offered
         by cloud service providers.

      The definition of resource server, resource owner, authorization
      server, and client reuse the definition in [RFC6749].

3.  Aauth: Agent OBO Its User(s)

3.1.  Example Case

   A typical use case of AI agent on-behalf-of the user to access public
   resources can be a virtual agent assistant.  For example, a trip
   planning app assistant helps the user to plan trips.  This case is
   obvious and similar ones have been mentioned in
   [I-D.rosenberg-aiproto-framework].  In this case, when the trip
   assistant needs to search for the current balance of the user, it
   needs the authorization of the user to access his bank account app.
   While it may also need to search for hotels, and it may require the
   account of the user under some booking applications.  In addition, it
   may also need to use some of the data stored in the cloud personal
   gallery, which may require temporary access token.  Therefore, AI
   agent OBO user(s) need different levels of authentication and
   authorization to access these resources.



Yao                       Expires 23 April 2026                 [Page 4]

Internet-Draft            Agent AuthN and AuthZ             October 2025


3.2.  Model

   Figure 1 shows the extension of the OAuth 2.0 model proposed in
   [RFC6749].  There are several updates and new components in this
   model.  The big difference is the introduction of AI agent and API
   proxy server.  If under traditional OAuth 2.0 model, client(AI agent)
   will directly communicate with resource owners and resource servers.
   But this is not efficient and scalable in the AI era, since an agent
   may consult many resource owners at the same time, and different
   resource owners may require different levels of privileges to access
   protected resources.  To overcome the issue, industries have proposed
   Model Context Protocol(MCP).  It introduces MCP server and protocol
   to let AI agents only communicate with the MCP server to request for
   resources.  The MCP server will help AI agents to do API calling and
   specific data resource access.  In Figure 1, MCP server refers to the
   API proxy server.  In the diagram, API proxy server will communicate
   with different resource owners and resource servers.  The agent may
   also support communicating directly with the resource owner and
   resource server.  For example, the resource owner is another agent
   that is interconnected with the agent itself.































Yao                       Expires 23 April 2026                 [Page 5]

Internet-Draft            Agent AuthN and AuthZ             October 2025


                                                2          +--------+
                                             +------------->Resource|
                                             |+------------+Owner 1 |
                                             || 3          +--------+
                                             ||      8     +--------+
                                             ||  +-------->|Resource|
                                   +------+  ||  |+--------+Server 1|
                                   |      +--+|  ||  9     +--------+
                                   |      <---+  ||
                           +------->  API +------+|
                           |       | Proxy|       |
                           | +-----|Server<-------+
                           | |     |      |
                           | |     |      +-----+
                           | |     |      <-+   |   2      +--------+
                           | |     +---^+-+ |   +--------->|Resource|
                       1,7 | |         ||   +--------------+Owner 2 |
                           | |4,10     ||     3            +--------+
                           | |         ||          8       +--------+
                           | |         |+----------------->|Resource|
   +----+  0     +-----+   | |         +-------------------+Server 2|
   |User+-------->     +---+ |                  9          +--------+
   |    <--------+     <-----+
   +----+  11    |     |          1             +--------+
                 |  AI +----------------------->|Resource|
                 |Agent<------------------------+Owner 3 |
                 |     |          4             +--------+
                 |     +-----------+     7      +--------+
                 |     |           +----------->|Resource|
                 |     <------------------------+Server 3|
                 +--^-++              9         +--------+
                    | |
                    | |
                    | |  5         +-------+
                    | +------------> Auth  |
                    +--------------+Servers|
                         6         +-------+

                    Figure 1: AI Agent OBO User Workflow

3.3.  Workflow

   The detailed workflow of Figure 1 is as follows:

   *  Step 0, the user initially asks for AI agent for some tasks via
      prompts.





Yao                       Expires 23 April 2026                 [Page 6]

Internet-Draft            Agent AuthN and AuthZ             October 2025


   *  Step 1, the AI agent interpret the prompts and communicate with
      the API proxy server to search for specific data resources and
      implement function calling.  Alternatively, the agent will ask the
      resource server for the grant if they are directly connected.

   *  Step 2, the API proxy server asks for multiple resource owners for
      the grant of access of the protected data resources.

   *  Step 3, resource owners reply to the API server what
      authentication grant(e.g., authorization code) they need for the
      access to the required resource.

   *  Step 4, the API proxy server will gather messages from different
      resource owners and reply to the AI agent containing multiple
      authorization grants from different resource owners.
      Alternatively, resource owner 3 will replies to the agent with the
      authorization grant directly.

   *  Step 5, the AI agent communicates with different authorization
      servers with multiple authorization grants.

   *  Step 6, auth servers reply to the AI agent with the required
      access tokens.

   *  Step 7, AI agent replies to the API server with the required
      access tokens.  Alternatively, it directly sends the access token
      to the resource server(resource server 3).

   *  Step 8, the API proxy server sends different access tokens to
      different resource servers respectively.

   *  Step 9, resource servers send protected data resources to the API
      proxy server.  The resource server 3 directly sends the protected
      data resources to the AI agent.

   *  Step 10, the API proxy server replies to the AI agent with the
      information that it needs.

   *  Step 11, AI agent replies to the user with the answer.

4.  Aauth: Agent OBO Itself










Yao                       Expires 23 April 2026                 [Page 7]

Internet-Draft            Agent AuthN and AuthZ             October 2025


4.1.  Example Case

   In addition to virtual AI agents, there is another type, physical AI
   agent.  AI robots, embodied AI, and other AI terminals have
   differentiated capabilities to implement multiple jobs.  For example,
   in a remote rescue case, an AI search and rescue vehicles, and an
   robot dog can be dynamically formed into a networked system.  The
   robot dog can scan and transmit the live videos to remote console and
   control signals to the AI search and rescue vehicle, while the AI
   search and rescue vehicles can use its robotic arm to move obstacles
   based on the signals from the robot dog or the remote console.  Some
   other similar cases are mentioned in [TR22.870].
   Compared to the case in which the agent is OBO its user, the major
   difference in this case is that agent need identification of itself,
   that is the agent identification(AID).  In previous case, agent can
   be assigned a Client ID(CID).  The scope of its authority is
   determined by its user, and is less than its users' authority scope.
   While if agent is OBO itself, it is the user.  So it has the same
   privilege as the user.  How to define the AID needs further
   discussion and is beyond the scope of this document.

4.2.  Model

   The model of the agent OBO itself can be extended
   from[I-D.ietf-oauth-v2-1].  As shown in Figure 2, the AI agent is the
   resource owner.  When assigned with some specific tasks, it may
   enable some software functions, and then it will trigger the client
   within these software functions for authentication and authorization.

    +---------+                               +---------------+
    |         |--(A)- Authorization Request ->|   Resource    |
    |         |                               |     Owner     |
    |         |<-(B)-- Authorization Grant ---|  (AI Agent or |
    |         |                               | Other owners) |
    |         |                               +---------------+
    |         |
    |         |                               +---------------+
    |         |--(C)-- Authorization Grant -->| Authorization |
    | Client  |                               |     Server    |
    |         |<-(D)----- Access Token -------|               |
    |         |                               +---------------+
    |         |
    |         |                               +---------------+
    |         |--(E)----- Access Token ------>|    Resource   |
    |         |                               |     Server    |
    |         |<-(F)--- Protected Resource ---|               |
    +---------+                               +---------------+




Yao                       Expires 23 April 2026                 [Page 8]

Internet-Draft            Agent AuthN and AuthZ             October 2025


                   Figure 2: AI Agent OBO Itself Workflow

4.3.  Workflow

   Detailed workflow is similar to [I-D.ietf-oauth-v2-1], and will not
   be stated in detail.

5.  Aauth: Agent OBO Other Agent(s)

5.1.  Example Case

   This case is more complex, but may be required if AI agents have
   differentiated capabilities and need to collaborate to finish some
   jobs, whatever the agents are from intra-domain or inter-domain,
   which has been discussed in [I-D.rosenberg-aiproto-framework].
   In this case, if one AI agent wants to access some protected data
   resources of other agents, or of the users of other agents.  It needs
   the authorization from them.  This is different compared to the
   situation that this agent only needs to seek for grant from the user
   it represents.

5.2.  Model

   Figure 3 shows the model when multiple agents work collaboratively,
   and there will be a chained authentication and authorization
   workflow.  Before AI Agent A requests AI agent B to help it implement
   a job, there should be prior knowledge that both agents need mutual
   trust.  If they come from the same domain, whatever it is a task-wise
   domain created by a console(e.g., 5G/6G core) or a durable domain
   created by a web application, they need verification from the 5G/6G
   core or the web application administrator.  If they come from
   different domains, they may need verification from an open platform
   that organize and issue the AIDs.  There are some ongoing work
   defining AID[I-D.narajala-ans],[I-D.narvaneni-agent-uri].  With this
   pre-verification, agents can communicate with each other.  But when
   one agent(AI agent B) needs access of the protected data resource of
   the user of AI agent A or AI agent C itself, it still need temporary
   authentication and authorization.  In this chained authentication and
   authorization workflow, the core idea here is to let the agent OBO
   user or the agent OBO itself always to communicate with the
   authorization server to get the access token.










Yao                       Expires 23 April 2026                 [Page 9]

Internet-Draft            Agent AuthN and AuthZ             October 2025


         +------+
         | Auth |
         |Server|
         +-^-+--+                 +------+    3   +--------+
           | |                    |      +-------->Resource|
           | |                    |      <--------+Owner 1 |
          7| |8             +----->  API |    4   +--------+
           | |              |     | Proxy|
          ++-v--+           | +---|Server|   11   +--------+
          | AI  |           | |   |      +-------->Resource|
          |Agent|           | |   |      <--------+Server 1|
          |  C  |           | |   |      |    12  +--------+
          +-^-+-+           | |   +------+
            | |         2,10| |
            | |             | |5,13
         6,9| |1,14         | |
    +----+  | |   +-----+   | |
    |User|  | |   |     +---+ |
    |    |  | +--->     <-----+
    +-+^-+  +-----+     |          2             +--------+
      ||          |  AI +----------------------->|Resource|
     0||15        |Agent<------------------------+Owner 2 |
    +-v+--+       |  B  |          5             +--------+
    | AI  | 6,14  |     +-----------+     10     +--------+
    |Agent<-------+     |           +----------->|Resource|
    |  A  +------->     <------------------------+Server 2|
    |     |  1,9  +-----+              13        +--------+
    +--^-++
       | |
       | |          7               +------+
       | +--------------------------> Auth |
       +----------------------------+Server|
                          8         +------+

                Figure 3: AI Agent OBO Other Agents Workflow

5.3.  Workflow

   The detailed workflow of Figure 3 is as follows:

   Step 0, a user asks its AI agent(AI agent A) for some help.

   Step 1, AI agent A redirects the help to Agent B when A is not
   capable, and Agent C asks for B's help too.

   Step 2, agent B ask API proxy server to call APIs.  Agent may also
   request resource owner's grant for its protected data resources.




Yao                       Expires 23 April 2026                [Page 10]

Internet-Draft            Agent AuthN and AuthZ             October 2025


   Step 3, the API proxy server send requests to resource owner 1.

   Step 4, the resource owner 1 send access grant to the API proxy
   server.

   Step 5, the API proxy server and resource owner 2 send the access
   grant to AI agent B.

   Step 6, AI agent B redirects the access grants to AI agent A or AI
   agent C, considering the resource belong to whom.

   Step 7, AI agent A and AI agent C send access grants to authorization
   servers.

   Step 8, authorization servers replies with authorization tokens.

   Step 9, Agent A and agent C pass the access tokens to agent B.

   Step 10, AI agent B passes the access tokens to API proxy server or
   resource owner 2, considering what resource agent B wants to access.

   Step 11, the API proxy server passes the access token to resource
   owner 1.

   Step 12, resource owner 1 gives the protected data resource to the
   API proxy server.

   Step 13, agent B gathers the data resources from the API proxy server
   and resource owner 2.

   Step 14, agent B sends back the processing result to agent A or agent
   C.

   Step 15, agent A processes further and sends back the final result to
   the user.

6.  Considerations on Other Important Factors

6.1.  Grant Dynamicity

   [RFC7591] mentions the mechanism to realize dynamic client
   registration.  Whether and when to grant AI agents with short-lived
   or long-lived authentication and authorization may need further
   discussion, considering various use cases that AI agents participant.







Yao                       Expires 23 April 2026                [Page 11]

Internet-Draft            Agent AuthN and AuthZ             October 2025


6.2.  Specific Identity for AI Agent

   As the second and the third case mentions in the previous section, AI
   agents may have independent identities in ACN.  The definition of
   AIDs is not within the scope of this document, but directly impacts
   authentication and authorization methods.

6.3.  Can AI Agents Represent Users to Consent Requests?

   In the third case mentioned in this document when agent is OBO other
   agents.  This document assumes that agent can represent its user to
   request for access tokens, while the choice on whether to consent
   requests(authorization grant) is still left to the user or the
   agent(agent C).  But it may evolve to the situation that AI agent can
   represent its user to give permission if there are some pre-
   validation on the content scope that AI agent can give external
   grants independently.

7.  Security Considerations

   AI Agent authentication and authorization introduce additional risks
   beyond those covered in [RFC6749] and [I-D.ietf-oauth-v2-1].  This
   section highlights specific threats and corresponding mitigations
   applicable to agent-to-agent (A2A) environments and Agent
   Communication Networks (ACN).

   Attention must be given to agent discovery, agent sandboxing, audit
   logging, and revocation mechanisms, and interactions should apply
   appropriate transport-layer security.  It is worth noting autonomous
   agents may act persistently and at machine speed, which creates
   several additional security challenges.

   Specific aspects of security will be discussed in more detail in this
   document.

7.1.  Agent Impersonation during Discovery

   An adversary may attempt to impersonate a legitimate AI agent during
   the discovery phase, registering false endpoints or replaying
   previously valid credentials to obtain unauthorized access tokens or
   sensitive data.

   Agents must perform authenticated discovery using DNS or another
   verifiable directory service and complete a cryptographically signed
   handshake before establishing trust.  Implementations might need to
   reject interactions with agents that cannot present verifiable
   handshake proofs.




Yao                       Expires 23 April 2026                [Page 12]

Internet-Draft            Agent AuthN and AuthZ             October 2025


7.2.  Excessive Attribute Disclosure

   During discovery and authorization, agents may disclose more
   identifying information than is necessary, creating privacy risks and
   enlarging the surface of attack.  Privacy-preserving credential
   mechanisms may be used to reveal only the minimum attributes
   necessary for the transaction.  Authorization servers and relying
   parties should avoid requesting attributes not strictly required for
   policy enforcement.

7.3.  Token Replay and Intermediary Exfiltration

   Access tokens exchanged between agents or through API proxy servers
   (e.g., MCP) may be intercepted or replayed by unauthorized
   intermediaries, resulting in impersonation or unauthorized resource
   access.

   A method should be used so that access tokens may be sender-
   constrained using mechanisms.  Furthermore, tokens may be configured
   to have short lifetimes or be scoped narrowly to the required
   operation.  For sensitive or human-triggered actions, a method to
   ensure that leaked tokens cannot independently authorize sensitive
   actions would be required.

8.  IANA Considerations

   TBD.

9.  Acknowledgements

10.  References

10.1.  Normative 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>.

   [RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
              P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
              RFC 7591, DOI 10.17487/RFC7591, July 2015,
              <https://www.rfc-editor.org/rfc/rfc7591>.

10.2.  Informative References

   [I-D.ietf-oauth-v2-1]
              Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
              Authorization Framework", Work in Progress, Internet-



Yao                       Expires 23 April 2026                [Page 13]

Internet-Draft            Agent AuthN and AuthZ             October 2025


              Draft, draft-ietf-oauth-v2-1-14, 19 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              v2-1-14>.

   [I-D.narajala-ans]
              Huang, K., Narajala, V. S., Habler, I., and A. Sheriff,
              "Agent Name Service (ANS): A Universal Directory for
              Secure AI Agent Discovery and Interoperability", Work in
              Progress, Internet-Draft, draft-narajala-ans-00, 16 May
              2025, <https://datatracker.ietf.org/doc/html/draft-
              narajala-ans-00>.

   [I-D.narvaneni-agent-uri]
              Narvaneni, Y., "The agent:// Protocol -- A URI-Based
              Framework for Interoperable Agents", Work in Progress,
              Internet-Draft, draft-narvaneni-agent-uri-02, 15 October
              2025, <https://datatracker.ietf.org/doc/html/draft-
              narvaneni-agent-uri-02>.

   [I-D.oauth-ai-agents-on-behalf-of-user]
              Thilina, T. and A. Dissanayaka, "OAuth 2.0 Extension: On-
              Behalf-Of User Authorization for AI Agents", Work in
              Progress, Internet-Draft, draft-oauth-ai-agents-on-behalf-
              of-user-02, 25 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-oauth-ai-
              agents-on-behalf-of-user-02>.

   [I-D.rosenberg-aiproto-framework]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in
              Progress, Internet-Draft, draft-rosenberg-aiproto-
              framework-00, 19 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-rosenberg-
              aiproto-framework-00>.

   [I-D.rosenberg-oauth-aauth]
              Rosenberg, J. and P. White, "AAuth - Agentic Authorization
              OAuth 2.1 Extension", Work in Progress, Internet-Draft,
              draft-rosenberg-oauth-aauth-01, 19 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-rosenberg-
              oauth-aauth-01>.

   [TR22.870] 3GPP, "Study on 6G Use Cases and Service Requirements",
              n.d..

Author's Address





Yao                       Expires 23 April 2026                [Page 14]

Internet-Draft            Agent AuthN and AuthZ             October 2025


   Kehan Yao
   China Mobile
   Email: yaokehan@chinamobile.com
















































Yao                       Expires 23 April 2026                [Page 15]


name: draft-zhao-ccamp-actn-optical-network-agent
rev: 00
title: Integration of Network Management Agent (NMA) into ACTN-Based Optical Network
time: 2025-10-20T10:21:30Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T10:21:30Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:03.420433+00:00
abstract:
With the growth of optical network scale, the complexity of network
   operation and maintenance has increased dramatically.  Enhancing the
   intelligence level of optical network operation and management and
   building high-level autonomous optical networks have become the
   common vision of global operators.  The development of AI, especially
   large AI model technologies, provides a feasible technical path for
   realizing autonomous perception, decision-making, analysis, and
   execution.  The existing ACTN architecture provides network
   abstraction and control functions for optical networks but lacks
   higher-level autonomous capabilities.

   This document explores the introduction of AI based Network
   Management Agent(NMA) functions into ACTN-based optical networks to
   achieve high-level autonomy of optical networks.  It discusses the
   ACTN-enhanced architecture of optical networks after the introduction
   of NMAs, including key components, interaction relationships, new
   interface requirements in the enhanced architecture, as well as
   typical use cases of agent-based autonomous operation and maintenance
   for optical networks.  The document aims to improve the autonomy
   level of optical networks and promote the realization of autonomous
   optical networks by extending the original ACTN architecture.

full_text:
Common Control and Measurement Plane                             X. Zhao
Internet-Draft                                                     CAICT
Intended status: Informational                                     H. Yu
Expires: 23 April 2026                                            Huawei
                                                                   Y. Xu
                                                                   CAICT
                                                         20 October 2025


 Integration of Network Management Agent (NMA) into ACTN-Based Optical
                                Network
             draft-zhao-ccamp-actn-optical-network-agent-00

Abstract

   With the growth of optical network scale, the complexity of network
   operation and maintenance has increased dramatically.  Enhancing the
   intelligence level of optical network operation and management and
   building high-level autonomous optical networks have become the
   common vision of global operators.  The development of AI, especially
   large AI model technologies, provides a feasible technical path for
   realizing autonomous perception, decision-making, analysis, and
   execution.  The existing ACTN architecture provides network
   abstraction and control functions for optical networks but lacks
   higher-level autonomous capabilities.

   This document explores the introduction of AI based Network
   Management Agent(NMA) functions into ACTN-based optical networks to
   achieve high-level autonomy of optical networks.  It discusses the
   ACTN-enhanced architecture of optical networks after the introduction
   of NMAs, including key components, interaction relationships, new
   interface requirements in the enhanced architecture, as well as
   typical use cases of agent-based autonomous operation and maintenance
   for optical networks.  The document aims to improve the autonomy
   level of optical networks and promote the realization of autonomous
   optical networks by extending the original ACTN architecture.

Discussion Venues

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

   Discussion of this document takes place on the Network Management
   Operations Working Group mailing list (nmop@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/ccamp/.

   Source for this draft and an issue tracker can be found at
   https://datatracker.ietf.org/doc/draft-zhao-ccamp-actn-optical-
   network-agent/.



Zhao, et al.              Expires 23 April 2026                 [Page 1]

Internet-Draft         NMA enhanced actn framework          October 2025


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 23 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.  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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Acronyms and Abbreviations  . . . . . . . . . . . . . . .   4
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  NMA-based enhanced ACTN architecture  . . . . . . . . . . . .   4
     3.1.  Enhanced ACTN architecture  . . . . . . . . . . . . . . .   4
     3.2.  Enhanced ACTN interfaces  . . . . . . . . . . . . . . . .   6
   4.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Service provisoning . . . . . . . . . . . . . . . . . . .   9
     4.2.  Service Assurance . . . . . . . . . . . . . . . . . . . .   9
     4.3.  Fault Handling  . . . . . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9



Zhao, et al.              Expires 23 April 2026                 [Page 2]

Internet-Draft         NMA enhanced actn framework          October 2025


     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   With the emergence and popularization of the SDN concept, [RFC8453]
   proposed the ACTN architecture, which provides network abstraction,
   service and connection control functions for optical networks and has
   been deployed in multiple operators' networks.  Currently, as the
   scale of optical networks continues to grow, the complexity of
   network Operations and Maintenance (O&M) has increased dramatically.
   Existing existing existing optical network O&M management systems are
   complex; scenarios such as optical network service provisioning and
   fault handling require extensive manual involvement, leading to
   complicated collaboration processes among O&M personnel and long
   processing durations.  Therefore, further enhancing the intelligence
   level of optical network operation and management, building high-
   level autonomous optical networks, and achieving the service
   experience of "Zero-X" (zero waiting, zero failure, zero touch) and
   "Self-X" (self-configuration, self-healing, self-optimization) have
   become the common vision of global operators.

   The development of AI, especially large AI model technologies,
   provides a feasible technical path for realizing autonomous
   perception, decision-making, analysis, and execution.  As one of the
   important forms of AI application implementation, the concept of AI
   Agent has gained extensive attention and recognition in the industry.
   An AI Agent is defined as an intelligent entity capable of perceiving
   the environment, making autonomous decisions, and executing actions,
   which can gradually achieve set goals through independent thinking
   and tool invocation.  The four core elements of an AI Agent include
   planning, tools, execution, and memory.  Most current AI Agents are
   based on Large Language Models (LLMs), i.e., LLM-based Agents.  The
   relationship between an AI Agent and a large model can be summarized
   as: Agent = large model + memory + planning + tool use.

   Currently, the IETF document [I-D.zhao-nmop-network-management-agent]
   has proposed an AI Agent for network O&M management, which can
   automatically perform network state perception, task intent parsing,
   task planning, decision-making, and task execution.  Based on user
   task intent or preset goals, it enables closed-loop processing of
   scenario-oriented network O&M management tasks.

   This document, building on the Network Management Agent (NMA) concept
   proposed in [I-D.zhao-nmop-network-management-agent], explores the
   introduction of NMA into the ACTN-based optical network architecture.
   By enhancing the capabilities of the agent, it aims to improve the
   intelligent O&M management capabilities of optical networks and drive



Zhao, et al.              Expires 23 April 2026                 [Page 3]

Internet-Draft         NMA enhanced actn framework          October 2025


   the realization of high-level autonomy in optical networks.  This
   document will first discuss the enhanced ACTN architecture of optical
   networks after the introduction of NMA, analyze in detail the key
   components, interaction relationships, and new interface requirements
   in the new architecture, and provide examples of typical agent-based
   autonomous O&M use cases for optical networks.

2.  Terminology

2.1.  Acronyms and Abbreviations

   AI: Artificial Intelligence

   LLM: Large Language Model

   NMA: Network Management Agent, refers to AI based network management
   agent

   Agent: Specifically refers to NMA, i.e., the AI Agent for network
   management.

2.2.  Definitions

   The document defines the following terms:

   Network Management Agent (NMA):  A network management entity built
      based on ML/AI and equipped with the autonomous task processing
      capabilities.  It can automatically carry out network status
      perception, task intent interpretation, task planning, decision-
      making and task execution operations based on user task intentions
      or preset goals, so as to achieve closed-loop processing of
      scenarios-oriented network management tasks.  For different
      application scenarios, NMA can be subdivided into multiple
      scenario-oriented agents.

3.  NMA-based enhanced ACTN architecture

3.1.  Enhanced ACTN architecture

   The enhanced ACTN architecture for optical networks after the
   introduction of NMA is illustrated in Figure 1 below.  The AI agents
   (i,e.  NMA) are introduced within the ACTN architectural framework as
   auxiliary components intended to augment and assist existing ACTN
   functional entities, rather than to replace them.  In alignment with
   this design principle, the NMAs are conceptually implemented as
   design components within the MDSC, PNC, or CNC, rather than as
   independent entities external to these controllers.  The agents can
   interact with existing ACTN functional components through



Zhao, et al.              Expires 23 April 2026                 [Page 4]

Internet-Draft         NMA enhanced actn framework          October 2025


   standardized protocols such as the Management Control Protocol (MCP).
   This integrated design approach ensures backward compatibility with
   the established ACTN framework and enables seamless interaction with
   the existing ACTN interfaces and control logic.

            +----------------------------------+
            |           Enhanced CMC           |
            | +--------+ +--------+ +--------+ |
            | |  NMA1  | |  NMA2  | |  NMA3  | |
            | +--------+ +--------+ +--------+ |
            +-----------------^----------------+
                              |(1)Extened CMI
            +-----------------v----------------+
            |           Enhanced MDSC          |
            | +--------+ +--------+ +--------+ |
            | |  NMA1  | |  NMA2  | |  NMA3  | |
            | +--------+ +--------+ +--------+ |
            +-----------------^----------------+
                              |(2)Extended MPI
                         +----+-----------------------+-----------+
                         |                            |           |
  +----------------------v--------------------+  +----v----+ +----v----+
  |               Enhanced PNC1               |  |         | |         |
  | +----------+             +------+         |  |         | |         |
  | |          |        +----> NMA2 >----+    |  |         | |         |
  | | Original |        |(5) +------+    |    |  |  PNC2   | |   PNC3  |
  | | Function | (4) +--^---+   (5)  +---v--+ |  |         | |         |
  | |  Modules <-----> NMA1 >--------> NMA3 | |  |         | |         |
  | +----------+     +------+        +------+ |  |         | |         |
  +----------------------v--------------------+  +----v----+ +----v----+
                         |(3)Extended SBI             |           |
  +----------------------v--------------------+  +----v----+ +----v----+
  |               Network domain 1            |  | Domain2 | | Domain3 |
  +-------------------------------------------+  +---------+ +---------+


              Figure 1: NMA-based enhanced ACTN architecture

   The enhanced ACTN architecture includes the following key entities:

   NMA-enhanced CNC (Customer Network Controller):  As defined in










Zhao, et al.              Expires 23 April 2026                 [Page 5]

Internet-Draft         NMA enhanced actn framework          October 2025


      [RFC8453], the CNC is responsible for transmitting the customer’s
      Virtual Network Service (VNS) requirements to the network operator
      via the CNC-MDSC Interface (CMI).  By integrating NMA entities
      related to service scenarios at the CNC layer, it can address
      operation and management needs specific to the service domain,
      enhance the intelligence level of end-to-end service operation and
      management, and enable intelligent service-domain capabilities
      such as automated service provisioning and automated work order
      flow.

   NMA-enhanced MDSC (Multi-Domain Service Coordinator):  As defined in
      [RFC8453], the MDSC undertakes core functions including multi-
      domain service coordination and network virtualization/
      abstraction.  By introducing NMA entities for cross-domain
      scenarios at the MDSC layer, it can meet cross-domain O&M
      management requirements, strengthen closed-loop task processing
      capabilities in typical scenarios, and improve the efficiency of
      optical network management and control.

   NMA-enhanced PNC (Provisioning Network Controller):  As defined in
      [RFC8453], the Provisioning Network Controller (PNC) oversees
      configuring the network elements, monitoring the topology
      (physical or virtual) of the network, and collecting information
      about the topology (either raw or abstracted).  By integrating NMA
      entities for single-domain scenarios (e.g., Fault Management NMA,
      Service Assurance NMA) at the PNC layer, it can address single-
      domain O&M management needs and enhance the ability to handle
      various network O&M tasks within the domain.

3.2.  Enhanced ACTN interfaces

   As shown in Figure 1, the architecture includes 5 types of
   interfaces:

   1.  Extended CMI: The interface between CNC and MDSC.  After
       introducing NMA entities at each layer, the communication
       requirements between the original CMI interfaces will be enhanced
       from traditional transactional communication to include agent-
       oriented conversational communication.  The CMI interface needs
       to be extended to meet the requirements of agent capability
       invocation and interaction between upper and lower layers.

   2.  Extened MPI: The interface between MDSC and PNC.  Similar to CMI,
       after introducing NMA entities into MDSC and PNC, the original
       MPI also needs to be extended to support agent capability
       invocation and interaction between upper and lower layers.





Zhao, et al.              Expires 23 April 2026                 [Page 6]

Internet-Draft         NMA enhanced actn framework          October 2025


   3.  SBI: The interface between PNC and physical network devices,
       which is out of scope of ACTN discussions.

   4.  Interfaces between NMAs and original functional modules at each
       layer: These are internal system interfaces, which can be
       implemented through private interfaces or interface solutions
       such as MCP, and are not within the scope of discussion in this
       document.

   5.  Interfaces between NMAs within same layers: These are internal
       system interfaces that can use private interfaces or general
       agent communication interfaces (e.g., A2A, ACP, etc.), and are
       out of scope of ACTN discussions.

   Since NMAs can be deployed on different controllers within the ACTN
   hierarchy, two possible inter-controller AI-agent communication
   scenarios can be identified.  For example, when there is a need for
   direct communication between NMAs in the upper-layer MDSC and those
   in the lower-layer PNC (A2A Communication), it will manifest as a
   single communication channel physically but multiple communication
   processes logically (i,e.including multiple A2A communication
   processes).

   Figure 1 illustrates these scenarios between the MDSC and PNC (The
   case between the MDSC and CNC is similar and omitted here for
   simplicity).

   As shown in Figure 1(a), when both the MDSC and PNC host AI agents,
   they can communicate directly through agent-to-agent (A2A) protocols
   (or other solutions).  In contrast, when only one controller is
   equipped with an AI agent—as depicted in Figures 1(b) and 1(c)—the
   agent communicates with the other controller, which lacks an agent,
   via the existing ACTN MPI.  For example, in Figure 1(b), the AI agent
   residing on the MDSC uses a RESTCONF client to interact with the PNC
   through MPI calls.
















Zhao, et al.              Expires 23 April 2026                 [Page 7]

Internet-Draft         NMA enhanced actn framework          October 2025


+---------------------+ +----------------------+ +----------------------+
|         MDSC        | |          MDSC        | |          MDSC        |
|                     | |          +----------+| |                      |
|+-----------+   +---+| |+---+  MCP|   other  || |+----------++--------+|
||  Other    |MCP|   || ||   | +--->functional|| || Original ||Restconf||
||functional <--->NMA|| ||   | |   |  modules || ||functional|| Client ||
|| modules   |   |   || ||NMA<-+   +----------+| ||  modules ||        ||
|+-----------+   +-^-+| ||   | |   +----------+| |+----------++---^----+|
|                  |  | ||   | |MCP| Restconf || |                |     |
|                  |  | |+---+ +--->  Client  || |                |     |
|                  |  | |          +-----^----+| |                |     |
+------------------|--+ +----------------|-----+ +----------------|-----+
                   |A2A                  | MPI                    | MPI
+------------------|--+ +----------------|-----+ +----------------|-----+
|         PNC      |  | |          PNC   |     | |         PNC    |     |
|                  |  | |                |     | |          +-----v----+|
|+-----------+   +-v-+| |+----------++---v----+| |+---+  MCP|   other  ||
||   Other   |MCP|   || || Original ||Restconf|| ||   | +--->functional||
||functional <--->NMA|| ||functional|| Server || ||   | |   |  modules ||
||  modules  |   |   || ||  modules ||        || ||NMA<-+   +----------+|
|+-----------+   +---+| |+----------++--------+| ||   | |   +----------+|
|                     | |                      | ||   | |MCP| Restconf ||
|                     | |                      | |+---+ +--->  Client  ||
|                     | |                      | |          +----------+|
+---------------------+ +----------------------+ +----------------------+


    Figure 2: Inter-controller NMA communication scenarios between
                             MDSC and PNC

4.  Use cases

   The ACTN architecture enhanced by NMA can effectively improve the
   automation and intelligence levels in typical O&M management
   scenarios of optical networks by building agents for different
   scenarios.  Examples of typical application scenarios include:

   1.  Service Provisioning: enable users to describe services in
       natural language and to automate service design, provisioning,
       and deployment processes.

   2.  Service Assurance: ensuring compliance with service-level
       agreements (SLAs), including assisting in risk detection,
       prediction, and decision-making for preemptive actions to prevent
       service degradation.






Zhao, et al.              Expires 23 April 2026                 [Page 8]

Internet-Draft         NMA enhanced actn framework          October 2025


   3.  Fault Handling: support anomaly detection, fault localization,
       root cause analysis, and generate fault repair solution to
       accelerate fault resolution and improve network reliability.

4.1.  Service provisoning

   TBD

4.2.  Service Assurance

   TBD

4.3.  Fault Handling

   TBD

5.  Security Considerations

   TBD

6.  IANA Considerations

   This document has no requests for IANA action.

7.  References

7.1.  Normative References

7.2.  Informative References

   [I-D.zhao-nmop-network-management-agent]
              Zhao, X., Wang, M., Wu, B., Ceccarelli, D., Zheng, H., and
              J. Zhou, "AI based Network Management Agent(NMA): Concepts
              and Architecture", Work in Progress, Internet-Draft,
              draft-irtf-nmrg-network-digital-twin-arch-09, 17 October
              2025, <https://datatracker.ietf.org/doc/html/draft-irtf-
              nmrg-network-digital-twin-arch-09>.

   [RFC8453]  Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
              Control of TE Networks (ACTN)", RFC 8453,
              DOI 10.17487/RFC8453, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8453>.

Authors' Addresses







Zhao, et al.              Expires 23 April 2026                 [Page 9]

Internet-Draft         NMA enhanced actn framework          October 2025


   Xing Zhao
   CAICT
   Beijing
   China
   Email: zhaoxing@caict.ac.cn


   Henry Yu
   Huawei
   Canada
   Email: henry.yu1@huawei.com


   Yunbin Xu
   CAICT
   China
   Email: xuyunbin@caict.ac.cn


































Zhao, et al.              Expires 23 April 2026                [Page 10]


name: draft-mzsg-rtgwg-agent-cross-device-comm-framework
rev: 01
title: Cross-device Communication Framework for AI Agents in Network Devices
time: 2025-11-02T04:03:01Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T04:03:01Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Autonomous netops", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420436+00:00
abstract:
With the development of large language models (LLM), AI Agent
   software continues to emerge.  AI agents deployed on different
   network devices need to collaborate to accomplish some complex tasks,
   such as network measurement and network troubleshooting.  This
   collaboration requires cross-device communication between AI agents.

   This document proposes a cross-device communication framework for AI
   agents in network devices, and analyzes the requirements for the
   communication protocol.

full_text:
Network Working Group                                             J. Mao
Internet-Draft                                                   G. Zeng
Intended status: Standards Track                                  B. Liu
Expires: 5 May 2026                                              N. Geng
                                                                X. Shang
                                                                  Q. Gao
                                                                   Z. Li
                                                     Huawei Technologies
                                                         1 November 2025


 Cross-device Communication Framework for AI Agents in Network Devices
         draft-mzsg-rtgwg-agent-cross-device-comm-framework-01

Abstract

   With the development of large language models (LLM), AI Agent
   software continues to emerge.  AI agents deployed on different
   network devices need to collaborate to accomplish some complex tasks,
   such as network measurement and network troubleshooting.  This
   collaboration requires cross-device communication between AI agents.

   This document proposes a cross-device communication framework for AI
   agents in network devices, and analyzes the requirements for the
   communication protocol.

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 5 May 2026.

Copyright Notice

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




Mao, et al.                Expires 5 May 2026                   [Page 1]

Internet-Draft     Network Device Agent Communication      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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Framework and Key Components  . . . . . . . . . . . . . . . .   3
   5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Requirements for AI Agent in Network Devices  . . . . . .   6
     5.2.  Requirements for Agent Protocol . . . . . . . . . . . . .   6
     5.3.  Requirements for Security schema  . . . . . . . . . . . .   6
   6.  Illustration  . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Using A2A as the communication protocol . . . . . . . . .   7
     6.2.  Using MCP as the communication protocol . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   With the development of large language models (LLM), AI Agent
   software continues to emerge.  They have played a significant role in
   enhancing work and production efficiency.  Deploying AI Agents on
   network devices will be the next beneficial attempt.

   AI agents deployed on different network devices need to collaborate
   to accomplish more complex tasks, especially those that span multiple
   devices and involve network-level operations.  For example, this can
   help us perform better in areas such as network
   measurement[I-D.zeng-mcp-network-measurement] and network
   troubleshooting[I-D.zeng-mcp-troubleshooting].

   This collaboration requires communication between AI agents, so this
   document proposes a cross-device communication framework for AI
   agents in network devices, and analyzes the requirements for the
   communication protocol.




Mao, et al.                Expires 5 May 2026                   [Page 2]

Internet-Draft     Network Device Agent Communication      November 2025


   In this framework, the agents that communicate with each other are
   peers, capable of using synchronous and asynchronous communication
   methods, and support both structured and unstructured messages.

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

3.  Terminology

   A2A: Agent2Agent Protocol

   MCP: Model Context Protocol

4.  Framework and Key Components


   The figure below shows the communication framework, including three
   network devices A~C, with some AI agents deployed on each device.




























Mao, et al.                Expires 5 May 2026                   [Page 3]

Internet-Draft     Network Device Agent Communication      November 2025


                                              Device B
                                             +-------------------------+
                                             |   +------------------+  |
                                   /---------+-->|Integrated Agent 1|  |
                                   |         |   +------------------+  |
                                   |         |   +------------------+  |
                                   | /-------+-->|Integrated Agent 2|  |
                                   | |       |   +------------------+  |
                                   | |       |                         |
  Device A                         | |       +-------------------------+
 +-------------------------+       | |
 | +-------------------+ --+-------/ |
 | |Communication Agent| --+---------/  communicate using Agent Protocol
 | +++-----------------+ --+-------\
 |  ||  +--------------+   |       |
 |  ||->|Worker Agent 1|   |       |           Device C
 |  |   +--------------+   |       |         +-------------------------+
 |  |   +--------------+   |       |         |   +-------------------+ |
 |  |-->|Worker Agent 2|   |       \---------+-->|Communication Agent| |
 |      +--------------+   |                 |   +++-----------------+ |
 +-------------------------+                 |    ||  +--------------+ |
                                             |    ||->|Worker Agent 1| |
                                             |    |   +--------------+ |
                                             |    |   +--------------+ |
                                             |    |-->|Worker Agent 2| |
                                             |        +--------------+ |
                                             +-------------------------+

Figure 1: Cross-device Communication Framework for AI Agents in Network Devices

   Agents on network devices are categorized into three types:
   Communication Agent, Worker Agent, and Integrated Agent.

   *  Communication Agent: Responsible for the intelligent agent
      communication of this network device with external systems.  It
      aggregates the capabilities of all local Worker Agents to generate
      the overall capability of the network device for external
      representation.  It receives cross-device access requests from
      Worker Agents and uses the Agent protocol to communicate with
      Communication Agents on other devices.  It also manages
      asynchronous or long-term tasks.










Mao, et al.                Expires 5 May 2026                   [Page 4]

Internet-Draft     Network Device Agent Communication      November 2025


   *  Worker Agent: It performs specific functions for a particular set
      of tasks locally, such as network measurement and troubleshooting.
      It does not handle AI agent communication across devices.  Worker
      Agents on different devices do not communicate with each other.
      Within a device, Worker Agents can communicate with each other or
      with the Communication Agent using either the Agent protocol or
      custom methods.  This document does not impose any restrictions on
      the communication methods.

   *  Integrated Agent: Possesses both the functions of Worker Agent and
      Communication Agent.  It has the capability to perform specific
      tasks and communicate with other agents.


   The Communication Agents on each device have a peer relationship with
   each other.  Based on the invocation relationship during a single
   communication, they can be further categorized into two roles: Client
   Agent and Server Agent.

   *  Client Agent: Constructs task requirements into request messages
      and sends them to the Server Agent via the Agent Protocol.  It
      waits for the Server Agent to return a response message.  The task
      result is obtained by parsing the response message, or recording
      the task ID in the response message returned by the Server Agent
      and retrieving the task result from the Server Agent by the task
      ID later.

   *  Server Agent: In terms of capability discovery, it constructs the
      capabilities of AI agents in the device into capability
      negotiation messages and sends them to the Client Agent via the
      Agent Protocol.  For processing task requests, it receives request
      messages from the Client Agent through the Agent Protocol.  For
      short-term tasks, after completing the task, it constructs the
      task result into a response message.  For long-term tasks, it
      generates a task ID and constructs the task ID into a response
      message.  The response message is then sent to the Client Agent
      via the Agent Protocol.  When a long-term task is completed, the
      task result is cached, and the Server Agent waits for the Client
      Agent to retrieve the task result using the task ID.


   The cross-device communication protocol between AI agents in network
   devices is referred as Agent Protocol.








Mao, et al.                Expires 5 May 2026                   [Page 5]

Internet-Draft     Network Device Agent Communication      November 2025


   *  Agent Protocol: The communication protocol between agents on two
      devices, which includes functions such as capability discovery and
      negotiation, task assignment and result collection,
      authentication, and secure communication.  For example, emerging
      protocols like A2A or MCP, or mature protocols like NETCONF/YANG,
      can be used.


5.  Requirements


5.1.  Requirements for AI Agent in Network Devices

   TBD

5.2.  Requirements for Agent Protocol


   The communication protocol between AI agents in network devices is
   referred as Agent Protocol.  There are some requirements for it.

   [REQ 2-1a] Agent Protocol MUST support synchronous request/response
   interaction.

   [REQ 2-1b] Agent Protocol SHOULD support streaming interaction for
   better experience in some man-machine interaction scenarios.

   [REQ 2-1c] Agent Protocol MUST support to response task id
   immediately and acquire the result by task id later.

   [REQ 2-1d] Agent Protocol SHOULD support bidirectional interaction
   for the scenarios where Server Agent asks for more information from
   Client Agent.

   [REQ 2-1e] Agent Protocol MUST support to exchange structured
   messages, such as message in JSON or Protobuf format.

   [REQ 2-1f] Agent Protocol SHOULD support to exchange unstructured
   messages, such as natural language.

   [REQ 2-1g] TBD

5.3.  Requirements for Security schema

   TBD






Mao, et al.                Expires 5 May 2026                   [Page 6]

Internet-Draft     Network Device Agent Communication      November 2025


6.  Illustration


6.1.  Using A2A as the communication protocol

   TBD

6.2.  Using MCP as the communication protocol

   TBD

7.  IANA Considerations

   TBD

8.  Security Considerations

   TBD


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/info/rfc2119>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [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>.

9.2.  Informative References

   [I-D.zeng-mcp-network-measurement]
              Zeng, G. and J. Mao, "MCP-based Network Measurement
              Framework: Using Model Context Protocol for Intelligent
              Network Measurement", Work in Progress, Internet-Draft,
              draft-zeng-mcp-network-measurement-00, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-zeng-mcp-
              network-measurement-00>.




Mao, et al.                Expires 5 May 2026                   [Page 7]

Internet-Draft     Network Device Agent Communication      November 2025


   [I-D.zeng-mcp-troubleshooting]
              Zeng, G. and J. Mao, "Using the Model Context Protocol
              (MCP) for Intent-Based Network Troubleshooting
              Automation", Work in Progress, Internet-Draft, draft-zeng-
              mcp-troubleshooting-00, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-zeng-mcp-
              troubleshooting-00>.

Authors' Addresses

   Jianwei Mao
   Huawei Technologies
   Beijing
   100095
   China
   Email: MaoJianwei@huawei.com


   Guanming Zeng
   Huawei Technologies
   Email: zengguanming@huawei.com


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


   Nan Geng
   Huawei Technologies
   Email: gengnan@huawei.com


   Xiaotong Shang
   Huawei Technologies
   Email: shangxiaotong@huawei.com


   Qiangzhou Gao
   Huawei Technologies
   Email: gaoqiangzhou@huawei.com


   Zhenbin Li
   Huawei Technologies
   Email: robinli314@163.com





Mao, et al.                Expires 5 May 2026                   [Page 8]


name: draft-zl-agents-networking-architecture
rev: 00
title: Agents Networking Architecture for Enterprise and Broadband
time: 2025-10-20T15:40:43Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T15:40:43Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420438+00:00
abstract:
This document introduces agents networking architecture and defines
   the core components of agent networking, as well as typical
   interactions among these key components.

full_text:
network working group                                           L. Zhang
Internet-Draft                                                    B. Liu
Intended status: Informational                       Huawei Technologies
Expires: 23 April 2026                                           N. Geng
                                                                  Huawei
                                                                 Z. Wang
                                                             Independent
                                                         20 October 2025


      Agents Networking Architecture for Enterprise and Broadband
               draft-zl-agents-networking-architecture-00

Abstract

   This document introduces agents networking architecture and defines
   the core components of agent networking, 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 23 April 2026.

Copyright Notice

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











Zhang, et al.             Expires 23 April 2026                 [Page 1]

Internet-Draft       Agents Networking Architecture         October 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 architecture 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 Architecture  . . . . . . .   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 23 April 2026                 [Page 2]

Internet-Draft       Agents Networking Architecture         October 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 architecture and defines
   the core components of agent networking, 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 architecture and Components

2.1.  Overview of Agents Networking

   The overall architecture 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 architecture






Zhang, et al.             Expires 23 April 2026                 [Page 3]

Internet-Draft       Agents Networking Architecture         October 2025


   The architecture 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 23 April 2026                 [Page 4]

Internet-Draft       Agents Networking Architecture         October 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 23 April 2026                 [Page 5]

Internet-Draft       Agents Networking Architecture         October 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 Architecture

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 23 April 2026                 [Page 6]

Internet-Draft       Agents Networking Architecture         October 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 23 April 2026                 [Page 7]

Internet-Draft       Agents Networking Architecture         October 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 23 April 2026                 [Page 8]

Internet-Draft       Agents Networking Architecture         October 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 23 April 2026                 [Page 9]

Internet-Draft       Agents Networking Architecture         October 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 23 April 2026                [Page 10]

Internet-Draft       Agents Networking Architecture         October 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 23 April 2026                [Page 11]

Internet-Draft       Agents Networking Architecture         October 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 23 April 2026                [Page 12]

Internet-Draft       Agents Networking Architecture         October 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
   Beijing
   China
   Email: gengnan@huawei.com


   ZiHang Wang
   Independent
   Beijing
   China
   Email: 1639283202@qq.com

















Zhang, et al.             Expires 23 April 2026                [Page 13]


name: draft-wmz-nmrg-agent-ndt-arch
rev: 03
title: Network Digital Twin and Agentic AI based Architecture for AI driven Network Operations
time: 2026-02-24T07:19:56Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T07:19:56Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Model serving/inference", "Policy/governance", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:03.420440+00:00
abstract:
A Network Digital Twin (NDT) provides a network emulation tool usable
   for different purposes such as scenario planning, impact analysis,
   and change management.  Integrating a Network Digital Twin into
   network management together with Agentic AI, it allows the network
   management activities to take user intent or service requirements as
   input, automatically assess, model, and refine optimization
   strategies under realistic conditions but in a risk-free environment.
   Such environment that operates to meet these types of requirements is
   said to have AI driven Network Operations.

   AI driven Network Operations brings together existing technologies
   such as Agentic AI and Network Digital Twin which may be seen as the
   use of a toolbox of existing components enhanced with a few new
   elements.

   This document describes an architecture for AI driven network
   operations and shows how these components work together with network
   digital twin and Agentic AI capabilities.  It provides a cookbook of
   existing technologies to satisfy the architecture and realize intent-
   based network management to meet the needs of the network service.

full_text:
Network Management                                                 Q. Wu
Internet-Draft                                                    Huawei
Intended status: Informational                                   C. Zhou
Expires: 28 August 2026                                     China Mobile
                                                         L. M. Contreras
                                                              Telefonica
                                                                  S. Han
                                                            China Unicom
                                                                 Y. Hong
                                                      Daejeon University
                                                        24 February 2026


  Network Digital Twin and Agentic AI based Architecture for AI driven
                           Network Operations
                  draft-wmz-nmrg-agent-ndt-arch-03

Abstract

   A Network Digital Twin (NDT) provides a network emulation tool usable
   for different purposes such as scenario planning, impact analysis,
   and change management.  Integrating a Network Digital Twin into
   network management together with Agentic AI, it allows the network
   management activities to take user intent or service requirements as
   input, automatically assess, model, and refine optimization
   strategies under realistic conditions but in a risk-free environment.
   Such environment that operates to meet these types of requirements is
   said to have AI driven Network Operations.

   AI driven Network Operations brings together existing technologies
   such as Agentic AI and Network Digital Twin which may be seen as the
   use of a toolbox of existing components enhanced with a few new
   elements.

   This document describes an architecture for AI driven network
   operations and shows how these components work together with network
   digital twin and Agentic AI capabilities.  It provides a cookbook of
   existing technologies to satisfy the architecture and realize intent-
   based network management to meet the needs of the network service.

Discussion Venues

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

   Discussion of this document takes place on the Network Management
   mailing list (nmrg@irtf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/nmrg.

   Source for this draft and an issue tracker can be found at
   https://github.com/QiufangMa/Agent-architecture.

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 28 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.

Table of Contents

   1.  Introduction
   2.  Conventions and Definitions
   3.  Introduction of Concepts
     3.1.  Generative AI and Agentic AI
     3.2.  Network Digital Twin
   4.  Characteristics of AI driven Network Operations
   5.  Architecture Design
     5.1.  Overall Architecture
     5.2.  Functional Components
       5.2.1.  Network Applications
       5.2.2.  Autonomous Domain
     5.3.  Functional Interfaces
       5.3.1.  Human in the Loop
       5.3.2.  Application to Network AI Agent Interface
       5.3.3.  Network AI Agent to Task AI Agent Interface (Single
               Autonomous Domain)
       5.3.4.  Network AI Agent to Network AI Agent Interface (Cross
               Autonomous Domain)
       5.3.5.  Network AI Agent/Task AI Agent to Agent Gateway
               Interface
       5.3.6.  Network AI Agent to Network Digital Twin Interface
       5.3.7.  Network AI Agent to Knowledge Base Interface
       5.3.8.  Task AI Agent to Physical Network Interface
       5.3.9.  Feedback-driven Improvement Interface
       5.3.10. Network Element AI Agent and Network AI Agent
               Collaboration Interface
   6.  AI Driven Network Operations: Relationship Between
           Characteristics and Functional Components
   7.  AI Agent Registration and Team formation
   8.  Agent to Agent Communication Security
   9.  AI Driven Network Operations: A collection of Use Cases
     9.1.  Multi-Agent Collaboration on Network Configuration Change
     9.2.  Multi-Agent Collaboration on Network Troubleshooting
     9.3.  Multi-Agent Collaboration on Network Optimization
     9.4.  Network level Energy Efficiency Management in the
           IP+Optical network
     9.5.  Network Security Drills (Human in the Loop)
   10. Challenges of Integrating Network Digital Twin and Agentic AI
           into Network Management
     10.1.  Create domain specific language for agents and models
     10.2.  Trust and Security
     10.3.  Protocols between Agent and Agent/Human operator/Tools
       10.3.1.  High Risk Operations
       10.3.2.  The Timeliness Requirements of Collaboration
       10.3.3.  Collaboration Reliability
     10.4.  Benchmarking
       10.4.1.  Single Agent Benchmarking
       10.4.2.  Multi-Agent Benchmarking
   11. Security Considerations
   12. IANA Considerations
   13. Conclusion
   14. References
     14.1.  Normative References
     14.2.  Informative References
   Appendix A.  Acknowledgements
   Appendix B.  Changes between Revisions
   Contributors
   Authors' Addresses

1.  Introduction

   The rapid expansion of network scale and the increasing demands on
   these networks necessitate of continuous network reconfiguration to
   better adapt to ever-changing service requirements.

   Since network changes are directly related to service operations, any
   successful change needs to not only ensure that new services are
   provisioned smoothly, but also that existing services are not
   affected and that no problems are introduced with the new
   configurations.  Network operators are, therefore, increasingly
   cautious about making network changes, given that they need to review
   the solution design as well as evaluate all change impacts, before
   making any change.  Then, after the change, they need to perform
   dialing tests, monitor traffic, and manually check table entries.

   The Network Digital Twin (NDT)
   [I-D.irtf-nmrg-network-digital-twin-arch] has been proposed as a mean
   to provide a network emulation tool for scenario planning, impact
   analysis, and change management.  Agentic AI introduces disruptive
   paradigm to the network management and allow declarative intent
   interpretation, multi-step action, multi-agent coordination.
   Integrating a Network Digital Twin into network management together
   with Agentic AI, it allows network management activities to
   dynamically adapt to customer needs, network changes, as well as to
   automatically assess, model, and refine optimization strategies under
   realistic conditions but in a risk-free environment.  An environment
   that operates to meet these types of requirements is said to have AI
   driven network operations.

   AI Driven network operations provide the following capabilities to
   applications by coordinating the components that operate and manage
   the network:

   *  Service intent and service assurance work together to ensure that
      the network change or network optimization aligns with business
      goals and that the services provided meet the agreed-upon Service
      Level Agreements (SLAs).

   *  Provide network capacity planning and ensure that the network has
      sufficient capacity , resources, and infrastructure to meet
      current and future demands.

   *  Provide simulation on fault scenarios, formulate recovery plans,
      and verify whether the plans are applicable and effective so that
      the service will not be affected during disaster recovery drill.

   *  Support fault and risk detection and provide network health check
      and network risk check.

   *  Model the network configuration change and use a virtual topology
      model to test network changes and assess the effect of the network
      configuration changes on the network.

   *  Model the protocol operations and interactions among devices in
      the network and simulate specific networking protocols such as IS-
      IS, OSPF, BGP, SR, etc to understand how they perform under
      different conditions.

   *  Model traffic flow across the network, including traffic
      generation, flow control, routing, and congestion control and
      evaluate traffic's impact on network performance.

   *  Support generation of rectification solutions for potential
      network risks and provide verification on the repair solution in
      seconds, including loop, address conflict, and security policy
      conflict.

   This document describes an architecture for AI Driven network
   operations, showing how these components work together with network
   digital and AI capabilities.  It provides a cookbook of existing
   technologies to satisfy the architecture and realize intent-based
   networking to meet the needs of applications.

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.

   The document uses the following definitions and acronyms defined in
   [I-D.irtf-nmrg-network-digital-twin-arch]:

   *  Network Digital Twin (NDT)

   *  Artificial Intelligence (AI)

   The following acronyms are used throughout this document:

   *  Generative Artificial Intelligence (Gen-AI)

   *  Large Language Model (LLM)

   *  Retrieval-Augmented Generation (RAG)

   *  Agentic AI [I-D.hong-nmrg-agenticai-ps]

   *  Multiple Agent System (MAS)

   *  Remote Code Execution (RCE)

   Besides, this document defines the following terminology:

   Network AI Agent:  Network AI Agent is an autonomous system or entity
      with awareness of its environment, capable of conducting analysis,
      making decisions, and executing actions with specific intent based
      on its knowledge representation to achieve a set of service goals
      [TMF-1251D].  In addition, it is able of planning the tasks and
      decompose the tasks into several sub-tasks and coordinate with
      Task agent for these sub-tasks.

   Task AI Agent:  Task AI Agent is responsible for coordinating with
      Network AI Agent in the multi-Agent System and executing specific
      task assigned by Network AI Agent.

3.  Introduction of Concepts

3.1.  Generative AI and Agentic AI

   The integration of AI into network operations has marked a
   significant leap forward in the pursuit of network automation and
   intelligence, while generative AI further enhances the role of AI
   driven network operations and management.  Generative AI is a
   subfield of AI that uses generative models such as Large Language
   Models (LLMs) to generate new and original content such as text,
   images, videos, or other forms of data with the capability to adapt
   and make decisions to achieve specific goals.

   Agentic AI refers to the broader category of AI systems that exhibit
   "agency"—the ability to act independently and iteratively to perform
   tasks without constant human prompting [I-D.hong-nmrg-agenticai-ps].
   In the context of network operations and management, Network AI
   agents are increasingly being designed to interact with physical
   world and act upon it based on tools [Google-Agents-Whitepaper] and
   perform network management tasks such as understanding user intent,
   generating network configurations, diagnosing and resolving network
   incidents [I-D.ietf-nmop-network-incident-yang].  Meanwhile, other
   SDOs also try to define terms related to Network AI agent in the
   context of network operations and management, e.g., TM Forum defines
   Autonomous Agent in [TMF-1251D] as one of AN (Autonomous Network)
   Terminologies.

3.2.  Network Digital Twin

   The Network Digital Twin is a digital representation that is used in
   the context of network.  The concept and architecture of the Network
   Digital Twin are specified in
   [I-D.irtf-nmrg-network-digital-twin-arch].  Three core functional
   components which includes Data Repository component, a Service
   Mapping Models component, and an NDT Management component are
   introduced to characterize the Network Digital Twin and its reference
   architecture.

   The Network Digital Twin is widely recognized to be useful as an
   advanced platform for network emulation, serving as a tool for
   scenario planning, impact analysis, and change management.  By
   delivering applications requests to the Network Digital Twin through
   standardized interfaces (see Section 9.4 of
   [I-D.irtf-nmrg-network-digital-twin-arch]), the Network Digital Twin
   exposes the various capabilities to network applications.

4.  Characteristics of AI driven Network Operations

   AIOPS was first defined by Gartner in 2016, combining "artificial
   intelligence" and "IT operations" to describe the application of AI
   and machine learning to enhance IT operations.  However there is no
   unified definition for characteristic of "AI driven network
   operations" within the networking industry.  Referring to the
   characteristics of AIOPS in IT field and the characteristics of
   networking itself, this document introduces six key elements (i.e.,
   awareness, decision, analysis, execution, intent and knowledge) to
   characterize the AI driven network operation and its use, as shown in
   Figure 1.  They together form a close-loop of network operation and
   management.

           +---------------------------------------------------+
           |                  +---------+                      |
           |                  |  Intent |                      |
           |                  +---------+                      |
           |                                                   |
           | +-----------+                       +-----------+ |
           | |  Analysis |                       | Decision  | |
           | +-----------+       --------        +-----------+ |
           |                 ////        \\\\                  |
           |                |AI Driven Network|                |
           |                |  Operations    |                 |
           |                 \\\\        ////                  |
           |                     --------                      |
           | +-----------+                      +------------+ |
           | |  Awareness|                      |  Execution | |
           | +-----------+                      +------------+ |
           |                                                   |
           |                 +-----------+                     |
           |                 | Knowledge |                     |
           |                 +-----------+                     |
           +---------------------------------------------------+

        Figure 1: Six Key Elements to Characterize AI driven network
                                 operation

   *  Intent:  Intent is defined as a set of operational goals and
         outcomes defined in a declarative manner without specifying how
         to achieve or implement them in [RFC9315].  The Network AI
         Agent must accurately interpret and understand the user's high-
         level business or operational objectives, this involves
         translating declarative requirements into specific network
         instructions, e.g., configurations.

   *  Knowledge:  The Network AI agent relies on a knowledge base that
         includes network policies, historical data, expert experience,
         extra-system experience (updates to LLMs/their implied
         ‘knowledge bases’) and Manually or semi-manually entered
         knowledge, e.g., new equipment spec sheets,best practices in
         product manual.  The knowledge is used to inform its analysis,
         decision-making, and execution processes.  Over time, the
         Network AI agent can expand its knowledge through machine
         learning, incorporating new data and experiences to improve its
         performance.  For example, it learns which configurations are
         optimal for specific scenarios or how to respond most
         effectively to particular types of network incidents
         [I-D.ietf-nmop-network-incident-yang].

   *  Analysis:  The Network AI agent continuously analyzes vast amounts
         of network data from various sources, including network
         telemetry [RFC9232] and external feeds, and identify the gap
         between user intent and the existing network status.  By
         integrating Network digital twin
         [I-D.irtf-nmrg-network-digital-twin-arch] with Network AI agent
         and leveraging machine learning and other data analytics
         techniques, it also identifies network fault, problem,
         incident, anomaly and perform data driven intelligent analysis
         such as service impact analysis, and so on.  Their distinction
         is further discussed in [I-D.ietf-nmop-terminology].

   *  Decision:  Based on the intent and network analysis, AI makes
         informed decisions.  By integrating network digital twin
         [I-D.irtf-nmrg-network-digital-twin-arch] and AI, the
         intelligence decisions making can be realized.  These decisions
         could involve dynamically adjusting network parameters, e.g.,
         rerouting traffic to avoid congestion.  The decision-making
         process is driven by predefined policies, real-time data
         analysis, and AI models (e.g., LLMs) that enable the Network AI
         agent to choose the best course of action to meet the specified
         intent.  Network AI agent may also verify the correctness of
         the decision outcome by performing some network simulation or
         validation process.

   *  Awareness:  Awareness is achieved through real-time monitoring and
         data collection.  The Network AI agent maintains a
         comprehensive visibility of the network, enabling it to make
         context-aware decisions.  Network operators can also use the
         awareness understand the exact cause of specific network issues
         and achieve closed-loop decision-making.

   *  Execution:  Once a decision is made, the Network AI agent executes
         the necessary actions to implement it.  This could involve,
         e.g., sending configuration to network controllers or network
         devices through NETCONF/RESTCONF protocols.  The execution is
         carried out in a controlled and precise manner to ensure that
         the network behaves as intended without causing disruptions.
         The Network AI agent also verifies that the executed actions
         have the desired effect and makes the proper adjustments if
         needed.

5.  Architecture Design

5.1.  Overall Architecture

   Figure 2 provides the overall architecture for integrating Network
   Digital Twin and Network AI Agent System.  The components and
   functional interfaces are discussed in Section 5.2 and Section 5.3,
   respectively.  The use cases described in Section 9 show how
   different components are used selectively to provide different
   services.  It is important to understand that the relationships and
   interfaces shown between components in this figure are illustrative
   of some of the common or likely interactions; however, this figure
   does not preclude other interfaces and relationships as necessary to
   realize specific functionality.

+------------------------------------------------------------------------+
|Network Applications                                                    |
|            +-------+   +-------+          +-------+                    |
|            | App 1 |   | App 2 |   ...    | App n |                    |
|            +-------+   +-------+          +-------+                    |
+-------------------------^----------------------------------------------+
                          | Intent
+-------------------------+----------------------------------------------+
|Autonomous Domain        |                                              |
|+------------------------+-----------------------+   +----------------+ |
||Multi-Agent System      |                       |   |  Agent Gateway | |
||                +-------v--------+              |   |                | |
||                |Network AI Agent|              |   |+--------------+| |
||                +-------^--------+              |   || Registration || |
||                        |                       |   |+--------------+| |
||       +----------------+------------+--------+ <--->+--------------+| |
||       |                |            |        | |   ||   Security   || |
||+------v-----+ +--------v---+ +------v-----+  v |   |+--------------+| |
|||Task Agent 1<->Task Agent 2<->Task Agent 3| ...<-+ |+--------------+| |
||+------------+ +------------+ +------------+    | | ||Observability || |
|+-----------------------^------------------------+ | |+--------------+| |
|                        |                          | |+--------------+| |
|+-----------------------v------------------------+ | ||Knowledge Base|| |
||            Network Digital Twin                | | |+--------------+| |
|+-----------------------^------------------------+ | +------^---------+ |
|                        |                          |        |           |
|+--------------------------------------------------v--------+---------+ |
||Physical Network                                           |         | |
||      +---------+    +------------------+             +----v----+    | |
||      |         |    |                  |             |  +-----+|    | |
||      |   NE    |    |NE(lightweight AI)|     ...     |NE|Agent||    | |
||      |         |    |                  |             |  +-----+|    | |
||      +---------+    +------------------+             +---------+    | |
|+----------------+----------------------------------------------------+ |
+------------------------------------------------------------------------+

   Figure 2: An Architecture for Integrating Network AI Agent with
                         Network Digital Twin

5.2.  Functional Components

   This section describes the functional components shown as boxes in
   Figure 2.  The interactions between those components, the functional
   interfaces, are described in Section 5.3.

5.2.1.  Network Applications

   Various network applications at the service level can effectively run
   over a AI driven Network operation platform to implement either
   conventional or innovative network operations, with low cost and less
   service impact on real networks.

   A network application may be a software tool that a user uses to make
   requests to the network to set up specific services such as end-to-
   end connections or scheduled bandwidth reservations or NOC
   Application /Service AI Agent Application that is responsible for
   monitoring, managing, and maintaining the health, performance, and
   availability of complex networks.

   Network applications make requests that need to be addressed by the
   AI driven network.  Such requests are exchanged through a northbound
   intent interface (e.g., Restful API, Natural Language Programming
   Interface(NLPI),A2A, A2A-T), so that they can be applied by multi-
   agent system at the appropriate twin instance(s).

5.2.2.  Autonomous Domain

   An autonomous domain is a self-governing network that integrates NDT
   and AI driven capabilities to achieve autonomous network management.
   It comprises the following sub-components.

5.2.2.1.  Multi-Agent System

   Multi-Agent system acts as the smart brain of the Autonomous Domain,
   which is responsible for conducting AI-based analysis and making
   decisions regarding network management operations.  It usually
   comprises a Network AI Agent and one or multiple task agents.

   The Network AI Agent coordinates cross-task-agent collaboration,
   aligns tasks with user intent, and supervises the task execution of
   each task agent.  And task agents are designed to perform specific
   functionalities, they could be scenario-oriented and classified
   according to the function they perform.  Task Agents can adapt to new
   circumstances through access to evolving knowledge and reasoning,
   planning.  It leverages the inference of LLM, the simulation of
   Network Digital Twin, and the contextual and domain-specific
   knowledge provided by Knowledge Base to accomplish specific network
   operation task.  Some ongoing efforts (MCP [MCP], A2A [A2A]) in the
   industry may help with multi-agents coordination.

5.2.2.2.  Agent Gateway

   The Agent Gateway, which serves as a central management hub, provides
   essential services for the Multi-Agent System, including agent
   registration/discovery, authentication, observability, and knowledge
   base.

5.2.2.2.1.  Registration

   AI Agents need to first discover each other and understand their
   capabilities to collaborate.  Agent Registration manages the process
   by which new agents could join the system, making them discoverable
   and available.  It supports the unified registration of all AI agents
   within the autonomous domain, including those residing on network
   devices.  Each Agent instance submits its own metadata information
   including URI, supported authentication methods, and capabilities to
   the Agent Registry.  And the consumer Agent (e.g., the Network AI
   Agent or task agent) could query or subscribe to the Agent Registry
   to find appropriate Agents for task execution.

   Agent skills [Agent-skills], introduced by Anthropic, provides a new
   way for Agents to improve how they perform specific tasks through
   folds that include instructions, scripts, and resources that are only
   loaded when needed.  Skills are folds containing a "skill.md" file,
   Registration component enables Agents to query directories for
   required skills.

   [A2A] implements Agent Registration by providing the Agent Card
   mechanism to ensure Agents from different vendors can register and
   discover other Agents they need.

5.2.2.2.2.  Security

   The security component enforces trusted inter-Agent communication by
   verifying the identity of AI Agents and enforcing security policies
   throughout their interaction.  It provides unified security
   functionalities for all AI Agents within the autonomous domain,
   including those residing on network devices.  Some existing
   authentication methods such as OAuth 2.0, allow to issue each AI
   Agent its own authentication credentials to establish trusted
   communication.

   Standardized protocols like TLS (Transport Level Security) could be
   leveraged to protect sensitive data exchanged between AI Agents.

   It is also worth noting that once authenticated, authorization
   defines the specific tools and data an agent can access, which often
   using a Least Privilege access control method.  It is also
   recommended to log every Agent decision and tooling call to maintain
   audit trail.

5.2.2.3.  Observability

   Observability component provides unified monitoring capabilities for
   all AI agents within the autonomous domain and enable network
   operators to gain deep insights into Agent behaviors.  It collects
   logs, metrics and traces for each Agent and provides end-to-end
   visibility into task progress, failures, and network performance such
   as latency.

   In addition, it can also make sure every action is governed by
   declarative policy, logged, and traceable for operational integrity,
   e.g., it can discern whether a human-in-the-loop approved an action
   or if the agent acted autonomously.

5.2.2.3.1.  Knowledge Base

   The Knowledge Base serves as a crucial repository of information
   within the architecture.  It enables the injection of expert
   knowledge and chain of thoughts, provides the necessary knowledge and
   memory that helps Agents make more accurate and practive context-
   aware decisions.  It also helps mitigate the hallucination problems
   that can arise in large-scale models, which enhances the accuracy of
   task execution.  Additionally, the Knowledge Base plays a key role in
   providing the data needed for techniques like Retrieval-Augmented
   Generation (RAG), which further boosts the system's ability to
   generate reliable and relevant outputs.

   In case of coupling MCP [MCP] with the network management system, the
   new knowledge also can be used to support modification of the
   currently operating automation Closed Loop, such as: - Choice of
   tools (data, analytics, algorithms/decision processes, closed loops)
   - Orchestration of tools

5.2.2.4.  Network Digital Twin

   A Network Digital Twin provides an enhanced and optimized solution in
   the face of increasing network and business types, scale, and
   complexity.  It simulates the behavior, performance, and
   characteristics of the actual network, which could help in validation
   and testing scenarios, analyzing and predicting network behavior
   without affecting the real physical network.

   As described in Section 7 of
   [I-D.irtf-nmrg-network-digital-twin-arch], the core functional
   components of an Network Digital Twin includes Data Repository,
   Service Mapping Models, and a Network Digital Twin Management
   component.  The Network Digital Twin collects the real-time
   operational and instrumentation data from network through the
   appropriate real network-facing input interfaces, and it delivers NDT
   services through appropriate application-facing output interfaces,
   which is the interfaces to Network AI Agent(s) in Figure 2.

5.2.2.5.  Physical Network

   This is the actual hardware and infrastructure that makes up the
   network, which includes a set of network devices and wiring.  In a
   physical network, Network Elements (NEs) with Lightweight AI
   [I-D.irtf-nmrg-ai-challenges] or AI Agent may also achieve some local
   close loop without relying on human intervention.  It is also
   possible for Lightweight AI or AI Agent to coordinate with other AI
   Agent(s) to enhance the automation and efficiency of network
   operations.  The Network Lightweight AI models could be trained,
   validated, deployed, and executed on Network Elements, and further
   refined (e.g., model re-training) through monitoring and continuous
   optimization based on feedback from LLM.

5.3.  Functional Interfaces

   This section describes the interfaces between functional components
   that might be externalized in an implementation allowing the
   components to be distributed across platforms.  Where existing
   protocols might provide all or most of the necessary capabilities,
   they are noted.

   As noted in Section 5.1, it is important to understand that the
   relationships and interfaces shown between components in Figure 2 are
   illustrative of some of the common or likely interactions; however,
   this figure and the descriptions in the subsections below do not
   preclude other interfaces and relationships as necessary to realize
   specific functionality.  Thus, some of the interfaces described below
   might not be visible as specific relationships in Figure 2, but they
   can nevertheless exist.

5.3.1.  Human in the Loop

   The architecture allows human experts to monitor, guide, approve, or
   intervene in the AI driven network operations.  Human may provide
   guidance and make critical decisions when necessary.  By involving
   human in the process, the architecture can leverage their insights
   and experience, ensuring AI actions align with organizational goals.

   Human in the loop is also helpful to provide a safeguard for complex
   or sensitive decisions, where human judgement is essential to avoid
   potential errors or ethical dilemmas.

   This typically uses natural language as the primary mode of
   interaction, a chat platform that allows for conversational
   interaction with AI Agents can be leveraged.  In some scenarios,
   operators may use structured format for strategy injection via
   workflows.  Protocols like A2A [A2A], and RESTful API can be
   leveraged.

5.3.2.  Application to Network AI Agent Interface

   Intent based Network Management helps in delivering application
   requests to the AI Driven network operation platform and exposing the
   various platform capabilities to network applications.

   Standardized protocols and interfaces facilitate smooth communication
   between applications and AI driven network operation platform and
   ensures different systems from various vendors can work together
   seamlessly.  The interfaces between Network applications and Network
   AI Agent can adopt IG1453 Agent to Agent Protocol for Telecoms (A2A-
   T) [A2A-T] specified by TM Forum.

5.3.3.  Network AI Agent to Task AI Agent Interface (Single Autonomous
        Domain)

   This interface governs the coordination and task delegation within
   the Multi-Agent System of a single Autonomous Domain.  The Network AI
   Agent, acting as the principal coordinator, uses this interface to
   decompose high-level goals into specific tasks and assign them to
   specialized Task Agents (e.g., for configuration generation or fault
   diagnosis).  It facilitates communication for task assignment,
   progress monitoring, and result aggregation.  This coordination can
   be implemented using protocols like [A2A-T].

5.3.4.  Network AI Agent to Network AI Agent Interface (Cross Autonomous
        Domain)

   This interface enables collaboration and information exchange between
   Network AI Agents residing in different Autonomous Domains.  It is
   essential for scenarios requiring end-to-end service assurance or
   coordinated optimization across multi-domain networks.  Through this
   interface, Network AI Agents can negotiate resource allocation, share
   summarized domain-specific insights (while preserving detail
   isolation for privacy and scalability), and coordinate actions to
   fulfill cross-domain objectives.  Standardized protocols like A2A-T
   [A2A-T], designed for agent interoperability in telecommunication
   area, are candidate technologies for implementing this cross-domain
   interface, ensuring secure and reliable interaction between
   autonomous systems from different administrative domains.

5.3.5.  Network AI Agent/Task AI Agent to Agent Gateway Interface

   The interface between Multi-Agent System and Agent Gateway serves as
   the management bridge which encompasses a set of services designed to
   manage the lifecycle, security, and collaborative capabilities of the
   AI Agents.

   Registration handles Agent onboarding, lifecycle tracking (e.g.,
   heartbeat monitoring, status updates), and capability-based Agent
   discovery.  Interfaces like RESTful APIs with structural schema for
   AI Agents metadata description could be leveraged.  Protocols like
   A2A [A2A] Agent card mechanism may also be used to ensure
   interoperability among different Agent vendors.  It is also worth
   noting that message queue mechanisms such as Kafka could also be a
   candidate interface for asynchronous communications for agent
   registration and discovery.

   Authentication ensures trusted inter-Agent communication by verifying
   the identity of AI Agents and enforcing security policies throughout
   their interaction.  Protocols like Transport Layer Security (TLS)
   could be leveraged for in-transit data Protection.  While OAuth 2.0
   and OpenID Connect are increasingly used to authenticate AI Agents.

   The interface between AI Agent and Knowledge Base is specified in
   Section 5.3.7.

5.3.6.  Network AI Agent to Network Digital Twin Interface

   The interface between Multi-Agent System and Network Digital Twin are
   the application-facing interface as defined in
   [I-D.irtf-nmrg-network-digital-twin-arch].  Furthermore, the Model
   Context Protocol (MCP) [MCP] can be leveraged to standardize this
   interaction, enabling the NDT to expose its simulation and analysis
   capabilities as a set of discoverable "tools" that the AI Agent can
   dynamically invoke.  This MCP-based approach facilitates seamless
   integration and richer contextual exchange between the Agent and the
   NDT.

5.3.7.  Network AI Agent to Knowledge Base Interface

   Knowledge Base service provides contextual data and insights to
   enhance the decision-making accuracy of the Multi-Agent System.

   Interfaces such as Cypher or SPARQL with schema-defined data models
   (e.g., LPG or RDF for knowledge representation) allow efficient
   retrieval and updates.  Other high-throughput interfaces such as gRPC
   or RESTful API can be the candidate for synchronous semantic search
   queries.  For large-scale knowledge operations, asynchronous data
   message systems (e.g., Kafka) can also be employed for data ingestion
   and real-time knowledge synchronization across distributed Agents.

   Additionally, the Model Context Protocol (MCP) [MCP] could also serve
   as a standardized interface for AI Agents to dynamically access and
   utilize a wide range of tools and data sources provided by the
   Knowledge Base.  It enables the Knowledge Base to expose contextual
   information, expert rules, and external data as "tools" that Agents
   can invoke, significantly enhancing their reasoning and problem-
   solving capabilities.

5.3.8.  Task AI Agent to Physical Network Interface

5.3.8.1.  Data Collection

   Data Collection interface is responsible for gathering data from the
   physical network through various different tools and methods (e.g.,
   IPFIX [RFC7011], YANG-push [RFC8639],[RFC8641], BMP [RFC7854], and
   MCP [MCP]).  It collects various types of network data including
   configuration data, operational data, network topology, routing data,
   logs, and trace on management plane, control plane, and forwarding
   plane as needed.  The collected data is fed into the Network Digital
   Twin and Network AI Agent(s) to provide with up-to-date information
   about the current state of the physical network.

5.3.8.2.  Configuration

   Once network decisions are made and confirmed, the Multi-Agent System
   performs specific actions to the physical network, e.g., modify
   specific configuration on network controllers or network devices
   through protocols like NETCONF [RFC6241] , RESTCONF [RFC8040], MCP
   [MCP].  It is the component that makes the planned control and
   management changes a reality in the real physical network.

5.3.8.3.  Lightweight AI and Large AI Model Collaboration Interface

   Collaboration between small AI model and large AI model is also
   designed to be supported by this interface.

   In the past, we only support AI and machine learning technologies at
   the network level, e.g., we can use collected various different
   network data to provide network analysis and generate network
   insight.  With more intelligence introduced into the network element,
   more GPU/NPU resource can be allocated for AI inference, this make
   collaboration between large AI model and small AI model possible.

   Large AI models can provide basic logical reasoning and generalized
   analytical decision-making capabilities While specialized small AI
   models can provide efficient problem-solving capabilities in
   specialized areas.  The synergy between the two allows the AI agent
   to combine both multitasking generalization capabilities and domain
   expertise, thus minimizing the reliance on human intervention in the
   network management process.

   On one hand, we can use accumulated field engineering expertise to
   train large AI model into one foundation model for fault management
   AI agent, On the other hand, we can deploy small AI model, leverage
   hardware resource or chipset resource in the intelligent network
   element to collect more fine granularity data or provide local
   processing for Collected data and summary report generation, Trend
   prediction, etc.  When small AI model is outdated and unable to
   detect specific applications or security risk, these specific
   applications and security risk information can be collected by
   network analytics platform to retrain this small AI model and re-
   deploy it in the same network element when this small AI model has
   been trained to work correctly to detect applications or security
   risk.

   With collaboration between large AI model and small AI model, we can
   allow Network AI Agent within the Network controller interact with
   network element and has more quick response to network change.

   This collaboration, facilitated by APIs or agent communication
   protocols like A2A [A2A], combines the generalization power of large
   models with the efficiency and low-latency of specialized small
   models, leading to quicker and more context-aware responses to
   network change.

5.3.9.  Feedback-driven Improvement Interface

   The architecture should incorporate mechanism for continuous
   improvement based on feedback.  This includes collecting data on AI
   decisions, network performance, and user feedback to identify areas
   for enhancement.  By analyzing the feedback, the system can adapt and
   optimize its operations over time, leading to better performance and
   more accurate decision-making.  For example, if a Network AI Agent
   fails to accurately identify the exact cause of a network incident,
   the relevant records can be submitted as negative samples to the LLM
   which provides inference services, this allows the LLM to be trained
   on these negative samples for optimization.

   This interface is implemented through a combination of system
   interfaces that collect, process, and apply feedback.  Operational
   feedback—including the outcomes of AI decisions, network state
   metrics—is collected as structured data via system logging streams
   (e.g., in JSON format) and message queues (e.g., Kafka).  This data
   is then consumed by analytics components and machine learning
   platforms through APIs (e.g., RESTful, gRPC) to refine AI models, for
   instance, by using failure records as negative samples for fine-
   tuning.  Subsequently, optimized models and updated knowledge are
   deployed back into the runtime system via model serving and
   configuration management interfaces, closing the improvement loop.

5.3.10.  Network Element AI Agent and Network AI Agent Collaboration
         Interface

   Network devices collect information from multiple dimensions,
   including flow information, configuration, events, alarms, logs,
   dynamic topology and routes, and device status (including CPU,
   memory, and hardware health).  With large amount of data collected to
   the domain controller for analysis and processing, the data accuracy
   is very limited and therefore it is hard to determine the service
   impact within 1 minute.  In addition, it usually require multiple
   step interaction, complex task management with various different data
   types or data sources.

   To address those challenges, the network AI Agent can delegate
   massive data analysis and processing to distributed AI Agent in each
   network element, e.g., a) only allow distributed AI Agent export
   processed analytic data to help establish global view of network
   observability. b) or export key network fault information for Network
   AI Agent for further investigation the root cause of the problem.

   For the former case, routing protocol specific fault data such as BGP
   Status Changed, OSPF Neighbor state changes, IS-IS Adjacency Changed
   data or hardware related fault data such as Optical fail, Physical
   Port down can be collected and using pre-trained LLM model with
   expert experience to match fault pattern and invoke corresponding
   routing protocol troubleshooting MCP tools and finally root cause.
   In addition, it allows network maintenance engineer using nature
   language interface to look up troubleshooting information or it
   allows Network AI Agent or Task Agent at the network element using
   MCP interface to invoke tools from MCP server within the network
   element.

                               +------------+     +------------+
                               |  Network   |     |            |
              Human Operator   |  AI Agent  |     | Task Agent |
                   |           |            |     |            |
                   |           |+----------+|     |+----------+|
                   |           ||MCP Client||     ||MCP Client||
                   |           |+----------+|     |+----+-----+|
                 Intent        +------+-----+     +-----+------+
                   |                  |                 |
           +-------+------------------+-----------------+-------+
           |       |                  +------------+    |       |
           | +-----V-----------------+    +--------+----+------+|
           | |Protocol Fault Agent   |    |Protocol|Fault Agent||
           | |  +---------+ +------+ |    |  +-----V----V-+    ||
           | |  |  ONNOX  | | MCP  +-+----+-->    MCP     |    ||
           | |  |  Model  | |Client| |    |  |   Server   |    ||
           | |  +---------+ +------+ |    |  +------------+    ||
           | +-----------------------+    +--------------------+|
           |                                                    |
           +----------------------------------------------------+
                         Smart Network Element

          Figure 3: Network Element AI Agent and Network AI Agent
                        Collaboration Usage Example

6.  AI Driven Network Operations: Relationship Between Characteristics
    and Functional Components

   The architecture in Figure 2 provides a concrete implementation
   framework to realize the six key characteristics of AI-driven network
   operations described in Section 4.  Each characteristic is directly
   supported by specific functional components within the Autonomous
   Domain.  The following clarifies how the architecture operationalizes
   these characteristics:

   *  Intent:  The Network Applications Layer conveys a high-level user
         intent via northbound interfaces.  The Network AI Agent
         interprets this intent and translates it into actionable
         network operation tasks to each task Agent.

   *  Knowledge:  The Knowledge Base in Agent Gateway serves as the
         central repository for domain-specific knowledge, expert rules,
         and historical data.  It provides the necessary context and
         long/short memory to support accurate decision-making by task
         Agents.

   *  Analysis:  The AI Agent in Multi-Agent System performs intelligent
         analysis using data and tools.  It leverages the Network
         Digital Twin to simulate and validate scenarios, enabling data-
         driven insights and gap analysis between intent and current
         network state.

   *  Decision:  The AI Agent in Multi-Agent System makes informed
         decisions based on its analysis results.  It utilizes the
         Network Digital Twin for risk-free validation before finalizing
         decisions.  The decision may be sent to human operators for
         confirmation before actions are taken.

   *  Awareness:  The AI Agent in Multi-Agent System gathers data from
         the Physical Network, it may also fetch data from the Network
         Digital Twin which maintains a dynamic, virtual representation
         of Physical Network.  Together, they provide comprehensive
         network visibility and context-aware awareness.

   *  Execution: ：The AI Agent in Multi-Agent System implements
      validated decisions by applying configurations or control actions
      to the Physical Network via southbound interfaces such as NETCONF,
      RESTCONF, or Model Context Protocol [MCP].

7.  AI Agent Registration and Team formation

                                                     +----------------+
                                                     |Agent Gateway   |
                    +-----------+                    | +------------+ |
                    |  Network  |      Register      | |            | |
                    | AI Agent  +--------------------+->            | |
                    +-----------+                    | |Registration| |
          |---------------+----------------+---------+->            | |
         Register       Register         Register    | |  Center    | |
          |               |                |         | +------------+ |
   +------+----+   +------+-----+    +-----+----+    |                |
   |   Fault   |   |Optimization|    | Change   |    |                |
   | Task Agent|   |Task Agent  |    |Task Agent| ...|                |
   +-----------+   +------------+    +----------+    +----------------+


                    +-----------+
                    |  Incident |
                    |   Center  |                    +----------------+
                    +-----+-----+                    |Agent Gateway   |
                     Incident Notif                  | +------------+ |
                          |        Registry based    | |   Agent    | |
           Intent   +-----V-----+    Discovery       | |            | |
          Objective |  Network  +--------------------+->Registration| |
     Human ---------> AI Agent  |                    | |            | |
    Operator        |           |                    | |  Center    | |
                    +-----+-----+                    | +------------+ |
             Policy Definition(Obj+Incident+Action)  |                |
                    Task Planning                    |                |
                   Agent Team Formation              |                |
          +---------------+----------------+         +----------------+
          |               |                |
    +-----+-----+    +----+------+    +----+------+
    |           |    |           |    |           |
    |Task Agent1|    |Task Agent1|    |Task Agent1|
    +-----------+    +-----------+    +-----------+

      Figure 4: AI Agent Registration and Team formation Usage Example

   The Agent gateway at the network level provides agent registration
   for both embedded AI agent in each network element and network AI
   agent and associated task agents.  The following steps are performed
   to provide Event driven AI Agent Team formation within the Agentic AI
   network management architecture:

   Step 1:  Human Operator pre-provision user intent which comprises
      objective, incident list and corresponding action list.

   Step 2:  Network AI Agent receieves user intent and generate
      corresponding policies which comprise objective, incident list and
      corresponding action list.  In addition, Network AI Agent
      subscribe corresponding incidents from incident center.

   Step3:  Network AI agent generate task planning based on objective
      and then discover matched task agent lists based on planned task
      from registration center within the agent gateway.

   Step4:  Upon receiving incident from the incident center, network AI
      agent assign the tasks to task agents corresponding to specific
      incident received.

   Step 5:  Network AI Agent distribute task to corresponding task
      agents and complete task agent team formation.

8.  Agent to Agent Communication Security

      Artifacts Delivery
    +-----------+
    |           |                                    +----------------+
    |           |                                     Agent Gateway   |
    |        +--V--------+  Agent Identity Discovery | +------------+ |
    |        |    Task   <---------------------------+->   Agent    | |
    |        |  AI Agent <---------------------+     | |            | |
    |        +-^------^--+  Authentication     |  +--+->Registration| |
    |          |      |       Handshake        |  |  | |            | |
    |   Secure |  Stateful                     |  |  | |  Center    | |
    |   Task   |   Monitoring                  |  |  | +------------+ |
    Negotiation|      |                        |  |  |                |
    |          |      |     Agent Identity     |  |  | +-------------+|
    |        +-V------V--+     Discoverey      +--+--+->   Agent     ||
    |        |    Task   +------------------------+  | |Authorization||
    +-------->  AI Agent <---------------------------+->   Server    ||
             +-----------+  Authentication           | |             ||
                             Handshake               | +-------------+|
                                                     +----------------+

       Figure 5: Agent to Agent Communication Security Usage Example

   The following steps are performed to provide Agent to Agent
   Communication Security within the Agentic AI network management
   architecture:

   Step 1.  Discovery via Agent Card:  The workflow begins when a client
      agent requests the Agent Card from the remote agent's /.well-
      known/agent.json endpoint.  This JSON file acts as a secure
      manifest, declaring the agent’s identity, capabilities, and
      required security schemes.

   Step 2.  Authentication Handshake:  Before any task is sent, the
      client must fulfill the authentication requirements listed in the
      Agent Card.  This typically involves an OAuth 2.0 flow where the
      client obtains a JSON Web Token (JWT) to prove its identity and
      permissions.

   Step 3.  Secure Task Initiation: :Communication is established over
   HTTPS/TLS.  The client sends a tasks/send request using JSON-RPC 2.0.
   The server validates the token and authorizes the specific task based
   on the client's role.

   Step 4.  Stateful Monitoring & Feedback: :The task moves through a
   strictly defined lifecycle (submitted → working → completed).
   Security is maintained throughout as updates are streamed via Server-
   Sent Events (SSE) or webhooks, each tied to the unique, authorized
   Task ID.

   Step 5.  Artifact Delivery:  Final results (Artifacts) are delivered
      only after the task reaches a completed state.  These are
      structured objects (text, files, or data) returned to the verified
      requester, ensuring data integrity and preventing unauthorized
      access to output.

9.  AI Driven Network Operations: A collection of Use Cases

   Network AI Agent could help in the following phases which are usually
   mentioned in network management:

   *  Network Planning and Design: includes the understanding of user
      intent, generation of solutions, and simulation for decision-
      making.

   *  Service Deployment: includes the construction of the physical
      network, as well as intent understanding, pre-deployment
      simulation, automated configuration, post-deployment validation,
      and other capabilities to enhance the efficiency and accuracy of
      network configuration for service deployment.

   *  Network Monitoring and Troubleshooting: includes intent
      monitoring, issues identification, solution generation, evaluation
      and decision-making, solution implementation, and service
      validation.

   *  Network Change and Optimization: involves the design, evaluation,
      decision-making, implementation, and validation of network
      configuration changes or optimizations to improve network
      operation efficiency.

   In all phases and use cases, after the Agent performs specific
   action, it always continuously monitors the network by data
   collection.  Based on the result of network running analysis and user
   explicit feedback, it may adjust and optimize the management strategy
   if necessary.

9.1.  Multi-Agent Collaboration on Network Configuration Change

   Network configuration changes are needed in scenarios such as
   optimizing network or service performance, provisioning new network
   services, or resolving network incidents/faults.

                       +------------+
         Network       |  Service   |
         Operator ----->  AI Agent  |
                       |            |
                       +-----+------+
                             |Configuration               +---------+
                             |Change Intent               |         |
                     +-------V---------+                  |         |
                     |Network AI Agent |                  |         |
                     |     Goal        |                  |         |
             +-------| Task-1,Task-2   +------------------>         |
             |       |   ... Task-n    +-------+          | Network |
             |       +-------+---------+       |          | Digital |
             |               |                 |          |  Twin   |
             |               |                 |          |  Task   |
       +-----V------+  +-----V-------+  +------V----+     |  Agent  |
       |   Config   |  |  Config     |  |  Config   <----->         |
       | Generation |  | Distribution|  |Validation |     |         |
       | Task Agent |  |  Task Agent |  | Task Agent|     |         |
       +------------+  +-------------+  +-----^-----+     +---------+
                                              |
                                       +------V------+
                                       |  Resource   |
                                       | Allocation  |
                                       | Task Agent  |
                                       +-------------+

     Figure 6: Intent Based Network Configuration Change Usage Example

   Network configuration change leveraging Network AI Agent and Network
   Digital Twin may experience the following typical steps:

   Step 1:  The network operator inputs the intent of network
      configuration change into the Network AI Agent using natural
      language.  The network operator may simply explain the objectives
      and requirements of the changes.

   Step 2:  Network AI Agent first verifies the identity of the user
      requesting the change and checks the user's permissions to make
      certain types of network changes against predefined rules or
      policies.  It then understands and parses the initial intent of
      the request, by leveraging the powerful knowledge and reasoning
      capabilities of LLM and decompose the tasks into configuration
      generation task, configuration distribution task, configuration
      validation task and assign to corresponding task agents.
      Configuration generation Task Agent first generates initial
      suggestions for specific network configuration update, which may
      include multiple possible network configuration change plans if
      possible.

   Step 3:  Network AI Agent further communicates with the Configuration
      Validation task agent and Network Digital Twin task agent to
      validate the suggested configuration change, including the syntax
      and semantics of the configuration, verification of effected
      application and resources.  The network digital Twin task agent
      may generate a report indicating the validation result, and
      suggested configuration fix when the validation fails after
      network simulation leveraging the current physical network
      operational state.

   Step 4:  Network AI Agent may generate a configuration change plan
      and submit to the network operator for approval.  Based on the
      feedback from the operator, Network AI Agent then further decides
      whether to optimize the change plan or deliver the plan to the
      Configuration Distribution task agent to conduct the physical
      network configuration change.  The configuration distribution task
      agent may further communicate with resource allocation task agent
      to obtain network resource (e.g.,vlan, IP subnet) allocated by
      resource allocation task agent.

9.2.  Multi-Agent Collaboration on Network Troubleshooting

                                  |
                          Human   |Network Troubeshooting
                         Operator |Intent
                                  |                    +---------+
                         +--------V--------+           | Network |
                         | Network AI Agent|           | Digital |
                         |     Goal        |           |  Twin   |
                         | Task-1,Task-2   +----------->  Task   |
                         | ....Task-n      |           |  Agent  |
                         +--------+--------+           +---------+
                                  |
            |------------------+--+-----------+------------+
        +---+----------+ +-----+-----+  +-----+----+ +-----+------+
        |    Fault     | |   Fault   |  |   Fault  | |   Fault    |
        |Identification| | Diagnosis |  |  Repair  | | Prediction |
        | Task Agent   | |Task Agent |  |Task Agent| | Task Agent |
        +--------------+ +-----------+  +----------+ +------------+

        Figure 7: Intent based Network Troubleshooting Usage Example

   The network operator inputs the intent of network configuration
   change into the Network AI Agent using natural language.  Network AI
   Agent could plan and decompose network troubleshooting tasks and
   coordinate with fault identification task agent, fault diagnosis task
   agent, fault repair task agent and fault prediction task agent to
   assist in network troubleshooting in the following significant
   aspects:

   *  Fault Identification:  Network AI Agent coordinates with fault
         identification task agent continuously monitors and aggregates
         data from various sources, the comprehensive data collection
         provides a holistic view of the network operational state.  By
         analyzing the real-time data, fault identification task Agent
         could detect network anomalies swiftly, which enables the
         prompt identification of potential issues before they escalate
         into major faults, minimizing downtime or service disruptions.
         In some cases, the Lightweight AI located in the Network
         Element may handle some simple fault identification tasks
         (e.g., optical module fault automatic identification) to
         enhance the awareness, while the fault identification task
         agent and LLM could leverage their powerful processing
         capabilities to analyze the time-domain data collected from the
         optical module.

   *  Fault Diagnosis:  Once a fault is identified, Network AI Agent
         coordinate with fault diagnosis task agent to delve into
         diagnosing the exact cause, fault diagnosis task agent may also
         invoke some existing operations such as "incident-diagnose" RPC
         defined in [I-D.ietf-nmop-network-incident-yang].  By
         correlating symptoms and/or applying AI models trained on
         historical data, fault diagnosis task agent can narrow down the
         potential causes and pinpoint the exact cause, which
         accelerates the diagnosis process and reduces the time needed
         to address the issue.

   *  Fault Repair:  After diagnosing the fault, Network AI Agent can
         coordinate with fault repair task agent to generate targeted
         repair solutions.  These solutions range from specific
         configuration adjustments to more complex fixes (e.g., hardware
         replacement).  Fault Repair task Agent would also communicate
         with the Network Digital Twin task agent to simulate the
         proposed repair solutions and get feedback from the Network
         Digital Twin task agent.  In advanced setups, fault repair task
         agent may automatically execute these repairs, ensuring quick
         restoration of normal operations and enhancing the overall
         reliability and efficiency of network management.  But the
         fault repair task agent may also first present the fault
         details and repair advice to the network operator for review,
         and proceed to carry out the repair task once it is confirmed.

   *  Fault Prediction  As an advanced enhancement of fault management
         capabilities, fault prediction aims to reduce network risks
         through proactive management that prevents problems before they
         occur.  Before a fault actually occurs, the fault prediction
         task agent can coordinate with network digital twin task agent
         to construct a dynamic simulation model by collecting real-time
         multi-dimensional operational state data, including network
         topology, traffic load, and device performance indicators.
         Based on the network data, the fault predication task agent
         uses large models and machine learning algorithms (such as
         time-series prediction models and anomaly detection models) to
         reason and analyze potential faults—for example, predicting the
         risk of physical link interruption based on optical cable
         signal attenuation data.  Furthermore, the fault prediction
         task Agent generates recommended operations to avoid faults and
         validates them through simulation in the network digital twin
         task agent, thereby achieving predictive maintenance of the
         network.

9.3.  Multi-Agent Collaboration on Network Optimization

                                |
                                |
                        Human   |Network Optimization
                       Operator |Intent
                                |                    +---------+
                       +--------V--------+           | Network |
                       | Network AI Agent|           | Digital |
                       |     Goal        |           |  Twin   |
                       | Task-1,Task-2   +----------->  Task   |
                       | ....Task-n      |           |  Agent  |
                       +--------+--------+           +---------+
                                |
                     +----------+----------------+
                     |                           |
             +-------+------+            +-------+-------+
             | Optimization |            |  Optimization |
             |  Generation  |            |  Distribution |
             | Task Agent   |            | Task Agent    |
             +--------------+            +---------------+

         Figure 8: Intent based Network Optimization Usage Example

   Network optimization is often introduced due to the Network AI
   Agent's awareness of some potential network faults or anomalies
   through continuously monitoring of network operational state, e.g.,
   AI models may predicts network congestion by analyzing historical and
   real-time network traffic data.  It may also be triggered by the
   network operator actively inputting the network optimization intent.

   Based on the analysis of network data and user's intent (if any),
   Network AI Agent collaborate with Optimization Solution Generation
   Task Agent to propose network optimization strategies.  For instance,
   once the network congestion sometime in the future is predicted, it
   may proactively optimize the network configuration, or suggest
   scaling up to meet specific demands.

   Before the network optimization is conducted, Network AI Agent
   coordinates with the network digital twin task agent to implement and
   evaluate the optimization solution using the Network Digital Twin
   platform.  This may need repeated trials and validations based on
   specific evaluation criteria, before the optimal strategy could be
   selected.  Network AI Agent may also first present the suggested
   network optimization solution to the network operator for review, and
   apply it to the physical network through optimization solution
   distribution task agent after obtaining approval from the network
   operator.

9.4.  Network level Energy Efficiency Management in the IP+Optical
      network

                            +-----------------+
                            |  Multi-Domain   |
                            |    AI Agent     |
                            |  GREEN Goal     |
                            | Task-1,Task-2   |
                            | ....Task-n      |
                            +--------+--------+
                                     |
                       +-------------+--------------+
                       |                            |
                 +-----+------+              +------+-----+
                 |    IP      |              |   Optical  |
                 |   Domain   |              |   Domain   |
                 |   Network  |              |   Network  |
                 |   AI Agent |              |   AI Agent |
                 +------------+              +------------+

     Figure 9: Intent based Network level Energy Efficiency Management
                               Usage Example

   Network level Energy Efficiency refer to a set of processes used to
   discover a inventory of capabilities, use specific metrics to monitor
   and assess energy consumption of the entire IP+Optical network ,
   operate, and control the use of available energy in an optimized
   manner while achieving the network’s functional and performance
   requirements by improving overall network utilization.

   Multi-Domain AI Agent can work together with network AI Agent in each
   autonomous domain to allow network operators not only see real time
   energy consumption in the network devices of large scale network
   through interaction with the GREEN Network AI Agent, but also allow
   them see

   o which network devices enable energy saving, which devices not,
   which are legacy ones,

   o The total energy consumption changing trend over the time of the
   day, for all network devices,

   o Energy efficiency changing trend over the time of the day for the
   whole network.

   On the other hand, With the end to end observability to energy
   consumption statistics data and energy efficiency statistics data,
   the Network AI Agent in each autonomous domain can collaborate with
   network digital twin to know which part of the network need to be
   adjusted or optimized based on network status change.

9.5.  Network Security Drills (Human in the Loop)

                                 +----------------+   Human
                                 | Agent Gateway  |  Operator
            +-----------------+  |                | /---------\
            | Network AI Agent|  |+--------------+| | Analyze |
            |     Goal        |  ||              || | Define  |
            | Task-1,Task-2   <-->|Observability |<-> Inject  |
            | ....Task-n      |  ||              || \---------/
            +-------+---------+  |+--------------+|
                    |            |                |
                    |            +---------^------+
                    |                      |
            +-------V------ ---------------V----------------+
            | Dynamic Attack and Defense Verification System|
            |        Based on Network Digital Twin          |
            |      +---------+      +---------+             |
            |      | Dynamic |      | Dynamic |             |
            |      | Security|      |Security |             |
            |      | Attack  |      |Defense  |             |
            |      |  Task   |      |  Task   |             |
            |      |  Agent  |      |  Agent  |             |
            |      +---------+      +---------+             |
            +--------------------^--------------------------+
                                 |Data Collection
            +--------------------+--------------------------+
            |            Network Infrastructure             |
            +-----------------------------------------------+

        Figure 10: Intent based Network Security Drill Usage Example

   The human operator can work together with the Network AI Agent to
   conduct Network security Drill.  The human operator can instruct the
   Network AI Agent with specific injection policy to work with network
   digital twin help construct a dynamic attack-defense verification
   system in network security drills through NDT and AI reasoning
   capabilities.  The dynamic attack-defense verification system
   comprise dynamic security attack task agent and dynamic security
   defense task agent which are responsible security risk attack task
   and security risk defense task respectively assigned by the network
   AI agent.  The dynamic security attack task agent uses generative AI
   to automatically generate diversified attack paths, models network
   topologies with graph neural networks, covers attack stages such as
   reconnaissance and penetration, and dynamically adjusts strategies
   via reinforcement learning to simulate the adaptive characteristics
   of network attacks.  The virtual range built based on the NDT can 1:1
   map the production environment, supporting simulations of composite
   scenarios like ransomware chain attacks and supply chain attacks —
   such as simulating the entire process of Contivirus laterally
   penetrating to domain controllers through weak passwords.

   During drills, Human operator can instruct the Network AI Agent to
   work with the dynamic security defense task agent to automatically
   deploy virtual environments with vulnerabilities, collect defense
   response data in real time through NDT, and generate attack path
   heatmaps and repair suggestions.  This capability can further verify
   emergency response processes, inject real-time threat intelligence to
   dynamically update drill scenarios, and simulate end-to-end automated
   deployment, vulnerability injection, and real-time analysis of
   security drills, enhancing the proactive verification ability of
   defense systems against real-world threats.

10.  Challenges of Integrating Network Digital Twin and Agentic AI into
     Network Management

   In addition to the research challenges in coupling AI and network
   management specified in [I-D.irtf-nmrg-ai-challenges], this document
   also identifies some challenges that need to be considered when
   integrating agentic AI together with network digital twin for network
   operations.

10.1.  Create domain specific language for agents and models

   Feeding network data into machine-readable knowledge for autonomous
   AI agents involves transforming raw telemetry and metadata into a
   structured semantic format.  This process typically uses the Model
   Context Protocol (MCP) and Domain Specific Languages (DSLs) to bridge
   the gap between low-level network signals and high-level AI
   reasoning.

   o Semantic & Contextual

   Network data in the wire format is often low-fidelity and lacks the
   context for AI to "reason" about intent or impact.  AI agents may
   struggle to understand rigid structure for the interaction,e.g., a
   numerical value represents "Frame Delay" without explicit ontological
   mapping.  Multi-task collaboration and Agent operation involve some
   ambiguity and uncertainty.  The natural language interactions should
   be supported for understanding and handling uncertain or ambiguous
   tasks.  With the presence of existing standard of natural language
   interaction, the task of defining common functions for any agent to
   agent communications becomes that of defining the semantics of the
   information that should be transferred, as opposed to defining a
   rigid structure for the interaction.

   o Data Quality & Fragmentation

   Information is often fragmented across multiple vendor tools and
   legacy systems, preventing a unified knowledge model.  Processing
   high-velocity data and non-standardized formats makes it difficult
   for AI to generalize across different device types or data sources.

   o Technical & Computational

   Architectural Limits: Standard hardware often lacks the capacity for
   real-time AI operations at the data-plane level.

   Token/Memory Limits: Large AI models have finite "context windows",
   which restricts their ability to process long or complex network
   sequences.

   o Operational & Trust

   "Black Box" Problem: AI decisions can be opaque, making it hard for
   human operators to audit or trust automated actions.

   Skill Gap: There is a significant shortage of professionals with the
   cross-disciplinary expertise needed for both networking and AI
   development.

10.2.  Trust and Security

   Multi-Agent Collaborations and interactions can be break down into 4
   typical scenarios:

   o Human operator-> AI Agent-> APIs/Tools/APIs/LLMs

   In a single-agent scenario, Human operators access services through
   the network management AI agent.  The network management AI agent has
   multiple functions (fault and optimization), and authentication is
   required to prevent users from Performing unauthorized actions by
   exploiting privilege vulnerabilities,e.g., accessing the optimization
   function interface when they only have fault agent permissions.

   o AI Agent -> API Services

   In a single-agent scenario, the network management AI agent triggers
   tasks automatically based on trace and log information.  In some
   cases, the logging or decision-making process cannot be traced.

   o Human operator-> AI Agent -> multiple AI Agent

   Multiple agents may call each other.  For example, if a faulty agent
   A calls an optimization agent B, authentication is required to
   prevent Manipulating communication channels of agents to influence
   decision-making processes.

   o External AI Agent ->AI Agent-> APIs/Tools/APIs/LLMs

   External AI agents can directly access the network management AI
   Agent by simulating human operation through interface protocols.  For
   example, a customer AI agent can access the Network AI Agent through
   a northbound interface protocol such as A2A, MCP.  In some case,
   there might have target flaws in protocols like MCP or A2A;
   e.g.,consent bypass, context hijacking, etc.

   Ensuring robust security throughout the entire AI-based network
   management architecture is essential to prevent unauthorized access
   and maintain the security of the network infrastructure.  The
   security risk can be break down into the following cases:

   o External system interacts with AI agent

   Human Operators or external systems bypass their privileges to
   operate the Network management AI agent

   *  Human operators operate through a network management AI agent, but
      the service scope that the AI agent can handle may exceed the
      user's authorized privileges, leading to unauthorized access.

   *  Human operators manipulate business operations using agent
      delegation and authorization.

   *  Human operators Coerce intelligent agents to manipulate users into
      performing covert operations.

   o AI Agent Interact with Tools/APIs/LLMs

   *  Interact with Tools/APIs/LLMs with Privilege Escalation

      Since network management AI agents rely on LLM for inference when
      accessing APIs and tools, there is a possibility of malicious
      injection scenarios where the APIs accessed by the agent exceed
      the expected scope,e.g.,Using AI to generate execution
      environments and inject malicious code.

   *  Interact with Tools/APIs/LLMs without audit

      When an agent interacts with an API or tool, the logs are
      currently recorded as system logs, which cannot distinguish
      between different agents, the logging or decision-making process
      for specific agent cannot be traced and pose a risk of
      repudiation.

   o Multiple Agent Collaboration and Communication

   *  Multi-Agent Communication with Privilege Escalation

      When agents communicate with each other via intent communication
      and understanding, there is a cascading permission amplification
      problem,e.g.,AI-generated false information disrupts the reasoning
      process , leading to Privilege Escalation.

   *  Interaction with internal AI Agent

      As a microservice, a network management AI agent can be accessed
      by other services or AI agents,e.g., Performing unauthorized
      operations by exploiting authentication vulnerabilities,which
      poses a risk of Privilege Escalation.

10.3.  Protocols between Agent and Agent/Human operator/Tools

10.3.1.  High Risk Operations

   "network change" in the network management field refers to the
   modification, adjustment, or configuration of physical or logical
   resources in the existing network.  Because these operations directly
   affect the continuity and stability of existing network services,
   even minor unauthorized access or errors can lead to large-scale
   network outages.  In case of high risk operation, the following
   measures should be taken into account.

   o Regardless of whether the initiator of the operation is a human or
   an agent, each network change request must be re-authenticated.

   o For operations involving "bulk deletion" or "core route changes",
   the system must require approval from a second high-privilege account
   before issuing the command or enforcing the policy.

   o High-risk configurations should be tested on a very small scale
   first.  The system should automatically monitor the indicators, and
   if any abnormalities are detected, the configuration should be
   automatically rolled back within milliseconds.

10.3.2.  The Timeliness Requirements of Collaboration

   For real-time network operation and maintenance scenarios with high
   real-time requirements, such as scheduling strategy optimization and
   critical fault repair, the rapid generation of network optimization
   decisions is crucial.  However AI Agents based on large models adopt
   a "Token-based" generation and reasoning approach, which is limited
   by computing power and algorithms, resulting in generally slow
   reasoning speeds.  In addition, the simulation and verification
   process of Network Digital Twin (NDT) further increases decision
   latency, which leads to long end-to-end decision-making time in
   complex scenarios and is difficult to meet the real-time requirements
   of services.

   Also tasks such as fault diagnosis, complaint handling, and user
   experience improvement often have strict time constraints.  For
   example, if a fault is not resolved within a set time, it can trigger
   an escalation of the complaint, requiring efficient collaboration
   among multiple agents.  In addition, In a network management
   environment, you might need agents to subscribe to real-time network
   alarms or telemetry events.  However Google-initiated A2A protocol
   primarily follows a task-oriented "request-response" model and
   doesn't support a native pub/sub or event-driven architecture.

   To improve decision efficiency, continuous efforts are needed in
   lightweight NDT modeling algorithms, optimizing large model reasoning
   frameworks (such as quantization technology and parallel computing),
   and deploying high-performance AI acceleration hardware.

10.3.3.  Collaboration Reliability

   Fault diagnosis and complaint handling in the network management
   field are complex tasks, typically involving 10 to 20+ fields for one
   single message exchange between two AI Agents and requiring a high
   level of expertise.  In addition, Reliable task collaboration is
   incomplete and not sufficient for network management field, e.g.,
   Google-initiated A2A protocol doesn't defined handling strategies for
   task rejection, missing information during task collaboration, and
   failure to achieve task objectives.

   also In network management area, data sources can be diverse and
   heterogeneous, leading to potential issues such as data
   inconsistencies, missing, or outdated data.  Poor-quality data may
   result in inaccurate AI predictions and decisions.  For example, if
   incorrect or outdated network configuration data is provided, the
   model may provide incorrect repair advice when diagnosing network
   incidents or faults, it may suggest checking an non-existing
   interface.  Ensuring that data is properly cleaned, validated, and
   maintained is a significant challenge in providing reliable inputs
   for AI-driven network management.

10.4.  Benchmarking

10.4.1.  Single Agent Benchmarking

   The core of Single Agents assessment lies in its "omnipotence" and
   the quality of its direct interaction with the environment.

   o Task complexity bottleneck

   When dealing with long-term, multi-step tasks, single agents are
   prone to hallucination accumulation and reasoning chain breaks.
   Benchmark tests need to evaluate their persistent logic capabilities
   under context window constraints.

   o Command compliance and control

   The challenge lies in whether the model can strictly follow complex
   system prompts, especially when there are many tool options, which
   can easily lead to tool invocation errors or the omission of some
   instructions.

   o Generalization and memory

   To evaluate how monolithic models can efficiently manage long-term
   memory to handle new tasks without relying on external collaborative
   support.

10.4.2.  Multi-Agent Benchmarking

   The focus of collaborative assessment has shifted from "individual
   capabilities" to "system dynamics":

   o Coordination and communication overhead:

   Multi-agent systems (MAS) involve complex task decomposition and
   allocation (global planning).  Benchmarking needs to measure the
   communication efficiency between agents, alignment consistency, and
   the high latency and cost caused by multi-turn interactions.

   o Error tracing and attribution:

   When the final task fails, it is extremely challenging to accurately
   pinpoint which "role" went wrong or in which round of collaboration
   there was a deviation (failure attribution) due to the presence of
   multiple participants.

   o Swarm intelligence and social emergence:

   It is necessary to assess the dynamics of competition and cooperation
   among intelligent agents, including the existence of systemic risks
   such as information silos, resource waste, or vicious cycles.

11.  Security Considerations

   The security consideration from
   [I-D.irtf-nmrg-network-digital-twin-arch] apply here.  In addition,
   the following architectural risks need to be considered:

   o Memory Poisoning：If the AI/ML models used by the network AI Agent
   or Network digital twin are compromised or poisoned with malicious/
   fake data,they could begin making incorrect or malicious decisions.
   Robust checks and validation are necessary to ensure the integrity of
   these models.  Session isolation or memory access authentication is
   also required to mitigate such risk.

   o Misuse of Tools： When network AI Agent interacts with tools,
   Deceptive prompts or commands can be introduced.  Tool access
   verification, tool monitoring, log tracking of AI tool usage are
   required to mitigate such risk.

   o Privilege Compromise：When human operators interact with Network AI
   Agent or Network AI Agent interact with tools/APIs/LLM, unauthorized
   actions might be performed by exploiting privilege vulnerabilities.
   Fine-grained permission control, dynamic access verification, and
   role change monitoring are required to mitigate such risk.

   o Resource Overload：When Network AI Agent interact with tools/APIs/
   LLMs, system failures might be caused by exploiting resource-
   intensive features.  Deployment of resource management controls to
   limit high-frequency task requests from agents is required to
   mitigate such risk.

   o Cascading Hallucinations：In case of multi-agent collaboration or
   communication, AI-generated false information might disrupt the
   reasoning process.Output verification, secondary verification of AI-
   generated knowledge are required to mitigate such risk.

   o Intent Breaking &Goal Manipulation：When external AI Agent or human
   operators interact with the network AI Agent, reasoning through agent
   planning capabilities might be manipulated.  Planning verification,
   managing reflection processes, goal consistency protection are
   required to mitigate such risk.

   o Misaligned & Deceptive Behaviors：When Network AI Agent interact
   with tools/APIs/LLMs, harmful operations might be performed by
   exploiting reasoning vulnerabilities.  Manual confirmation of high-
   risk operations, logging, monitoring, and deception detection are
   required to mitigate such risk.

   o Repudiation & Untraceability：In case of multi-agent collaboration
   or communication, the logging or decision-making process might not be
   traced.  Logging & cryptographic signature, cryptographic
   verification are required to mitigate such risk.

   o Identity Spoofing & Impersonation：When Human operators interact
   with the network AI Agent or in case of multi-agent collaboration or
   communication,unauthorized operations might be performed by
   exploiting authentication vulnerabilities.  Comprehensive identity
   verification, trust boundary control, and continuous monitoring are
   required to mitigate such risk.

   o Overwhelming HITL(Human In The Loop)：In case of multi-agent
   collaboration or communication,fatigue auditors attack might take
   place.  Developing advanced human-machine interaction frameworks and
   adaptive trust mechanisms are required to mitigate such risk.

   o Unexpected RCE & Code Attacks：When the network AI Agent interacts
   with tools/APIs/LLMs, Using AI to generate execution environments and
   inject malicious code might take place.  Restrict AI code generation
   permissions, sandbox isolation, and manual review of generated code
   are required to mitigate such risk.

   o Agent Communication Poisoning：In case of multi-agent collaboration
   or communication, communication channels of agents might be
   manipulated to influence decision-making processes.  Message
   authentication, communication verification, implementing multi-agent
   authentication mechanisms.

   o Rogue Agents in MAS：In case of multi-agent collaboration, there
   might be malicious or compromised agents.  Restricting the autonomy
   of agents and conducting regular AI testing are required to mitigate
   such risk.

   o Humans Attacks on MAS：In case of multi-agent collaboration,
   business operations might be manipulated using agent delegation and
   authorization.  Restricting the delegation mechanism, implementing AI
   agent identity authentication, and isolate tasks in segments are
   required to mitigate such risk.

   o Human Manipulation：When Human operators interact with the network
   AI Agent, AI agents might be coerced to manipulate users into
   performing covert operations.  Safety guardrails, content moderation,
   output content detection are required to mitigate such risk.

   o Insecure Inter-Agent Protocol Abuse：In case of multi-agent
   collaboration, there might be target flaws in protocols like MCP or
   A2A; e.g.,consent bypass, context hijacking, etc.  Strong
   authentication,data validation, restricting delegation to scoped
   function,logging agent and tool invocations and encrypting
   communications are required to mitigate such risk.

   o Supply Chain Compromise：In case of multi-agent collaboration,
   Vulnerable, malicious, outdated, harmful components might be included
   into the agent.  Digital signatures of SBOMs (AI_, Agent_),applying
   version control, chaining authentication, environment isolation are
   required to mitigate such risk.

   o Lifecycle security: The entire management lifecycle of the network
   AI agents and the network digital twin—from initial deployment and
   configuration to updates and decommissioning—must be secured against
   unauthorized access and manipulation.

12.  IANA Considerations

   This document has no requests to IANA.

13.  Conclusion

   The following items were felt to be good starting points for IETF
   work:

   *  Nature Language Interaction protocol to ensure both The accuracy
      and efficiency of structured data for deterministic tasks and
      natural language interactions for understanding and handling
      uncertain or ambiguous tasks.

   *  Translate Service Level YANG Data model and Network Level YANG
      Data model into DSL payloads and APIs which can be consumed by
      Agents and Models.

   *  Human and Agent Interaction to support explainable, observability
      and controllable capabilities.

   *  Define semantic information transfer or agent prompt language
      template for Agent to Agent Communication.

   *  Agent to Agent Protocol extensions for IP Network Agent and
      Network Element Agent Collaboration.

14.  References

14.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>.

   [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>.

14.2.  Informative References

   [A2A]      "Agent2Agent (A2A) protocol", April 2025, <https://google-
              a2a.github.io/A2A/#/documentation?id=agent2agent-protocol-
              a2a>.

   [A2A-T]    "Agent to Agent Protocol for Telecoms (A2A-T)", 2025,
              <https://www.tmforum.org/resources/introductory-guide/
              ig1453-agent-to-agent-protocol-for-telecoms-a2a-
              t-v1-0-0/>.

   [Agent-skills]
              "Agent Skills", 2025, <https://agentskills.io/home>.

   [Google-Agents-Whitepaper]
              "Agents", 2024,
              <https://www.kaggle.com/whitepaper-agents>.

   [I-D.hong-nmrg-agenticai-ps]
              Hong, Y., Youn, J., Wu, Q., and B. Claise, "Motivations
              and Problem Statement of Agentic AI for network
              management", Work in Progress, Internet-Draft, draft-hong-
              nmrg-agenticai-ps-00, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-hong-nmrg-
              agenticai-ps-00>.

   [I-D.ietf-nmop-network-incident-yang]
              Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng,
              "A YANG Data Model for Network Incident Management", Work
              in Progress, Internet-Draft, draft-ietf-nmop-network-
              incident-yang-08, 13 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
              network-incident-yang-08>.

   [I-D.ietf-nmop-terminology]
              Davis, N., Farrel, A., Graf, T., Wu, Q., and C. Yu, "Some
              Key Terms for Network Fault and Problem Management", Work
              in Progress, Internet-Draft, draft-ietf-nmop-terminology-
              23, 18 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
              terminology-23>.

   [I-D.irtf-nmrg-ai-challenges]
              François, J., Clemm, A., Papadimitriou, D., Fernandes, S.,
              and S. Schneider, "Research Challenges in Coupling
              Artificial Intelligence and Network Management", Work in
              Progress, Internet-Draft, draft-irtf-nmrg-ai-challenges-
              05, 18 March 2025, <https://datatracker.ietf.org/doc/html/
              draft-irtf-nmrg-ai-challenges-05>.

   [I-D.irtf-nmrg-network-digital-twin-arch]
              Zhou, C., Yang, H., Duan, X., Lopez, D., Pastor, A., Wu,
              Q., Boucadair, M., and C. Jacquenet, "Network Digital
              Twin: Concepts and Reference Architecture", Work in
              Progress, Internet-Draft, draft-irtf-nmrg-network-digital-
              twin-arch-11, 6 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
              network-digital-twin-arch-11>.

   [MCP]      "Model Context Protocol", November 2024,
              <https://modelcontextprotocol.io/>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/rfc/rfc6241>.

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,
              <https://www.rfc-editor.org/rfc/rfc7011>.

   [RFC7854]  Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
              Monitoring Protocol (BMP)", RFC 7854,
              DOI 10.17487/RFC7854, June 2016,
              <https://www.rfc-editor.org/rfc/rfc7854>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/rfc/rfc8040>.

   [RFC8639]  Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
              E., and A. Tripathy, "Subscription to YANG Notifications",
              RFC 8639, DOI 10.17487/RFC8639, September 2019,
              <https://www.rfc-editor.org/rfc/rfc8639>.

   [RFC8641]  Clemm, A. and E. Voit, "Subscription to YANG Notifications
              for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
              September 2019, <https://www.rfc-editor.org/rfc/rfc8641>.

   [RFC9232]  Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
              A. Wang, "Network Telemetry Framework", RFC 9232,
              DOI 10.17487/RFC9232, May 2022,
              <https://www.rfc-editor.org/rfc/rfc9232>.

   [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
              Tantsura, "Intent-Based Networking - Concepts and
              Definitions", RFC 9315, DOI 10.17487/RFC9315, October
              2022, <https://www.rfc-editor.org/rfc/rfc9315>.

   [TMF-1251D]
              "AN Agent Architecture v1.0.0", May 2025,
              <https://www.tmforum.org/resources/introductory-guide/
              ig1251d-an-agent-architecture-v1-0-0/>.

   [TMF-1258] "Autonomous Networks Glossary v1.2.0", May 2025,
              <https://projects.tmforum.org/wiki/display/PUB/
              IG1258+Autonomous+Networks+Glossary+v1.2.0>.

Appendix A.  Acknowledgements

   This work has benefited from the discussions of NMRG interim meeting
   on Agentic AI.  Thanks Chris Janz for wonderful comments and
   discussion on proactive close loop.

Appendix B.  Changes between Revisions

   v02 - v03

* Agentic AI Architecture Update.
* Rewrite Functional Interfaces section for user to agent, agent to agent, agent to tools communication.
* Explore Relationship Between      Management      Characteristics and Functional Components in section 6.
* Rewrite a collection of use cases to support multi-agent collaborations.
* Rewrite Challenges section to cover Trust and Security, protocol and benchmarking.
* Add workflows for Agent Registration, Discovery, team forming.
* Add workflow for Agent to Agent Communciation Security.
* Rewrite Security Consideration Section.
* Add Conclusion Section.

   v00 - v01

* Add Security Consideration Section;
* Add Acknowledge Section;
* Clarify the relation between knowlege and tools;
* Clarify the souce of knowlege;
* Clarify the key characteristics of Network AI Agent to adpat to the environment change.

Contributors

   Qiufang Ma
   Huawei
   Email: maqiufang1@huawei.com


   Zhenqiang Li
   CMCC
   Email: lizhenqiang@chinamobile.com


   Lionel Tailhardat
   Orange Research
   Email: lionel.tailhardat@orange.com


Authors' Addresses

   Qin Wu
   Huawei
   China
   Email: bill.wu@huawei.com


   Cheng Zhou
   China Mobile
   China
   Email: zhouchengyjy@chinamobile.com


   Luis M. Contreras
   Telefonica
   Email: luismiguel.contrerasmurillo@telefonica.com


   Sai Han
   China Unicom
   China
   Email: hans29@chinaunicom.cn


   Yong-Geun Hong
   Daejeon University
   Email: yonggeun.hong@gmail.com


