| Internet-Draft | MACP | November 2026 |
| Li, et al. | Expires 6 May 2027 | [Page] |
This document defines a protocol suite and architectural framework for secure and scalable multi-agent collaboration. The proposed Multi-Agent Collaboration Protocol (MACP) enables trusted agent onboarding, capability-based query, distributed capability synchronization, and secure interaction among agents and external resources. The architecture introduces key entities such as the Agent Management Center (AMC), Agent Gateway (AGW), Agents, and External Resource Services (ERS), along with a set of protocols that collectively support dynamic, capability-driven collaboration across administrative domains.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 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.¶
The rapid evolution of large-scale multi-agent systems introduces new requirements for coordination, security, and service discovery across distributed environments. Agents are no longer confined to isolated execution contexts, but increasingly operate across administrative domains, network boundaries, and heterogeneous infrastructures. However, existing mechanisms for service interaction and discovery exhibit several limitations when applied to multi-agent collaboration:¶
Lack of unified trust establishment: Current agent interaction models often assume pre-established trust or rely on application-layer authentication, without a network-level mechanism to ensure that participating agents are authenticated, authorized, and accountable across domains.¶
Insufficient capability abstraction and discoverability: Traditional service discovery mechanisms (e.g., DNS-based or registry-based approaches) focus on endpoint resolution rather than capability-oriented matching, making them unsuitable for dynamic agent collaboration where tasks are fulfilled based on functional capabilities rather than fixed service locations.¶
Limited visibility across distributed environments: Existing systems lack a mechanism to construct a distributed, up-to-date view of available agent capabilities, especially when agents are registered under different control points or administrative domains.¶
Inefficient or ad hoc discovery mechanisms: Without coordinated discovery strategies, agent systems rely on broadcast-like or centralized queries, leading to scalability challenges and increased latency in locating suitable collaborators.¶
Fragmented protocol landscape: While protocols such as A2A, MCP, or other interaction mechanisms exist, they operate in isolation and do not provide an integrated framework for authentication, registration, discovery, and coordination.¶
These limitations become more critical as multi-agent systems scale, where dynamic task composition, cross-domain collaboration, and secure interaction are fundamental requirements. To address these challenges, this document proposes the Multi-Agent Collaboration Protocol (MACP), a protocol suite and architectural framework that:¶
Establishes a trusted onboarding mechanism via a centralized authentication and authorization entity.¶
Introduces capability-based abstraction and identification for agents.¶
Enables distributed capability synchronization across control points.¶
Integrates existing interaction protocols into a cohesive collaboration framework.¶
By shifting from endpoint-centric interaction to capability-driven collaboration, MACP enables scalable, secure, and flexible multi-agent systems that can operate effectively across heterogeneous and distributed environments.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
The following terms are defined in this draft:¶
Agent: An automated intelligent entity capable of e.g interacting with its environment, acquiring contextual information, reasoning, self-learning, decision-making, executing tasks (autonomously or in collaboration with other Al Agents) to achieve a specific goal.¶
Agent Gateway: The Agent Gateway is a functional entity that serves as the infrastructure for enabling interconnection and collaboration among agents. While its core role remains consistent, it is inherently flexible in deployment and can be realized in various forms—ranging from a network service to a dedicated gateway—depending on the architectural and operational requirements of different network environments.¶
Agent Management Center (AMC): It is the trusted infrastructure service responsible for agent identity lifecycle management and credential issuance.¶
Agent Identity Code (AIC): An Agent Identity Code (AIC) is a verifiable, globally unique identifier that represents the identity of an Agent.¶
Agent Capability Specification (ACS): An Agent Capability Specification (ACS) is a structured description of an agent's capabilities and service information that can be stored, retrieved, and matched.¶
Agent Credential: An Agent Credential is a tamper-resistant data object issued by an Agent Management Center(or its credential authority component), used by an Agent to prove identity attributes and/or authorization to a relying party. Examples include X.509 certificates and security tokens.¶
Agent-Gateway Interaction Protocol (AGIP): The AGIP defines the control-plane interaction between an Agent and its locally attached Agent Gateway. It provides mechanisms for agent onboarding, capability registration, lifecycle management, and capability resolution, enabling an Agent to obtain suitable collaboration peers based on capability requirements.¶
Agent Authentication and Authorization Protocol (AAAP): The AAAP defines how authentication and authorization decisions are requested and enforced.¶
Capability Directory Synchronization Protocol (CDSP): The CDSP establishes a distributed, hierarchical view of agent capabilities by synchronizing summarized capability information among capability management and access entities.¶
Agent Capability Management Server (ACMS): An ACMS manages one or more types of agent capabilities, forms capability tables, and synchronizes summarized capability information with peer ACMSs.¶
Agent Capability Access Server (ACAS): An ACAS provides the attachment point for locally attached agents and maintains information about locally attached agents, including their access link identifiers and capability types.¶
Capability Table: A table maintained by ACMSs that maps capability types to next-hop capability management entities.¶
Access Mapping Table: A table maintained by ACASs that maps locally attached agents to their agent identifiers and capability types.¶
The MACP architecture consists of the following key entities:, as shown in figure 1. Each functional entity represents a logical role in the IoA architecture, implementations MAY combine multiple entities into a single product.¶
+-----------------------+
|Agent Management Center|
| (Authentication & |
| Authorization) |
+-----------------------+
| AAAP | AAAP
| |
+-------------------+ +--------------------+
| Agent Gateway 1 | | Agent Gateway 2 |
| + Registration |----------| + Registration |
| + Capa Resolution | CDSP | + Capa Resolution |
| + Capa Sync | | + Capa Sync |
+--+-----+----------+ +--------+-----+-----+
| |
AGIP | AGIP |
| |
+-----------------------+ +----------------------+ +-----------------+
| Agent | A2A | Agent | MCP |External Resource|
| (Role A) |----------- | (Role B) |------- | Service (ERS) |
+----------+------------+ +----------------------+ +-----------------+
| |
+----------+------------+ +----------+------------+
| User A | | User B |
+-----------------------+ +-----------------------+
Figure 1 MACP Architecture Overview¶
The Agent Management Center is the trusted infrastructure service responsible for agent identity lifecycle management and credential issuance. The AMC provides centralized authentication and authorization services. It ensures that only legitimate and trusted agents are allowed to join the system. Specifically, the AMC:¶
Authenticates agent identity¶
Determines authorization scope and execution permissions¶
Issues authorization credentials (e.g., certificates or tokens)¶
Multiple Agent Management Center MAY exist in an IoA deployment, each managing a subset of agents within its administrative scope. A deployment MAY realize the identity management function and the credential authority function as separate services, provided they maintain consistent identity-to-credential binding.¶
The Agent Gateway is a functional entity that serves as the infrastructure for enabling interconnection and collaboration among agents. While its core role remains consistent, it is inherently flexible in deployment and can be realized in various forms—ranging from a network service to a dedicated gateway—depending on the architectural and operational requirements of different network environments.¶
The Agent Gateway provides the following functions:¶
Agent Registration: Maintains agent identity and capability information.¶
Agent Capability Directory Management: Stores and organizes registered agent capabilities.¶
Agent Capability Directory Synchronization: Exchanges summarized capability information with peer capability management entities.¶
Agent Group Communication Support: Enables multi-agent coordination.¶
Each AGW maintains a local capability view and participates in forming a distributed capability knowledge plane. More specific requirements are specified in [draft-liu-dmsc-gw-requirements][GW-REQ].¶
The Agent is an automated intelligent entity capable of e.g interacting with its environment, acquiring contextual information, reasoning, self-learning, decision-making, executing tasks (autonomously or in collaboration with other Al Agents) to achieve a specific goal.¶
An Agent is responsible for:¶
Maintaining its own identity information (e.g., AIC) and credentials locally.¶
Maintaining its capability description (e.g., ACS) and ensuring consistency with its current state.¶
Performing authentication and authorization checks for interconnection, including mutual verification of peer agents and validation of presented credentials. - Conducting agent-to-agent interaction, including session establishment, message exchange, and task/context management.¶
Accessing external resources when required to fulfill tasks.¶
Producing monitoring and logging data for troubleshooting, auditing, and governance purposes.¶
These are internal agent capabilities described here for informational purposes. They are NOT standardized as separate architectural functional components. In an interaction, an Agent MAY assume different roles depending on the collaboration mode. The DMSC architecture does not constrain the set of possible roles; specific collaboration protocols MAY define role semantics appropriate to their interaction patterns.¶
For example, in a task-driven collaboration [draft-yang-dmsc-ioa-task-protocol] [draft-yang-dmsc-ioa-task-protocol]:¶
Leader: The Agent that initiates tasks and organizes collaboration.¶
Partner: The Agent that accepts tasks and provides services, executing assigned tasks and returning results to the Leader.¶
A single Agent implementation MAY act in different roles across different interactions. Role assignment is per-interaction, not per-deployment.¶
The External Resource Service (ERS) represents external systems such as APIs, databases, or compute services that agents may invoke. ERS is conceptually external to the agent collaboration system and is accessed via existing protocols.¶
ERS may include both domain-specific services and shared infrastructure services. In particular, certain ERS instances MAY correspond to widely deployed Internet-scale infrastructure (e.g., naming, data access, or knowledge retrieval systems), which provide common capabilities that are not specific to agent collaboration but are essential for its operation. In this sense, ERS can be viewed as leveraging existing or future shared Internet service infrastructure, rather than replicating such functionality within the agent system itself.¶
A key design principle is the separation of responsibilities between the agent collaboration system and ERS. The agent system is responsible for:¶
Agent identity, trust establishment, and authorization¶
Agent capabilities registration, abstraction¶
Coordination and interaction among agents¶
In contrast, ERS is responsible for:¶
Providing external data, computation, or domain-specific functionality¶
Supporting tasks that require capabilities beyond the agent system itself¶
Agents interact with ERS when executing tasks that require external resources, while core collaboration functions—such as routing, and coordination—remain within the agent system. The MACP architecture intentionally avoids redefining general-purpose Internet services (e.g., naming or data retrieval), and instead focuses on enabling agents to discover, select, and utilize such services in a coordinated manner.¶
The following are protocol data objects referenced by the functional entities. They are not functional entities themselves:¶
Agent Identity Code (AIC): An Agent Identity Code (AIC) is a verifiable, globally unique identifier that represents the identity of an Agent. An AIC is allocated by an Agent Gateway during agent registration.¶
Agent Capability Specification (ACS): An Agent Capability Specification (ACS) is a structured description of an agent's capabilities and service information that can be stored, retrieved, and matched. An ACS MAY use the JSON [RFC8259] [RFC8259] format, typically including: the agent's AIC, functional capabilities, technical characteristics, service interfaces, and security requirements.¶
Agent Credential: An Agent Credential is a tamper-resistant data object issued by an AMC (or its credential authority component), used by an Agent to prove identity attributes and/or authorization to a relying party. Examples include X.509 certificates and security tokens.¶
The following table provides a summary of all functional entities and external actors in the simplified DMSC architecture.¶
| # | Entity | Type | Role in Architecture | |----|---------------------------|-------------------|-------------------------------------------------------| | 1 | Agent | Core entity | Autonomous task execution and collaboration | | 2 | Agent Management Center | Infrastructure | Identity lifecycle management and credential issuance | | 3 | Agent Gateway | Infrastructure | Capability directory, synchronization | | 4 | External Resource Service | Infrastructure | External resource exposure and invocation handling | | 5 | User | External actor | Task initiation, authorization, and result consumption| Figure 2 A summary of all functional entities¶
MACP defines a set of protocols to enable interaction among entities.¶
The Agent-Gateway Interaction Protocol (AGIP) defines the control-plane interaction between an Agent and its locally attached Agent Gateway (AGW). AGIP provides a unified interaction framework that enables Agents to join the collaboration system, advertise and maintain their capabilities, and request capability resolution services throughout their lifecycle.[draft-sz-dmsc-iaip]¶
As the primary interface between an Agent and the AGW, AGIP supports two complementary interaction procedures. The first enables an Agent to establish its identity and advertise its capabilities to the gateway, allowing the AGW to maintain an up-to-date capability directory of locally attached Agents. The second enables an Agent to submit collaboration requests during runtime. Upon receiving such requests, the AGW interprets the requested capabilities, resolves them against its distributed capability knowledge, and returns one or more suitable collaboration Agents.¶
Accordingly, AGIP consists of the following two procedures: Agent Registration and Capability Advertisement, Capability Resolution.¶
This procedure enables an Agent to become a trusted participant in the collaboration system while publishing its capabilities to the attached Agent Gateway.¶
AGIP is responsible for:¶
Agent identity declaration.¶
Capability advertisement.¶
Agent registration and deregistration.¶
Capability update and lifecycle management.¶
Operational flow:¶
The Agent sends a registration request to its attached AGW, carrying its identity information together with its Agent Capability Specification (ACS).¶
The AGW invokes the Agent Authentication and Authorization Protocol (AAAP), as described in Section 5.2, to authenticate and authorize the requesting Agent.¶
Upon successful authentication and authorization, the AGW allocates a globally unique Agent Identity Code (AIC).¶
The AGW stores the advertised capability information in its local capability directory and associates it with the allocated AIC.¶
The AGW acknowledges successful registration to the Agent.¶
The registered capability information becomes available for subsequent synchronization with peer capability management entities through the Capability Directory Synchronization Protocol (CDSP).¶
After registration, an Agent MAY update its capability information whenever its supported functions, service interfaces, execution status, or other capability-related attributes change. Likewise, an Agent MAY deregister from the AGW when it leaves the collaboration system, allowing the corresponding capability information to be withdrawn from the capability directory.¶
After successful registration, an Agent MAY request collaboration services by submitting a capability request to its attached AGW through AGIP.¶
Upon receiving a request from an agent, the AGW performs the following operations:¶
Receive the capability request from the requesting Agent.¶
Interpret and normalize the requested capability into an internal capability representation.¶
Match the normalized capability against the capability directory maintained by the AGW.¶
Identify one or more candidate Agents capable of satisfying the requested capability.¶
Apply local selection policies when multiple candidate Agents are available.¶
Return the capability resolution result to the requesting Agent.¶
The capability directory maintained by the AGW contains both capabilities advertised by locally registered Agents and abstract capability summaries synchronized from peer capability management entities through CDSP. Consequently, capability resolution may identify candidate Agents either within the local administrative domain or in remote domains without requiring the requesting Agent to interact directly with multiple gateways.¶
When multiple candidate Agents satisfy the requested capability, the AGW MAY rank or select candidates according to locally configured policies, including capability matching degree, resource availability, execution load, trust relationships, network conditions, administrative policies, or application-specific optimization objectives.¶
The Agent Authentication and Authorization Protocol (AAAP) is used between the Agent Gateway (AGW) and the Agent Management Center (AMC) to establish trust for agents attempting to join the system.¶
AAAP is responsible for:¶
Verifying the identity of an agent (via AGW as a proxy)¶
Determining the authorization scope and permitted operations¶
Issuing authorization credentials (e.g., tokens or certificates)¶
Operational flow:¶
The AGW receives a registration request from an agent.¶
The AGW initiates an AAAP request to the AMC, carrying agent identity information.¶
The AMC performs authentication and authorization checks.¶
Upon success, the AMC returns an authorization credential and policy constraints.¶
The AGW enforces the received authorization decision.¶
The AMC acts as the trust anchor of the system, while the AGW acts as the policy enforcement point (PEP).¶
Note that although AAAP establishes the initial trust relationship between an agent and the system (i.e., onboarding trust), subsequent interactions between agents may require additional, context-specific authentication and authorization. Such interaction-level mechanisms are out of scope for AAAP and MAY leverage existing frameworks (e.g., OAuth-based token exchange or similar delegation mechanisms) to support secure, fine-grained access control between agents.¶
An agent MUST successfully complete AAAP before participating in invocation or collaboration. However, successful onboarding via AAAP does not eliminate the need for authentication and authorization during runtime interactions between agents.¶
The Capability Directory Synchronization Protocol (CDSP) is used among capability management entities to establish a distributed, hierarchical view of agent capabilities across the network. CDSP follows the distributed onboarding and information synchronization mechanism defined in [draft-wang-dmsc-drisac], which separates capability management into two functional roles: the Agent Capability Management Server (ACMS) and the Agent Capability Access Server (ACAS).¶
An ACMS maintains and synchronizes summarized capability information and forms a distributed capability plane by exchanging its summarized capability tables with peer ACMSs. An ACAS provides the attachment point for locally attached agents and maintains per-agent access and capability information. Within the MACP architecture, an Agent Gateway MAY realize the ACAS role for its locally attached agents and participate in the distributed capability plane through CDSP, either directly through an ACMS.¶
CDSP is designed to:¶
Enable distributed visibility of agent capabilities across multiple ACMSs and administrative domains¶
Avoid centralized bottlenecks through hierarchical aggregation and propagation¶
Preserve privacy and scalability by exchanging summarized capability information rather than complete capability descriptions¶
Support capability-based forwarding, incremental updates, and policy-controlled synchronization through the capability table¶
CDSP relies on two data structures to support capability-based matching and forwarding. A Capability Table is maintained by each ACMS to determine the next-hop ACMS for capability-related requests. Each entry associates a target capability type with one or more next-hop ACMSs. Capability tables are constructed through inter-ACMS connectivity: ACMSs establish logical adjacencies through configured or otherwise established inter-ACMS relationships, advertise the capability types for which they are responsible, and generate forwarding entries based on the exchanged advertisements. An Access Mapping Table is maintained by each ACAS to record the association between locally attached agents and their corresponding agent identifiers, capability types, and access link identifiers, enabling local capability matching during the discovery procedure.¶
When an Agent joins the system, the distributed onboarding procedure proceeds as follows:¶
The Agent onboards to an ACAS (e.g., its locally attached Agent Gateway) and sends a capability onboarding request, carrying its capability types and agent identifier, 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 and propagates the summarized information toward the responsible ACMS.¶
The target ACMS authenticates and confirms the onboarding.¶
The ACAS returns an onboarding acknowledgement to the Agent.¶
When the ACAS directly connected to an Agent is already the Agent's target ACMS, capability onboarding is completed directly on that ACMS; otherwise, the target ACMS is located according to the Capability Table and the information is forwarded along the capability path until the responsible ACMS is reached.¶
Capability discovery is intent-driven and leverages the same hierarchical structure.¶
A requester submits a task intent, and the client-side Agent attaches to an ingress ACMS.¶
The ingress ACMS maps the intent to a capability vector and determines the next-hop ACMS according to the Capability Table, initiating an agent query locally.¶
The agent query is forwarded according to the Capability Table until the destination ACAS is reached.¶
The destination ACAS performs local matching according to its Access Mapping Table.¶
The matching results (i.e., a list of agent identifiers of all available agents) are returned to the requesting entity.¶
CDSP does not transfer complete capability descriptions. Each capability is associated with a capability vector. ACMSs exchange summarized capability information, which MAY include semantic descriptions or structured representations of the capability, along with limited metadata such as version or category. Detailed implementation-specific information and sensitive attributes MUST NOT be propagated through CDSP.¶
CDSP supports different synchronization scopes depending on deployment requirements. During initial establishment between peer capability entities or recovery scenarios, a full synchronization MAY be performed. In steady-state operation, synchronization is typically incremental or selective, where only updated or policy-permitted entries are exchanged. Synchronization MAY be triggered periodically, by local events (such as agent registration, deregistration, or capability updates), or on demand by peer entities when needed for coordination purposes.¶
Given the distributed nature of CDSP, strict consistency across all capability entities is not required. Instead, the system operates under an eventual consistency model, where capability views converge over time. To support this, capability entries SHOULD include versioning or timestamp information, allowing entities to reconcile updates and prefer the most recent information. Conflict resolution policies MAY be applied when inconsistencies arise. All CDSP exchanges MUST be authenticated and integrity-protected.¶
The protocols defined in this document specify how Agents, Agent Gateways (AGWs), and gateway support functions exchange registration information, capability information, authentication information, and collaboration requests. These protocols provide the information required for gateway-assisted collaboration. However, they do not specify how an Agent Gateway transforms the exchanged information into an operational collaboration decision.¶
In practical deployments, an Agent Gateway performs more than protocol forwarding, capability directory management, or message relay. When an Agent submits a collaboration request through the Agent-Gateway Interaction Protocol (AGIP), the gateway is responsible for determining whether the request can be satisfied, which Agent or service is appropriate, and under what operational constraints the collaboration should proceed. Although the decision logic may vary across deployments, the need for gateway-side decision making is common across heterogeneous agent ecosystems.¶
To produce an appropriate collaboration decision, the gateway may need to interpret the request objective, correlate it with registered capability descriptions, evaluate candidate capabilities, apply authorization and operational policies, consider trust relationships, and assess execution context before selecting an appropriate collaboration target. These decision inputs are derived from the protocol interactions defined in MACP but require additional gateway-side processing before they can be used for collaboration decisions.¶
The decision process may also incorporate information obtained from multiple gateway support functions. Capability directories synchronized through CDSP provide candidate capability views. Authentication and authorization services defined by AAAP provide identity and permission information. Registration information maintained through AGIP provides capability metadata and lifecycle state. Operational policies, administrative constraints, network conditions, and deployment-specific knowledge may further influence the gateway's decision. These information sources collectively contribute to gateway-side decision making but do not themselves define how decisions are produced.¶
After a collaboration decision has been made, the gateway may further determine how the request should be handed over to the selected interaction mechanism. Depending on deployment requirements, the gateway may prepare additional information describing the selected capability, applicable policy constraints, interaction context, routing information, trust context, or failure reasons. The resulting decision and handoff context enable different interaction mechanisms, including A2A, MCP, IAIP, or other protocols, to execute collaboration while preserving consistent capability, policy, and trust semantics.¶
The gateway-side decision process described above complements the protocol interactions defined by MACP. While MACP specifies how collaboration information is exchanged among Agents and Agent Gateways, it does not define how gateways interpret requests or derive collaboration decisions from the exchanged information.¶
This motivates the need for a gateway mediation function. A companion draft, Gateway Mediation Layer [draft-zhang-dmsc-ioa-semantic-interaction], analyzes the mediation inputs, decision process, outputs, and interoperability considerations required for gateway-assisted collaboration across heterogeneous agent environments.¶
Interaction between agents and external resources (ERS) is supported via existing protocols such as:¶
MACP does not redefine these protocols but enables their integration within the architecture.¶
Capabilities are the core abstraction in MACP.¶
Each capability is associated with a Capability vector.¶
Capabilities are registered, indexed, and discovered via AGWs.¶
Capability information is abstracted during synchronization to protect sensitive details.¶
Capability descriptions MAY be semantic or structured depending on use case.¶
This abstraction enables flexible and scalable service composition.¶
TBD¶