agentgateway: an AI-native proxy for MCP, A2A and LLM traffic
Next Generation Agentic Proxy for AI Agents and MCP servers
At a glance
- What is it?
- agentgateway is a Rust reverse proxy that sits in front of LLM providers, MCP tool servers and other agents, with two deployment shapes: a flat YAML standalone binary and a Kubernetes controller using Gateway API. The design is coherent, but the README describes features rather than showing configuration, so most evaluation work happens in the docs site.
- Who is it for?
- Adopt agentgateway if you already run Kubernetes and want MCP tool federation, LLM provider routing and A2A traffic governed by one Gateway API resource set, or if you want the same policy in a standalone binary driven by flat YAML. Do not adopt it if you need a stable config surface today, since the project describes itself as in active development and ships beta releases alongside stable ones.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap agentgateway is aimed at
Most teams adopting agents end up with three separate connectivity problems that look unrelated until they are in production. The first is agent-to-LLM traffic: several providers, each with its own auth scheme and response shape, plus a need to cap spend. The second is agent-to-tool traffic: MCP servers that may speak stdio, HTTP, SSE or Streamable HTTP, each with its own OAuth story. The third is agent-to-agent traffic, which the README frames around A2A and describes as needing capability discovery, modality negotiation and task collaboration. agentgateway's claim is that one proxy can cover all three rather than three sidecars or three vendor SDKs. The intended user is an infrastructure or platform engineer who already owns ingress or a service mesh and is being asked to make agent traffic auditable. It is not aimed at a single developer calling one model from a script; there is no reason to put a proxy in that path.
One binary, two control planes
The repository describes two deployment environments that share the same proxy core. The standalone path runs without the Kubernetes controller and is driven by flat YAML, which is what the agentgateway.dev/docs/standalone/latest documentation covers. The Kubernetes path uses a built-in controller and Gateway API, documented under agentgateway.dev/docs/kubernetes/latest. That split matters more than it first appears: Gateway API resources are namespaced, reconciled and versioned by the cluster, while flat YAML is a file you edit and reload. The feature list spans LLM routing to OpenAI, Anthropic, Gemini and Bedrock behind an OpenAI-compatible API, MCP tool federation across the transports named above, an OpenAPI integration path, A2A handling, inference routing to self-hosted models via Kubernetes Inference Gateway extensions, guardrails, and security and observability through JWT and API key auth, OAuth, a CEL policy engine for RBAC, rate limiting, TLS and OpenTelemetry. Inference routing is the one feature that is explicitly Kubernetes-bound, since it depends on Inference Gateway extensions and decisions based on GPU utilization, KV cache, LoRA adapters and queue depth. If you run standalone, that part of the feature list is not available to you.
What the material does not show about the data path
The README gives an architecture diagram and a feature list, not a request walkthrough. So the honest statement is that the request lifecycle is not documented in the material available here. What can be inferred is the shape: traffic enters the proxy, policy is evaluated (auth, then CEL-based RBAC, then rate limits), guardrails run, and the request is forwarded either to an LLM provider, to an MCP server over one of the four transports, or to another agent over A2A. Where prompt enrichment and budget accounting sit in that order is not stated. That ordering is exactly the kind of detail that determines whether a guardrail can be bypassed by a retry, and it is the first thing to look for in the docs rather than in the README. Treat the diagram as a component inventory, not a sequence.
Getting it running: what the README actually gives you
The README does not include install commands, a config file, or a flag list. It points to two quickstarts: the standalone quickstart at agentgateway.dev/docs/standalone/latest/quickstart and the Kubernetes quickstart at agentgateway.dev/docs/kubernetes/latest/quickstart. Those are the only concrete entry points in the supplied material, and the repository also offers a Codespaces badge, so the fastest way to see the thing move without a cluster is the hosted dev container. Beyond that, the material names the concepts you will be configuring (providers, MCP transports, guardrail backends, CEL policies, OpenTelemetry exporters) without giving their keys. I am not going to invent YAML for this article. If you need to decide this week, open the standalone quickstart first, since flat YAML will tell you more about the config model in ten minutes than the feature list will.
Limits, and where this is the wrong tool
The README states that agentgateway is in active development and invites issues for missing features. The release history supports taking that seriously: v1.5.0 shipped on 2026-08-27, a v1.5.0-beta.1 two days earlier on 2026-08-25, and v1.4.1 on 2026-07-29. A steady beta cadence alongside stable tags is normal for a young proxy, but it means the config surface can move between minor versions, and any policy you write today should be treated as version-pinned. The second limitation is scope. This is a gateway, so it governs traffic at the boundary; it does not sandbox what an MCP tool does once invoked, and it does not decide whether a given tool should be reachable at all beyond the policy you write. If your actual problem is that one agent is calling one internal tool, a proxy adds a hop, a config file and an upgrade obligation for no governance benefit. Third, the inference routing feature depends on Kubernetes Inference Gateway extensions, so a team running VMs or plain containers cannot use it. Fourth, the material does not state supported versions, resource requirements, or a compatibility matrix, so capacity planning has to come from your own load test.
Compared with a general-purpose proxy plus glue
The obvious alternative is an existing L7 proxy such as Envoy or NGINX with custom filters, or a service mesh sidecar, plus hand-written code for provider translation and MCP session handling. The difference is where the protocol knowledge lives. A general proxy routes on host, path and headers; it has no concept of an MCP tool list or an A2A capability negotiation, so you write that logic yourself and maintain it as the specs change. agentgateway puts MCP and A2A awareness inside the proxy, which is the whole reason it exists. The cost of that choice is the inverse: you inherit its release cadence and its opinions about how tools are federated, and you cannot swap the MCP handling for your own without leaving the project. If your traffic is plain HTTP between services with no MCP or A2A in it, the general proxy is the better answer and always will be.
Licence, maintenance and what to verify first
agentgateway is Apache-2.0 and is described in the README as a Linux Foundation project, with a CONTRIBUTION.md, a Discord, a public community meeting calendar and published recordings. Those are governance signals rather than quality signals; they tell you where decisions get made and how to ask about them, not whether the code is good. Practically, the maintenance cost you are signing up for is tracking minor releases and re-validating policy after each one, plus reading the docs for whichever of the two deployment modes you chose, because a feature documented for Kubernetes may not exist in the standalone config. The licence itself is permissive and carries no copyleft obligation on your own code, but the repository also lists a sponsor and links to external services (OpenAI moderation, AWS Bedrock Guardrails, Google Model Armor, DeepWiki), and those integrations have their own terms. That is a question for your own review, not something this article can settle. The single thing to verify before you commit: open the standalone quickstart and the Kubernetes quickstart, and confirm that the deployment mode you intend to run documents the guardrail and auth backends you need. If it does not, you are evaluating a roadmap, not a gateway.
Editorial conclusion
Adopt agentgateway if you already run Kubernetes and want MCP tool federation, LLM provider routing and A2A traffic governed by one Gateway API resource set, or if you want the same policy in a standalone binary driven by flat YAML. Do not adopt it if you need a stable config surface today, since the project describes itself as in active development and ships beta releases alongside stable ones. Before committing, read the standalone quickstart and the Kubernetes quickstart and confirm which of the two config models you will actually run, then check whether the guardrail backends you need (OpenAI moderation, AWS Bedrock Guardrails, Google Model Armor, or a custom webhook) are documented for your deployment mode.
Community notes