agentgateway: one gateway for LLM, MCP and A2A agent traffic

The microservices era got the API gateway; what does the agent era get? Outbound agent traffic comes in three flavors — LLM API calls, MCP tool servers, and A2A messages between agents — each with its own auth scheme and failure modes, each hand-rolled inside every application. agentgateway is a Linux Foundation open-source (Apache-2.0) project that funnels all three into one gateway built as a Rust control plane over an Envoy data plane: applications connect only to the gateway, and authentication, rate limiting, retries and audit policies live in one place, with session affinity for A2A traffic. The project states its ambition plainly — to be the Nginx of the agent era. Created March 2025, last pushed October 28, 2026, with v1.7.0 released October 27, the repo sits at 5,745 stars, and agentgateway.dev offers a hosted control plane.

Core features

• Three protocols, one door: LLM traffic gets per-provider upstream auth and key rotation; MCP backends aggregate into a single MCP endpoint; A2A traffic routes by agent name with sticky sessions. Applications speak the protocols — the gateway handles retries and credentials.
• Policy as configuration: auth (JWT/OAuth/API key), RBAC, per-consumer rate limits and request rewrites are declared centrally in the control plane and enforced in the data plane; for MCP, authorization goes down to individual tool names and methods.
• Observability before outages: every tool call, model call and agent-to-agent message emits structured logs and metrics via OpenTelemetry — tracing “which tool did the agent call and what did it cost” no longer means grepping app logs.
• Two deployment shapes: a single static binary for local development and sidecars, or a Kubernetes Gateway API implementation for production; the docs walk from Docker Compose to multi-cluster.

Typical use cases

• Enterprise guardrails for agent traffic: security teams can govern which models and MCP tools agents may touch without touching each agent application — the gateway layer’s job.
• Shared LLM budgets across teams: per-consumer rate limits and usage metrics land at the gateway instead of being re-implemented per team.
• MCP tool aggregation: wrap internal databases, search and APIs as MCP servers, then expose them to the whole organization’s agents through one controlled endpoint with permissions in one place. Compared with a homegrown MCP proxy, the gateway also carries per-tenant quotas and audit trails.

Quick start

# Single-binary start (v1.7.0; official Docker images also available)
curl -LO https://github.com/agentgateway/agentgateway/releases/latest

The repo’s examples/ directory ships complete configs for MCP aggregation, A2A routing and JWT auth, and the agentgrid console (the source of the UI screenshot above) renders topology and health in a browser. The migration path is spelled out too: existing Envoy configuration can be introduced gradually rather than switched in one step, and the docs carry a section on the minimal diff to move from raw LLM SDK calls to gateway-managed traffic.

For a feel of what the three protocols look like at the application layer, see our coverage of agentplay, which maps local Coding Agent sessions including their A2A-shaped exchanges, and pipecat, a real-time voice agent framework whose outbound LLM traffic is exactly what a gateway layer like this governs.

Summary

agentgateway fits platform teams that need governance over AI agent traffic: three protocols behind one door, centralized policy, solid observability, and the backing of the Linux Foundation and the Envoy community — arguably the most complete open-source implementation in this brand-new “agent infrastructure” category. Three honest caveats: the repo is young (March 2025, rapid iteration only through 2026), so production references skew to early adopters; the Rust data plane is a black box for most teams, and deep debugging depends on the community; and versus rolling your own Envoy/Istio config, it saves you the glue layer that translates agent protocols into gateway config — not the gateway itself. If you want a reverse proxy for hosting MCP servers, see our MCP gateways coverage; if you want an agent orchestration framework, that layer is out of scope here. The simplest test of whether you need it: when the questions “what did the agent call, what did it cost, and can it call it again” start repeating across applications, it is time for a gateway layer to answer them in one place.