Architecture

A high-level view of where Agent Gateway sits, how traffic flows through it, and how it helps you govern agent interactions.

The Agent Gateway sits between your agents and the services they need to reach. It gives you one place to apply identity, access control, trust, observability, and payment policies across agent traffic, without rebuilding those controls in every application. Reference →

Agent gateway architecture

Where the gateway sits

At a high level, Agent Gateway acts as a control layer between:

  • your agents, applications, and automations.
  • the tools, APIs, models, and partner systems they call.
  • the policies and controls your organisation needs to enforce.

Instead of embedding security and governance logic into each client or backend, you centralise those responsibilities in the gateway.

Architecture layers

For most customers, the architecture is easiest to understand in four layers:

Entry layerExposes network endpoints. Multiple traffic types share the same deployment while remaining separately governed.
Control layerAuthenticates callers, applies security and business rules, and enforces identity, policy, rate limits, trust checks, and payment rules.
Routing layerForwards approved requests to the correct internal service, tool endpoint, or remote gateway, keeping routing decisions consistent and observable.
Operations layerCentralises configuration, credential rotation, traffic observation, and behaviour updates without requiring changes to individual clients or services.

Protocol support

Agent Gateway is designed for modern agent and machine-to-machine traffic. Depending on your use case, it can sit in front of:

  • A2A workloads.
  • MCP tool access.
  • Payment-aware agent traffic.
  • Standard HTTP services and APIs.

This means you can apply a common governance model even when different teams or partners use different protocols.

Request lifecycle

When a request enters the gateway, the customer-level flow is straightforward:

Receive the request

The gateway accepts traffic from an agent, application, partner system, or operator-facing tool.

Verify identity and permissions

The gateway checks who is calling, what they are allowed to do, and whether any protocol-specific requirements must be met.

Apply policy and controls

The gateway evaluates security, access, trust, rate-limit, and payment rules before a request is allowed through.

Forward to the destination

If the request is approved, the gateway sends it to the correct destination, such as an internal service, external API, model endpoint, or partner gateway.

Record what happened

The gateway emits logs, metrics, and traces so operators can understand request behaviour, failures, and policy outcomes.

This makes the gateway useful not only as a routing layer, but as an enforcement and observability layer.

Inbound and outbound control

Agent Gateway handles both directions of traffic:

  • Inbound traffic: requests coming into a protected agent or service through the gateway.
  • Outbound traffic: requests a managed agent makes to tools, APIs, models, or external systems.

This matters because organisations often need different controls depending on direction. For example, you may want to authenticate external callers on the way in, while applying identity propagation, partner trust rules, or cost controls on the way out.

Direct service connectivity

Some deployments use Agent Gateway primarily to protect agent-to-agent interactions. Others use it to expose direct integrations to tools, APIs, or model providers. In both cases, the value is the same: traffic passes through a consistent control point before it reaches the destination.

That lets you:

  • expose internal capabilities safely.
  • standardise how external services are reached.
  • centralise credential handling and policy enforcement.
  • make agent interactions easier to audit and operate.

Gateway federation

For cross-organisation or cross-network scenarios, multiple Agent Gateway instances can connect to each other. This allows agent traffic to move across organisational boundaries without requiring every backend system to be exposed directly.

Federation is useful when:

  • different teams or companies need to connect agents securely.
  • services live in separate networks or cloud environments.
  • you want a governed path between parties rather than direct point-to-point integration.

In those cases, the gateway acts as both a local enforcement point and a trusted handoff point to another gateway.

See Gateways for the connection model and operational setup.

Operations and configuration

From an operator perspective, the architecture is designed so teams can manage behaviour centrally instead of changing every client and service individually.

In practice, that means you can:

  • Define who can call what.
  • Control how agents identify themselves.
  • Route traffic to the correct internal or external destination.
  • Collect telemetry for compliance and troubleshooting.
  • Update gateway behaviour as integrations and policies evolve.

For field-level configuration details, use the Reference.

What this means for business

At a business level, Agent Gateway gives you a repeatable architecture for governed AI interactions. Instead of treating each agent or integration as a special case, you can adopt one control point that makes access, trust, routing, and observability consistent across the estate.

That is especially valuable when you are:

  • scaling from isolated pilots to shared platforms.
  • connecting multiple teams or partner organisations.
  • enforcing policy without rewriting every workload.
  • preparing for more autonomous agent ecosystems over time.
  • Reference: Field-level configuration details for deploying and operating the gateway.
  • Surfaces: The routing model used to represent and govern managed agents.