| Internet-Draft | Agent Gateway Core functional Architectu | June 2026 |
| Miao, et al. | Expires 27 December 2026 | [Page] |
This document defines the core functional architecture of the Agent Gateway as a universal infrastructure component. The Agent Gateway is designed to address key challenges in single-domain multi-agent collaboration and cross-domain multi-agent communication, including trust boundaries, protocol termination, capability discovery, and task routing. The main framework consists of four gateway capabilities: the A2A Gateway (supporting inter-agent communication), the MCP Gateway (supporting tool invocation), the Model Routing Gateway (supporting large language model invocation), and the Network Gateway (supporting underlying network connectivity). The A2A Gateway is further decomposed into five core capabilities: protocol translation, authentication and security, asynchronous task management, peer-to-peer network management, and Agent routing capabilities (including Agent registry, capability discovery, task routing, and load balancing). This document is intended for designers and implementers seeking to build standardized, interoperable agent communication infrastructure.¶
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 27 December 2026.¶
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.¶
As agent technology evolves from single-device intelligence to multi-device collaboration and cross-domain interconnection, there is a growing demand for inter-agent communication across home, vehicle, and enterprise campus scenarios. Typical use cases include:¶
Traffic lanes, for instance, have emerged and been commonly used for¶
Single-domain multi-agent collaboration: Within the same home domain, a lighting agent, security agent, and environment agent collaborate to execute an "away mode" scene;¶
Cross-domain agent communication: A vehicle agent interacts with a home agent across domains to enable "auto-arm when leaving, pre-condition when approaching";¶
Cross-vendor agent interoperability: Agents from different brands (e.g., Midea Home Agent and Huawei Vehicle Agent) need to cooperate across trust domains.¶
Existing agent communication architectures lack a standardized cross-domain trust boundary and protocol termination layer. To address this problem, this document proposes the Agent Gateway as a unified infrastructure component and defines its core functional architecture. This architecture covers four categories of gateway capabilities, corresponding to inter-agent communication, tool invocation, large model routing, and network connectivity, thereby forming a complete end-to-end agent communication middleware.¶
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.¶
The overall architecture of the Agent Gateway consists of four logical sub-gateways. They may be deployed on the same physical node or distributed across multiple nodes. Each sub-gateway has clearly defined responsibilities and standardized interfaces, collectively providing unified ingress and egress control.¶
+----------------------------------------------------------------+ | Agent Gateway | | | | +------------------+ +------------------+ | | | A2A Gateway | | MCP Gateway | | | | (Inter-Agent | | (Tool Invocation)| | | | Communication) | | | | | +--------+---------+ +--------+---------+ | | | | | | +--------+---------+ +--------+---------+ | | | Model Routing | | Network Gateway | | | | Gateway | | (Network | | | | (LLM Invocation) | | Connectivity) | | | +------------------+ +------------------+ | | | +----------------------------------------------------------------+¶
The following subsections describe the functions of each sub-gateway.¶
The A2A Gateway is the core of the Agent Gateway. It is responsible for handling inter-agent connectivity, discovery, task routing, and security management. It exposes standardized A2A protocol endpoints externally (e.g., /.well-known/agent.jsonand POST /a2a/tasks) and connects internally to sub-agents or upstream Supervisor Agents. The A2A Gateway comprises the following five core capabilities:¶
Description: Translates external A2A requests (HTTP/HTTPS, WebSocket, gRPC, etc.) into commands understandable by internal agents (e.g., local MQTT, DDS, soft bus messages), and vice versa;¶
Applicable Scenarios: Bridging external protocols with internal proprietary protocols during cross-domain agent communication; unifying protocols across different subsystems (ZigBee, BLE, Wi-Fi) within a single domain;¶
Design Considerations: Support plugin-based protocol adapters to allow dynamic loading of new transport protocols and serialization formats (JSON, Protobuf, CBOR).¶
Description: Performs identity verification and authorization checks on all incoming requests to the A2A Gateway. Supports OAuth 2.0 Device Flow, JWT issuance and verification, and Scope whitelisting. For cross-domain requests, mutual TLS (mTLS) or Federation-based trust relationships must be established;¶
Applicable Scenarios: Mandatory identity verification for cross-domain calls; optional within a single domain to prevent malicious nodes from impersonating legitimate agents;¶
Design Considerations: Built-in Certificate Revocation List (CRL) caching; support for Human-in-the-Loop (HITL) triggering of secondary confirmation for highly sensitive operations (e.g., unlocking a door).¶
Description: Manages the lifecycle of all tasks passing through the A2A Gateway, including task creation, status tracking, result delivery, and timeout handling. Follows the Task object model defined in the Google A2A protocol (task_id, status, artifacts, messages);¶
Applicable Scenarios: Long-running agent collaboration tasks (e.g., "whole-house cleaning" requiring sequential execution by multiple agents); cross-domain tasks that may require asynchronous waiting due to network latency;¶
Design Considerations: Support persistent task queues (SQLite/LevelDB); provide two result notification methods: callback URL or WebSocket push; support task cancellation and pause/resume.¶
Description: Manages peer connections with other domain Agent Gateways. Includes NAT traversal (STUN/TURN/ICE), reverse channel maintenance (WebSocket/MQTT long-lived connections), heartbeat keep-alive, and reconnection strategies;¶
Applicable Scenarios: Between a home domain Gateway and a cloud Relay Gateway; between a home domain Gateway and a vehicle domain Gateway;¶
Design Considerations: Support both active connection initiation and passive acceptance modes; provide connection quality monitoring and automatic switchover to backup paths.¶
Agent routing capabilities form the intelligent scheduling module within the A2A Gateway, comprising the following sub-functions:¶
Agent Registry: Receives registration information (Agent ID, Skill list, address, protocol type) from all agents within the domain, forming a domain-wide agent directory. Supports dynamic registration/deregistration and automatic removal upon heartbeat timeout.¶
Agent Capability Discovery: Exposes an aggregated Agent Card externally (/.well-known/agent.json), hiding internal topology; provides capability query interfaces internally for other agents or upper-layer orchestration engines to search for available Skills.¶
Agent Task Routing: Distributes tasks to the correct agent instance based on the target Skill ID or intent matching. Supports content-based routing (e.g., by device type or zone) and weight-based routing.¶
Load Balancing: When multiple agent instances provide the same Skill (e.g., redundant backups), distributes tasks according to predefined policies (round-robin, least connections, consistent hashing) to improve availability.¶
The MCP (Model Context Protocol) Gateway is responsible for managing the registration, discovery, and invocation of external tools. It provides a unified way for agents to invoke non-agent services or device capabilities, such as:¶
Calling a weather API to retrieve real-time data;¶
Controlling IoT devices that do not possess full agent capabilities (via device SDKs);¶
Accessing databases or file systems.¶
Core Functions:¶
Tool Registration and Metadata Management: Receives tool provider Schema registrations (compliant with MCP Tool Schema specification), including input parameters, output format, and authentication requirements.¶
Tool Invocation Proxy: Forwards tool invocation requests initiated by agents to the corresponding tool backend and returns results to the agent. Supports both synchronous and asynchronous modes.¶
Security Sandbox: Performs permission checks (whether the caller is authorized to use the tool), rate limiting, and input filtering for tool invocations to prevent malicious injection.¶
Tool Chaining: Supports composing multiple tools into composite tools, simplifying orchestration logic on the agent side.¶
Relationship between the MCP Gateway and the A2A Gateway: The A2A Gateway handles agent-to-agent communication; the MCP Gateway handles agent-to-tool communication. Both may share common infrastructure services such as authentication and logging within the Agent Gateway.¶
The Model Routing Gateway provides a unified entry point for agents to invoke large language models (LLMs), enabling model selection, load balancing, and cost control.¶
Core Functions:¶
Model Registration and Routing: Maintains a list of available models (e.g., Hunyuan, DeepSeek, GPT-4o, etc.) and routes requests to the most suitable model instance based on model preference, task type (reasoning, generation, translation), token budget, and other factors.¶
Unified API Adaptation: Converts vendor-specific APIs (OpenAI-compatible format, Hunyuan API, Claude API, etc.) into a standard interface (e.g., OpenAI Chat Completion format), reducing integration complexity for agents.¶
Context Management and Caching: Implements semantic caching for frequently occurring requests (e.g., common knowledge queries) to reduce duplicate invocations; supports sliding window context truncation to control token consumption.¶
Security and Compliance: Performs content filtering on model outputs (sensitive word detection, privacy leakage detection); records audit logs for compliance purposes.¶
The Model Routing Gateway is typically deployed in the cloud or at the edge. It works in conjunction with the A2A Gateway: agents delegate inference tasks to the Model Routing Gateway via the A2A Gateway, which then invokes the specific LLM.¶
The Network Gateway provides underlying network connection management capabilities, ensuring that the Agent Gateway can stably access the internet and communicate with external entities.¶
Core Functions:¶
Connection Management: Manages the connection state of multiple network links (Ethernet, Wi-Fi, cellular), supporting primary/backup switching and failover.¶
NAT Traversal: Integrates STUN/TURN/ICE clients to provide underlying P2P capabilities for peer-to-peer network management; relays traffic via TURN when no public IP is available.¶
Firewall and Port Mapping: Automatically configures UPnP or manual port forwarding rules so that external A2A requests can reach the Gateway's listening ports.¶
Quality of Service (QoS): Assigns priority levels to different types of traffic (control commands, media streams, bulk data) to ensure low latency for critical tasks.¶
Network Diagnostics: Provides diagnostic tools such as connectivity testing, bandwidth measurement, and packet loss statistics to assist operations and maintenance.¶
The Network Gateway typically runs on home routers, edge servers, or cloud hosts, serving as the bridge between the Agent Gateway and the physical network.¶
As the sole entry point for cross-domain communication, the Agent Gateway 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.¶
TBA.¶
TBA.¶