Agent Communication Gateway for Semantic Routing and Working Memory

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 (), a traffic model that classifies data-plane and control-plane flows per gateway tier (), cross-domain semantic routing and name resolution (, ), resilience and scalability guidance (), and operational considerations (). 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.

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 and when, and only when, they appear in all capitals, as shown here.

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.

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 .

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

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

Function Placement across Tiers The infrastructure functions of 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. 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.

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.

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.

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

Agent-GW Entity Relationship across Internal Semantic Domain and External Ecosystem 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) ]]> 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.

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.

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.

Data-Plane Traffic

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.

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 .

Cross-Domain Forwarding Path and Per-Hop Functions | Domain |-->|Inter-dom. |-->| Domain |-->| Access | | GW A1 |(2)| GW D1 |(3)| GW |(4)| GW D2 | | GW B1 | +--------+ +--------+ +-----------+ +--------+ +--------+ ]]> 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 ), 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.

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.

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 () 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 (). Working memory synchronization: triggered only by session migration or disaster recovery, not periodic. See .

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.

Example: A2A Request Normalization Illustrative A2A message (ingress) that Agent-GW normalizes into an internal semantic request: Illustrative normalized semantic request inside Agent-GW (after parsing and policy checks):

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: Example ROS command topic for an embodied agent target:

Infrastructure Functions

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.

Enterprise Copilot: Split Routing by Privacy and Capability Tags Example ingress request (MCP-like) and split dispatch:

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.

Industrial Scenario: Intent Decomposition and Protocol Translation 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) | +----------------------+ +----------------------+ ======================================================================= ]]> Illustrative sub-task outputs:

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 , this scenario is the horizontal control-plane case of : 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.

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

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 . Consumer privacy relies on the context-minimization rules of : 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 (), 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):

Operational Considerations Incremental deployment: the hierarchy is adoptable in stages. Stage 1 is a single Domain Agent-GW (the collapsed form of ). 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 .

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 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 to make misrouting detectable.

IANA Considerations This document has no IANA actions at this time.

Acknowledgements TBD