DMSC Working Group X. Li Internet-Draft China Telecom Intended status: Standards Track B. Liu Expires: 6 May 2027 Huawei Technologies J. Liu Beijing University of Posts and Telecommunications C. Du Tsinghua L. Zhang AsiaInfo Technologies (China) Inc 2 November 2026 Multi-agent Collaboration Protocol Suites Architecture draft-li-dmsc-macp-07 Abstract 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. Status of This Memo 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. Li, et al. Expires 6 May 2027 [Page 1] Internet-Draft MACP November 2026 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Multi-agent Collaboration Protocol Architecture . . . . . . . 5 4.1. Agent Management Center . . . . . . . . . . . . . . . . . 6 4.2. Agent Gateway . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. External Resource Service (ERS) . . . . . . . . . . . . . 8 4.5. Data Objects . . . . . . . . . . . . . . . . . . . . . . 9 4.6. Entity Summary . . . . . . . . . . . . . . . . . . . . . 10 5. Multi-Agent Collaboration Protocol Suite Overview . . . . . . 10 5.1. Agent-Gateway Interaction Protocol(AGIP) . . . . . . . . 10 5.1.1. Agent Registration and Capability Advertisement . . . 11 5.1.2. Capability Resolution . . . . . . . . . . . . . . . . 12 5.2. Agent Authentication and Authorization Protocol (AAAP) . 12 5.3. Capability Directory Synchronization Protocol (CDSP) . . 13 5.4. Gateway-side Mediation Requirements . . . . . . . . . . . 16 5.5. Agent to External Resource Service Protocol . . . . . . . 17 6. Capability Model . . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 9. Normative References . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction 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 Li, et al. Expires 6 May 2027 [Page 2] Internet-Draft MACP November 2026 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. Li, et al. Expires 6 May 2027 [Page 3] Internet-Draft MACP November 2026 * 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. 2. Conventions used in this document 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]. 3. Terminology 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. Li, et al. Expires 6 May 2027 [Page 4] Internet-Draft MACP November 2026 * 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. 4. Multi-agent Collaboration Protocol Architecture 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. Li, et al. Expires 6 May 2027 [Page 5] Internet-Draft MACP November 2026 +-----------------------+ |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 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. Li, et al. Expires 6 May 2027 [Page 6] Internet-Draft MACP November 2026 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 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]. 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. Li, et al. Expires 6 May 2027 [Page 7] Internet-Draft MACP November 2026 * 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. Li, et al. Expires 6 May 2027 [Page 8] Internet-Draft MACP November 2026 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. Li, et al. Expires 6 May 2027 [Page 9] Internet-Draft MACP November 2026 * 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. Multi-Agent Collaboration Protocol Suite Overview MACP defines a set of protocols to enable interaction among 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. Li, et al. Expires 6 May 2027 [Page 10] Internet-Draft MACP November 2026 5.1.1. Agent Registration and Capability Advertisement 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: 1. The Agent sends a registration request to its attached AGW, carrying its identity information together with its Agent Capability Specification (ACS). 2. The AGW invokes the Agent Authentication and Authorization Protocol (AAAP), as described in Section 5.2, to authenticate and authorize the requesting Agent. 3. Upon successful authentication and authorization, the AGW allocates a globally unique Agent Identity Code (AIC). 4. The AGW stores the advertised capability information in its local capability directory and associates it with the allocated AIC. 5. The AGW acknowledges successful registration to the Agent. 6. 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. Li, et al. Expires 6 May 2027 [Page 11] Internet-Draft MACP November 2026 5.1.2. Capability Resolution 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: 1. Receive the capability request from the requesting Agent. 2. Interpret and normalize the requested capability into an internal capability representation. 3. Match the normalized capability against the capability directory maintained by the AGW. 4. Identify one or more candidate Agents capable of satisfying the requested capability. 5. Apply local selection policies when multiple candidate Agents are available. 6. 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. 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: Li, et al. Expires 6 May 2027 [Page 12] Internet-Draft MACP November 2026 * 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 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). Li, et al. Expires 6 May 2027 [Page 13] Internet-Draft MACP November 2026 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: 1. 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. 2. The ACAS records the received information in its Access Mapping Table. Li, et al. Expires 6 May 2027 [Page 14] Internet-Draft MACP November 2026 3. The ACAS summarizes onboardings belonging to the same capability type and propagates the summarized information toward the responsible ACMS. 4. The target ACMS authenticates and confirms the onboarding. 5. 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. 1. A requester submits a task intent, and the client-side Agent attaches to an ingress ACMS. 2. 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. 3. The agent query is forwarded according to the Capability Table until the destination ACAS is reached. 4. The destination ACAS performs local matching according to its Access Mapping Table. 5. 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. Li, et al. Expires 6 May 2027 [Page 15] Internet-Draft MACP November 2026 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. 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. Li, et al. Expires 6 May 2027 [Page 16] Internet-Draft MACP November 2026 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. Li, et al. Expires 6 May 2027 [Page 17] Internet-Draft MACP November 2026 6. Capability Model 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. 7. IANA Considerations TBD 8. Acknowledgement TBD 9. Normative References [draft-sz-dmsc-iaip] S, S., "Intent-based Agent Interconnection Protocol at Agent Gateway. draft-sz-dmsc-iaip. ", 9 February 2026. [draft-verma-dmsc-nlip-notes] V, D., "Use of Natural Language for Agent Communication. draft-verma-dmsc-nlip-notes. ", 11 February 2026. [draft-wang-dmsc-drisac] Wang, Y., "Distributed Onboarding and Information Synchronization of Agent Capabilities. draft-wang-dmsc- drisac-01, ", August 2026. Li, et al. Expires 6 May 2027 [Page 18] Internet-Draft MACP November 2026 [draft-yang-dmsc-ioa-task-protocol] Y, C., "Internet of Agents Task Protocol (IoA Task Protocol) for Heterogeneous Agent Collaboration. draft- yang-dmsc-ioa-task-protocol. ", 14 January 2026. [draft-zhang-dmsc-gateway-directory-sync] Z, L., "Gateway Capability Directory and Synchronization for Internet of Agents. draft-zhang-dmsc-gateway- directory-sync. ", 28 April 2026. [draft-zhang-dmsc-ioa-semantic-interaction] Z, L., "Ontology-based Semantic Interaction for Internet of Agents. draft-zhang-dmsc-ioa-semantic-interaction. ", 4 February 2026. [GW-REQ] L, B., "Gateway Requirements for Dynamic Multi-agents Secured Collaboration. draft-liu-dmsc-gw-requirements. ", 16 January 2026. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . Authors' Addresses Xueting Li China Telecom Beiqijia Town, Changping District Beijing Beijing, 102209 China Email: lixt2@foxmail.com Li, et al. Expires 6 May 2027 [Page 19] Internet-Draft MACP November 2026 Bing Liu Huawei Technologies No. 156 Beiqing Road Beijing China Email: leo.liubing@huawei.com Jun Liu Beijing University of Posts and Telecommunications 10 Xitucheng Road, Haidian District Beijing 100876 China Email: liujun@bupt.edu.cn Chenguang Du Tsinghua Beijing 100094 China Email: du_chenguang@outlook.com Lianhua Zhang AsiaInfo Technologies (China) Inc Beijing 100000 China Email: zhanglh2@asiainfo.com Li, et al. Expires 6 May 2027 [Page 20]