Agent Gateway Scenario Analysis and Functional Requirements for Cross-Domain Multi-Agent Communication

Introduction As agent technology evolves from single-device intelligence to multi-device collaboration and cross-domain interconnection, there is a growing demand for multi-agent communication across home, vehicle, and enterprise campus scenarios. Typical use cases include:

Multiple sub-agents (lighting, security, HVAC) within a home collaborating to execute an "arrive home" scene;
A vehicle agent communicating with a user home agent across domains to enable "auto-arm when leaving, pre-condition when approaching";
Agents from different vendors (e.g., User Home Agent and 3rd-party Vehicle Agent) needing to cooperate across trust domains.

However, current agent communication architectures lack a standardized cross-domain trust boundary and protocol termination layer. This document aims to analyze three representative scenarios (single-domain single-agent, single-domain multi-agent, and cross-domain multi-agent), identify gaps in existing solutions, and argue for the necessity, capability requirements, and deployment options of an Agent Gateway as a universal infrastructure component.

Conventions Used in This Document

Abbreviations

AGW: Agent Gateway
HITL: Human-in-the-loop
HVAC: Heating, Ventilation and Air Conditioning

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Scenario Analysis and Gap Identification

Scenario 1: Single-Domain Single-Agent (1 Agent + Multiple Nodes)

Use Case Description A home has a single Agent managing multiple smart devices (physical nodes). For example:

A central hub (Node A) runs the Supervisor Agent;
A smart speaker (Node B) serves as the voice interaction interface;
A ZigBee gateway (Node C) connects ZigBee lights and sensors.

The Supervisor Agent communicates with each node via a soft bus (e.g., DSoftBus, local MQTT) and provides a unified service externally. Users issue commands via voice or app; the Supervisor Agent parses the intent and dispatches tasks to the appropriate node. Naturally, if all household devices are assigned IP addresses, a mesh network can be established over the home network. Furthermore, the aforementioned devices can communicate directly via peer-to-peer (P2P) protocols.

Is an Agent Gateway Needed No. In this scenario, all communication occurs within the same trust domain (home LAN). The Supervisor Agent can interact directly with each node. There is no cross-domain security boundary. External access (e.g., mobile app) typically goes through the vendor cloud, which is outside the scope of Agent Gateway.

Gaps in Current Solutions Note: Gaps in this scenario are more about "external exposure" and "standardization," but introducing an Agent Gateway is not strictly necessary; these gaps could be addressed by enhancing the Supervisor Agent itself.

Scenario 2: Single-Domain Multi-Agent (Multiple Agents Within One Domain)

Use Case Description A home contains multiple independent agents, each managing a different subsystem, requiring inter-operation. For example:

Lighting Agent: manages all lighting devices;
Security Agent: manages door locks, cameras, alarms;
Environment Agent: manages HVAC, curtains, air purifiers.

These agents may run on different hardware nodes (central hub, smart speaker, dedicated gateway). They need to discover each other's capabilities, subscribe to events, and collaboratively execute scenes (e.g., "away mode": Security Agent arms, Lighting Agent turns off lights, Environment Agent switches to energy-saving mode).

Is an Agent Gateway Needed Yes, but with a different role than in the cross-domain scenario. Here, the Agent Gateway should act as an intra-domain registry and task routing layer, rather than a cross-domain security boundary.

Required Capabilities

Intra-domain Agent Card Registration and Discovery: Each agent registers its Skills and capability description (Agent Card) with the Gateway; the Gateway maintains a domain-wide capability index.
Intra-domain Task Routing: When Agent A needs to invoke a Skill of Agent B, the request goes through the Gateway, which handles addressing and optional load balancing.
Event Bus: Support publish/subscribe model so agents can subscribe to events from other agents (e.g., security alarm triggered �� lighting turns on).
Local-first: All communication should complete within the LAN, without depending on public internet connectivity.

Deployment Location

Standalone device: e.g., home central hub, NAS, or high-performance router.
Collocated with Supervisor Agent: If the domain has a single Supervisor Agent managing all sub-agents, it can also serve as the Gateway.

