DMSC H. Yang Internet-Draft AsiaInfo Technologies (China) Inc. Intended status: Informational G. Dong Expires: 3 January 2027 China Telecom L. Zhang Y. Li S. Wang AsiaInfo Technologies (China) Inc. 2 July 2026 Gateway Mediation Layer for AI Agent Collaboration draft-yang-dmsc-gateway-semantic-layer-02 Abstract Cross-domain and policy-controlled agent collaboration can require mediation decisions that are not always suitable for an agent client or an agent server alone. A collaboration request may need to combine a stated goal, capability profiles, tenant or domain policy, trust evidence, disclosure limits, operational constraints, and handoff context before a concrete interaction mechanism is used. This document identifies gateway-side interaction mediation as a distinct interoperability gap in many AI Agent Gateway deployments. It does not claim that every agent collaboration requires a gateway. Rather, it explains why many deployments need a mediation point where request goals, capability profiles, policy, trust, and handoff constraints can be evaluated before interaction proceeds. The document describes a Gateway Mediation Layer as a decision- support and interface layer between application-level goals and concrete agent interaction mechanisms. It focuses on the role, inputs, outputs, and narrow set of interoperable artifacts that may require further work, such as Mediation Requests, Mediation Responses, Handoff Contexts, Failure Records, and Evidence References. It does not propose standardizing internal matching algorithms, domain ontologies, prompt engineering, or model-specific decision logic. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Yang, et al. Expires 3 January 2027 [Page 1] Internet-Draft Gateway Mediation Layer July 2026 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 3 January 2027. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability to AI Agent Gateway Standardization . . . . . . 6 5. 3GPP Service Requirements as Mediation Drivers . . . . . . . 7 6. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 9 7. Position in a DMSC Gateway Architecture . . . . . . . . . . . 10 8. Inputs to Gateway Mediation . . . . . . . . . . . . . . . . . 11 8.1. Mediation Request Goal . . . . . . . . . . . . . . . . . 12 8.2. Mediation Request Context . . . . . . . . . . . . . . . . 12 8.3. Registered Capability Profiles . . . . . . . . . . . . . 12 8.4. Mediation Policy Scope . . . . . . . . . . . . . . . . . 12 8.5. Mediation Trust Binding . . . . . . . . . . . . . . . . . 12 9. Gateway Mediation Operations . . . . . . . . . . . . . . . . 12 10. Outputs of the Gateway Mediation Layer . . . . . . . . . . . 13 10.1. Mediation Response . . . . . . . . . . . . . . . . . . . 13 10.2. Handoff Context . . . . . . . . . . . . . . . . . . . . 13 10.3. Failure Record . . . . . . . . . . . . . . . . . . . . . 13 10.4. Evidence Reference . . . . . . . . . . . . . . . . . . . 14 11. Relationship to Existing Mechanisms . . . . . . . . . . . . . 14 Yang, et al. Expires 3 January 2027 [Page 2] Internet-Draft Gateway Mediation Layer July 2026 11.1. Gateway Deployment Scenarios and Gap Analysis . . . . . 14 11.2. Discovery and Directory Mechanisms . . . . . . . . . . . 14 11.3. Agent Interaction Mechanisms . . . . . . . . . . . . . . 15 11.4. Capability Description Mechanisms . . . . . . . . . . . 15 11.5. Trust, Authorization, and Audit Mechanisms . . . . . . . 15 12. Protocol and Interoperability Considerations . . . . . . . . 16 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 16. Informative References . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction AI agent deployments are moving from local tool use toward collaboration across domains, platforms, networks, tenants, vendors, operational boundaries, and trust boundaries. In simple deployments, an agent can directly select a tool or endpoint and invoke it using a local protocol. In more complex deployments, a domain may need to decide what capabilities are visible, how a request goal is interpreted, which policies constrain the interaction, which trust evidence is acceptable, and what information can be handed off to a subsequent protocol step. These decisions can create a need for a gateway-side mediation point. Although cross-domain and policy-controlled deployments can reuse existing connectivity, discovery, capability description, trust evidence, and syntactic interoperability mechanisms, those mechanisms are not sufficient by themselves. A deployment may be able to find an endpoint, retrieve a machine-readable description, and parse a message while still being unable to decide whether a candidate capability is appropriate for the requested goal, whether local policy permits disclosure, whether trust evidence is sufficient, or why a task failed. The missing element in such deployments is not another complete communication protocol, but a mediation decision function that connects request goals, capability profiles, policy, trust, and handoff constraints. This document positions the Gateway Mediation Layer as that decision function when an AI Agent Gateway is used as the mediation point. It focuses on the information and decision artifacts needed by an AI Agent Gateway to make reliable collaboration decisions and prepare controlled handoff to existing interaction mechanisms. This document provides applicability and gap analysis for gateway- side interaction mediation and identifies a limited set of candidate interoperable artifacts. It complements gateway deployment scenario and gap analysis work [I-D.dunbar-dmsc-gw-scenarios-gap-analysis], Yang, et al. Expires 3 January 2027 [Page 3] Internet-Draft Gateway Mediation Layer July 2026 gateway directory and synchronization work [I-D.zhang-dmsc-gateway-directory-sync], and protocol-suite architecture work such as MACP [I-D.li-dmsc-macp]. Scope limitations and non-goals are listed in Section 6. 2. Terminology The following terms are used in this document: AI Agent Gateway: A gateway or gateway function that mediates agent collaboration across administrative, policy, trust, operational, capability-description, or network boundaries. The term denotes a logical role and does not require a single physical node. Gateway Mediation Layer: A logical decision-support and interface layer in an AI Agent Gateway that interprets request goals, uses registered capability profiles, applies policy and trust constraints, prepares handoff context, and records decisions or failures. Mediation Request Goal: A goal-oriented statement of what a user, application, or upstream agent wants to achieve, without necessarily naming a fixed agent, tool, endpoint, or protocol. Mediation Request Context: The domain, service scope, time window, data sensitivity, operational state, user or tenant constraints, and other information needed to interpret a mediation request and constrain handoff. Registered Capability Profile: A gateway-visible description of an agent, tool, service, or function. It may be derived from an A2A Agent Card, MCP descriptor, ANML or metadata document, local registration payload, or operator-managed source. Mediation Policy Scope: The authorization scope, data exposure limits, privacy constraints, tenant policy, domain policy, regulatory constraints, and operational limits that apply to a mediation decision. Mediation Trust Binding: The trust evidence, identity status, authorization or delegation evidence, provenance, attestation result, receipt, or registry validation status associated with a candidate capability or handoff decision. Mediation Response: The gateway output that records whether a candidate capability, agent, gateway, service, or interaction target was selected, rejected, constrained, or handed off, together with applicable reasons, scope, and references. Yang, et al. Expires 3 January 2027 [Page 4] Internet-Draft Gateway Mediation Layer July 2026 Handoff Context: Information prepared by the gateway to enable a subsequent interaction through A2A, MCP, IAIP, HTTP, or another suitable mechanism. Failure Record: A structured record of why mediation, policy validation, trust validation, or handoff preparation failed. Evidence Reference: A reference to evidence used by a mediation decision, such as a source description, validation status, authorization scope, delegation evidence, attestation result, receipt, provenance record, or audit reference. The referenced evidence itself may be provided by other mechanisms. 3. Problem Statement Cross-domain and policy-controlled agent collaboration introduces mediation requirements that cannot always be placed solely at an agent client or an agent server. A collaboration request may involve a goal from an application, candidate capabilities from multiple source descriptions, policies from one or more domains, and trust evidence from security mechanisms. These inputs must be turned into a decision that can be used by a concrete interaction protocol. Some mediation decisions can be made by an agent client or an agent server in simple deployments. A client-side agent may understand the user's goal, and a server-side agent may understand its own capability description. However, in deployments that cross administrative, policy, trust, operational, capability-description, or network boundaries, neither side necessarily has the full cross- domain view or the local authority needed to decide which capabilities are visible, which tenant or domain policy applies, which trust evidence is sufficient, what context may be disclosed, how heterogeneous capability descriptions should be compared, or how a failure should be reported for audit, accounting, troubleshooting, or escalation. Gateway deployment scenarios analyzed in [I-D.dunbar-dmsc-gw-scenarios-gap-analysis] show that gateway functions can provide value in deployments involving multiple tenants, multiple vendors, cross-organization collaboration, policy- controlled capability exposure, operational visibility, mobility, and physical-world action authorization. These scenarios indicate that many deployments need a mediation function when request goals, capability profiles, local policy, cross-domain trust evidence, disclosure control, operational visibility, and auditable outcomes must be evaluated together. An AI Agent Gateway is one architectural role that can host this function. Yang, et al. Expires 3 January 2027 [Page 5] Internet-Draft Gateway Mediation Layer July 2026 The Gateway Mediation Layer is applicable when such a mediation point is used to decide how request goals, capability profiles, policy constraints, trust evidence, and handoff context are interpreted before interaction proceeds. The standardization question is: what mediation inputs, responses, handoff context, failure records, and references are needed at that mediation point so that those decisions can be expressed and used in an interoperable way? Without a gateway mediation layer, the following interoperability failures can occur: - A candidate is reachable but selected incorrectly because capability meaning is ambiguous. - A syntactically valid description is used outside its intended profile, version, or domain context. - Policy constraints and capability constraints are evaluated separately and produce inconsistent outcomes. - Trust evidence is available but not connected to the capability, delegation, or handoff decision. - A task is handed off without sufficient task meaning, context summary, disclosure limits, or failure handling information. - Failures are reported as opaque errors, making retry, escalation, audit, accounting, and troubleshooting difficult. The gateway mediation layer therefore helps the gateway not only select an appropriate agent or capability, but also record why a task was not completed. It turns decision and failure causes into structured information that the gateway can use for retry, escalation, audit, accounting, and controlled handoff. 4. Applicability to AI Agent Gateway Standardization This document is intended to support discussion of AI Agent Gateway work by identifying a specific gateway-side function rather than defining a complete gateway architecture. In this document, the relevant function is interaction mediation: the gateway interprets request goals, registered capability profiles, policy constraints, trust evidence, and handoff context before a concrete interaction mechanism is used. The function is used when a gateway mediates collaboration across administrative, tenant, vendor, policy, trust, capability- description, operational, or network boundaries. In such Yang, et al. Expires 3 January 2027 [Page 6] Internet-Draft Gateway Mediation Layer July 2026 deployments, the gateway may need to decide which capabilities are visible, whether a discovered or registered capability fits a request goal, what context may be disclosed, which evidence is sufficient, and how a selected interaction should be constrained or explained. Existing mechanisms can provide important inputs. Discovery mechanisms can locate candidate agents, tools, services, or capability documents. Description mechanisms can expose machine- readable capabilities and operational metadata. Trust, authorization, attestation, and audit mechanisms can provide evidence. Communication mechanisms can carry the subsequent interaction. However, these mechanisms do not by themselves define the gateway-side decision output that connects request goals, capability profiles, policy, trust, and handoff constraints. The potential IETF work identified by this document is therefore limited to interoperable gateway decision artifacts and references, such as Mediation Requests, Mediation Responses, Handoff Contexts, Failure Records, Evidence References, source-description validation status, and policy or trust constraint references. The document does not propose standardizing gateway algorithms, ranking policy, domain ontologies, a new discovery protocol, a new agent communication protocol, or a complete product architecture. This framing allows the gateway mediation layer to be discussed as one candidate component of AI Agent Gateway work: it explains why a gateway is more than a forwarding proxy, while keeping the possible standardization target narrow and compatible with existing discovery, description, security, audit, and communication mechanisms. 5. 3GPP Service Requirements as Mediation Drivers 3GPP TR 22.870 studies 6G use cases and service requirements, including AI-assisted services, AI Agent communication, data exposure, privacy protection, intent-based service operation, and mobility-related service behavior [TR-22-870]. Selected service- requirement themes from TR 22.870 illustrate why gateway-mediated deployments may need a mediation layer. +===========================+=====================================+ | 3GPP service-requirement | Mediation decision need in a | | theme | gateway | +===========================+=====================================+ | On-demand networking with | When intent handling is mediated by | | AI Agent (PR 6.21.6-1 and | a gateway, mediation decisions may | | PR 6.21.6-3): translating | be needed to relate the received | | received intent into | intent to service and performance | | service and performance | requirements, identify the intent | Yang, et al. Expires 3 January 2027 [Page 7] Internet-Draft Gateway Mediation Layer July 2026 | requirements, and | source, associate it with the | | associating an intent | subscriber context, and record the | | source with resulting | actions resulting from the | | actions. | interpreted intent. | +---------------------------+-------------------------------------+ | 6G system assisted AI | When such service invocation or | | Agent service (PR 6.8.6-1 | data exchange is mediated by a | | to PR 6.8.6-3): AI Agent | gateway, mediation decisions may be | | applications invoking | needed to relate the requested task | | selected network | to the appropriate 3GPP service | | services, receiving | capability, interpret exposed QoS | | exposed information such | or data-characteristic information, | | as QoS changes, and | apply operator policy and | | exchanging multi-modal | permission constraints, and prepare | | data subject to operator | a constrained handoff to the | | policy and permission. | selected interaction mechanism. | +---------------------------+-------------------------------------+ | Data exposure service (PR | When third-party data access is | | 5.5.5.3-1 and PR | mediated by a gateway, mediation | | 5.5.5.3-2): authorized | decisions may be needed to describe | | third-party access to | accessible data characteristics and | | processed user-equipment- | processing capabilities while | | related data and metadata | preserving operator policy, | | describing accessible | regulatory constraints, subscriber | | data characteristics and | permission, and protection of UE | | processing capabilities. | identities and individual user | | | data. | +---------------------------+-------------------------------------+ | Privacy protection of | When information exposure is | | data exposure (PR | mediated by a gateway, mediation | | 5.5.7.3-1 and PR | decisions may be needed to | | 5.5.7.3-2): protecting | determine disclosure scope and | | user privacy, location | handoff constraints while | | privacy, identity | preserving user privacy, location | | information, and | privacy, identity protection, and | | corresponding exposed | recipient authorization context. | | information. | | +---------------------------+-------------------------------------+ | AI Agents communication | When AI Agent communication is | | (PR 6.7.6-1 to PR | mediated by a gateway, mediation | | 6.7.6-6): trusted access, | decisions may be needed to | | attribute exposure, | interpret exposed agent attributes, | | registration and | relate registered capabilities to a | | discovery of authorized | collaborative task, constrain | | third-party AI Agents, | discovery and service exposure to | | secure communication, | authorized third-party AI Agents, | | service exposure, and | and bind the selected collaborator | | coordination within or | to policy, permission, and trust | Yang, et al. Expires 3 January 2027 [Page 8] Internet-Draft Gateway Mediation Layer July 2026 | across AI Agent groups. | context. | +---------------------------+-------------------------------------+ | Flexible traffic routing | When traffic-routing decisions are | | and mobility-related | exposed to or consumed by a | | service behavior (PR | gateway-mediated agent workflow, | | 5.9.7.6-1): routing | mediation decisions may be needed | | decisions may depend on | to represent the mobility context | | UE mobility between | and routing outcome so that handoff | | multiple 6G core networks | or failure handling reflects the | | of the same PLMN. | change between 6G core networks. | +---------------------------+-------------------------------------+ Table 1: 3GPP Requirement Themes and Gateway Mediation Decisions These requirement themes indicate that a gateway decision is not only an endpoint or protocol selection. It may need to combine request goals, capability profiles, policy limits, trust status, exposure constraints, network context, and failure reasons. The gateway mediation layer therefore provides the decision vocabulary and output objects needed to make such decisions reusable across interaction mechanisms and administrative domains. 6. Scope and Non-Goals This document describes the role and interoperability needs of a gateway mediation layer. It identifies candidate inputs, outputs, and gateway-side mediation operations. Out of scope are: - a universal ontology for all AI agents; - a full domain ontology library; - a new agent communication protocol; - a replacement for A2A, MCP, Agent Cards, ANML, ATN, DAWN, OAuth, WIMSE, TLS, DNS, HTTP, or other mechanisms; - a discovery query protocol or global registry; - a task orchestration or session protocol; - an authentication, authorization, attestation, or trust framework; - a complete audit, usage accounting, payment, or settlement system; or Yang, et al. Expires 3 January 2027 [Page 9] Internet-Draft Gateway Mediation Layer July 2026 - an internal product architecture for gateways. Domain ontologies, business knowledge, and model-specific interpretation logic remain domain-specific or implementation- specific. They may inform capability profiles, task interpretation, policy constraints, and handoff context, while the gateway mediation layer focuses on how gateways reference, constrain, validate, and explain mediation decisions through interoperable artifacts. 7. Position in a DMSC Gateway Architecture The Gateway Mediation Layer sits between application-level goals and agent interaction mechanisms. Above it, applications or upstream agents provide request goals, task orchestration needs, or human escalation signals. Below it, interaction mechanisms such as A2A, MCP, IAIP, HTTP APIs, Agent Cards, and metadata documents carry tasks, messages, tools, resources, endpoints, and descriptions. The mediation layer provides two interface points: - a Mediation Request Interface, which turns request goals and task context into inputs usable by the gateway decision function; and - a Mediation Response Interface, which turns gateway decisions into response, handoff, failure, and evidence information for concrete interaction mechanisms. Gateway support functions such as registry and discovery, identity and authorization, directory synchronization, audit, and accounting provide inputs to the mediation layer, but do not replace it. Likewise, transport and security mechanisms provide connectivity, secure channels, integrity protection, and policy enforcement, but do not by themselves define request-goal interpretation, capability- profile use, or handoff context. Yang, et al. Expires 3 January 2027 [Page 10] Internet-Draft Gateway Mediation Layer July 2026 +--------------------------------+ +------------------------+ | Application Request | | Gateway Support | | Request Goal | | Functions | | Task Orchestration | | | | Human Escalation | | Registry / Discovery | +---------------+----------------+ | | | | Identity / Authz | Mediation Request Interface | | | | Sync / Directory | +--------------------------------+ | | | Gateway Mediation Layer |<---| Audit / Accounting | | Request Goal Context | | | | Capability Profile Use | | Control / Management | | Policy Scope Evaluation | | support to mediation | | Trust Binding Evaluation | | and interaction layers | | Handoff Context | | | | Failure / Evidence Records | | | +---------------+----------------+ | | | | | Mediation Response Interface | | | | | +--------------------------------+ | | | Agent Interaction Mechanisms |<---| | | A2A Tasks / Messages | | | | MCP Tools / Resources | | | | IAIP / HTTP APIs | | | | Agent Cards / Metadata | | | +---------------+----------------+ | | | | | +--------------------------------+ | | | Transport and Security | | | | Connectivity | | | | Secure Channels | | | | Integrity Protection | | | +--------------------------------+ +------------------------+ Figure 1: Gateway Mediation Layer Position Solid vertical arrows represent the main runtime decision flow. Side arrows represent control and management support from registry, discovery, identity, authorization, synchronization, audit, and accounting functions. The figure is illustrative rather than a required gateway implementation architecture. 8. Inputs to Gateway Mediation A gateway mediation layer can use the following classes of input. The precise data model may be defined by other drafts or future work. Yang, et al. Expires 3 January 2027 [Page 11] Internet-Draft Gateway Mediation Layer July 2026 8.1. Mediation Request Goal A mediation request goal describes the goal of an interaction. It may be provided by an application, user-facing agent, orchestrator, or upstream domain. In gateway-mediated deployments, it often needs to be interpreted together with task context, policy constraints, capability profiles, and trust evidence, rather than treated only as a string or endpoint selector. 8.2. Mediation Request Context Mediation request context includes the domain, service scope, time window, data sensitivity, operational state, user or tenant constraints, and other information needed to interpret the request goal and constrain handoff. 8.3. Registered Capability Profiles Registered capability profiles may come from A2A Agent Cards, MCP descriptors, ANML or other machine-readable metadata documents, local registration payloads, or gateway-managed directories. A gateway may validate, normalize, and constrain these profiles before using them for decisions. 8.4. Mediation Policy Scope Mediation policy scope includes authorization scope, data exposure limits, privacy constraints, tenant policy, domain policy, regulatory constraints, and operational limits. A capability fit is not sufficient if policy does not allow use or disclosure. 8.5. Mediation Trust Binding Mediation trust binding may include identity status, authorization or delegation evidence, provenance, attestation results, receipts, registry validation, or other trust metadata. The gateway mediation layer uses such trust information as a constraint on selection and handoff. 9. Gateway Mediation Operations The mediation layer performs gateway-side operations that turn inputs into decisions. These operations may be implemented in different ways by different deployments. The internal algorithms are not proposed for standardization by this document, but their outputs may require interoperable representation. Yang, et al. Expires 3 January 2027 [Page 12] Internet-Draft Gateway Mediation Layer July 2026 - Interpret request goals: Relate a request goal and request context to registered capability profiles and operational context. - Evaluate candidate capability profiles: Determine which candidate capabilities can satisfy the request goal and request context. - Apply policy and trust scope: Filter or constrain candidates according to local policy, authorization, disclosure limits, and trust evidence. - Prepare handoff context: Produce task meaning, context summary, disclosure limits, target references, and failure handling information for the next interaction mechanism. - Record decisions and failures: Produce decision reasons and failure records that can support retry, escalation, audit, accounting, and troubleshooting. 10. Outputs of the Gateway Mediation Layer 10.1. Mediation Response A Mediation Response indicates whether a candidate capability, agent, gateway, or service was selected, rejected, constrained, or handed off. It can include the selected capability, decision reason, profile or version references, applicable scope, and policy or trust constraints. 10.2. Handoff Context A Handoff Context carries information needed by the next interaction mechanism. It can include task meaning, context summary, disclosure limits, interaction mechanism, target reference, and failure handling information. It allows a gateway decision to be used by A2A, MCP, IAIP, HTTP, or another suitable mechanism without replacing those mechanisms. 10.3. Failure Record A Failure Record distinguishes failures such as capability mismatch, request-goal ambiguity, parameter mismatch, policy constraint failure, trust insufficiency, stale capability information, unavailable context, and context-version mismatch. These distinctions allow gateways and upstream applications to decide whether to retry, try another candidate, escalate, request more information, or record an auditable event. Yang, et al. Expires 3 January 2027 [Page 13] Internet-Draft Gateway Mediation Layer July 2026 10.4. Evidence Reference An Evidence Reference links a mediation decision, handoff context, or failure record to the evidence used by the gateway. Such references can point to source descriptions, validation status, authorization or delegation evidence, attestation results, receipts, provenance records, or audit references without embedding the full evidence object in every mediation artifact. 11. Relationship to Existing Mechanisms 11.1. Gateway Deployment Scenarios and Gap Analysis The gateway deployment scenario and gap analysis draft identifies deployment cases in which AI Agent Gateway functions provide operational or interoperability benefits beyond direct agent-to-agent communication [I-D.dunbar-dmsc-gw-scenarios-gap-analysis]. It analyzes single-domain, multi-vendor, multi-tenant, cross- organization, telecom operator, mobility-driven, and physical-world- operation scenarios, and discusses gateway functions such as operational onboarding, capability advertisement and discovery, peer selection and routing, identity and trust establishment, policy enforcement, observability, synchronization, and network-aware reachability. The mediation layer identified here supports those gateway functions. For example, policy-controlled capability exposure requires the gateway to evaluate capability profiles and disclosure sensitivity; peer selection and routing require request-to-capability evaluation; observability and audit require structured decision and failure reasons; and cross-domain handoff requires a constrained description of task meaning, context, policy, and trust evidence. 11.2. Discovery and Directory Mechanisms Discovery mechanisms such as DAWN-related work can locate candidate agents, tools, skills, services, or capability documents. Gateway directory and synchronization work can provide validated and policy- constrained capability views, capability digests, lifecycle state, freshness, and provenance information [I-D.zhang-dmsc-gateway-directory-sync]. Yang, et al. Expires 3 January 2027 [Page 14] Internet-Draft Gateway Mediation Layer July 2026 The gateway mediation layer does not replace discovery or directory synchronization. It consumes discovery and directory outputs and determines how discovered or registered capabilities relate to request goals, policy constraints, trust evidence, and handoff requirements. In this sense, discovery and directory mechanisms provide candidate inputs, while the gateway mediation layer provides the mediation decision. 11.3. Agent Interaction Mechanisms Agent interaction mechanisms such as A2A, MCP, IAIP, HTTP APIs, or similar protocols can carry tasks, messages, artifacts, tool calls, resources, prompts, context, or interaction state [A2A] [MCP] [I-D.sz-dmsc-iaip]. They remain responsible for the concrete interaction. The gateway mediation layer prepares constrained handoff information for such mechanisms. It does not define their message formats, session behavior, transport behavior, or tool invocation procedures. Interaction mechanisms carry the selected interaction, while the gateway mediation layer records why that interaction is selected, constrained, rejected, or handed off. 11.4. Capability Description Mechanisms Capability descriptions may be provided through Agent Cards, MCP descriptors, ANML or other metadata documents, ACAP-like capability documents, local registration payloads, or gateway-managed directories [I-D.jeskey-anml]. Such descriptions can expose useful information about capability names, interfaces, authentication requirements, transport configuration, profile references, or operational metadata. The gateway mediation layer treats these descriptions as inputs. It may validate, normalize, constrain, and reference them, but it does not define a replacement capability advertisement or metadata format. Capability descriptions state what a capability claims or exposes; the gateway mediation layer decides how those claims can be used in a given policy, trust, and handoff context. 11.5. Trust, Authorization, and Audit Mechanisms Trust, authorization, attestation, and audit mechanisms can provide identity status, delegation evidence, authorization scope, provenance, attestation results, receipts, or audit evidence. Examples include OAuth, WIMSE, RATS, SCITT, ATN, EMILIA-style receipts, DNSSEC, DANE, and domain-specific trust mechanisms [I-D.somoza-atn-agent-trust-negotiation]. Yang, et al. Expires 3 January 2027 [Page 15] Internet-Draft Gateway Mediation Layer July 2026 The gateway mediation layer consumes such evidence as constraints on selection and handoff. It does not define authentication, authorization, attestation, trust negotiation, receipt, or audit protocols. Trust and authorization mechanisms provide evidence; the gateway mediation layer determines how that evidence constrains capability visibility, selection, disclosure, handoff, and failure reporting. 12. Protocol and Interoperability Considerations Not every gateway mediation function needs to be standardized. Internal matching algorithms, ranking policies, user-interface behavior, ontology management tools, knowledge-base storage, prompt engineering, model selection, and gateway module decomposition are implementation choices. Potential protocol or interoperability work is narrower. It concerns the artifacts that cross a gateway boundary, are consumed by another component, or need to be recorded in a stable and comparable form. The following objects are the primary candidates for further analysis: - Mediation Request: a gateway input artifact that carries the request goal, request context, applicable policy scope, and references to candidate capability profiles or discovery results. - Mediation Response: a gateway decision artifact that records whether a candidate capability, agent, gateway, service, or interaction target was selected, rejected, constrained, or handed off. It may include the selected target reference, source- description references, profile and version references, applicable scope, policy and trust constraint references, decision reason, and validation status. - Handoff Context: a constrained handoff artifact that carries task meaning, context summary, disclosure limits, interaction mechanism, target reference, policy and trust constraints, and any profile references needed by the next interaction mechanism. It allows a gateway mediation decision to be used by A2A, MCP, IAIP, HTTP, or another suitable mechanism without replacing those mechanisms. - Failure Record: a structured failure artifact that distinguishes capability mismatch, request-goal ambiguity, profile mismatch, policy constraint failure, trust insufficiency, stale capability information, unavailable context, context-version mismatch, and handoff preparation failure. It supports retry, fallback, escalation, audit, accounting, and troubleshooting without exposing unnecessary raw prompts or internal policy details. Yang, et al. Expires 3 January 2027 [Page 16] Internet-Draft Gateway Mediation Layer July 2026 Additional supporting references may also require interoperable treatment when they are exchanged across domains or retained for audit. These include source description references and validation status, gateway-managed capability view or digest references, profile and version references, policy constraint references, trust evidence references, and decision or failure reason-code registries. Future work should determine which of these artifacts need common data models, which only require reference conventions, and which can remain deployment-specific. Such work should reuse existing discovery, description, security, authorization, attestation, audit, and transport mechanisms rather than defining replacements for them. 13. Security Considerations The Gateway Mediation Layer influences which agents or capabilities are selected, what context is disclosed, and how tasks are handed off. Incorrect mediation decisions can cause policy violations, capability misuse, failed handoff, or misleading audit records. Mediation inputs should therefore be protected against tampering, replay, downgrade, stale references, and misleading provenance. Gateways should distinguish self-asserted source descriptions from validated gateway-managed views. Trust evidence and authorization scope should be bound to the capability or handoff decision where possible. Authentication, authorization, attestation, transport security, and trust negotiation should reuse existing mechanisms such as TLS, OAuth, WIMSE, RATS, SCITT, ATN, DNSSEC, DANE, or domain-specific trust mechanisms where appropriate. 14. Privacy Considerations Mediation request goals, request context, capability profiles, and failure records can reveal sensitive information about users, business processes, network operations, internal tools, operational policy, or data access patterns. Gateway mediation decisions should use minimal disclosure. Handoff contexts should carry only the task meaning, context summary, and disclosure limits needed for the next interaction. Failure records should be useful for retry and troubleshooting without exposing unnecessary raw prompts, personal data, confidential business information, or internal policy details. Yang, et al. Expires 3 January 2027 [Page 17] Internet-Draft Gateway Mediation Layer July 2026 15. IANA Considerations This document makes no request for IANA action. 16. Informative References [A2A] Google Developers Blog, "Agent2Agent Protocol: A New Era of Agent Interoperability", 9 April 2025, . [I-D.dunbar-dmsc-gw-scenarios-gap-analysis] Dunbar, L. and Y. Wang, "Deployment Scenarios and Gap Analysis for AI Agent Gateway", Work in Progress, Internet-Draft, draft-dunbar-dmsc-gw-scenarios-gap- analysis, 2026, . [I-D.jeskey-anml] Jeskey, A., "Agentic Notation Markup Language", Work in Progress, Internet-Draft, draft-jeskey-anml, 2026, . [I-D.li-dmsc-macp] Li, Z., "Multi-Agent Collaboration Protocol for Internet of Agents", Work in Progress, Internet-Draft, draft-li- dmsc-macp, 2026, . [I-D.somoza-atn-agent-trust-negotiation] Somoza, E., "Agent Trust Negotiation: Capability, Delegation, and Provenance Binding for AI Agents", Work in Progress, Internet-Draft, draft-somoza-atn-agent-trust- negotiation, 2026, . [I-D.sz-dmsc-iaip] Sun, S., "Intent-based Agent Interconnection Protocol at Agent Gateway", Work in Progress, Internet-Draft, draft- sz-dmsc-iaip, 2026, . [I-D.zhang-dmsc-gateway-directory-sync] Zhang, L., "Gateway Capability Directory and Synchronization for Internet of Agents", Work in Progress, Internet-Draft, draft-zhang-dmsc-gateway-directory-sync, 2026, . Yang, et al. Expires 3 January 2027 [Page 18] Internet-Draft Gateway Mediation Layer July 2026 [MCP] Anthropic, "Introducing the Model Context Protocol", 25 November 2024, . [TR-22-870] 3GPP, "Study on 6G Use Cases and Service Requirements", 3GPP TR 22.870, 2026, . Authors' Addresses Huiling Yang AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: yanghl10@asiainfo.com Guozhen Dong China Telecom Beiqijia Town, Changping District Beijing 102209 China Email: donggz@chinatelecom.cn Lianhua Zhang AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: zhanglh2@asiainfo.com Yun Li AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: liyun9@asiainfo.com Yang, et al. Expires 3 January 2027 [Page 19] Internet-Draft Gateway Mediation Layer July 2026 Shoufeng Wang AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: wangsf11@asiainfo.com Yang, et al. Expires 3 January 2027 [Page 20]