| Internet-Draft | Agent Gateway Interconnection: Use Cases | November 2026 |
| Wang | Expires 6 May 2027 | [Page] |
This document defines use cases and requirements for interconnection of Agent Gateways (AGWs) across separate administrative domains. An Agent Gateway acts as a trust and protocol boundary for AI agents, mediating agent discovery, intent routing, policy enforcement, context translation, and secure cross-domain collaboration. This draft does not specify a wire protocol. Instead, it collects representative deployment scenarios and derives functional, operational, and interoperability requirements to guide future protocol design for AGW-to-AGW interconnection.¶
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 6 May 2027.¶
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.¶
AI agents are increasingly deployed as autonomous or semi-autonomous entities that perform tasks, consume tools, maintain context, and coordinate with other agents. Agents may belong to different organizations, run on heterogeneous stacks, expose different interaction protocols, and operate under independent trust and data governance rules.¶
Direct agent-to-agent communication raises several practical problems: agent endpoint mobility, divergent capability schemas, lack of consistent policy enforcement boundaries, uncontrolled leakage of private context or memory, and difficulty in auditing cross-organizational agent interactions.¶
An Agent Gateway (AGW) is a logical component deployed at domain boundaries to address these concerns. An AGW terminates local agent sessions, evaluates access and data policies, translates intent and context representations, routes requests toward remote agents via peer AGWs, and mediates response flows back into the local domain.¶
When multiple administrative domains each run their own AGW, the ability for these gateways to interoperate becomes foundational. This interconnection is not simply IP reachability or TLS transport; it requires agreement on agent identity, capability advertisement, intent framing, policy signaling, context scoping, and audit records.¶
This document first introduces the basic AGW interconnection model. It then describes a set of concrete use cases derived from industrial automation, enterprise collaboration, edge-cloud agent deployment, and multi-party service orchestration. From those use cases, it extracts a structured set of requirements that future AGW interconnection protocols, data models, and policy languages should satisfy.¶
This document is intended as input for subsequent protocol, data model, and semantic standardization work.¶
The key terms used in this document are defined below:¶
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 baseline model considered in this document is peer-to-peer interconnection between AGWs, where each AGW represents its local administrative domain.¶
A local agent sends a request to its home AGW. The home AGW evaluates local policy. If the target agent resides outside the local domain, the home AGW forwards the request to the remote AGW. The remote AGW evaluates its own ingress policy, translates intent and context into representations understood by local agents, selects or routes to a suitable agent, and returns results through the same gateway path.¶
This model assumes that the AGWs are the policy enforcement points for cross-domain agent interaction. Agents inside a domain do not need to know the identity, location, or native protocol of remote agents. They only interact with their local AGW.¶
The model supports several variations:¶
This document does not assume a single fixed topology. Requirements are written to be topology-agnostic unless explicitly scoped to a use case.¶
Scenario: An enterprise agent in Domain A needs to execute a specialized compliance-checking task that is only available from an agent service operated by a regulated partner in Domain B.¶
The local agent submits an intent to its AGW-A. AGW-A looks up the target capability, determines it resides in Domain B, and opens an interconnection session with AGW-B. AGW-A attaches only the minimal context and data required for the compliance check, subject to pre-negotiated data handling policy. AGW-B validates the request against its ingress policy, forwards the intent to the compliance agent, receives the result, and returns it to AGW-A. AGW-A logs the interaction and presents the result to the requesting agent.¶
Scenario: An industrial orchestration agent in a factory domain needs to find any available agent that can perform predictive equipment diagnostics. Multiple supplier domains each operate their own diagnostic agents and AGWs.¶
The local AGW queries peer AGWs for matching capability declarations. Each peer AGW returns a filtered view of available agents and capabilities according to its own advertising policy. The requesting AGW ranks candidates and returns reachable options to the local agent. The agent can then select a suitable capability and initiate a task through the selected peer AGW.¶
Scenario: A supply chain workflow requires sequential coordination among agents belonging to a shipper, a customs broker, and a port operator, each in separate administrative domains. Each agent performs a distinct step and produces artifacts needed by the next party.¶
The workflow coordinator agent starts the process through its AGW. Each subsequent task step is delegated to the next domain's AGW. AGWs mediate handoff of task state and artifacts, enforce per-step access controls, and record transition events. If one party rejects a handoff due to policy or data issues, the AGW returns a structured fault back to the workflow coordinator.¶
The requirements below are grouped into functional, interoperability, and operational categories.¶
REQ-FUN-01: An AGW interconnection mechanism MUST support the forwarding of agent intent requests from a local AGW to an adjacent AGW, and the return of corresponding responses, task outputs, or structured faults.¶
REQ-FUN-02: An AGW interconnection mechanism MUST support discovery and lookup of agent capabilities advertised by peer AGWs. Discovery responses MAY be filtered by the advertising AGW's policy.¶
REQ-FUN-03: An AGW MUST support policy-based selection of whether to forward a request, what subset of local context may be sent, and which adjacent AGW receives the request.¶
REQ-FUN-04: An AGW MUST Support the reception of task requests, and based on the described task requests, determine the tasks to be processed and the types of tasks. Determine whether there is an agent combination matching the task type within the first area of the current first intelligent agent boundary gateway management, and if such an agent combination exists, schedule this agent combination to handle the task.¶
REQ-FUN-05: An AGW MUSTSupport the generation of task notifications based on the task type, without the existence of the aforementioned agent combination, and sending them to the adjacent intelligent agent boundary gateway to query whether there is a matching agent combination within the adjacent area. Here, the adjacent area refers to the area managed by the adjacent intelligent agent boundary gateway.¶
REQ-FUN-06: An AGW MUSTSupport the sending of the task to the corresponding boundary gateway upon receiving the successful matching information returned by the adjacent intelligent agent boundary gateway, so that the boundary gateway can schedule the matching intelligent agent combination to handle the task.¶
REQ-FUN-07:An AGW MUSTSupport sending a query request to the agent control center when receiving the matching failure information returned by the adjacent agent boundary gateway, so that the agent control center can coordinate the handling of cross-region tasks.¶
REQ-INT-01: The interconnection mechanism MUST define a base machine-readable format for capability advertisements so that peer AGWs can determine whether they understand a given agent service.¶
REQ-INT-02: The interconnection mechanism SHOULD provide a standard way to signal translation requirements between heterogeneous agent interaction protocols, such as MCP, A2A, custom REST agent APIs, or proprietary agent runtimes.¶
REQ-OPS-01: AGWs participating in interconnection MUST expose standardized metrics for request volume, latency.¶
REQ-OPS-02: The interconnection protocol SHOULD support structured logging and event reporting that can be exported to local observability systems without exposing sensitive agent context.¶
REQ-OPS-03: An AGW MUST support rate-limiting control for peer-originated requests to protect local agent resources from overload.¶
This draft collects representative deployment scenarios and derives functional, operational, and interoperability requirements to guide future protocol design for AGW-to-AGW interconnection.¶
This document has no IANA actions.¶
TBD.¶
.¶