Gaps in Current Solutions

Scenario 3: Cross-Domain Multi-Agent Communication

Use Case Description Two or more agents from different trust domains need to communicate across domain boundaries. Typical use cases:

Home Domain <-> Vehicle Domain: As the owner drives home, the vehicle agent sends an "estimated arrival in 10 minutes" event to the home agent, which pre-conditions the HVAC, turns on lights, and disarms the security system.
Home Domain <-> Cloud LLM Agent: A user queries home status or issues commands via a cloud-based LLM agent, which invokes Skills exposed by the home agent.
Home Domain A <-> Home Domain B (neighbor assistance): Neighbor A's security agent detects an anomaly and notifies neighbor B's security agent to increase vigilance.

Is an Agent Gateway Needed Strongly needed. Cross-domain scenarios face fundamental challenges including NAT traversal, trust establishment, protocol translation, and information hiding. An Agent Gateway is an essential cross-domain trust boundary and protocol termination layer.

Required Capabilities

External A2A Endpoint: Expose standardized endpoints, such as for /.well-known/agent.json and POST /a2a/tasks, supporting HTTP/HTTPS.
Authentication and Authorization: for example, Support OAuth2 Device Flow, JWT issuance and verification, and Scope whitelisting.
Aggregated Agent Card: Merge all intra-domain Skills into a single Card for external exposure, hiding internal topology.
Reverse Channel Management: Accept reverse WebSocket/MQTT connections from the intra-domain Supervisor Agent for task dispatch and artifact return.
Cross-domain Federation: Establish mutual trust with Gateways in other domains, exchange aggregated Cards, and enable cross-domain discovery and Task Proxy.
HITL (Human-in-the-Loop): For high-risk Skills (e.g., unlock door), support suspending the Task and pushing a confirmation request to the user's app.
Audit Logging: Record the full chain of cross-domain calls (issuer, skill_id, status, timestamp).

Deployment Location

Home network edge: Deployed on the home gateway (router/ONT) or a standalone edge computing device, serving as the sole external entry point for the home domain.
Cloud: If the home lacks public reachability, deploy on the vendor cloud as a Relay Gateway; the home Supervisor Agent connects via a reverse channel.
Hybrid mode: Cloud Gateway acts as global Registry and Auth Broker; Edge Gateway performs local A2A termination (when publicly reachable).

Gaps in Current Solutions

Consolidated Gap Analysis Based on the analysis of the three scenarios above, common gaps across current agent communication architectures can be summarized as follows:

Core Functions Core conclusion: As agents evolve from single-node to multi-node and from intra-domain to cross-domain operation, the lack of a standardized trust boundary and protocol termination layer has become a primary bottleneck. The Agent Gateway is the key infrastructure component to fill this gap.

Optional Functions

Deployment Recommendations

Single-domain multi-agent scenario: The Agent Gateway can be deployed on an intra-domain central hub device, collocated with or separate from the Supervisor Agent.
Cross-domain multi-agent scenario: The Agent Gateway should be deployed at the home network edge or in the vendor cloud, serving as the sole external entry point.
Hybrid deployment: Cloud Gateway acts as global Registry and Auth Broker; Edge Gateway performs local A2A termination, balancing reachability and low latency.

Security Considerations The Agent Gateway, as the sole entry point for cross-domain communication, must enforce strict security measures:

All external interfaces MUST use TLS 1.3 encryption.
Authentication tokens SHOULD have a limited validity period (recommended no more than 24 hours) and support refresh.
Cross-domain requests MUST pass mTLS or Federation-level cascading trust verification.
Highly sensitive operations (e.g., door lock control) MUST enable the HITL mechanism, and HITL confirmation requests SHOULD be delivered to the user through an independent channel (e.g., mobile push notification).
All gateway components SHOULD record complete audit logs, including request source, target, operation, result, and timestamp. Logs MUST be tamper-proof.

Acknowledgements TBA.

IANA Considerations TBA.