Agent Gateway Interconnection: Use Cases and Requirements

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

Terminology The key terms used in this document are defined below:

Agent Gateway (AGW): A domain boundary component that mediates interactions between local agents and agents reachable through peer agent gateways. The AGW enforces local policy, translates representations, advertises or resolves agent capabilities, and tracks cross-domain agent sessions.
Intent: A structured or semi-structured description of a task objective that an agent is requested to fulfill. An intent is distinct from raw natural language prompts and may include constraints, required outputs, and permitted data scope.
Capability: A machine-readable declaration of what an agent or agent pool can perform, including supported intents, tool interfaces, data schemas, quality commitments, and policy constraints.
Context: State associated with an agent session, including conversation history, intermediate task artifacts, credentials, and local environment bindings. Context is generally sensitive and must not cross domain boundaries unless explicitly permitted.
Administrative Domain: A trust and policy boundary under unified operational control. A domain may contain multiple agents, multiple AGWs, or a hierarchical AGW deployment.

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.

Agent Gateway Interconnection Model 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:

direct peering between two AGWs;
transit peering through intermediate AGWs;
hierarchical AGW trees (edge AGWs connecting to regional or cloud AGWs);
federated AGW topologies with optional directory services for capability discovery.

This document does not assume a single fixed topology. Requirements are written to be topology-agnostic unless explicitly scoped to a use case.

Use Cases

Cross-Domain Task Delegation 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.

Federated Agent Discovery and Capability Lookup 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.

Multi-Party Collaborative Agent Workflow 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.

Requirements The requirements below are grouped into functional, interoperability, and operational categories.

Functional Requirements 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.

Interoperability Requirements 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.

Operational Requirements 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.

Conclusion This draft collects representative deployment scenarios and derives functional, operational, and interoperability requirements to guide future protocol design for AGW-to-AGW interconnection.

IANA Considerations This document has no IANA actions.

Security Considerations TBD. .