Multi-agent Collaboration Protocol Suites Architecture

4.1. Agent Management Center

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

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

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][GW-REQ].¶

4.3. Agent

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

4.4. External Resource Service (ERS)

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

4.5. Data Objects

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

4.6. Entity Summary

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

5.1. Agent-Gateway Interaction Protocol(AGIP)

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

5.2. Agent Authentication and Authorization Protocol (AAAP)

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:¶

1. The AGW receives a registration request from an agent.¶

2. The AGW initiates an AAAP request to the AMC, carrying agent identity information.¶

3. The AMC performs authentication and authorization checks.¶

4. Upon success, the AMC returns an authorization credential and policy constraints.¶

5. The AGW enforces the received authorization decision.¶

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

5.3. Capability Directory Synchronization Protocol (CDSP)

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

5.4. Gateway-side Mediation Requirements

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

5.5. Agent to External Resource Service Protocol

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