Gateway Mediation Layer for AI Agent Collaboration
draft-yang-dmsc-gateway-semantic-layer-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Huiling Yang , Guozhen Dong , Lianhua Zhang , Yun Li , Shoufeng Wang | ||
| Last updated | 2026-07-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yang-dmsc-gateway-semantic-layer-02
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,
<https://developers.googleblog.com/en/a2a-a-new-era-of-
agent-interoperability/>.
[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, <https://datatracker.ietf.org/doc/draft-
dunbar-dmsc-gw-scenarios-gap-analysis/>.
[I-D.jeskey-anml]
Jeskey, A., "Agentic Notation Markup Language", Work in
Progress, Internet-Draft, draft-jeskey-anml, 2026,
<https://datatracker.ietf.org/doc/draft-jeskey-anml/>.
[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,
<https://datatracker.ietf.org/doc/draft-li-dmsc-macp/>.
[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, <https://datatracker.ietf.org/doc/
draft-somoza-atn-agent-trust-negotiation/>.
[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,
<https://datatracker.ietf.org/doc/draft-sz-dmsc-iaip/>.
[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, <https://datatracker.ietf.org/doc/draft-zhang-dmsc-
gateway-directory-sync/>.
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,
<https://www.anthropic.com/news/model-context-protocol>.
[TR-22-870]
3GPP, "Study on 6G Use Cases and Service Requirements",
3GPP TR 22.870, 2026,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=4374>.
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]