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 Discovery: Supports both proactive and reactive agent discovery.¶

• 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, and discovery¶

• 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 discovery, 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,agent discovery, 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 Registration Protocol (ARP)

The Agent Registration Protocol (ARP) is used between an Agent and an AGW to onboard the agent into the system [draft-sz-dmsc-iaip]. ARP is responsible for:¶

• Agent identity declaration¶

• Capability registration (capability-based onboarding)¶

• Lifecycle management (registration, update, deregistration)¶

Operational flow:¶

1. The agent sends a registration request to the AGW, including: agent identity information and capability vector.¶

2. The AGW triggers AAAP to validate the agent (as described in Section 5.2).¶

3. Upon successful authorization, the AGW assigns a globally unique Agent ID (AIC).¶

4. The master AGW store the agent's capabities information in the local capability directory.¶

5. The agent is considered available once ARP and AAAP are completed successfully.¶

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

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 discovery or 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. Agent Discovery Protocol (ADP)

The Agent Discovery Protocol (ADP) enables AGWs to locate agents that provide required capabilities, supporting both local and distributed discovery.¶

ADP is designed to:¶

• Enable capability-based matching instead of endpoint-based lookup¶

• Support both low-latency local discovery and network-wide search¶

• Adapt to dynamic and partially known environments¶

When an agent or user request is received, the AGW evaluates the requested capability against its local capability directory. This directory includes both locally registered agents and capability summaries learned from other AGWs via CDSP. If a matching capability is found locally, the AGW can directly identify candidate agents and proceed with interaction setup. If the required capability cannot be satisfied using local information, the AGW initiates a distributed discovery process. In this case, the request is propagated to other AGWs in the network.¶

ADP supports both proactive and reactive discovery behaviors within a unified framework. In proactive scenarios, AGWs maintain an updated distributed capability view through CDSP, thereby enabling most discovery requests to be resolved locally with minimal latency. In reactive scenarios, when local knowledge is insufficient, AGWs dynamically query the network to identify suitable agents. Upon receiving a request, an AGW evaluates it against its capability directory and returns matching results if available. Responses SHOULD include the relevant Capability vectors, the corresponding Agent ID, and abstracted routing or reachability information sufficient for subsequent interaction.¶

Multiple candidate agents MAY be returned for a single request. The requesting AGW is responsible for selecting an appropriate agent based on local policies, optimization criteria, or contextual requirements.¶

5.5. Agent to Agent Communication overall Protocol Suites

From the perspective of an Agent, Agent-to-Agent (A2A) interaction is realized through a layered protocol suite, where each layer is responsible for a distinct aspect of task execution, semantic alignment, and interaction coordination, as shown in the figure below. These layers collectively ensure that agent collaboration is not only functionally correct but also semantically consistent and policy-compliant.¶

At the Application Layer, the agent is responsible for structuring and governing the execution of tasks prior to interaction with other agents. This includes task orchestration capabilities, where complex objectives are decomposed into smaller executable units and managed through an internal state model that tracks execution progress. In parallel, the agent applies policy and governance logic to determine how tasks should be executed or delegated. Such policies MAY include rule-based constraints and dynamic capability-based access control (CBAC), which influence decision-making based on context and authorization scope. The Application Layer also incorporates mechanisms for robustness and operational control, including human-in-the-loop (HITL) intervention and failure handling strategies such as escalation, retry, or fallback. The output of this layer is a structured and policy-compliant task intent that is ready for semantic processing.¶

The Semantic Layer provides the mechanisms required to transform application-level intent into a representation that can be consistently interpreted across agents. At this layer, agents rely on shared or compatible ontology and profile models to express capabilities in terms of classes, properties, and constraints[draft-zhang-dmsc-ioa-semantic-interaction] . Before interaction, the agent validates the generated semantic representation to ensure consistency, applicability, and determinism, thereby avoiding ambiguity during execution. For inputs expressed in natural language [draft-verma-dmsc-nlip-notes], the agent performs intent normalization [draft-sz-dmsc-iaip], translating unstructured descriptions into structured semantic forms while accounting for confidence levels and potential ambiguity. To ensure interoperability across different domains or versions, the Semantic Layer also supports alignment and version governance, enabling mapping between heterogeneous schemas and maintaining compatibility. In addition, agents MAY utilize supporting knowledge resources, such as standardized glossaries or remediation knowledge, to improve interpretation and resolve inconsistencies. The output of this layer is a normalized and validated semantic intent that can be directly mapped to interaction protocols.¶

