Agentgateway

What it is

Agentgateway is a proxy built specifically for AI agent traffic and the Model Context Protocol (MCP). Instead of retrofitting a general-purpose API gateway (nginx, Envoy, Kong) to handle agent-to-agent and agent-to-tool communication, it's designed from the ground up for that traffic pattern: MCP server discovery, tool call routing, agent authentication, and the kind of observability you need when your "clients" are LLMs making non-deterministic calls. It's written in Rust, which matters here because agent traffic can be chatty and latency-sensitive, and you don't want GC pauses or a slow runtime sitting between an agent and a tool it's trying to invoke.

Who builds it and why

170 contributors and 3,614 GitHub stars is a real, active open-source project, not a side script. The MCP ecosystem exploded through 2024-2025 as Anthropic's protocol became a de facto standard for connecting LLMs to tools and data sources, and existing infrastructure (API gateways, service meshes) had no native concept of "MCP server" or "agent session." Agentgateway exists to fill that gap before someone bolts MCP support onto Envoy as an afterthought. CNCF maturity level is not publicly available, so treat this as pre-foundation or early-stage foundation involvement rather than an incubating/graduated project with the governance guarantees that implies.

Production readiness signal

v1.3.1 as the latest release suggests the project is past the 0.x experimentation phase and has stabilized a base feature set. Rust as the implementation language is a plus for a proxy — memory safety without a GC, good for something sitting in the request path. 170 contributors is a healthy signal for bus-factor and code review diversity. What's missing from the public data: founding date, CNCF maturity tier, and any adopter list or production case studies. If you're evaluating this for a regulated or high-availability environment, you'll need to ask the maintainers directly for reference deployments — don't assume production-hardened just because the version number is past 1.0.

Who should use this

• Teams building multi-agent systems where agents call MCP servers as tools and need centralized routing, auth, and rate limiting instead of point-to-point connections
• Platform teams standardizing MCP server exposure across an org — one gateway in front of many internal MCP servers instead of every team rolling their own auth
• Rust-shop or performance-conscious teams that want a lightweight proxy rather than pulling in a full service mesh to solve an agent-traffic problem

Who should NOT use this

• Teams that don't use MCP and have no near-term plan to — this is not a general API gateway, and you'll be fighting the tool's opinions if you try to force generic REST/gRPC traffic through it
• Anyone needing CNCF-graduated project guarantees (governance, security audits, vendor-neutral IP) for a compliance requirement — maturity status here is unclear
• Orgs without in-house Rust or systems-level debugging capability who need a vendor to call at 3am — check the pricing section, because right now that vendor may not exist
• Teams already deep into Envoy/Istio who just need MCP support bolted on — check if your existing mesh has added MCP filters before adopting a second piece of edge infrastructure

Alternatives

• Envoy + MCP filters — if your org already runs Envoy/Istio, adding MCP-aware filters keeps you on one gateway instead of introducing a second proxy layer.
• Kong with AI Gateway plugins — commercial support and a broader plugin ecosystem if you need more than agent traffic through the same gateway.
• Custom MCP reverse proxy — for small setups, a thin homegrown proxy in front of a couple of MCP servers may be less operational overhead than adopting a new gateway category.

Pricing

Fully open source under Apache-2.0. No paid tier, enterprise edition, or commercial support offering is publicly available. Budget for self-support (or contributing fixes upstream yourself) until/unless a commercial entity forms around the project.