| Internet-Draft | Abbreviated-Title | August 2026 |
| Wang & Wang | Expires 6 February 2027 | [Page] |
The large-scale deployment of autonomous AI Agents introduces challenges to capability description, registration, and discovery. Existing agent communication protocols mainly focus on application-layer interactions and typically rely on centralized registration and discovery mechanisms, which limit scalability, robustness, and semantic extensibility. This document proposes a distributed and hierarchical capability registration and information synchronization mechanism for AI Agents. The mechanism introduces a multi-level capability taxonomy, capability vectors, and globally unique Service Identifiers (Service IDs), and defines two functional entities: Agent Capability Registration Server (ACRS) and Agent Capability Access Server (ACAS). A capability table is constructed and synchronized among ACRSs to enable semantic-based forwarding of capability-related requests. Furthermore, capability registration and discovery procedure are specified, enabling precise selection of agents based on task requirements. The proposed mechanism provides a scalable foundation for capability-aware routing and semantic collaboration in the Internet of Agents (IoA).¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 February 2027.¶
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.¶
AI systems are evolving from task-specific applications toward autonomous agents capable of perception, reasoning, and action execution. In this paradigm, agents are expected to communicate, collaborate, and invoke each other's capabilities across network administrative domains to accomplish complex tasks. Consequently, capability registration and discovery become fundamental functions for enabling agent interoperability.¶
Existing service registration mechanisms are primarily designed for static service instances and are not intended to support highly dynamic agent capabilities or large-scale collaborative agent environments.¶
This document defines a distributed mechanism for hierarchical capability registration and semantic-based capability discovery for AI Agents. The mechanism provides a scalable foundation for capability-aware request forwarding and agent selection without modifying the underlying network infrastructure.¶
The following terms are defined in this draft:s¶
Agent Capability Type:The basic subdivision unit in the hierarchical capability classification system, which identifies a specific functional category that an agent is able to provide.¶
Agent Capability Vector: A structured representation of the capability types to indicate the agent's full capabilities¶
Service ID: A globally unique identifier representing a callable AI Agent instance.¶
ACRS: Agent capability registration server that manage one or more types of capabilities. ACRSs form an overlay network where capability tables are exchanged and synchronized.¶
ACAS: Agent capability access server that act as the direct attachment anchor for AI agents.¶
Capability Table: A table maintained by ACRSs that maps capability vectors to next-hop capability servers.¶
Access Mapping Table: A table maintained by ACASs that maps connected agents to their Service IDs and capability types.¶
AI systems are evolving from traditional service-oriented applications toward autonomous agents capable of dynamically providing, consuming, and composing capabilities. Unlike conventional service instances, AI Agents continuously join and leave the network, update their capabilities, and participate in dynamic collaboration relationships. Existing registration and discovery mechanisms are primarily designed for relatively static service environments. Such mechanisms do not adequately address the scalability, capability dynamics, and semantic diversity introduced by large-scale AI Agent deployments. As the number of participating agents increases, centralized registration architectures may become bottlenecks for capability management and discovery.¶
Therefore, a capability registration mechanism is required to support scalable capability registration, distributed information synchronization, efficient capability discovery, and dynamic management of AI Agent capabilities in open network environments.¶
Agent capabilities are represented using a hierarchical classification model as shown in Figure 1. The multi-level capability tree organizes capabilities from coarse-grained capability classes to progressively finer-grained subordinate capability classes. The hierarchy is extensible and allows new capability classes to be introduced without affecting existing classifications.¶
[ Agent Capabilities ]
|
+--------------+ . . .
| |
[ Parent Capability [ Parent Capability ------- (Parent Capability Class)
Class A ] Class B ] (Extensible as needed)
|
+--------+--------+ . . . +--------+
| | |
[ Subordinate [ Subordinate [ Subordinate ] --- (Level 1 Subordinate Class)
Class A1 ] Class A2 ] Class An ] (Extensible as needed)
|
+----+ . . . +------+ . . .
| |
[ Subordinate [ Subordinate ] ---------------- (Level 2 Subordinate Class)
Class A1-1 ] Class A1-n ] (Extensible as needed)
:
:
+--------+ . . . +--------+ . . .
| | | |
[ Subordinate [ Subordinate ] ---------------- (Level N Subordinate Class)
Class A1-1...1] Class A1-1...n] (Extensible as needed)
Figure 1 Multi-level Capability Tree Architechture¶
A Capability Table is maintained by each ACRS to determine the next-hop ACRS for capability-related requests. Each table entry associates a target capability type with one or more next-hop ACRSs. Each entry consists of a target capability type and the corresponding next-hop ACRS.¶
For illustration purposes, consider ACRS responsible for Capability A.the capability table it maintains is presented in a similar form as shown in Table 1:¶
Table 1 Capability Table of ACRS responsible for Capability A | Target Capability Type | Next-Hop ACRS | | A | - | | B | B | | C | B/D | | D | D |¶
Capability tables are constructed based on inter-ACRS connectivity and are synchronized dynamically. Capability Tables are constructed as follows:¶
An Access Mapping Table is maintained by each ACAS to record the association between locally attached AI Agents and their corresponding Service IDs. The table enables local capability matching during the capability discovery procedure.Each entry includes: service ID, capability types,and access link identifier.¶
For illustration purposes, consider a general ACAS maintains the access mapping table as shown in Table 2:¶
Table 2 Access Mapping Table of general ACAS | Agent | Access Link ID | Service ID | Agent Capability Type | | 1 | Physical Port Number | SID-001 | D | | 2 | VLAN ID | SID-002 | B2, A | | 3 | VXLAN VNI | SID-003 | B2, C | | 4 | MPLS Label | SID-004 | E | | 5 | SRv6 SID | SID-005 | F |¶
The access link identifier distinguishes all available agents directly connected to this access server, enabling efficient matching of locally attached agents according to capability requirements in the capability discovery process.¶
A distributed and hierarchical capability registration mechanism is defined. An AI Agent, based on its capability classification, advertises its registration information toward the corresponding ACRS by following capability-table-based routing.The capability registration procedure consists of the following steps:¶
An AI Agent connects to an ACAS and sends a capability registration request (capability types and service ID) to the attached ACAS. The ACAS records the received information in its Access Mapping Table¶
The ACAS aggregates registrations belonging to the same capability type. The aggregated information is propagated toward the responsible ACRS.¶
The ACAS forwards summarized information toward the target ACRS according to the capability table.¶
The target ACRS authenticates and confirms registration.¶
A registration success response is returned.¶
The ACRS relays registration information based on the capability table. When the ACAS directly connected to an agent happens to be the agent's target ACRS, capability registration is completed directly on that ACRS. Otherwise, the target registration server have to be located according to the capability table.¶
Capability discovery is initiated according to the capability requirements derived from a task intent. An AI agent issues a discovery query that is forwarded based on capability classification using the capability table, enabling location and matching of agents with required capability types. The intent-driven capability discovery mechanism is as follows:¶
A requester submits a task intent to the service domain, and the client-side AI Agent attaches to an ingress ACRS.¶
The ingress ACRS maps intent to capability vector and determines the next-hop ACRS according to the capability table. It initiates an agent query locally and determines whether the destination ACAS is directly reachable; otherwise, the request is forwarded according to the capability table.¶
The ACRS sends an agent query request to the target ACAS.¶
The target ACAS performs local matching according to the access mapping table.¶
The ACAS returns the matching results (i.e., a list of Service IDs of all available agents) to the requesting ACRS, which then returns the matching Service IDs to the requesting entity.¶
This document makes no request of IANA.¶
Authentication between agents, ACASs, and ACRSs is REQUIRED. Capability advertisements SHOULD be integrity-protected. Access control policies MUST be enforced at registration and discovery stages.¶
TBD¶