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

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

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

3.1.3. Gaps in Current Solutions

*-------------------------------------------------------------------------*
|      Issue              |                Description                    |
*-------------------------*-----------------------------------------------*
| Lack of standardized    |The Supervisor Agent's capabilities (Skills)   |
| external interface      |have no standard way to be exposed externally; |
|                         |apps must use vendor-specific private APIs     |
*-------------------------*-----------------------------------------------*
| Node discovery and      |Nodes register via soft bus, but registration  |
| registration rely on    |format and heartbeat mechanisms are            |
| proprietary protocols   |non-standard                                   |
*-------------------------*-----------------------------------------------*
| Insufficient offline    |Some solutions rely on cloud-based intent      |
| autonomy                |parsing, degrading local orchestration         |
|                         |when disconnected                              |
*-------------------------*-----------------------------------------------*

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

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

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

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

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

3.2.5. Gaps in Current Solutions

*-------------------------*-----------------------------------------------*
|      Issue              |                Description                    |
*-------------------------*-----------------------------------------------*
| No standard inter-agent |Agents discover each other via proprietary     |
| discovery               |soft bus or hardcoded addresses; no unified    |
|                         |registry                                       |
*-------------------------*-----------------------------------------------*
| Task routing depends on |Agent A must know Agent B's address and        |
| point-to-point          |protocol,creating tight coupling               |
| connections             |                                               |
*-------------------------*-----------------------------------------------*
| No standardized event   |Event formats and subscription mechanisms      |
| subscription            |vary across vendors, hindering cross-brand     |
|                         |collaboration                                  |
*-------------------------*-----------------------------------------------*
| Unclear intra-domain    |No unified authentication between agents; a    |
| security boundary       |malicious agent could impersonate another      |
*-------------------------*-----------------------------------------------*

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

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

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

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

3.3.5. Gaps in Current Solutions

*-------------------------*-----------------------------------------------*
|      Issue              |                Description                    |
*-------------------------*-----------------------------------------------*
| Cross-domain discoverye |mDNS/BLE limited to LAN; cloud-to-cloud        |
| unavailable             |integration costly; no standardized Agent      |
|                         |Card format                                    |
*-------------------------*-----------------------------------------------*
| No standard NAT         |Direct connection requires public IP/DDNS;     |
| traversal solution      |reverse channel protocols are proprietary      |
*-------------------------*-----------------------------------------------*
| No standardized event   |Event formats and subscription mechanisms      |
| subscription            |vary across vendors, hindering cross-brand     |
|                         |collaboration                                  |
*-------------------------*-----------------------------------------------*
| Cross-domain trust      |No unified Federation trust bootstrap process; |
| establishment is        |Scope models inconsistent                      |
| difficult               |                                               |
*-------------------------*-----------------------------------------------*
| No standard HITL        |Actions like unlocking doors lack a            |
| mechanism for high-risk |standardized human-in-the-loop confirmation    |
| operations              |workflow                                       |
*-------------------------*-----------------------------------------------*
| No cross-domain         |External agents require multiple protocol      |
| semantics for task      |translations to reach the target sub-agent     |
| routing                 |                                               |
*-------------------------*-----------------------------------------------*
| Audit logs scattered    |Cross-domain call chains cannot be traced      |
|                         |end-to-end                                     |
*-------------------------*-----------------------------------------------*