| Internet-Draft | Gateway Semantic Layer | June 2026 |
| Yang, et al. | Expires 1 January 2027 | [Page] |
Cross-domain and policy-controlled agent collaboration can require semantic decisions that are not always suitable for an agent client or an agent server alone. A collaboration request may need to combine business intent, capability meaning, tenant or domain policy, trust evidence, disclosure limits, operational constraints, and handoff context before a concrete interaction mechanism is used.¶
This document identifies such gateway-side semantic decision-making 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 intent, capability meaning, policy, trust, and handoff constraints can be evaluated before interaction proceeds.¶
The document describes a Gateway Semantic Layer as a decision layer between application-level intent 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 Resolution Results, Handoff Descriptors, Failure Explanations, and related references.¶
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 1 January 2027.¶
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.¶
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 business intent 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 mediation point for semantic decision-making.¶
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 matches the business intent, 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 intent, capability meaning, policy, trust, and handoff constraints.¶
This document positions the Gateway Semantic Layer as that decision function when an AI Agent Gateway is used as the mediation point. It focuses on the semantic 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 semantic decision-making 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], gateway directory and synchronization work [I-D.zhang-dmsc-gateway-directory-sync], semantic interaction work [I-D.zhang-dmsc-ioa-semantic-interaction], and protocol-suite architecture work such as MACP [I-D.li-dmsc-macp]. Scope limitations and non-goals are listed in Section 6.¶
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, semantic, or network boundaries. The term denotes a logical role and does not require a single physical node.¶
Gateway Semantic Layer: A logical decision layer in an AI Agent Gateway that uses semantic information to interpret intent, understand capability meaning, apply policy and trust constraints, prepare handoff, and explain decisions or failures.¶
Business Intent: 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.¶
Capability Description: A 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.¶
Gateway-managed Capability View: A validated, normalized, policy-constrained view of capabilities that a gateway uses for decisions. It may be derived from one or more source descriptions.¶
Semantic Resolution: A gateway-side process that uses business intent, task context, capability descriptions, policy constraints, and trust evidence to select, reject, constrain, or hand off candidate capabilities.¶
Resolution Result: The output of semantic resolution, including the selected capability or rejection decision, decision reason, applicable scope, and constraints.¶
Handoff Descriptor: Information prepared by the gateway to enable a subsequent interaction through A2A, MCP, IAIP, HTTP, or another suitable mechanism.¶
Failure Explanation: A structured explanation of why semantic resolution, policy validation, trust validation, or handoff preparation failed.¶
Cross-domain and policy-controlled agent collaboration introduces semantic decision requirements that cannot always be placed solely at an agent client or an agent server. A collaboration request may involve business intent 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 semantic 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, semantic, 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 normalized, 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. From the semantic-decision perspective, these scenarios indicate that many deployments need a mediation function when semantic decisions must combine intent, capability meaning, local policy, cross-domain trust evidence, disclosure control, operational visibility, and auditable outcomes. An AI Agent Gateway is one architectural role that can host this function.¶
The gateway semantic layer is applicable when such a mediation point is used to decide how business intent, capability descriptions, policy constraints, trust evidence, and handoff context are interpreted before interaction proceeds. The semantic question is: what semantic information and decision outputs are needed at that mediation point so that those decisions can be expressed and used in an interoperable way?¶
Without a gateway semantic 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 semantic profile, version, or domain context.¶
- Policy constraints and semantic 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 semantics.¶
- Failures are reported as opaque errors, making retry, escalation, audit, accounting, and troubleshooting difficult.¶
The semantic layer therefore helps the gateway not only select the right agent or capability, but also understand and explain 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.¶
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 semantic decision-making: the gateway interprets business intent, capability meaning, 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, semantic, operational, or network boundaries. In such deployments, the gateway may need to decide which capabilities are visible, whether a discovered or registered capability matches an intent, 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 intent, capability meaning, 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 Resolution Results, Handoff Descriptors, Failure Explanations, semantic profile 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 semantic 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.¶
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 semantic decision layer.¶
| 3GPP service-requirement theme | Semantic decision need in a gateway |
|---|---|
| On-demand networking with AI Agent (PR 6.21.6-1 and PR 6.21.6-3): translating received intent into service and performance requirements, and associating an intent source with resulting actions. | When intent handling is mediated by a gateway, semantic decisions may be needed to relate the received intent to service and performance requirements, identify the intent source, associate it with the subscriber context, and record the actions resulting from the interpreted intent. |
| 6G system assisted AI Agent service (PR 6.8.6-1 to PR 6.8.6-3): AI Agent applications invoking selected network services, receiving exposed information such as QoS changes, and exchanging multi-modal data subject to operator policy and permission. | When such service invocation or data exchange is mediated by a gateway, semantic decisions may be needed to relate the requested task to the appropriate 3GPP service capability, interpret exposed QoS or data-characteristic information, apply operator policy and permission constraints, and prepare a constrained handoff to the selected interaction mechanism. |
| Data exposure service (PR 5.5.5.3-1 and PR 5.5.5.3-2): authorized third-party access to processed user-equipment-related data and metadata describing accessible data characteristics and processing capabilities. | When third-party data access is mediated by a gateway, semantic decisions may be needed to describe accessible data characteristics and processing capabilities while preserving operator policy, regulatory constraints, subscriber permission, and protection of UE identities and individual user data. |
| Privacy protection of data exposure (PR 5.5.7.3-1 and PR 5.5.7.3-2): protecting user privacy, location privacy, identity information, and corresponding exposed information. | When information exposure is mediated by a gateway, semantic decisions may be needed to determine disclosure scope and handoff constraints while preserving user privacy, location privacy, identity protection, and recipient authorization context. |
| AI Agents communication (PR 6.7.6-1 to PR 6.7.6-6): trusted access, attribute exposure, registration and discovery of authorized third-party AI Agents, secure communication, service exposure, and coordination within or across AI Agent groups. | When AI Agent communication is mediated by a gateway, semantic decisions may be needed to interpret exposed agent attributes, relate registered capabilities to a collaborative task, constrain discovery and service exposure to authorized third-party AI Agents, and bind the selected collaborator to policy, permission, and trust context. |
| Flexible traffic routing and mobility-related service behavior (PR 5.9.7.6-1): routing decisions may depend on UE mobility between multiple 6G core networks of the same PLMN. | When traffic-routing decisions are exposed to or consumed by a gateway-mediated agent workflow, semantic decisions may be needed to represent the mobility context and routing outcome so that handoff or failure handling reflects the change between 6G core networks. |
These requirement themes indicate that a gateway decision is not only an endpoint or protocol selection. It may need to combine intent meaning, capability meaning, policy limits, trust status, exposure constraints, network context, and failure reasons. The gateway semantic layer therefore provides the decision vocabulary and output objects needed to make such decisions reusable across interaction mechanisms and administrative domains.¶
This document describes the role and interoperability needs of a gateway semantic layer. It identifies candidate inputs, outputs, and gateway-side semantic 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¶
- an internal product architecture for gateways.¶
Domain ontologies and business knowledge remain domain-specific. They provide the meaning basis for capability descriptions, task interpretation, policy constraints, and handoff context, while the gateway semantic layer focuses on how gateways reference, constrain, validate, map, and explain semantic information for decisions.¶
The Gateway Semantic Layer sits between application-level intent and agent interaction mechanisms. Above it, applications or upstream agents provide business 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 semantic layer provides two contracts:¶
- an intent-to-decision-input contract, which turns business goals and task context into inputs usable by the gateway decision function; and¶
- a decision-to-interaction-handoff contract, which turns gateway decisions into handoff 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 semantic 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 capability meaning, business intent, or handoff semantics.¶
+--------------------------------+ +------------------------+
| Application Intent | | Gateway Support |
| Business Goal | | Functions |
| Task Orchestration | | |
| Human Escalation | | Registry / Discovery |
+---------------+----------------+ | |
| | Identity / Authz |
Intent-to-Decision-Input Contract | |
| | Sync / Directory |
+--------------------------------+ | |
| Gateway Semantic Layer |<---| Audit / Accounting |
| Intent Normalization | | |
| Capability Meaning | | Control / Management |
| Policy-aware Validation | | support to semantic |
| Trust-aware Selection | | and interaction layers |
| Handoff Semantics | | |
| Failure Explanation | | |
+---------------+----------------+ | |
| | |
Decision-to-Interaction Handoff | |
| | |
+--------------------------------+ | |
| Agent Interaction Mechanisms |<---| |
| A2A Tasks / Messages | | |
| MCP Tools / Resources | | |
| IAIP / HTTP APIs | | |
| Agent Cards / Metadata | | |
+---------------+----------------+ | |
| | |
+--------------------------------+ | |
| Transport and Security | | |
| Connectivity | | |
| Secure Channels | | |
| Integrity Protection | | |
+--------------------------------+ +------------------------+
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.¶
A gateway semantic layer can use the following classes of input. The precise data model may be defined by other drafts or future work.¶
Business intent 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 meaning, and trust evidence, rather than treated only as a string or endpoint selector.¶
Task context includes the domain, service scope, time window, data sensitivity, operational state, user or tenant constraints, and other information needed to interpret the intent and constrain handoff.¶
Capability descriptions 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 descriptions before using them for decisions.¶
Policy constraints include authorization scope, data exposure limits, privacy constraints, tenant policy, domain policy, regulatory constraints, and operational limits. A semantic match is not sufficient if policy does not allow use or disclosure.¶
Trust evidence may include identity status, authorization or delegation evidence, provenance, attestation results, receipts, registry validation, or other trust metadata. The gateway semantic layer uses trust evidence as a constraint on selection and handoff.¶
The semantic layer performs gateway-side operations that turn inputs into decisions. These operations may be implemented in different ways by different deployments, but their outputs may require interoperable representation.¶
- Normalize meanings: Map heterogeneous descriptions, vocabulary terms, profile references, and versions into a gateway-managed capability view.¶
- Match intent to capability: Determine which candidate capabilities can satisfy the business intent and task context.¶
- Apply policy and trust: Filter or constrain candidates according to local policy, authorization, disclosure limits, and trust evidence.¶
- Prepare handoff semantics: Produce task meaning, context summary, disclosure limits, and failure semantics for the next interaction mechanism.¶
- Explain decisions and failures: Produce decision reasons and failure reasons that can support retry, escalation, audit, accounting, and troubleshooting.¶
A Resolution Result indicates whether a candidate capability, agent, gateway, or service was selected or rejected. It can include the selected capability, decision reason, semantic profile or version references, applicable scope, and policy or trust constraints.¶
A Handoff Descriptor carries information needed by the next interaction mechanism. It can include task meaning, context summary, disclosure limits, interaction mechanism, target reference, and failure semantics. It allows a gateway decision to be used by A2A, MCP, IAIP, HTTP, or another suitable mechanism without replacing those mechanisms.¶
A Failure Explanation distinguishes failures such as capability mismatch, intent misunderstanding, parameter semantic 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.¶
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 semantic layer identified here supports those gateway functions. For example, policy-controlled capability exposure requires the gateway to understand capability meaning and disclosure sensitivity; peer selection and routing require intent-to-capability matching; 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.¶
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].¶
The gateway semantic layer does not replace discovery or directory synchronization. It consumes discovery and directory outputs and determines how discovered or registered capabilities relate to business intent, policy constraints, trust evidence, and handoff requirements. In this sense, discovery and directory mechanisms provide candidate inputs, while the gateway semantic layer provides the mediation decision.¶
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 semantic 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 semantic layer explains why that interaction is selected, constrained, rejected, or handed off.¶
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, semantic profiles, or operational metadata.¶
The gateway semantic 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 semantic layer decides how those claims can be used in a given policy, trust, and handoff context.¶
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].¶
The gateway semantic 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 semantic layer determines how that evidence constrains capability visibility, selection, disclosure, handoff, and failure reporting.¶
Not every gateway semantic 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:¶
- Resolution Result: a gateway decision artifact that records whether a candidate capability, agent, gateway, service, or interaction target was selected or rejected. It may include the selected target reference, source-description references, semantic profile and version references, applicable scope, policy and trust constraint references, decision reason, and validation status.¶
- Handoff Descriptor: a constrained handoff artifact that carries task meaning, context summary, disclosure limits, interaction mechanism, target reference, policy and trust constraints, and any semantic profile references needed by the next interaction mechanism. It allows a semantic gateway decision to be used by A2A, MCP, IAIP, HTTP, or another suitable mechanism without replacing those mechanisms.¶
- Failure Explanation: a structured failure artifact that distinguishes capability mismatch, intent ambiguity, semantic 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.¶
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, semantic 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.¶
The Gateway Semantic Layer influences which agents or capabilities are selected, what context is disclosed, and how tasks are handed off. Incorrect semantic interpretation can cause policy violations, capability misuse, failed handoff, or misleading audit records.¶
Semantic 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.¶
Business intent, task context, capability descriptions, semantic profiles, and failure explanations can reveal sensitive information about users, business processes, network operations, internal tools, operational policy, or data access patterns.¶
Gateway semantic decisions should use minimal disclosure. Handoff descriptors should carry only the task meaning, context summary, and disclosure limits needed for the next interaction. Failure explanations should be useful for retry and troubleshooting without exposing unnecessary raw prompts, personal data, confidential business information, or internal policy details.¶
This document makes no request for IANA action.¶