Skip to main content

Agent Communication Gateway for Semantic Routing and Working Memory
draft-agent-gw-01

Document Type Active Internet-Draft (individual)
Authors Xiaohui Xie , 王梓安 , Tianshuo Hu , Yong Cui
Last updated 2026-03-04
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-01
Agent-GW                                                    Xiaohui. Xie
Internet-Draft                                       Tsinghua University
Intended status: Standards Track                              Zian. Wang
Expires: 2 September 2026Beijing University of Posts and Telecommunications
                                                            Tianshuo. Hu
                                                               Yong. Cui
                                                     Tsinghua University
                                                            1 March 2026

  Agent Communication Gateway for Semantic Routing and Working Memory
                           draft-agent-gw-01

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

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.

Xie, et al.             Expires 2 September 2026                [Page 1]
Internet-Draft  Agent Communication Gateway for Semantic      March 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Deployment Model and Trust Boundary . . . . . . . . . . . . .   4
   5.  Network and Infrastructure Requirements . . . . . . . . . . .   5
   6.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Internal/External Entity Relationship . . . . . . . . . .   6
     6.2.  Functional Planes . . . . . . . . . . . . . . . . . . . .   7
   7.  Protocol Model and Input/Output Examples  . . . . . . . . . .   7
     7.1.  Example: A2A Request Normalization  . . . . . . . . . . .   7
     7.2.  Example: Southbound Output Mapping  . . . . . . . . . . .   8
   8.  Infrastructure Functions  . . . . . . . . . . . . . . . . . .   8
     8.1.  Agent Identification and Capability Directory . . . . . .   8
     8.2.  Automated Protocol Adaptation and Interface Normalization
           (APA) . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.3.  Infrastructure-Level Agent Evaluation and Compliance  . .   9
     8.4.  Dynamic Orchestration and Semantic Routing  . . . . . . .   9
     8.5.  Evolutionary Knowledge Management . . . . . . . . . . . .   9
     8.6.  Collaborative Inference Acceleration (KDN)  . . . . . . .  10
   9.  Representative Deployment Scenarios . . . . . . . . . . . . .  10
     9.1.  Scenario 1: Enterprise Copilot with Local Secure Routing
           and External Egress . . . . . . . . . . . . . . . . . . .  10
     9.2.  Scenario 2: Industrial Planning with IoT (MQTT/REST) and
           Embodied Agent (ROS Bridge) . . . . . . . . . . . . . . .  11
     9.3.  Scenario 3: Peer Agent-GW Synchronization and Inference
           Artifact Transfer . . . . . . . . . . . . . . . . . . . .  12
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

Xie, et al.             Expires 2 September 2026                [Page 2]
Internet-Draft  Agent Communication Gateway for Semantic      March 2026

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.

Xie, et al.             Expires 2 September 2026                [Page 3]
Internet-Draft  Agent Communication Gateway for Semantic      March 2026

   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.

Xie, et al.             Expires 2 September 2026                [Page 4]
Internet-Draft  Agent Communication Gateway for Semantic      March 2026

   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.

Xie, et al.             Expires 2 September 2026                [Page 5]
Internet-Draft  Agent Communication Gateway for Semantic      March 2026

6.1.  Internal/External Entity Relationship

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

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

   Figure 1: Agent-GW Entity Relationship across Internal Semantic
                    Domain and External Ecosystem

Xie, et al.             Expires 2 September 2026                [Page 6]
Internet-Draft  Agent Communication Gateway for Semantic      March 2026

   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.

6.2.  Functional Planes

   Agent-GW can be described as four logical planes:

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

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.

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

Xie, et al.             Expires 2 September 2026                [Page 7]
Internet-Draft  Agent Communication Gateway for Semantic      March 2026

   Illustrative normalized semantic request inside Agent-GW (after
   parsing and policy checks):

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

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

8.  Infrastructure Functions

8.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 2 September 2026                [Page 8]
Internet-Draft  Agent Communication Gateway for Semantic      March 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.

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

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

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

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

Xie, et al.             Expires 2 September 2026                [Page 9]
Internet-Draft  Agent Communication Gateway for Semantic      March 2026

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

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.

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

      Figure 2: Enterprise Copilot: Split Routing by Privacy and
                           Capability Tags

   Example ingress request (MCP-like) and split dispatch:

Xie, et al.             Expires 2 September 2026               [Page 10]
Internet-Draft  Agent Communication Gateway for Semantic      March 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
     }
   }

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

   Figure 3: Industrial Scenario: Intent Decomposition and Protocol
                             Translation

   Illustrative sub-task outputs:

Xie, et al.             Expires 2 September 2026               [Page 11]
Internet-Draft  Agent Communication Gateway for Semantic      March 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"}}
       }
     ]
   }

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

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

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.

Xie, et al.             Expires 2 September 2026               [Page 12]
Internet-Draft  Agent Communication Gateway for Semantic      March 2026

   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

13.  References

13.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 2 September 2026               [Page 13]