Agent Communication Gateway for Semantic Routing and Working Memory

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 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

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 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.¶

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.¶

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).¶

                 +--------------------------------+
                 |     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 ]

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.¶

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.¶

.....................................................................
 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)

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.¶

 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  |
+--------+   +--------+   +-----------+   +--------+   +--------+

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.¶

{
  "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"]
}

{
  "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
  }
}

{
  "req": "temp_read",
  "loc": "Line B"
}

/cmd_vel
/navigate_to

10. Infrastructure Functions

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.¶

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.¶

                       [ 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)     |
  +----------------------+                   +----------------------+
=======================================================================

{
  "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
  }
}

                [ 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)     |
  +----------------------+                   +----------------------+
=======================================================================

{
  "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"}}
    }
  ]
}

{
  "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"]
    }
  }
}

{
  "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
  }
}

{
  "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.¶

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.¶

16. Acknowledgements

TBD¶

Authors' Addresses