Agent Communication Gateway for Semantic Routing and Working Memory
draft-agent-gw-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 | Xiaohui Xie , 王梓安 , Tianshuo Hu , Yong Cui | ||
| Last updated | 2026-07-12 | ||
| 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-agent-gw-02
Agent-GW Xiaohui. Xie
Internet-Draft Tsinghua University
Intended status: Standards Track Zian. Wang
Expires: 7 January 2027 Beijing University of Posts & Telecommunications
Tianshuo. Hu
Yong. Cui
Tsinghua University
6 July 2026
Agent Communication Gateway for Semantic Routing and Working Memory
draft-agent-gw-02
Abstract
This document presents an architectural framework for an Agent
Communication Gateway (Agent-GW), designed to support large-scale,
heterogeneous, and dynamic multi-agent collaboration across
administrative and protocol boundaries.
As agents evolve from isolated entities to a collaborative digital
workforce, the infrastructure must transition from rigid, endpoint-
based connectivity to intent-based interaction. This draft proposes
Agent-GW as an infrastructure hub that provides native primitives for
Semantic Routing (dispatching tasks by intent and capability),
Working Memory (shared structured context across multi-step
workflows), automated protocol adaptation (normalizing heterogeneous
interfaces into a unified agent-facing protocol), oracle-free agent
evaluation, and collaborative inference acceleration via a Knowledge
Delivery Network (KDN).
Beyond a single-gateway deployment, this document defines a
hierarchical architecture for wide-area, multi-domain agent networks:
three gateway tiers (access, domain, and inter-domain). It describes
which traffic classes traverse which tiers on both the data plane and
the control plane, and specifies cross-domain semantic routing, name
resolution, resilience, and operational considerations.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Xie, et al. Expires 7 January 2027 [Page 1]
Internet-Draft Agent Communication Gateway for Semantic July 2026
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 7 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. Conventions used in this document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Model and Trust Boundary . . . . . . . . . . . . . 6
5. Hierarchical Deployment Architecture . . . . . . . . . . . . 6
5.1. Gateway Tiers . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Function Placement across Tiers . . . . . . . . . . . . . 7
5.3. Collapsed and Incremental Deployments . . . . . . . . . . 8
6. Network and Infrastructure Requirements . . . . . . . . . . . 8
7. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9
7.1. Internal/External Entity Relationship . . . . . . . . . . 9
7.2. Functional Planes . . . . . . . . . . . . . . . . . . . . 10
8. Traffic Model and Forwarding Paths . . . . . . . . . . . . . 11
8.1. Data-Plane Traffic . . . . . . . . . . . . . . . . . . . 11
8.1.1. Intra-Domain Agent-to-Agent . . . . . . . . . . . . . 11
8.1.2. Cross-Domain Agent-to-Agent . . . . . . . . . . . . . 11
8.1.3. Agent-to-External-Tool (Egress) . . . . . . . . . . . 12
8.2. Control-Plane Traffic . . . . . . . . . . . . . . . . . . 12
9. Protocol Model and Input/Output Examples . . . . . . . . . . 13
9.1. Example: A2A Request Normalization . . . . . . . . . . . 13
9.2. Example: Southbound Output Mapping . . . . . . . . . . . 14
10. Infrastructure Functions . . . . . . . . . . . . . . . . . . 14
10.1. Agent Identification and Capability Directory . . . . . 14
10.1.1. Cross-Domain Name Resolution . . . . . . . . . . . . 15
Xie, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Agent Communication Gateway for Semantic July 2026
10.2. Automated Protocol Adaptation and Interface Normalization
(APA) . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.3. Infrastructure-Level Agent Evaluation and Compliance . . 16
10.4. Dynamic Orchestration and Semantic Routing . . . . . . . 16
10.4.1. Cross-Domain Semantic Routing . . . . . . . . . . . 16
10.5. Evolutionary Knowledge Management . . . . . . . . . . . 17
10.6. Collaborative Inference Acceleration (KDN) . . . . . . . 17
11. Resilience and Scalability . . . . . . . . . . . . . . . . . 17
12. Representative Deployment Scenarios . . . . . . . . . . . . . 18
12.1. Scenario 1: Enterprise Copilot with Local Secure Routing
and External Egress . . . . . . . . . . . . . . . . . . 18
12.2. Scenario 2: Industrial Planning with IoT (MQTT/REST) and
Embodied Agent (ROS Bridge) . . . . . . . . . . . . . . 19
12.3. Scenario 3: Peer Agent-GW Synchronization and Inference
Artifact Transfer . . . . . . . . . . . . . . . . . . . 20
12.4. Scenario 4: Cross-Enterprise Collaboration over the Full
Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 21
12.5. Scenario 5: Consumer Personal Assistant over Public Agent
Services . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Operational Considerations . . . . . . . . . . . . . . . . . 23
14. Security Considerations . . . . . . . . . . . . . . . . . . . 24
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
17.1. Normative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
The rapid advancement of Large Language Models (LLMs) has catalyzed
the emergence of an "Internet of Agents", where autonomous software
entities and tool-like services interconnect to form collaborative
workflows. Unlike traditional microservices, agents have varying
degrees of autonomy, reasoning capabilities, and diverse interface
standards. Early deployments were often siloed within proprietary
frameworks, limiting cross-domain collaboration.
As these systems scale, the bottleneck shifts from basic connectivity
to context management and efficient orchestration. Delivering the
right context to the right agent at the right time, while controlling
the cost of inference, becomes an infrastructure challenge. Existing
gateways optimized for static endpoints and stateless forwarding lack
semantic awareness to interpret intents or manage multi-step task
lifecycles.
This document introduces the Agent Communication Gateway (Agent-GW),
situated between agents and external tools or services. Agent-GW
elevates the network from a passive transport layer to an active
Xie, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Agent Communication Gateway for Semantic July 2026
semantic intermediary by introducing two core primitives: Semantic
Routing (intent/capability-based dispatch) and Working Memory
(shared, incrementally updated context). It further defines protocol
adaptation, evaluation, observability, and KDN-based inference
acceleration.
A single gateway serving one administrative domain covers many
deployments. When agent collaboration spans enterprises, sites, and
provider networks, however, a single gateway is no longer sufficient:
capability information must be aggregated and advertised across
domains, requests must be forwarded through multiple gateways, and
each hop plays a distinct role. This document therefore also
specifies a hierarchical deployment architecture (Section 5), a
traffic model that classifies data-plane and control-plane flows per
gateway tier (Section 8), cross-domain semantic routing and name
resolution (Section 10.4, Section 10.1), resilience and scalability
guidance (Section 11), and operational considerations (Section 13).
The design deliberately follows patterns proven in existing Internet
infrastructure: hierarchical resolution as in DNS, aggregated inter-
domain advertisement as in BGP, and trapezoid-style cross-domain
forwarding as in SIP.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] and
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
3. Terminology
The following terms are defined in this draft:
Agent-GW (Agent Communication Gateway) An infrastructure component
coordinating multi-agent communication, responsible for protocol
adaptation, semantic routing, and context management.
Access Agent-GW The gateway tier closest to terminal agents (host-
level or edge-node deployment). It performs agent admission,
authentication, protocol normalization (APA), local working memory
for attached sessions, and near-agent KDN caching.
Domain Agent-GW The gateway tier serving one administrative domain
(enterprise, campus, or site). It performs intra-domain semantic
routing, maintains the domain capability directory, enforces
domain policy, and controls the ISD/EHE boundary.
Xie, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Agent Communication Gateway for Semantic July 2026
Inter-domain Agent-GW The gateway tier interconnecting
administrative domains over a wide-area network. It aggregates
capability advertisements from domain gateways, performs inter-
domain semantic routing, negotiates cross-domain trust, and relays
KDN artifacts between domains.
Internal Semantic Domain (ISD) The internal network domain,
typically a LAN or on-prem cluster, where agent-to-agent messages
follow standardized or controlled protocols (e.g., A2A, MCP, or
natural language over a controlled channel). The ISD is
considered within a primary trust boundary.
External Heterogeneous Ecosystem (EHE) External networks and
services outside the LAN trust boundary, often with diverse and
unstructured protocols and varying security postures (e.g., public
SaaS APIs, Internet services, third-party tools).
Semantic Routing Routing a request based on the semantic intent of a
task and the capabilities/trust state of available agents, rather
than static endpoint addresses.
Capability Digest A summarized, privacy-preserving representation of
the capabilities available within a domain, advertised by a Domain
Agent-GW to the inter-domain tier. A digest supports routing
decisions without exposing per-agent details.
Cross-Domain Semantic Route The ordered sequence of Agent-GW hops
(access, domain, inter-domain, domain, access) traversed by a
semantic request whose originator and target reside in different
administrative domains.
Working Memory A structured, temporary storage mechanism that
maintains context and state across a multi-step or multi-turn
workflow. It can be session-scoped and policy-controlled.
KDN (Knowledge Delivery Network) A mechanism that treats inference
artifacts (e.g., LLM KV caches) as reusable and distributable
objects, enabling cooperative acceleration across agents or
gateways.
APA (Adaptive Protocol Adapter) An automated protocol adaptation
function that discovers/infers external interface schemas and
normalizes heterogeneous protocols (e.g., HTTP, gRPC, MQTT) into
an internal standardized format.
MCP (Model Context Protocol) A reference standard for connecting AI
assistants/agents to tools and data sources, used here as an
example of a normalized internal interaction format.
Xie, et al. Expires 7 January 2027 [Page 5]
Internet-Draft Agent Communication Gateway for Semantic July 2026
A2A Agent-to-agent messaging format/protocol used inside the ISD.
This draft treats A2A as a generic class of agent messaging and
illustrates how Agent-GW routes and adapts it.
Peer Agent-GW Another Agent-GW instance at the same tier in a
different node/site/domain. Peer Agent-GWs may synchronize
selected state or inference artifacts subject to policy.
4. Deployment Model and Trust Boundary
Many deployments distinguish "internal" versus "external" entities by
a network boundary aligned with a LAN. In this draft, the Internal
Semantic Domain (ISD) refers to the internal LAN/on-prem cluster
where agents and enterprise tools operate under shared governance,
while the External Heterogeneous Ecosystem (EHE) refers to networks
and services outside that boundary.
Agent-GW logically sits at the intersection of these domains. It
provides (1) semantic routing and state functions within the ISD, and
(2) border adaptation functions for controlled egress/ingress across
the trust boundary. Policies MAY restrict what context, memory, or
inference artifacts can cross from ISD to EHE.
The internal/external distinction is a deployment choice. The same
Agent-GW architecture can be deployed as a pure internal hub (no
external egress), a border gateway, or a hybrid topology with peer
synchronization. When agent collaboration extends beyond a single
administrative domain, multiple gateways are organized into the
hierarchy defined in Section 5.
5. Hierarchical Deployment Architecture
A single Agent-GW is sufficient for one LAN-scoped ISD. Wide-area
agent networks spanning multiple enterprises, sites, or provider
networks require several gateways with distinct roles. This section
defines a three-tier reference hierarchy. The tiers are logical
roles: an implementation MAY collapse two or all three tiers into one
physical gateway (Section 5.3).
5.1. Gateway Tiers
*Access Agent-GW:* deployed closest to terminal agents, typically on
the same host or edge node. It terminates agent attachment:
authentication of the agent's AID, protocol normalization via APA,
working memory for locally attached sessions, and a near-agent KDN
cache. Access gateways hold no routing state beyond their parent
Domain Agent-GW.
Xie, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Agent Communication Gateway for Semantic July 2026
*Domain Agent-GW:* deployed per administrative domain (enterprise,
campus, site). It provides intra-domain semantic routing, the
authoritative capability directory for the domain, policy
enforcement, and the ISD/EHE border functions including egress to
external tools.
*Inter-domain Agent-GW:* deployed at interconnection points between
domains (e.g., by a consortium, an exchange operator, or a provider).
It maintains aggregated Capability Digests advertised by member
domains, performs inter-domain semantic routing, negotiates cross-
domain trust and policy, and relays KDN artifacts between domains.
+--------------------------------+
| Inter-domain Agent-GW |
| (digest aggregation, x-domain |
| routing, trust negotiation) |
+-------+----------------+-------+
Capability Digest, | | A2A + KDN
trust state (up) | | artifacts (down)
+----------+ +----------+
| |
+----------+---------+ +-----------+--------+
| Domain Agent-GW D1 | | Domain Agent-GW D2 |
| (intra-domain |--> REST/MQTT | (intra-domain |
| routing, policy, | egress to | routing, policy, |
| directory, WM) | ext. tools | directory, WM) |
+----+----------+----+ +----+----------+----+
| | | |
+-----+----+ +---+------+ +-----+----+ +---+------+
| Access | | Access | | Access | | Access |
| GW A1 | | GW A2 | | GW B1 | | GW B2 |
+----+-----+ +----+-----+ +----+-----+ +----+-----+
| A2A/MCP | | |
[ Agents ] [ Agents ] [ Agents ] [ Agents ]
Figure 1: Three-Tier Agent-GW Hierarchy
5.2. Function Placement across Tiers
The infrastructure functions of Section 10 are distributed across
tiers following two principles:
*Push down (toward the access tier):* functions that are per-agent,
latency-sensitive, or bandwidth-heavy. Agent authentication,
protocol adaptation, and KDN caching SHOULD execute as close to the
agent as possible, so that malformed or unauthorized traffic is
filtered before consuming upstream resources and cached artifacts are
served without crossing the backbone.
Xie, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Agent Communication Gateway for Semantic July 2026
*Pull up (toward the inter-domain tier):* functions that require a
cross-domain view. Capability aggregation, inter-domain route
selection, and cross-domain trust negotiation MUST reside at the tier
that can observe multiple domains. Per-agent detail is summarized
into Capability Digests on the way up; the inter-domain tier never
needs, and SHOULD NOT hold, per-agent state.
5.3. Collapsed and Incremental Deployments
Small deployments MAY collapse the hierarchy: a single gateway acting
simultaneously as access, domain, and (if federated later) inter-
domain tier. A standalone single-gateway deployment serving one LAN-
scoped ISD is exactly this collapsed form. A deployment starting
with one Domain Agent-GW can add access gateways for scale-out and
join an inter-domain tier for federation without changing agent-
facing interfaces.
6. Network and Infrastructure Requirements
Agent interactions are typically context-heavy, short-lived, and
driven by high-level goals. To support this, the infrastructure
SHOULD satisfy the following requirements:
*Intent-Based Addressing:* The infrastructure SHOULD support
addressing based on capabilities and intent rather than topology.
*Stateful Context Management:* Agentic workflows often involve multi-
step reasoning where context accumulates. The gateway MUST support
policy-controlled state retention and retrieval.
*Heterogeneous Interoperability:* The ecosystem includes diverse
protocols. The gateway SHOULD provide automated adaptation layers
(e.g., APA) and normalization into standardized internal formats.
*Dynamic Capability Discovery:* The gateway SHOULD provide real-time
capability discovery and health/status tracking for dispatch
decisions.
*Hierarchical Scalability:* Routing state advertised across domains
MUST be aggregatable (e.g., as Capability Digests) so that inter-
domain state grows with the number of domains, not with the number of
agents.
*Loop-Free Forwarding:* Cross-domain semantic requests MUST carry
hop-limit and path-record information sufficient for gateways to
detect and terminate forwarding loops.
Xie, et al. Expires 7 January 2027 [Page 8]
Internet-Draft Agent Communication Gateway for Semantic July 2026
*Inference Efficiency:* The gateway MAY cache and share inference
artifacts such as KV caches (KDN) to reduce redundant computation and
improve TTFT.
*Trust Boundary Enforcement:* The gateway MUST enforce policies for
data privacy, context leakage prevention, and capability spoofing
mitigation, especially across ISD/EHE and inter-domain boundaries.
7. Architecture Overview
This section describes the reference architecture of the Agent
Communication Gateway (Agent-GW). Agent-GW functions as a semantic
intermediary operating at the application and cognitive layers, with
explicit separation between core semantic/state functions and border
adaptation functions.
7.1. Internal/External Entity Relationship
Figure 2 illustrates Agent-GW within a LAN-scoped Internal Semantic
Domain (ISD) and its controlled interfaces to an External
Heterogeneous Ecosystem (EHE). This figure is intentionally
structured to highlight (a) internal agents and clients, (b) Agent-GW
core state/routing functions, (c) border adaptation functions, and
(d) southbound targets including legacy APIs, native agents, and peer
gateways.
Xie, et al. Expires 7 January 2027 [Page 9]
Internet-Draft Agent Communication Gateway for Semantic July 2026
.....................................................................
Internal Semantic Domain (Standardized A2A / MCP / NL)
+--------------------+ +---------------------+
| Client Agent (A1) | | User Interface (U1) |
+----------+---------+ +----------+----------+
| (A2A Msg) | (A2A Msg)
v v
+-------------------------------------------------------------------+
| Agent Communication Gateway (Agent-GW) |
| |
| [ Core State & Routing Functions ] |
| +-------------------+ +-------------------+ +-------------------+ |
| | Capability Dir | | Semantic Router | | Working Memory & | |
| | (Trust State) | | (Intent->Target) | | KDN (Ctx/KV Cache)| |
| +---------+---------+ +---------+---------+ +---------+---------+ |
| | | | |
| [ Border Adaptation Functions ] |
| +---------+---------+ +---------+---------+ +---------+---------+ |
| | Auto-Adapter (APA)| | Native Passthrough| | Sync & State | |
| | (Protocol Trans.) | | (Direct Routing) | | Transfer (Knowl.) | |
| +---------+---------+ +---------+---------+ +---------+---------+ |
+-----------+---------------------+---------------------+-----------+
| | |
(REST/RPC) (MCP/A2A) (A2A+KV Cache)
v v v
+---------------+ +---------------+ +---------------+
| Legacy APIs | | Native Agents | | Peer Agent-GW |
| (T1) | | (T2) | | Node (N2) |
+---------------+ +---------------+ +---------------+
.....................................................................
External Heterogeneous Ecosystem (Unstructured / Diverse Protocols)
Figure 2: Agent-GW Entity Relationship across Internal Semantic
Domain and External Ecosystem
Operationally, messages originating from internal clients/agents
enter Agent-GW via standardized internal formats (e.g., A2A or MCP).
If a target resides in the EHE, Agent-GW invokes APA for protocol
adaptation and applies egress policies to prevent unintended context
leakage.
7.2. Functional Planes
Agent-GW can be described as four logical planes:
Xie, et al. Expires 7 January 2027 [Page 10]
Internet-Draft Agent Communication Gateway for Semantic July 2026
(1) Ingress/Access: protocol detection, authentication, sandboxing,
normalization. (2) Cognitive Orchestration: intent parsing,
planning, semantic routing, dispatch, observability hooks. (3)
Knowledge & State: working memory, experience/evolutionary memory,
KDN cache and artifact management. (4) Egress/Ecosystem Interface:
drivers for legacy systems, native agents, physical-world bridges,
and peer sync.
8. Traffic Model and Forwarding Paths
This section classifies the traffic observed in a hierarchical Agent-
GW deployment and specifies which gateway tiers each class traverses.
Two planes are distinguished: the data plane carries per-request
semantic traffic between agents and tools; the control plane carries
background synchronization between gateways. The separation matters
operationally: data-plane traffic is latency-sensitive and follows
the request path, while control-plane traffic is periodic,
aggregatable, and can be scheduled off-peak.
8.1. Data-Plane Traffic
8.1.1. Intra-Domain Agent-to-Agent
When originator and target attach to the same Domain Agent-GW, the
request traverses at most three gateway elements: originator's Access
Agent-GW, the Domain Agent-GW, and the target's Access Agent-GW. If
both agents attach to the same access gateway, the Domain Agent-GW
MAY be bypassed entirely after an initial routing decision, subject
to policy. This is the dominant traffic class and MUST NOT require
any inter-domain state.
8.1.2. Cross-Domain Agent-to-Agent
When originator and target reside in different administrative
domains, the request follows a five-hop Cross-Domain Semantic Route
analogous to the SIP trapezoid: access, domain, inter-domain, domain,
access. Each hop performs a distinct function, shown in Figure 3.
Agent X Agent Y
| ^
(1) | A2A request (5) dispatch |
v |
+--------+ +--------+ +-----------+ +--------+ +--------+
| Access |-->| Domain |-->|Inter-dom. |-->| Domain |-->| Access |
| GW A1 |(2)| GW D1 |(3)| GW |(4)| GW D2 | | GW B1 |
+--------+ +--------+ +-----------+ +--------+ +--------+
Figure 3: Cross-Domain Forwarding Path and Per-Hop Functions
Xie, et al. Expires 7 January 2027 [Page 11]
Internet-Draft Agent Communication Gateway for Semantic July 2026
Hop functions: (1) the originating Access Agent-GW authenticates the
agent and normalizes the request; (2) the originating Domain Agent-GW
parses the intent, detects that no local capability matches, applies
egress policy (context minimization per Section 14), and forwards
upward; (3) the Inter-domain Agent-GW matches the intent against
aggregated Capability Digests and selects the target domain; (4) the
target Domain Agent-GW applies ingress policy and performs final
agent selection against its authoritative directory; (5) the target
Access Agent-GW adapts and delivers the request to Agent Y. The
response follows the reverse path, or a direct gateway-to-gateway
shortcut if both domain gateways permit it.
8.1.3. Agent-to-External-Tool (Egress)
Requests targeting external tools or services in the EHE terminate at
the originating Domain Agent-GW, which performs APA translation and
egress policy enforcement. Egress traffic MUST NOT traverse the
inter-domain tier: the inter-domain tier interconnects semantic
domains, not external services.
8.2. Control-Plane Traffic
Control-plane flows run between gateways in the background and are
not on the per-request critical path:
*Capability advertisement:* agents register with their Access Agent-
GW; access gateways report attachments to the Domain Agent-GW; domain
gateways advertise Capability Digests to the inter-domain tier.
Aggregation at each step is analogous to prefix aggregation in BGP
and delegation in DNS: detail decreases and stability increases as
advertisements move up the hierarchy.
*Semantic heartbeat and trust state:* liveness and reliability-score
updates (Section 10.3) propagate upward with decreasing frequency and
granularity. Per-agent heartbeats stay within the domain; only
domain-level health and digest changes reach the inter-domain tier.
*KDN artifact transfer:* inference artifacts move horizontally
between peer gateways of the same tier under policy, or are pre-
fetched along the hierarchy toward where they will be consumed
(Section 11).
*Working memory synchronization:* triggered only by session migration
or disaster recovery, not periodic. See Section 12.3.
Xie, et al. Expires 7 January 2027 [Page 12]
Internet-Draft Agent Communication Gateway for Semantic July 2026
9. Protocol Model and Input/Output Examples
Agent-GW supports a mixed protocol environment. Within the ISD,
interactions are RECOMMENDED to use standardized agent messaging
(e.g., A2A or MCP). For southbound access to targets, Agent-GW MAY
translate into external protocols such as REST/HTTP, gRPC, MQTT, OPC
UA, ROS, or vendor-specific SDKs.
The following subsections provide illustrative (non-normative)
examples of message shapes and I/O mapping. These examples are
intended to clarify how semantic routing, working memory, and
adaptation interact.
9.1. Example: A2A Request Normalization
Illustrative A2A message (ingress) that Agent-GW normalizes into an
internal semantic request:
{
"a2a_version": "1",
"session_id": "s-123",
"from": "agent:A1",
"intent": "Inspect Assembly Line B",
"constraints": {
"latency_ms": 800,
"privacy": "internal_only"
},
"context_ref": ["wm://s-123/ctx"]
}
Illustrative normalized semantic request inside Agent-GW (after
parsing and policy checks):
Xie, et al. Expires 7 January 2027 [Page 13]
Internet-Draft Agent Communication Gateway for Semantic July 2026
{
"session_id": "s-123",
"intent": {
"task": "inspect",
"target": "assembly_line",
"id": "B"
},
"routing_hints": {
"privacy_scope": "ISD",
"required_capabilities": ["iot_read", "robot_navigation"]
},
"context": {
"working_memory_keys": ["ctx", "last_actions"],
"kdn_cache_allowed": true
}
}
9.2. Example: Southbound Output Mapping
When dispatching to a legacy IoT array, Agent-GW MAY translate a sub-
task into MQTT or REST. When dispatching to an embodied agent,
Agent-GW MAY translate into a ROS bridge. These mappings are policy-
controlled and can be produced by APA or pre-registered drivers.
Example REST payload for a legacy API target:
{
"req": "temp_read",
"loc": "Line B"
}
Example ROS command topic for an embodied agent target:
/cmd_vel
/navigate_to
10. Infrastructure Functions
10.1. Agent Identification and Capability Directory
This function establishes a root of trust for the agent network and
mitigates capability spoofing. Agent-GW maintains a dynamic
directory where entries represent active, verified agent states
rather than static records.
Xie, et al. Expires 7 January 2027 [Page 14]
Internet-Draft Agent Communication Gateway for Semantic July 2026
*Cryptographic Identity:* Participating agents SHOULD possess a
cryptographic Agent ID (AID) bound to credentials (e.g., X.509
certificate). An agent registers by submitting an AgentCard that
binds identity to a capability descriptor (e.g., capability hash,
policy tags).
*Capability Claim and Verification (CCV):* To reduce malicious
registration, Agent-GW MAY implement challenge-response verification
based on metamorphic testing principles (semantic variants of a task)
to evaluate functional consistency without requiring access to
internal model weights.
*Semantic Heartbeat:* To maintain freshness, Agent-GW MAY
periodically verify Layer-7 functional integrity (beyond L3 keep-
alives). Agents failing challenges MAY be dynamically quarantined or
pruned.
10.1.1. Cross-Domain Name Resolution
When a request addresses an agent by AID rather than by capability,
the AID is resolved along the hierarchy: the inter-domain directory
maps the AID to its home domain; the home Domain Agent-GW maps it to
the serving Access Agent-GW; the access gateway maps it to the live
endpoint. Each tier answers only from state it authoritatively
holds, mirroring DNS delegation.
Whether the AID-to-home-domain step reuses the existing DNS
infrastructure (e.g., a dedicated resource record or a well-known
naming convention) or requires an independent directory system is
left open in this document. Both options are viable; the trade-off
between deployment ease (DNS reuse) and richer semantics (dedicated
directory) is a topic for working group discussion.
10.2. Automated Protocol Adaptation and Interface Normalization (APA)
Residing at the border adaptation functions, APA normalizes
heterogeneous external protocols (HTTP, MQTT, gRPC, proprietary SDKs)
into an internal standardized request format (e.g., MCP or A2A). For
poorly documented interfaces, APA MAY apply active probing to infer
schemas and refine bindings with feedback loops.
Xie, et al. Expires 7 January 2027 [Page 15]
Internet-Draft Agent Communication Gateway for Semantic July 2026
10.3. Infrastructure-Level Agent Evaluation and Compliance
Agents are often black boxes. Agent-GW introduces infrastructure-
level evaluation to estimate reliability and compliance without
access to model weights. Using oracle-free metamorphic testing,
Agent-GW generates semantic variants of tasks and evaluates response
consistency. Results MAY contribute to a dynamic reliability score
used in routing.
10.4. Dynamic Orchestration and Semantic Routing
Static routing tables are insufficient for dynamic collaboration.
Agent-GW performs semantic routing by decomposing complex intents
into a DAG of sub-tasks and dispatching them to suitable targets
based on capability matching, trust score, privacy constraints, and
operational metrics.
10.4.1. Cross-Domain Semantic Routing
*Tiered resolution:* a Domain Agent-GW first matches the intent
against its local capability directory. On a miss, it queries the
inter-domain tier, whose aggregated Capability Digests identify one
or more candidate target domains. Final agent selection is always
performed by the target Domain Agent-GW against its authoritative
directory; the inter-domain tier selects domains, never individual
agents. It is RECOMMENDED that domain gateways resolve recursively
on behalf of agents (agents see a single request/response), while
inter-domain gateways operate iteratively among themselves (returning
referrals), mirroring the DNS recursive/iterative split.
*Digest aggregation:* a Domain Agent-GW advertises only a Capability
Digest upward: summarized capability classes, coarse capacity and
trust indicators, and policy tags. Per-agent entries MUST NOT be
advertised across domain boundaries. This bounds inter-domain
routing state (see Hierarchical Scalability in Section 6) and avoids
exposing internal structure, analogous to BGP announcing aggregated
prefixes rather than host routes.
*Loop avoidance:* semantic matching lacks the natural convergence of
longest-prefix matching, and digests from different domains can
overlap, so forwarding loops are possible. Every cross-domain
request MUST carry a hop limit (max_hops, decremented per gateway)
and a path record (via list of gateway identifiers). A gateway MUST
drop a request whose hop limit reaches zero or whose path record
already contains its own identifier, and SHOULD return a routing
error to the originator.
Xie, et al. Expires 7 January 2027 [Page 16]
Internet-Draft Agent Communication Gateway for Semantic July 2026
*Failure semantics:* when no route exists or dispatch fails, the
gateway detecting the failure returns an error whose category the
originator can act on. This document defines error categories only,
not message encodings: NO_ROUTE (no domain advertises a matching
digest), CAPABILITY_MISMATCH (target domain's authoritative directory
refutes the digest match), POLICY_DENIED (ingress or egress policy
rejected the request), and HOP_LIMIT_EXCEEDED. Upon
CAPABILITY_MISMATCH, the inter-domain gateway SHOULD try the next
candidate domain before failing the request.
10.5. Evolutionary Knowledge Management
Agent-GW MAY incorporate evolutionary memory that captures execution
traces, success/failure outcomes, and user corrections. This enables
continuous improvement in routing policies and can provide feedback
guidance to terminal agents.
10.6. Collaborative Inference Acceleration (KDN)
Multi-agent workflows often repeat reasoning over shared context.
KDN treats inference artifacts (e.g., LLM KV caches) as reusable
objects, enabling sharing across co-located agents or peer Agent-GWs
subject to policy. This can reduce TTFT and total compute.
11. Resilience and Scalability
*Gateway failover:* Access Agent-GWs hold only soft state (attachment
records rebuildable from re-registration), so an agent MAY re-attach
to any access gateway of the same domain after a failure. Domain
Agent-GWs hold working memory and directory state; deployments
requiring session survival across a domain-gateway failure MUST
replicate working memory to a standby (or a peer, per Section 12.3),
or explicitly accept degraded semantics in which in-flight sessions
restart while stateless routing continues.
*Access selection and load sharing:* where multiple access gateways
serve one domain, agents SHOULD be directed to a nearby, lightly
loaded instance at attachment time (e.g., via anycast or a directory-
provided candidate list). Because access-tier state is soft, re-
balancing is an attachment-time decision and does not require
connection migration.
Xie, et al. Expires 7 January 2027 [Page 17]
Internet-Draft Agent Communication Gateway for Semantic July 2026
*KDN cache placement:* artifact granularity follows the hierarchy.
Access gateways cache session-scoped artifacts for locally attached
agents; domain gateways cache artifacts shared across the domain's
workflows; the inter-domain tier does not cache artifact content and
only relays or brokers handles, so that bulk transfer happens at most
once per domain pair and backbone links are not consumed by repeated
artifact fetches.
12. Representative Deployment Scenarios
This section provides representative scenarios with explicit
internal/external boundaries, and concrete input/output protocol
examples. These scenarios are illustrative and non-normative.
12.1. Scenario 1: Enterprise Copilot with Local Secure Routing and
External Egress
An employee copilot receives a natural language request that requires
both private on-prem data and public market information. Agent-GW
routes sensitive processing to an internal SLM/LLM while allowing
limited external API egress for public data, enforcing privacy and
context minimization.
[ Employee Copilot Agent ]
(NL/MCP: "Summarize Q3 Private Report & compare with global markets")
|
===================================|===================================
v
[ Agent-GW ] (Semantic Router evaluates Privacy & Capability Tags)
|
+---------------------+---------------------+
| |
(Contains sensitive data) (Needs external info)
[ Local Secure Routing ] [ External Egress ]
(Read KV cache from KDN) (APA to API)
| |
v v
+----------------------+ +----------------------+
| Local Secure SLM | | Public Cloud API |
| (Data stays on-prem) | | (Global Markets) |
+----------------------+ +----------------------+
=======================================================================
Figure 4: Enterprise Copilot: Split Routing by Privacy and
Capability Tags
Example ingress request (MCP-like) and split dispatch:
Xie, et al. Expires 7 January 2027 [Page 18]
Internet-Draft Agent Communication Gateway for Semantic July 2026
{
"protocol": "MCP",
"task": "summarize_and_compare",
"inputs": {
"private_doc_ref": "vault://reports/q3-private",
"public_topic": "global markets"
},
"policy": {
"private_data_scope": "ISD",
"allow_external_egress": true,
"egress_context_budget_tokens": 200
}
}
12.2. Scenario 2: Industrial Planning with IoT (MQTT/REST) and Embodied
Agent (ROS Bridge)
A factory planning agent issues an A2A request: "Inspect Assembly
Line B". Agent-GW decomposes the intent into two sub-tasks: (1) read
sensor data from a legacy IoT array and (2) command a robotic dog to
navigate to the location. Agent-GW uses APA to translate A2A into
MQTT/REST for IoT, and native passthrough/bridge for ROS control.
[ Factory Planning Agent (The "Brain") ]
(A2A Protocol: "Inspect Assembly Line B")
|
===================================|===================================
v
[ Agent-GW ] (Semantic Router decomposes intent into 2 sub-tasks)
|
+---------------------+---------------------+
| |
[ Auto-Adapter (APA) ] [ Native Passthrough ]
(A2A -> MQTT/REST) (A2A -> ROS Bridge)
Payload: {"req":"temp_read", Payload: /cmd_vel,
"loc":"Line B"} /navigate_to
| |
v v
+----------------------+ +----------------------+
| Legacy IoT Array | | Robotic Dog |
| (Temp/Vision Sensors)| | (Embodied Agent) |
+----------------------+ +----------------------+
=======================================================================
Figure 5: Industrial Scenario: Intent Decomposition and Protocol
Translation
Illustrative sub-task outputs:
Xie, et al. Expires 7 January 2027 [Page 19]
Internet-Draft Agent Communication Gateway for Semantic July 2026
{
"subtasks": [
{
"id": "t1",
"target": "LegacyIoTArray",
"protocol": "MQTT/REST",
"payload": {"req":"temp_read","loc":"Line B"}
},
{
"id": "t2",
"target": "RoboticDog",
"protocol": "ROS",
"payload": {"topic":"/navigate_to","args":{"loc":"Line B"}}
}
]
}
12.3. Scenario 3: Peer Agent-GW Synchronization and Inference Artifact
Transfer
For multi-site deployments, a local Agent-GW MAY synchronize selected
working memory snapshots or KDN artifacts with a peer Agent-GW. This
supports mobility, disaster recovery, and cooperative acceleration.
Synchronization MUST be policy-gated and can be limited to anonymized
summaries or encrypted artifacts.
In the hierarchy of Section 5, this scenario is the horizontal
control-plane case of Section 8.2: synchronization between two Domain
Agent-GWs, either directly or brokered by the inter-domain tier.
Example: transfer a session context digest and a KV cache handle
rather than full raw prompts.
{
"sync": {
"peer": "agent-gw://node-n2",
"session_id": "s-123",
"transfer": {
"working_memory_digest": "sha256:...",
"kdn_artifact_handle": "kdn://artifact/kv/abc",
"encryption": "HPKE",
"policy_tags": ["no_raw_pii", "ttl_10m"]
}
}
}
Xie, et al. Expires 7 January 2027 [Page 20]
Internet-Draft Agent Communication Gateway for Semantic July 2026
12.4. Scenario 4: Cross-Enterprise Collaboration over the Full
Hierarchy
A design agent in enterprise E1 requests a manufacturability check
that only a simulation agent in partner enterprise E2 can perform.
The request traverses the full five-hop Cross-Domain Semantic Route
of Section 8.1.2.
Step (1)-(2): the agent submits an A2A request; the Access Agent-GW
authenticates it and the Domain Agent-GW D1 finds no local match. D1
applies egress minimization: the working memory reference is replaced
by a digest, and only the fields needed for routing leave the domain.
Request as forwarded by D1 to the inter-domain tier (illustrative):
{
"session_id": "s-778",
"origin_domain": "agent-gw://e1",
"intent": {
"task": "manufacturability_check",
"required_capabilities": ["cnc_simulation"]
},
"routing": {
"max_hops": 6,
"via": ["access-a1.e1", "domain.e1"]
},
"context": {
"working_memory_digest": "sha256:...",
"raw_context_allowed": false
}
}
Step (3): the Inter-domain Agent-GW matches "cnc_simulation" against
its aggregated Capability Digests, selects domain E2, appends itself
to the via list, and forwards. Step (4): Domain Agent-GW D2 applies
ingress policy (E1 is an authorized partner), selects the concrete
simulation agent from its authoritative directory, and dispatches via
the serving access gateway (step (5)). Had D2's directory refuted
the digest match, D2 would have returned CAPABILITY_MISMATCH and the
inter-domain gateway would have tried the next candidate domain per
Section 10.4.1.
The response carries the result and, subject to policy, a KDN
artifact handle so that follow-up requests in the same session can
reuse E2's inference state without resending context.
Xie, et al. Expires 7 January 2027 [Page 21]
Internet-Draft Agent Communication Gateway for Semantic July 2026
12.5. Scenario 5: Consumer Personal Assistant over Public Agent
Services
The preceding scenarios are enterprise-oriented. This scenario
illustrates a consumer-facing deployment: a personal assistant agent
on a user's smartphone attaches to an Access Agent-GW operated by the
user's connectivity or cloud provider, whose Domain Agent-GW serves a
large population of consumer agents. Merchants (airlines, hotels,
restaurants) operate their own domains and advertise Capability
Digests such as "flight_booking" or "hotel_reservation" to the inter-
domain tier.
The user asks the assistant to plan a weekend trip. The consumer
Domain Agent-GW decomposes the intent into booking sub-tasks and
resolves each through the inter-domain tier to a merchant domain,
following the Cross-Domain Semantic Route of Section 8.1.2. Consumer
privacy relies on the context-minimization rules of Section 14: the
user's preference profile and conversation history remain working
memory inside the consumer domain; only the minimal booking
parameters (dates, party size, budget ceiling) cross domain
boundaries.
Consumer attachment is inherently mobile: when the device moves from
home Wi-Fi to a cellular network, the assistant re-attaches to a
different Access Agent-GW of the same consumer domain. Because
access-tier state is soft (Section 11), the session continues against
the working memory held at the Domain Agent-GW without user-visible
interruption.
Booking sub-task as forwarded to a merchant domain (illustrative,
after egress minimization):
Xie, et al. Expires 7 January 2027 [Page 22]
Internet-Draft Agent Communication Gateway for Semantic July 2026
{
"session_id": "s-901",
"origin_domain": "agent-gw://consumer-isp",
"intent": {
"task": "hotel_booking",
"required_capabilities": ["hotel_reservation"]
},
"parameters": {
"city": "Chengdu",
"check_in": "2026-07-11",
"check_out": "2026-07-12",
"guests": 2,
"budget_ceiling": "CNY 800/night"
},
"context": {
"preference_profile": "withheld",
"working_memory_scope": "origin_domain_only"
}
}
13. Operational Considerations
*Incremental deployment:* the hierarchy is adoptable in stages.
Stage 1 is a single Domain Agent-GW (the collapsed form of
Section 5.3). Stage 2 adds Access Agent-GWs for scale-out within the
domain; agent-facing interfaces are unchanged because the access tier
presents the same normalized protocols. Stage 3 federates domains
through an inter-domain tier; only domain gateways need new
(northbound) functionality.
*Coexistence with existing infrastructure:* Agent-GW operates at the
application and semantic layers and does not replace L3/L4 elements.
Deployments MUST assume firewalls, enterprise proxies, and NATs on
the path; inter-gateway traffic SHOULD use standard transports (e.g.,
HTTPS) that traverse them. Where a service mesh exists, the access
tier MAY be realized as mesh sidecars, with the Domain Agent-GW as
the mesh's semantic control point.
*Observability:* each semantic request SHOULD carry an end-to-end
trace identifier propagated unchanged across all gateway hops, so
that a cross-domain request can be correlated over the five-hop path.
Gateways SHOULD record per-hop routing decisions (matched capability,
selected target, policy verdict) keyed by this identifier, forming
the audit trail required by Section 14.
Xie, et al. Expires 7 January 2027 [Page 23]
Internet-Draft Agent Communication Gateway for Semantic July 2026
14. Security Considerations
Introducing an active Agent-GW raises specific security challenges
including agent identity spoofing, capability poisoning, context
leakage, inference artifact theft, and cross-boundary data
exfiltration.
Agent-GW deployments MUST define explicit trust boundaries (e.g., ISD
vs EHE) and enforce policies for: (1) authentication/authorization
for agent registration and dispatch, (2) privacy scoping for working
memory, (3) egress filtering and context minimization, (4) encryption
and access control for KDN artifacts, (5) observability and audit
trails for routing decisions and protocol adaptation.
The hierarchy of Section 5 adds inter-tier and inter-domain concerns:
*Inter-tier trust model:* Access and Domain Agent-GWs of one domain
operate within a single trust domain under shared administration;
mutual authentication MAY rely on the domain's internal PKI. The
domain-to-inter-domain and inter-domain-to-inter-domain relationships
cross administrative boundaries and MUST use mutual authentication
with explicit, negotiated policy (which capability classes are
advertised, which origin domains are accepted, which artifact types
may transit).
*Cross-domain context minimization:* intent summaries and working
memory digests MAY cross domain boundaries when routing requires
them; raw working memory content MUST NOT cross by default and
requires an explicit per-session policy grant. Capability Digests
advertised upward MUST NOT reveal per-agent identity or internal
topology.
*Inter-domain gateways as high-value targets:* a compromised inter-
domain gateway can misroute requests of all member domains and forge
digests (capability poisoning at scale). Mitigations include signing
of Capability Digests by the originating domain (so the inter-domain
tier aggregates but cannot forge them), end-to-end protection of
request payloads between domain gateways so the inter-domain tier
routes on headers without reading payloads, and the audit trail of
Section 13 to make misrouting detectable.
15. IANA Considerations
This document has no IANA actions at this time.
Xie, et al. Expires 7 January 2027 [Page 24]
Internet-Draft Agent Communication Gateway for Semantic July 2026
16. Acknowledgements
TBD
17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses
Xiaohui Xie
Tsinghua University
Email: xiexiaohui@tsinghua.edu.cn
Zian Wang
Beijing University of Posts and Telecommunications
Email: zianwang@bupt.edu.cn
Tianshuo Hu
Tsinghua University
Email: huts22@mails.tsinghua.edu.cn
Yong Cui
Tsinghua University
Email: cuiyong@tsinghua.edu.cn
Xie, et al. Expires 7 January 2027 [Page 25]