The Coordination Layer defines the set of protocols that enable the agent to participate in distributed collaboration with other agents. This layer includes identity and trust establishment mechanisms, where the agent registers and maintains its identity through the Agent Registration Protocol (ARP) and operates under an authorization context provided via the Authentication and Authorization Protocol (AAAP). For interaction execution, the agent utilizes protocols such as the Task Invocation Protocol (TIP) [draft-yang-dmsc-ioa-task-protocol] and the Agent-to-Agent Protocol (A2A) to establish sessions, exchange messages, and coordinate task execution with peer agents. When the appropriate interaction target is not known in advance, the agent relies on the Agent Discovery Protocol (ADP) to identify candidate agents based on required capabilities. This discovery process is supported by capability knowledge made available through the Capability Directory Synchronization Protocol (CDSP), which ensures that the agent can perform discovery based on a distributed and continuously updated view of available capabilities. Together, these protocols provide the necessary mechanisms for secure, dynamic, and capability-driven interaction among agents.¶

These three layers operate in a coordinated manner across well-defined boundaries. The Application Layer defines what needs to be done, the Semantic Layer defines how it is described and understood, and the Coordination Layer defines how it is executed across agents. This organization enables a clear separation of concerns while preserving end-to-end coherence across task intent, semantic interpretation, and protocol execution. The layers are logically independent, allowing task logic, semantic models, and interaction protocols to evolve independently without compromising interoperability across agents.¶

+------------------------------------------------------------------+
|                    Application Layer                             |
|                                                                  |
| +------------------+ +------------------+ +------------------+   |
| | Task             | | Policy and       | | HITL and         |   |
| | Orchestration    | | Governance       | | Failure Handling |   |
| | - decomposition  | | - policy rules   | | - escalation     |   |
| | - state model    | | - dynamic CBAC   | | - fallback/retry |   |
| +------------------+ +------------------+ +------------------+   |
+-----------------------------+------------------------------------+
                              |
                              | Application-to-Semantic Contract
                              v
+------------------------------------------------------------------+
|                      Semantic Layer                              |
|                                                                  |
| +------------------+ +------------------+ +------------------+   |
| | Ontology and     | | Validation and   | | Natural-Language |   |
| | Profile Model    | | Rules            | | Intent           |   |
| | - classes and    | | - consistency    | | Normalization    |   |
| |   properties     | | - applicability  | | - text to intent |   |
| | - constraints    | | - deterministic  | | - confidence and |   |
| +------------------+ +------------------+ |   ambiguity      |   |
|                                           +------------------+   |
| +------------------+ +------------------+                        |
| | Alignment and    | | Knowledge        |                        |
| | Version          | | Resources        |                        |
| | Governance       | | - glossary/codes |                        |
| | - mapping        | | - remediation    |                        |
| |   confidence     | |   knowledge      |                        |
| | - compatibility  | |                  |                        |
| |                  | |                  |                        |
| +------------------+ +------------------+                        |
+-----------------------------+------------------------------------+
                              |
                              | Semantic-to-Interaction Contract
                              v
+------------------------------------------------------------------+
|                   Coordination Layer                             |
|       +---------------------+   +---------------------+          |
|       | Register & Identity |   |  Authentication     |          |
|       | - ARP               |   |  & Authorization    |          |
|       |                     |   |  - AAAP             |          |
|       +---------------------+   +---------------------+          |
|       +---------------------+   +---------------------+          |
|       | Invocation & Session|   | Sync & Discovery    |          |
|       | - TIP               |   | - CDSP              |          |
|       | - A2A               |   | - ADP               |          |
|       +---------------------+   +---------------------+          |
+------------------------------------------------------------------+
                              |
                              v
+------------------------------------------------------------------+
|       Transport Connectivity + Security Enforcement              |
+------------------------------------------------------------------+
  Figure 3 Agent to Agent Communication overall Protocol Suites

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