Multi-agent Collaboration Protocol Suites Architecture

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 .

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 synchronizes abstracted agent capability digests across agent gateways.

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.

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 agent capability digests with peer gateways. 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].

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

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. 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 AGWs 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 AGWs 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 between Agent Gateways (AGWs) to synchronize capability directory information and construct a distributed view of agent capabilities across the network. More detailed treatment of the gateway capability directory in [draft-zhang-dmsc-gateway-directory-sync] . CDSP is designed to: Enable distributed visibility of agent capabilities across multiple AGWs Avoid centralized bottlenecks in capability management Preserve privacy and scalability through abstraction Support incremental and policy-controlled synchronization. Each AGW maintains a local capability directory, which is populated through agent registration and updated over time. CDSP enables AGWs to exchange selected portions of these directories so that capability information is not confined to a single gateway but becomes visible, in an abstracted form, across multiple administrative or network domains. To ensure scalability and protect sensitive information, CDSP does not transfer complete capability descriptions. Instead, AGWs exchange capability directory entries in a summarized form. Each entry represents a capability exposed by an agent and is associated its corresponding capability vector. The exchanged information 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 AGWs or recovery scenarios, a gateway MAY perform a full synchronization of its capability directory. In steady-state operation, synchronization is typically incremental or selective, where only updated or policy-permitted entries are exchanged. The selection of entries MAY be governed by administrative policies, trust relationships, or capability classification. Synchronization can be triggered in multiple ways. An AGW MAY initiate periodic synchronization to maintain freshness of the distributed view. It MAY also perform event-driven updates when local changes occur, such as agent registration, deregistration, or capability updates. Additionally, synchronization MAY be requested on demand by peer gateways when needed for coordination purposes. Given the distributed nature of CDSP, strict consistency across all AGWs is not required. Instead, the system operates under an eventual consistency model, where capability directory views converge over time. To support this, capability entries SHOULD include versioning or timestamp information, allowing AGWs 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 , 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: Model Context Protocol (MCP) Agent-to-Tool (A2T) 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