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 2 September 2026.¶

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

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

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

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

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

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

6. 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 & KDN       | |
| |  | (Trust State)  |   | (Intent -> Target) |   | (Context / KV Cache)       | |
| |  +-------+--------+   +---------+----------+   +-----------+---------------+ |
| |          |                      |                          |                 |
| |  [ Border Adaptation Functions ]                                              |
| |  +--------------------+  +--------------------+  +--------------------------+|
| |  | Auto-Adapter (APA) |  | Native Passthrough |  | Sync & State Transfer    ||
| |  | (Protocol Trans.)  |  | (Direct Routing)   |  | (Knowledge Trans.)       ||
| |  +---------+----------+  +---------+----------+  +-----------+--------------+|
| +------------+-----------------------+-------------------------+---------------+
|              | (REST/RPC)           | (MCP/A2A)               | (A2A+KV Cache)
|              v                      v                         v
|        +-----------+          +-------------+           +-------------+
|        | Legacy    |          | Native      |           | Peer Agent-GW|
|        | APIs T1   |          | Agents T2   |           | Node N2      |
|        +-----------+          +-------------+           +-------------+
.................................................................................
External Heterogeneous Ecosystem (Unstructured / Diverse Protocols)

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

8. Infrastructure Functions

9. 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")
=========================================|=========================================
[ Agent-GW ]  (Semantic Router evaluates Data 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")
=========================================|=========================================
[ 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 Sensor|        | (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"]
    }
  }
}

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

11. IANA Considerations

This document has no IANA actions at this time.¶

12. Acknowledgements

TBD¶

Authors' Addresses