| Internet-Draft | Abbreviated-Title | August 2026 |
| Wang & Wang | Expires 19 February 2027 | [Page] |
AI Agents may dynamically join, leave, and update their capabilities while participating in interactions across administrative domains. Efficient capability discovery in such environments requires mechanisms to onboard agent capabilities and maintain consistent capability information across distributed management entities. Existing service registration and discovery mechanisms do not necessarily provide a capability-oriented mechanism for distributed synchronization and hierarchical forwarding of agent capability information.¶
This document proposes a distributed and hierarchical mechanism for AI Agent capability onboarding, information synchronization, and capability-based discovery. The mechanism introduces a hierarchical capability classification model and defines two functional entities: the Agent Capability Management Server (ACMS), which maintains and synchronizes capability information, and the Agent Capability Access Server (ACAS), which manages locally attached agents. Capability information is aggregated and propagated among ACMSs, while access information for locally attached agents is maintained by ACASs. A capability table is used to determine forwarding toward relevant ACMSs, and an access mapping table is used for local agent matching. The document also describes onboarding and intent-driven capability discovery procedures. The mechanism is intended to provide a distributed control-plane foundation for capability-aware agent discovery and does not define agent-to-agent interaction or task execution protocols.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 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 onboarding and discovery become fundamental functions for enabling agent interoperability.¶
Existing service registration and discovery mechanisms provide mechanisms for publishing and locating service instances, but they do not necessarily provide a distributed, capability-oriented model for representing and synchronizing the dynamically changing capabilities of AI Agents across administrative domains.¶
This document defines a distributed mechanism for hierarchical capability onboarding 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 one or more capability types associated with an AI Agent.¶
Agent ID: A globally unique identifier representing a callable AI Agent instance.¶
ACMS: Agent capability management server that manages one or more types of capabilities. ACMS forms the capabilities table via exchanging and synchronizing their summarized capabilities tables.¶
ACAS: Agent capability access server that provides the attachment point for AI Agents and maintains information about locally attached agents and their capabilities.¶
Capability Table: A table maintained by ACMSs that maps capability vectors to next-hop capability servers.¶
Access Mapping Table: A table maintained by ACASs that maps connected agents to their Agent 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 onboarding architectures may become bottlenecks for capability management and discovery.¶
Therefore, a capability onboarding mechanism is required to support scalable capability onboarding, 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 Architecture¶
A Capability Table is maintained by each ACMS to determine the next-hop ACMS for capability-related requests. Each table entry associates a target capability type with one or more next-hop ACMSs. Each entry consists of a target capability type and the corresponding next-hop ACMS.¶
For illustration purposes, consider ACMS 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 ACMS responsible for Capability A | Target Capability Type | Next-Hop ACMS | | A | - | | B | B | | C | B/D | | D | D |¶
Capability tables are constructed based on inter-ACMS 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 Agent IDs. The table enables local capability matching during the capability discovery procedure.Each entry includes: agent 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 | Agent ID | Agent Capability Type | | 1 | Physical Port Number | AID-001 | D | | 2 | VLAN ID | AID-002 | B2, A | | 3 | VXLAN VNI | AID-003 | B2, C | | 4 | MPLS Label | AID-004 | E | | 5 | SRv6 SID | AID-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 onboarding mechanism is defined. An AI Agent onboards to an ACAS which aggregate and propagate agent information to distributed ACMSs based on its local Access Mapping Table. ACAS subsequently advertises its agent information toward the corresponding ACMS. The capability onboarding procedure consists of the following steps:¶
An AI Agent onboards to an ACAS and sends a capability onboarding request, including capability types and agent ID, to the attached ACAS. The ACAS records the received information in its Access Mapping Table¶
The ACAS summarizes onboardings belonging to the same capability type. The summarized information is propagated toward the responsible ACMS.¶
The ACAS forwards summarized information toward the target ACMS according to the capability table.¶
The target ACMS authenticates and confirms the onboarding.¶
An onboarding success response (or Onboarding ACK) is returned.¶
The ACMS relays onboarding information based on the capability table. When the ACAS directly connected to an agent happens to be the agent's target ACMS, capability onboarding is completed directly on that ACMS. Otherwise, the target management 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. ACMSs synchronize summarized capability information and provide capability-based forwarding for discovery requests. 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 ACMS.¶
The ingress ACMS maps intent to capability vector and determines the next-hop ACMS 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 ACMS 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 Agent IDs of all available agents) to the requesting ACMS, which then returns the matching Agent IDs to the requesting entity.¶
This document makes no request of IANA.¶
Authentication between agents, ACASs, and ACMSs is REQUIRED. Capability advertisements SHOULD be integrity-protected. Access control policies MUST be enforced at onboarding and discovery stages.¶
TBD¶