Network Working Group L. Dunbar Internet Draft Futurewei Intended status: Informational Y. Wang Expires: December 24, 2026 China Telcom June 24, 2026 Deployment Scenarios and Gap Analysis for AI Agent Gateway draft-dunbar-dmsc-gw-scenarios-gap-analysis-00 Abstract This document examines deployment scenarios for AI agent collaboration and analyzes the circumstances under which AI Agent Gateway functions provide operational or interoperability benefits that cannot be achieved through direct agent-to-agent communication alone. The document considers both single-domain and multi-domain deployments, identifies specific challenges associated with each deployment model, evaluates the limitations of existing agent communication mechanisms (including MCP and A2A) with respect to those challenges, and demonstrates that gateway functions are necessary in deployments involving multiple tenants, multiple vendors, or multiple administrative domains. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." xxx, et al. Expires December 24, 2026 [Page 1] Internet-Draft GW Deployment Scenario The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 19, 2026 . Copyright Notice 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction..............................................3 2. Conventions and Definitions...............................4 3. Existing AI Agent Communication Ecosystem.................5 3.1. Model Context Protocol (MCP).........................5 3.2. Agent-to-Agent Communication (A2A)...................6 3.3. Agent Metadata and Capability Advertisement..........6 3.4. Observability and Operational Visibility.............7 3.5. Summary and Open Questions...........................7 4. Deployment Scenarios: Agent Collaboration in the UnionPay Ecosystem....................................................9 4.1. Scenario Overview....................................9 4.2. Single-Domain Agent Deployment.......................9 4.3. Multi-Vendor Intra-Domain Deployment................11 4.4. UnionPay Multi-Tenant Platform Deployment...........12 4.5. Cross-Organization Agent Collaboration..............13 4.6. Observations........................................15 Dunbar, et al. Expires Dec 24, 2026 [Page 2] Internet-Draft GW Deployment Scenario 5. Deployment Scenarios: Embodied AI Agent Collaboration in Telecom Operator Networks...................................15 5.1. Scenario Overview...................................16 5.2. Multi-Vendor Embodied Agent Collaboration within a Campus or Factory........................................16 5.3. Mobility-Driven Embodied Agent Collaboration across Cells and Edge Nodes.....................................17 5.4. Localized Authorization for High-Risk Physical Operations...............................................18 5.5. Cross-Organization, Cross-Domain Multi-Gateway Federation...............................................19 5.6. Observations........................................19 6. Analysis of AI Agent Gateway Functions...................20 6.1. Operational Onboarding and Reachability.............20 6.2. Capability Advertisement and Discovery..............20 6.3. Peer Agent Selection and Request Routing............22 6.4. Identity and Trust Establishment....................22 6.5. Policy Enforcement and Governance...................23 6.6. Observability and Operational Visibility............23 6.7. Gateway Synchronization and Information Exchange....24 6.8. Network-Aware Mobility and Reachability.............25 6.9. Action-Level Authorization for Physical-World Operations...............................................25 7. Gap Analysis.............................................26 7.1. Operational Management..............................26 7.2. Policy-Controlled Capability Exposure...............27 7.3. Multi-Tenant and Multi-Vendor Deployments...........27 7.4. Cross-Organization Collaboration....................28 7.5. Gateway Synchronization and Information Exchange....28 7.6. Mobility and Network Context Awareness..............29 7.7. Physical-World Action Authorization.................29 7.8. Summary.............................................30 8. Security Considerations..................................30 9. Manageability Considerations.............................30 10. IANA Considerations.....................................30 11. References..............................................30 11.1. Normative References...............................31 11.2. Informative References.............................31 12. Acknowledgments.........................................31 Appendix A:.................................................31 1. Introduction AI agents are increasingly deployed to collaborate across organizational boundaries - discovering peer agents, delegating tasks, and exchanging results to complete complex Dunbar, et al. Expires Dec 24, 2026 [Page 3] Internet-Draft GW Deployment Scenario business workflows. Existing protocols such as MCP [MCP] and A2A [A2A] address how agents communicate and describe their capabilities. They do not address whether agents are authorized to participate, which capabilities should be visible to which parties, or how interactions are governed and audited across organizations. [I-D.men-rtgwg-agent-networking-in-digibank] describes this challenge concretely in the context of digital banking. Use cases such as IPO bank statement auditing and retail credit processing require multiple specialized agents - operated by different banks, sponsor institutions, and regulators - to collaborate under strict authorization and audit requirements. In these environments, the absence of a governance layer is not a theoretical gap; it is an operational blocker. This document analyzes those use cases to identify where AI Agent Gateway functions are necessary and what gaps exist that may benefit from standardization. Section 3 evaluates existing mechanisms. Section 4 works through the deployment scenarios. Section 5 analyzes the required gateway functions. Section 6 presents the gap analysis. 2. Conventions and Definitions 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 following acronyms and terms are used in this document: AI Agent: A software entity that uses artificial intelligence techniques to interpret context, make decisions, and take actions toward achieving one or more goals, possibly by interacting with users and by invoking other agents, tools, or services. Agent Gateway (GW): An edge node that serves as an attachment anchor for agents within a provider-managed or Dunbar, et al. Expires Dec 24, 2026 [Page 4] Internet-Draft GW Deployment Scenario private network, providing operational onboarding, policy enforcement, capability exposure, routing, and observability functions. Attachment Context: The set of properties describing an agent's current network attachment (e.g., attachment point, domain, protocols). Directory Service: A service or registry enabling discovery of agents based on capabilities and returning associated metadata such as AgentIDs, endpoints, or Agent Cards. 3. Existing AI Agent Communication Ecosystem This section reviews the most relevant existing mechanisms for AI agent communication and capability advertisement, and explicitly identifies the deployment challenges they do not address. This analysis is essential for establishing why gateway functions are needed in the deployment scenarios described in Section 4. 3.1. Model Context Protocol (MCP) MCP [MCP] provides a standardized mechanism for connecting language-model applications with external tools, data sources, and contextual information. MCP enables tool access and integration between AI applications and supporting services. MCP does not address: o Large-scale agent discovery in dynamic environments o Inter-agent trust relationships across organizations o Operational governance, lifecycle management, or admission control o Policy enforcement across multiple tenants or administrative domains o Communications across organizational boundaries with audit requirements. Dunbar, et al. Expires Dec 24, 2026 [Page 5] Internet-Draft GW Deployment Scenario 3.2. Agent-to-Agent Communication (A2A) A2A [A2A] is an open protocol for communication and interoperability between independent agentic applications. A2A is hosted by the Linux Foundation and defines mechanisms for agent discovery via Agent Cards, capability advertisement, task delegation, and interaction negotiation. A2A provides important building blocks. However, A2A explicitly does not standardize the API for curated registries, and its discovery mechanisms vary by deployment. Specifically, A2A does not address the following deployment requirements: o Operational onboarding: A2A defines how an agent describes itself, but not whether an agent is approved to participate in a managed deployment, who owns it, what compliance checks it has undergone, or what lifecycle state it is in. o Policy-controlled visibility: A2A Agent Cards can be published at well-known URIs or in registries, but A2A does not define how to restrict which consumers can see which capabilities. An agent's capabilities are either public or require deployment-specific access control. o Consistent cross-vendor policy enforcement: A2A does not define how policies are enforced consistently across agents from different vendors or how policies are coordinated across administrative domains. o Cross-organization trust binding: A2A supports authentication, but does not define how requests are bound to organizational identities, business relationships, authorization context, or regulatory compliance records. 3.3. Agent Metadata and Capability Advertisement Agent metadata (including A2A Agent Cards) describes agent identity, endpoints, supported protocols, authentication requirements, and capabilities. Such metadata is foundational for agent discovery and selection. However, metadata alone is insufficient because: Dunbar, et al. Expires Dec 24, 2026 [Page 6] Internet-Draft GW Deployment Scenario o Sensitivity varies: Some capability information reveals internal business functions, operational topology, or available tools that should not be visible to all potential consumers. Publishing a complete Agent Card to all requesters is often inappropriate in enterprise or financial deployments. o Freshness is not guaranteed: Agent capabilities change as tools are updated, models are replaced, policies change, or tenants are created or deleted. No standard mechanism exists for invalidating or versioning Agent Cards across independently operated registries. o Authorization context is absent: An Agent Card describes what an agent can do, but does not describe who is authorized to invoke which capabilities under what conditions and for what business purpose. 3.4. Observability and Operational Visibility As agent deployments grow in complexity, operators require visibility into agent interactions for monitoring, troubleshooting, auditing, security analysis, and compliance. Importantly, operational visibility does not require access to encrypted communication content. Useful observability can be derived from non-content information: request metadata, routing events, authorization decisions, timing information, error codes, and audit records. Existing agent frameworks do not provide a standard mechanism for collecting, correlating, and exposing such non-content operational telemetry across agents from different vendors or across organizational boundaries. This gap is particularly significant in financial services environments subject to regulatory audit requirements. 3.5. Summary and Open Questions Existing agent communication mechanisms provide important foundations for AI agent ecosystems. MCP provides a mechanism for language-model applications to access external tools, services, and context. A2A provides a mechanism for independent agents to communicate, advertise capabilities, and collaborate on tasks. Agent metadata mechanisms, Dunbar, et al. Expires Dec 24, 2026 [Page 7] Internet-Draft GW Deployment Scenario including Agent Cards, provide a way to describe agents and their exposed capabilities. These mechanisms address important parts of the agent collaboration problem. In particular, they help answer questions such as how an AI application invokes a tool, how one agent communicates with another agent, and how an agent can describe its capabilities to potential clients. However, deployment scenarios introduce additional questions that may not be fully answered by the communication protocol alone. These questions become more significant as deployments scale from a small number of known agents to large, dynamic, multi-vendor, multi-tenant, or multi-domain environments. The following questions are particularly relevant to the analysis in this document: o How are agents discovered when the requesting agent does not already know the target agent or its Agent Card location? o How is capability information distributed, synchronized, and kept fresh across platforms, gateways, registries, or domains? o How can an operator verify that advertised capabilities, endpoints, and policies are authentic and current? o How should sensitive capability information be protected from unauthorized discovery? o How are local policies applied before an agent is exposed to other agents, tenants, organizations, or domains? o How are requests routed when agents move, scale dynamically, or are reachable only through managed infrastructure? o How can operators observe, audit, and troubleshoot agent- to-agent interactions without requiring agents to expose internal state? o Which of these functions are purely local deployment choices, and which require interoperable behavior between independently developed components? These questions do not imply that a dedicated AI Agent Gateway is required in every deployment. In a small single- domain environment, direct agent-to-agent communication and local configuration may be sufficient. In larger single- Dunbar, et al. Expires Dec 24, 2026 [Page 8] Internet-Draft GW Deployment Scenario domain deployments, gateway functions may provide operational value by centralizing policy enforcement, discovery, routing, and observability. In multi-domain deployments, gateway functions may also provide value by mediating capability exchange, reachability, trust establishment, and policy- controlled exposure across administrative boundaries. The following sections analyze deployment scenarios in which these questions arise and evaluate whether gateway functions may provide operational or interoperability benefits. 4. Deployment Scenarios: Agent Collaboration in the UnionPay Ecosystem This section uses the IPO Bank Statement Auditing scenario from [I-D.men-rtgwg-agent-networking-in-digibank] to analyze where Agent Gateway functions become necessary. This scenario is chosen because it spans multiple organizations, involves distributed data, requires verifiable regulatory authorization, and imposes cross-institution audit obligations. 4.1. Scenario Overview In an IPO auditing workflow, a Sponsor Institution must verify bank transaction records of the prospective listed company and its key personnel, which are dispersed across many member banks in the UnionPay network. With the company's authorization, the Sponsor Institution initiates requests through the UnionPay platform, which routes them to each bank and aggregates the results. In an agentic realization of this workflow, specialized agents - handling authorization, account discovery, statement retrieval, compliance review, and audit report generation - collaborate across organizational boundaries to complete the audit. Each agent type may be operated by a different organization or vendor. 4.2. Single-Domain Agent Deployment Within a single bank, capability advertisement and discovery - what A2A Agent Cards provide - answer questions such as what an agent can do, how it can be reached, and what authentication it requires. These are necessary but not sufficient for operational management. As the number of Dunbar, et al. Expires Dec 24, 2026 [Page 9] Internet-Draft GW Deployment Scenario agents grows across business units and vendors, a different set of questions arises: Is this agent approved to participate? Who owns it? Has it passed required security and compliance checks? Is it currently active or suspended? Which consumers are permitted to invoke it? What audit records are required for each invocation? These questions cannot be answered by an Agent Card. Consider what a bank must do before a Statement Retrieval Agent becomes available for use within its ecosystem: verify ownership, associate it with a responsible business unit, perform security and compliance review, determine which capabilities may be exposed and to which consumers, and define audit logging requirements. Subsequently, the agent may need to be suspended during maintenance, have its visibility restricted after a policy change, or be removed from service if abnormal behavior is detected. None of these actions are reflected in or triggered by capability metadata. Some operational state is also inappropriate to publish in an Agent Card at all, such as internal ownership, deployment location, compliance status, tenant association, risk classification, incident state, and policy bindings are useful to an administrator but must not be visible to all potential consumers. The gateway maintains this operational state separately from discoverable capability metadata, and controls what is exposed to whom. Dynamic deployment compounds this further. Agents are instantiated, upgraded, migrated, and retired over time. Their endpoints, health status, and policy bindings change. Without a managed control point tracking these lifecycle events and keeping operational state consistent, stale or unauthorized agents can remain reachable - a compliance and security risk in a regulated financial environment. The gateway addresses this by acting as the managed point for onboarding, admission control, lifecycle management, policy enforcement, health monitoring, and audit logging - without needing to inspect encrypted agent communication content. Even within a single domain, these functions are justified when the deployment contains many agents, multiple business units, sensitive capabilities, or regulatory compliance requirements. Dunbar, et al. Expires Dec 24, 2026 [Page 10] Internet-Draft GW Deployment Scenario 4.3. Multi-Vendor Intra-Domain Deployment A large bank participating in the UnionPay ecosystem may deploy agents developed by different vendors or attached to different internal systems, such as customer management, payment processing, account management, risk scoring, fraud detection, and compliance review systems. Although these agents may operate within a single administrative domain, they may use different agent frameworks, capability description formats, authentication methods, lifecycle management systems, or operational tools. Direct agent-to-agent communication may still be possible, but integration and management become more difficult as the number and diversity of agents increase. In this scenario, Agent Cards or similar metadata mechanisms can help describe individual agents and their exposed capabilities. However, capability descriptions alone do not ensure consistent operational onboarding, policy enforcement, access control, health monitoring, or audit logging across agents supplied by different vendors. For example, a compliance agent supplied by one vendor and a risk assessment agent supplied by another vendor may expose capability metadata in compatible formats, but the bank may still need a common way to validate ownership, associate each agent with internal policies, control which capabilities are exposed, monitor health state, and produce audit records across both systems. AI Agent Gateway functions may provide value by offering a common operational control point for heterogeneous agents. Such functions may normalize capability exposure, apply local policies, enforce access-control decisions, route requests to approved agents, collect non-content operational telemetry, and maintain lifecycle state across vendor-specific implementations. The gateway does not need to inspect encrypted agent-to-agent communication content. Instead, it can operate on policy- controlled metadata, routing events, authorization decisions, health information, lifecycle state, and audit records. Therefore, in a multi-vendor intra-domain deployment, the primary value of gateway functions is to reduce integration complexity and provide consistent operational governance Dunbar, et al. Expires Dec 24, 2026 [Page 11] Internet-Draft GW Deployment Scenario across heterogeneous agent systems, rather than to solve inter-domain interoperability. 4.4. UnionPay Multi-Tenant Platform Deployment UnionPay provides an interconnection platform used by many participating banks, payment institutions, merchants, service providers, and other authorized participants. In a future agentic service environment, the platform may need to support agents associated with different organizations, business roles, and tenants. For example, a participating bank may operate account inquiry agents, statement retrieval agents, credit assessment agents, or compliance agents. UnionPay may operate platform-level agents for routing, settlement support, risk monitoring, or service coordination. Sponsor institutions, auditors, merchants, or other authorized parties may operate agents that request services from the platform or from participating banks. In this deployment model, the key challenge is not only whether agents can communicate. The platform also needs to control which agents are allowed to participate, which capabilities are visible to which tenants, and which requests are permitted under applicable business rules, authorization status, and regulatory constraints. Agent Cards and similar metadata mechanisms can describe individual agents and their capabilities. However, in a multi-tenant platform, capability metadata may need to be filtered or exposed differently depending on the requesting party. For example, an auditing agent may be allowed to discover a bank's statement retrieval capability after proper authorization, while a merchant agent or unrelated tenant should not see or invoke the same capability. AI Agent Gateway functions may provide value by supporting policy-controlled capability exposure, tenant isolation, request routing, authorization enforcement, health monitoring, lifecycle management, and audit logging. These functions can help the platform expose agent capabilities in a controlled manner without requiring every agent to directly understand the policies, trust relationships, and visibility rules for every tenant. Dunbar, et al. Expires Dec 24, 2026 [Page 12] Internet-Draft GW Deployment Scenario Operational onboarding is also important in this scenario. Before an agent becomes available through the UnionPay platform, the platform may need to verify the agent's owning organization, associate the agent with a tenant or business role, validate required security and compliance attributes, and bind the agent to policies that determine how its capabilities may be exposed or invoked. The gateway does not need to inspect encrypted agent-to-agent communication content. Instead, it can operate on policy- controlled metadata, routing events, authorization decisions, health information, lifecycle state, tenant context, and audit records. Therefore, in a UnionPay multi-tenant platform deployment, the primary value of AI Agent Gateway functions is to provide controlled exposure, tenant isolation, policy enforcement, and operational governance across agents operated by different participants in a shared platform environment. 4.5. Cross-Organization Agent Collaboration Cross-organization agent collaboration occurs when agents operated by different organizations need to participate in a shared business process. In the UnionPay ecosystem, this may involve UnionPay, participating banks, sponsor institutions, auditors, merchants, payment institutions, or other authorized service providers. The IPO bank statement auditing scenario provides a representative example. A sponsor institution or auditor may operate an auditing agent that needs to request transaction records from multiple banks through the UnionPay ecosystem. Each bank may operate its own account inquiry agents, statement retrieval agents, authorization agents, and compliance agents. UnionPay may provide platform-level functions for routing, policy coordination, authorization verification, or service orchestration. In this deployment model, each organization remains responsible for its own agents, security policies, operational practices, and compliance obligations. Direct agent-to-agent communication across organizations may be possible in some cases, but it introduces questions that are less visible in a single-domain deployment. For example, an agent in one organization may need to determine which Dunbar, et al. Expires Dec 24, 2026 [Page 13] Internet-Draft GW Deployment Scenario external agents are authorized to receive requests, which capabilities may be exposed to a particular counterparty, whether the requesting party has valid authorization, and how audit records should be produced across organizational boundaries. Agent Cards or similar metadata mechanisms can describe the capabilities and endpoints of external agents. However, cross-organization collaboration also requires policy- controlled exposure of that information. A bank may not want all of its internal agents or capabilities to be visible to every external party. Instead, it may expose only selected capabilities to UnionPay, to specific sponsor institutions, or to authorized auditors under defined business agreements and user consent. AI Agent Gateway functions may provide value by mediating this controlled exposure. A gateway can help determine which capability information is visible to which external parties, validate requests against local policy, route authorized requests to internal agents, and maintain audit records for compliance and dispute resolution. This allows each organization to retain local control while enabling collaboration with other organizations. Trust establishment is another important consideration. In a cross-organization deployment, one organization may not directly know or trust every external agent. Gateway functions may help bind agent interactions to organizational identities, business relationships, authorization context, and applicable policy. For example, a bank may accept requests from a UnionPay-mediated auditing workflow only when the request is associated with a recognized sponsor institution, a valid authorization, and an approved business purpose. The gateway does not need to inspect encrypted agent-to-agent communication content. Instead, it can operate on policy- controlled metadata, routing events, authorization decisions, organizational identity information, lifecycle state, and audit records. This distinction is important because financial agent communications may contain sensitive personal, corporate, or transaction data that should remain protected. Dunbar, et al. Expires Dec 24, 2026 [Page 14] Internet-Draft GW Deployment Scenario Therefore, in cross-organization agent collaboration, the primary value of AI Agent Gateway functions is to support controlled capability exposure, trust establishment, policy enforcement, request routing, and auditability across organizational boundaries. This scenario provides a stronger interoperability motivation than purely single-domain deployment because independently operated systems may need common mechanisms to exchange metadata, express policy constraints, validate counterparties, and coordinate authorized agent interactions.. 4.6. Observations The UnionPay ecosystem demonstrates that AI Agent Gateway functions may provide value across multiple deployment models. Within a single administrative domain, gateway functions primarily address operational management, governance, policy enforcement, and observability. Across multiple organizations, gateway functions may additionally support capability discovery, trust establishment, controlled exposure of services, and interoperability among independently operated agent systems. These observations do not imply that a dedicated gateway is required in every deployment. Rather, they suggest that gateway functions become increasingly valuable as deployments grow in scale, involve multiple vendors, support multiple tenants, or span organizational boundaries. 5. Deployment Scenarios: Embodied AI Agent Collaboration in Telecom Operator Networks This section identifies scenario where Agent Gateway functions become necessary as telecom operator networks support large-scale access by embodied AI Agents. This scenario is chosen because it isolate the properties that distinguish embodied agents from data-handling agents - direct physical-world consequence and continuous network-side mobility - while also covering the progression from a single administrative domain to collaboration across organizations and operator networks: multi-vendor device collaboration Dunbar, et al. Expires Dec 24, 2026 [Page 15] Internet-Draft GW Deployment Scenario within a campus or enterprise site, mobility-driven collaboration across cells and edge nodes, authorization for high-risk physical operations, and cross-domain gateway federation. 5.1. Scenario Overview A telecom operator's private network and edge computing infrastructure increasingly serve as the connectivity and management substrate for embodied AI Agents deployed by an enterprise customer - robots, AGVs, robotic arms, and inspection drones performing physical tasks at a factory, campus, or comparable site. These agents are supplied by multiple equipment vendors, move within and beyond the boundaries of the site as their tasks require, and in some cases must hand off responsibility to agents operated by a different organization, potentially attached to a different operator's network. In an agentic realization of this deployment, specialized agents - handling device onboarding, task dispatch and capability discovery, mobility and reachability tracking, action-level authorization, and cross-organization handoff - collaborate within and across administrative boundaries to complete physical-world tasks. Each agent type may be supplied by a different vendor, operated by a different business unit, or owned by a different enterprise. 5.2. Multi-Vendor Embodied Agent Collaboration within a Campus or Factory In a smart factory, port, or comparable enterprise site, robots, AGVs, robotic arms, and cameras are typically supplied by different vendors but attach to the same operator-provided private network (5G private network or edge cloud). Each device may expose capability metadata through a mechanism such as an A2A Agent Card, describing what it can do, how it can be reached, and what authentication it requires. This does not answer the questions an operating site actually needs answered: who owns this device, has it passed admission review, is it currently active, which requesting agents are permitted to invoke it, and what record must be kept of each invocation. These questions are independent of which vendor supplied the device; they are state that the operator's private network, as the common point of attachment, must maintain regardless of vendor. Dunbar, et al. Expires Dec 24, 2026 [Page 16] Internet-Draft GW Deployment Scenario Beyond this, devices from different vendors do not natively understand each other's protocols, identity models, or capability formats. Without a common mediation layer, integration cost recurs with every new device class added to the site. AI agent gateway is well positioned to serve as the attachment anchor for this heterogeneous device population, since every device, irrespective of vendor, ultimately attaches through the same gateway-mediated point in network. AI Agent Gateway functions may provide value in this scenario by performing device onboarding and identity binding independent of vendor-specific implementation, normalizing heterogeneous capability descriptions into a common representation, enforcing site-level access policy uniformly across vendors, and maintaining a single lifecycle and audit record across an otherwise fragmented device population. This allows cross-vendor collaboration to be governed at the network layer rather than requiring each pair of agents to separately negotiate trust and capability exposure. 5.3. Mobility-Driven Embodied Agent Collaboration across Cells and Edge Nodes Delivery robot fleets and inspection drones are not fixed to a single site; they move continuously across a city, crossing cell coverage areas, edge nodes, and potentially network slice domains. Their location, attachment point, available edge compute, and connectivity quality change over time in a way that agents running in a fixed data-center deployment never encounter. An Agent Card can describe what an agent is capable of, but not where it currently is, which edge node it is attached to, or whether current network conditions meet a task's latency requirement - information that determines whether the agent is even a viable candidate for a given task at a given moment. This scenario most directly demonstrates a capability specific to the telecom network: location, slice-level service guarantees, and edge resource availability are information that originates natively within the operator's network and cannot be obtained through any agent-to-agent protocol alone. AI Agent Gateway functions may provide value in this scenario by maintaining each agent's current reachability, attachment point, and edge association as it moves; combining this mobility state with slice or QoS context to determine which Dunbar, et al. Expires Dec 24, 2026 [Page 17] Internet-Draft GW Deployment Scenario agents currently satisfy a task's network requirements; supporting session continuity and task handoff as an agent's underlying network attachment changes; and using this combined network and capability context to drive agent selection and request routing. None of these functions can be derived from capability metadata alone, since they depend on information that resides in the network rather than in the agent. 5.4. Localized Authorization for High-Risk Physical Operations A robotic arm performing a task, a drone entering a restricted flight zone, a vehicle changing its planned route these operations have consequences in the physical world; they are not ordinary API invocations. Whether such an operation may proceed depends on conditions that an Agent Card cannot express: whether the current location falls within an authorized zone, whether the operation falls within an approved time window, whether human supervisory approval has been obtained, whether the current risk level permits the action, and whether the action complies with applicable site or industry regulatory requirements. This implies that "whether two agents may communicate" and "whether a specific action may be executed" are distinct levels of trust decision, and the latter requires a finer- grained, more dynamic authorization mechanism, bound to both identity and compliance status and to controlled capability exposure. AI Agent Gateway functions may provide value in this scenario by evaluating each high-risk action request individually rather than authorizing communication once at the session level; binding action-level decisions to current location, time window, risk classification, and any required human approval state; restricting visibility of high-risk capabilities to requesters that meet defined authorization criteria; and recording an auditable decision trail for every executed or denied action. This draws an explicit separation between communication-layer trust and action-layer trust, a distinction not yet systematically addressed in existing treatments of agent interoperability. Dunbar, et al. Expires Dec 24, 2026 [Page 18] Internet-Draft GW Deployment Scenario 5.5. Cross-Organization, Cross-Domain Multi-Gateway Federation In smart-port operations, cross-city logistics, and joint emergency dispatch, the scope of embodied agent collaboration extends beyond a single enterprise or a single operator's network. Cargo handled within a port may be transferred to a fleet operated by a separate logistics enterprise, potentially attached to a different operator's network; a cross-region emergency response may require equipment under different government agencies and different operator jurisdictions to form a collaborative relationship on short notice. In these cases, no single gateway can enforce policy beyond its own domain, and no single gateway can cover the full collaboration chain alone. This is the only one of the four scenarios that genuinely requires a gateway-to-gateway protocol: one domain's gateway must convey identity, capability, reachability, authorization, and audit information to another domain's gateway, rather than reaching across to directly manage agents inside a domain it does not control. AI Agent Gateway functions may provide value in this scenario by exchanging selective identity, capability, and reachability information with a peer gateway in another domain; validating inbound requests against locally defined trust relationships and business agreements rather than against the requesting agent's own claims; mediating controlled, counterparty-specific exposure of capabilities and operational state across the domain boundary; and maintaining an audit record that spans the handoff even though each domain's internal agent activity remains independently governed. These functions depend on coordination between gateways rather than on the policy of any single administrative entity. 5.6. Observations Across these four scenarios, embodied agents introduce two requirements not well addressed in deployments built around stationary, software-only agents: action-level authorization for requests with direct physical-world consequences, and network-aware reachability management as agents move across coverage areas and edge nodes. A general specification of Agent Gateway functions should account for both, in addition to the cross-organization trust and operational governance requirements already established for non-embodied scenarios. Dunbar, et al. Expires Dec 24, 2026 [Page 19] Internet-Draft GW Deployment Scenario 6. Analysis of AI Agent Gateway Functions The deployment scenarios in Section 4 establish that gateway functions are necessary in large-scale, multi-tenant, and cross-organization environments. This section analyzes the specific gateway functions required and describes what each must provide. 6.1. Operational Onboarding and Reachability Operational onboarding is the process by which an agent is admitted into a managed deployment. This is distinct from publishing an Agent Card. Onboarding establishes: o Ownership: which organization and business unit is accountable for the agent o Compliance status: whether the agent has undergone required security and compliance review o Lifecycle state: whether the agent is approved, active, suspended, or retired o Policy bindings: which policies govern how the agent may be invoked and by whom o Audit requirements: what records must be produced for each invocation Reachability management is the ongoing function of tracking whether an onboarded agent is currently available, what its current endpoint is, and whether it is operating within expected parameters. As agents are dynamically instantiated, scaled, migrated, or retired, reachability information must be kept current and consistent across the gateway functions that depend on it. 6.2. Capability Advertisement and Discovery [I-D.men-rtgwg-agent-networking-in-digibank] characterizes the Agent Gateway's role along three dimensions that are directly relevant to capability advertisement and discovery: o Communication hub for intelligent collaboration: the gateway facilitates coordinated work among multiple agents by implementing unified communication protocols Dunbar, et al. Expires Dec 24, 2026 [Page 20] Internet-Draft GW Deployment Scenario and context management, ensuring different agents can execute complex business processes in an orderly and efficient manner. o Foundation for security and compliance: functioning as a centralized access control node, the gateway authenticates identities, checks permissions, and audits operations for all agents, ensuring every action complies with financial regulatory requirements. o Simplification and adaptation layer: the gateway encapsulates intricate APIs, data sources, and business systems into standardized services, allowing agents to invoke required functions without needing to understand backend technical details, thereby significantly reducing integration complexity. These three roles map directly onto the capability advertisement and discovery function. The gateway does not merely publish what agents can do (the Agent Card function). It controls who can discover those capabilities (security and compliance role), routes discovery queries to the appropriate agents (communication hub role), and normalizes capability descriptions across heterogeneous vendor implementations (simplification layer role). Gateways extend the capability advertisement function of A2A Agent Cards by providing policy-controlled discovery. Rather than publishing capabilities to all requesters uniformly, a gateway filters the set of advertised capabilities based on the identity, authorization context, and business relationship of the requesting party. This controlled exposure is essential in financial deployments where some capabilities are public, others restricted to specific business partners, and others available only under specific regulatory authorizations. In deployments where the underlying agents control physical equipment, this normalization extends beyond software API surfaces to vendor-specific device control and telemetry interfaces, which is the primary integration burden in the multi-vendor campus scenario in Section 5.2. Dunbar, et al. Expires Dec 24, 2026 [Page 21] Internet-Draft GW Deployment Scenario 6.3. Peer Agent Selection and Request Routing When multiple agents advertise compatible capabilities, a requesting agent must select an appropriate peer and route the request. In the UnionPay ecosystem, this selection may depend on: o Authorization context: the request must be routed to an agent whose owning organization is authorized to provide the requested information under the applicable authorization. o Business relationship: the selected agent must be associated with the correct counterparty institution. o Operational health: the selected agent must be in active lifecycle state and currently reachable. o Tenant boundary: in multi-tenant deployments, the request must be routed within the correct tenant scope. This function is substantially more complex than what A2A peer discovery provides. A2A can locate agents that match capability criteria, but does not have visibility into authorization context, business relationships, or operational health state. The gateway, having onboarded and monitored agents, has the necessary context for policy-aware routing. 6.4. Identity and Trust Establishment In cross-organization deployments, trust cannot be established by authentication alone. The gateway function for trust establishment must bind agent interactions to: o Agent identity: cryptographic verification of the agent's identity. o Organizational identity: verification that the agent is operated by the claimed organization. o Authorization context: verification that the specific request is covered by a valid authorization (e.g., a court order, regulatory mandate, or business agreement). o Policy compliance: verification that the request complies with local policies and applicable regulations. This binding is the core differentiator between A2A communication and gateway-mediated communication in regulated financial environments. An agent communicating via A2A can Dunbar, et al. Expires Dec 24, 2026 [Page 22] Internet-Draft GW Deployment Scenario authenticate itself but cannot present organizational authorization context in a standardized, machine-verifiable form. The gateway provides the trust infrastructure that makes organizational authorization context a first-class element of agent interactions. For embodied agents, agent identity verification may additionally need to bind to the identity of the underlying physical device, since admission and trust decisions are made at the device level rather than only at the software-agent level. 6.5. Policy Enforcement and Governance Policy enforcement is the function of evaluating whether a request is permitted before it is routed to the target agent. Policy enforcement may consider: o Access control: is the requesting agent permitted to invoke this capability? o Tenant isolation: does the request cross a tenant boundary that is not permitted? o Rate limits and quotas: has the requesting agent or organization exceeded its allowed invocation rate? o Business rules: does the request comply with applicable business agreements? o Safety policy: does the request comply with site-level safety constraints that must be enforced uniformly regardless of which vendor's equipment is involved. o Regulatory constraints: does the request comply with applicable data handling regulations? Centralizing policy enforcement in the gateway significantly simplifies the requirements placed on individual agents. Rather than requiring each agent to implement the full policy set for every possible counterparty, the gateway provides a common enforcement point. This is particularly important in multi-vendor environments where agents may be unable to interoperate on policy models. 6.6. Observability and Operational Visibility The gateway collects non-content operational telemetry as a natural byproduct of its other functions: routing events, Dunbar, et al. Expires Dec 24, 2026 [Page 23] Internet-Draft GW Deployment Scenario authorization decisions, health checks, lifecycle state transitions, and audit records are all available to the gateway without requiring inspection of encrypted agent communications. In the UnionPay context, this observability function must support: o Regulatory audits: producing records demonstrating that data accesses were authorized, compliant, and traceable o Operational troubleshooting: identifying which agent or gateway function caused a failure in a multi-step workflow o Anomaly detection: identifying unusual patterns in request rates, capability invocations, or routing decisions that may indicate security incidents o Cross-tenant separation: ensuring that observability records for different tenants are separated and accessible only to authorized parties. 6.7. Gateway Synchronization and Information Exchange In multi-domain deployments - such as the cross-organization collaboration scenario in Section 4.5 - multiple gateways must cooperate. Each bank may operate its own gateway, and UnionPay may operate a platform-level gateway. For the IPO auditing workflow to function, these gateways must be able to: o Exchange capability metadata: the UnionPay gateway must know which statement retrieval capabilities are available at each bank gateway, subject to the bank's visibility policies. o Propagate reachability updates: if a bank agent is suspended or its endpoint changes, other gateways must be notified. o Coordinate authorization context: when an auditing request carries a valid authorization, this authorization context must be conveyed to the receiving gateway in a verifiable form. o Produce correlated audit records: the audit trail for a cross-organization request must span gateways while maintaining chain of custody. Dunbar, et al. Expires Dec 24, 2026 [Page 24] Internet-Draft GW Deployment Scenario No existing standard addresses gateway-to-gateway information exchange for agent ecosystems. This represents the most significant interoperability gap identified in this document and is a strong candidate for standardization work. 6.8. Network-Aware Mobility and Reachability In addition to operational onboarding function, for embodied agents that move across cell coverage areas, edge nodes, and network slice domains, to select and route to a mobile agent it additionally requires network-side context: o Location and attachment context: the agent's current geographic position, the cell or access point it is attached to, and the edge computing node currently serving it. o Network quality context: current latency, bandwidth, and reliability characteristics of the agent's active connection, including any applicable network slice or QoS guarantee. o Continuity context: whether an in-progress task or session can be maintained as the agent's underlying network attachment changes, and what handoff is required if it cannot. This information originates within the telecom network itself rather than within the agent, and therefore cannot be obtained through capability advertisement alone. A gateway function that maintains this context, in addition to the lifecycle and ownership state established at onboarding, can determine not only whether a candidate agent is reachable, but whether it is currently the most suitable candidate for a given task under present network conditions. This function has no close counterpart in deployments where agents remain at a fixed network location. 6.9. Action-Level Authorization for Physical-World Operations The trust establishment function binds an agent interaction to verified agent identity, organizational identity, authorization context, and policy compliance. For embodied agents whose invocations produce direct physical-world effects, a request that is properly authenticated and authorized to be sent may still need to be evaluated again, Dunbar, et al. Expires Dec 24, 2026 [Page 25] Internet-Draft GW Deployment Scenario individually, before the physical action it requests is permitted to execute. Action-level authorization may consider: o Spatial constraints: whether the requested action falls within a zone the requesting agent or operation is currently authorized to operate in. o Temporal constraints: whether the action falls within an approved time window. o Human approval state: whether supervisory approval has been obtained where required. o Risk classification: whether the current risk level associated with the action and its context permits execution without additional review. This represents a second authorization layer beneath the session- or request-level trust established in Section 6.4: communication-level trust determines whether an agent may participate in an exchange at all, while action-level authorization determines whether a specific instruction within that exchange may take effect in the physical world. Treating these as a single undifferentiated authorization decision is insufficient once agent invocations carry physical consequences. 7. Gap Analysis Section 3.5 established that existing mechanisms (MCP, A2A, Agent Cards) do not address several key deployment requirements. Sections 4 and 5 demonstrated, through concrete scenarios, that these gaps result in real operational and interoperability problems. This section consolidates the gap analysis and identifies which gaps are candidates for standardization. 7.1. Operational Management Operational management encompasses agent onboarding, lifecycle management, health monitoring, capability exposure control, audit logging, and compliance reporting. These functions are currently left to deployment-specific implementations. Dunbar, et al. Expires Dec 24, 2026 [Page 26] Internet-Draft GW Deployment Scenario The gap: there is no standard model for representing agent lifecycle state, ownership, compliance status, policy bindings, physical location, maintenance state, safety certification, or operational health in a form that is interoperable across agent platforms, vendors, and administrative domains. When agents from different vendors are deployed in the same managed environment, each vendor's agent management model must be translated to the others' models, creating integration complexity that scales poorly. Standardization candidate: a common information model for agent operational state that is sufficient to support admission control, lifecycle management, health monitoring, and audit logging across heterogeneous implementations.. 7.2. Policy-Controlled Capability Exposure Agent Cards and metadata mechanisms describe what an agent can do but do not describe who is allowed to discover or invoke those capabilities under what conditions. The gap: there is no standard mechanism for expressing, distributing, and enforcing capability visibility policies. In multi-tenant and cross-organization deployments, each pair of interacting parties must implement ad-hoc access control for capability discovery, which prevents scalable agent ecosystem development. Standardization candidate: a standard mechanism for policy- controlled capability exposure, including a way for an agent or gateway to express visibility constraints on its capabilities and for a requesting gateway to apply those constraints consistently. 7.3. Multi-Tenant and Multi-Vendor Deployments The gap: there is no standard approach for tenant-aware agent discovery, routing, and policy enforcement. Each multi-tenant platform must implement its own tenant isolation model, making it difficult for agents or gateways from different vendors to interoperate in a shared multi-tenant environment. Dunbar, et al. Expires Dec 24, 2026 [Page 27] Internet-Draft GW Deployment Scenario Standardization candidate: a common model for tenant context in agent interactions, including how tenant identity is expressed in capability queries, routing decisions, and policy enforcement. 7.4. Cross-Organization Collaboration The gap: there is no standard mechanism for binding agent interactions to organizational identity, authorization context, and business relationships in a form that is machine-verifiable, cross-jurisdiction compliant, and auditable. This gap is the principal barrier to scalable cross-organization agent collaboration in regulated industries. The consequences of this gap are significant: without standard trust binding mechanisms, each pair of collaborating organizations must establish custom integration, negotiate custom audit record formats, and implement custom authorization verification. In the UnionPay ecosystem, which has thousands of participating institutions, this approach is not scalable. Standardization candidate: a standard mechanism for organizational trust context in agent interactions, including representation of organizational identity, authorization context, and applicable business relationships. This is the highest-priority standardization candidate identified in this document. 7.5. Gateway Synchronization and Information Exchange The gap: there is no standard mechanism for gateway-to- gateway exchange of capability metadata, reachability information, authorization context, or audit records. When independently operated gateways need to cooperate - as in the cross-organization IPO auditing scenario - each deployment must implement custom integration. Standardization candidate: a standard protocol for gateway- to-gateway information exchange, including at minimum: capability metadata distribution with policy-controlled visibility, reachability update propagation, authorization context conveyance, and correlated audit record production. Dunbar, et al. Expires Dec 24, 2026 [Page 28] Internet-Draft GW Deployment Scenario 7.6. Mobility and Network Context Awareness The deployment scenario of mobility-driven embodied agent collaboration demonstrated that selecting and routing requests to a mobile embodied agent depends on location, attachment, and network-quality information that originates within the operator's network rather than within the agent. The gap: there is no standard mechanism for representing or exchanging an agent's current network attachment context, such as location, edge association, connectivity quality, and applicable slice or QoS state, in a form gateway functions can consistently use for agent selection, routing, and session continuity. Existing capability metadata mechanisms describe what an agent can do, not where it currently is or under what network conditions it is reachable. Standardization candidate: a common representation for an agent's dynamic network context, sufficient to support mobility-aware reachability tracking, agent selection, and task continuity as agents move across coverage areas, edge nodes, and network domains. 7.7. Physical-World Action Authorization The deployment scenario of localized authorization for high- risk physical operations demonstrated that, for embodied agents, communication-level trust establishment is not sufficient to govern requests whose execution produces direct physical-world consequences The gap: there is no standard mechanism for expressing or evaluating action-level authorization conditions, such as spatial constraints, time windows, human approval state, and risk classification, separately from the communication-level trust established for the requesting agent. Without such a mechanism, a request that is properly authenticated and authorized to be sent may still execute a physical action that the current context does not support. Standardization candidate: a standard model for action-level authorization, distinct from session- or request-level trust, that allows a gateway to evaluate a specific physical-world Dunbar, et al. Expires Dec 24, 2026 [Page 29] Internet-Draft GW Deployment Scenario action against current spatial, temporal, approval, and risk conditions before permitting it to proceed. 7.8. Summary The analysis in this section does not conclude that AI Agent Gateways are required in all deployments. Small-scale deployments may operate successfully using direct agent-to- agent communication, Agent Cards, local configuration, or existing discovery mechanisms. However, as deployments become larger, involve multiple vendors or tenants, require stronger operational governance, or span organizational boundaries, additional gateway functions may provide value. Potential gaps include operational onboarding, lifecycle and health-state management, policy-controlled capability exposure, tenant- aware discovery, trust coordination, auditability, and gateway-to-gateway information exchange, network and mobility context, and physical-world action authorization. These gaps are most visible in managed deployments where independently developed agents, platforms, catalogs, or gateways need to exchange operational information or apply consistent policy behavior across deployment boundaries.. 8. Security Considerations TBD. 9. Manageability Considerations TBD 10. IANA Considerations TBD 11. References Dunbar, et al. Expires Dec 24, 2026 [Page 30] Internet-Draft GW Deployment Scenario 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [MCP] Model Context Protocol, "Model Context Protocol Specification", https://modelcontextprotocol.io/specification/ [A2A] Agent2Agent Protocol, "Agent2Agent Protocol Documentation", https://a2a-protocol.org/. 12. Acknowledgments Acknowledgements to xxx for their extensive review and suggestions. This document was prepared using 2-Word-v2.0.template.dot. Appendix A: Authors' Addresses Linda Dunbar Futurewei Email: ldunbar@futurewei.com YiFei Wang China Telecom wangyf85@chinatelecom.cn Contributors' Addresses Dunbar, et al. Expires Dec 24, 2026 [Page 31]