Agent Gateway Scenario Analysis and Functional Requirements for Cross-Domain Multi-Agent Communication
draft-miao-agw-cross-domain-scenario-analysis-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Chuanyang Miao , Ran Chen , Jinjie Yan | ||
| Last updated | 2026-06-26 | ||
| 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-miao-agw-cross-domain-scenario-analysis-00
Network Working Group C. Miao
Internet-Draft R. Chen
Intended status: Standards Track J. Yan
Expires: 28 December 2026 ZTE Corporation
26 June 2026
Agent Gateway Scenario Analysis and Functional Requirements for Cross-
Domain Multi-Agent Communication
draft-miao-agw-cross-domain-scenario-analysis-00
Abstract
This document analyzes the communication gaps in three representative
multi-agent scenarios: single-domain single-agent, single-domain
multi-agent, and cross-domain multi-agent. For each scenario, it
examines whether an Agent Gateway is needed, what capabilities it
should provide, and where it should be deployed. Based on the
consolidated gap analysis, this document derives a set of universal
functional requirements for the Agent Gateway as a standardized
cross-domain trust boundary and protocol termination layer. The
findings aim to guide the design of interoperable agent communication
infrastructure.
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 28 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Miao, et al. Expires 28 December 2026 [Page 1]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
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
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Scenario Analysis and Gap Identification . . . . . . . . . . 4
3.1. Scenario 1: Single-Domain Single-Agent (1 Agent + Multiple
Nodes) . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Use Case Description . . . . . . . . . . . . . . . . 4
3.1.2. Is an Agent Gateway Needed . . . . . . . . . . . . . 4
3.1.3. Gaps in Current Solutions . . . . . . . . . . . . . . 4
3.2. Scenario 2: Single-Domain Multi-Agent (Multiple Agents
Within One Domain) . . . . . . . . . . . . . . . . . . . 5
3.2.1. Use Case Description . . . . . . . . . . . . . . . . 5
3.2.2. Is an Agent Gateway Needed . . . . . . . . . . . . . 5
3.2.3. Required Capabilities . . . . . . . . . . . . . . . . 6
3.2.4. Deployment Location . . . . . . . . . . . . . . . . . 6
3.2.5. Gaps in Current Solutions . . . . . . . . . . . . . . 6
3.3. Scenario 3: Cross-Domain Multi-Agent Communication . . . 7
3.3.1. Use Case Description . . . . . . . . . . . . . . . . 7
3.3.2. Is an Agent Gateway Needed . . . . . . . . . . . . . 7
3.3.3. Required Capabilities . . . . . . . . . . . . . . . . 7
3.3.4. Deployment Location . . . . . . . . . . . . . . . . . 8
3.3.5. Gaps in Current Solutions . . . . . . . . . . . . . . 8
4. Consolidated Gap Analysis . . . . . . . . . . . . . . . . . . 9
4.1. Core Functions . . . . . . . . . . . . . . . . . . . . . 9
4.2. Optional Functions . . . . . . . . . . . . . . . . . . . 10
4.3. Deployment Recommendations . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Miao, et al. Expires 28 December 2026 [Page 2]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
1. 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.
2. Conventions Used in This Document
2.1. Abbreviations
* AGW: Agent Gateway
* HITL: Human-in-the-loop
* HVAC: Heating, Ventilation and Air Conditioning
2.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Miao, et al. Expires 28 December 2026 [Page 3]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
3. Scenario Analysis and Gap Identification
3.1. Scenario 1: Single-Domain Single-Agent (1 Agent + Multiple Nodes)
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
Miao, et al. Expires 28 December 2026 [Page 4]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
*-------------------------------------------------------------------------*
| 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. Scenario 2: Single-Domain Multi-Agent (Multiple Agents Within One
Domain)
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.
Miao, et al. Expires 28 December 2026 [Page 5]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
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 |
*-------------------------*-----------------------------------------------*
Miao, et al. Expires 28 December 2026 [Page 6]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
3.3. Scenario 3: Cross-Domain Multi-Agent Communication
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.
Miao, et al. Expires 28 December 2026 [Page 7]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
* 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
Miao, et al. Expires 28 December 2026 [Page 8]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
*-------------------------*-----------------------------------------------*
| 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 |
*-------------------------*-----------------------------------------------*
4. Consolidated Gap Analysis
Based on the analysis of the three scenarios above, common gaps
across current agent communication architectures can be summarized as
follows:
4.1. Core Functions
Miao, et al. Expires 28 December 2026 [Page 9]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
*-------------------------*-----------------------------------------------*-------------*
| Function | Description | Applicable |
| | | Scenarios |
*-------------------------*-----------------------------------------------*-------------*
| Agent Card Registration |Receive capability registrations from | |
| & Aggregation |intra-domain agents; merge into an aggregated |2, 3 |
| |Card; expose via standardized endpoint | |
*-------------------------*-----------------------------------------------*-------------*
| A2A Protocol Termination|Support standard A2A Task interface (POST | |
| |/a2a/tasks); translate external requests into |3 |
| |internal commands | |
*-------------------------*-----------------------------------------------*-------------*
| Authentication & |Support JWT/OAuth2; verify caller identity and |3 (optional |
| Authorization |Scope whitelist |for 2) |
*-------------------------*-----------------------------------------------*-------------*
| Reverse Channel |Accept reverse WebSocket/MQTT connections from | |
| Management |intra-domain Supervisor Agent for task dispatch|3 |
*-------------------------*-----------------------------------------------*-------------*
| Task Routing |Route Tasks to the correct intra-domain agent | |
| |or cross-domain Gateway based on Skill ID |2, 3 |
*-------------------------*-----------------------------------------------*-------------*
| Information Hiding |Do not expose sub-agent count, IP addresses, | |
| |protocols, or other internal details externally|3 |
*-------------------------*-----------------------------------------------*-------------*
| HITL Trigger |Mark high-risk Skills with | |
| |require_human_approval; suspend Task and wait |3 |
| |for user confirmation | |
*-------------------------*-----------------------------------------------*-------------*
| Audit logging |Record full chain of cross-domain calls |3 |
*-------------------------*-----------------------------------------------*-------------*
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.
4.2. Optional Functions
Miao, et al. Expires 28 December 2026 [Page 10]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
*-------------------------*-----------------------------------------------*-------------*
| Function | Description | Applicable |
| | | Scenarios |
*-------------------------*-----------------------------------------------*-------------*
| Intra-domain Event Bus |Support publish/subscribe between intra-domain | |
| |agents |2 |
*-------------------------*-----------------------------------------------*-------------*
| Federation |Exchange aggregated Cards with other domain | |
| Synchronization |Gateways for cross-domain discovery |3 |
*-------------------------*-----------------------------------------------*-------------*
| Local Caching & Offline |Cache aggregated Cards and authorization | |
| Autonomy |policies; handle authorized local Tasks when |2, 3 |
| |disconnected | |
*-------------------------*-----------------------------------------------*-------------*
4.3. 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.
5. 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).
Miao, et al. Expires 28 December 2026 [Page 11]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
* All gateway components SHOULD record complete audit logs,
including request source, target, operation, result, and
timestamp. Logs MUST be tamper-proof.
6. Acknowledgements
TBA.
7. IANA Considerations
TBA.
8. References
8.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/rfc/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/rfc/rfc8174>.
8.2. Informative References
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
Authors' Addresses
Chuanyang Miao
ZTE Corporation
Email: miao.chuanyang@zte.com.cn
Ran Chen
ZTE Corporation
Miao, et al. Expires 28 December 2026 [Page 12]
Internet-Draft Agent Gateway Scenario Analysis and Func June 2026
Email: chen.ran@zte.com.cn
Jinjie Yan
ZTE Corporation
Email: yan.jinjie@zte.com.cn
Miao, et al. Expires 28 December 2026 [Page 13]