agentgateway/agentgateway

Worth evaluating if your agents now call several model providers and MCP tools, and credentials, quotas and traces are scattered across each client. This is infrastructure for a team already operating agents, not a library you add to make one work.

The problem

A team ships an agent that calls OpenAI, a self-hosted model and a handful of MCP tool servers. Each client holds its own API keys, retries differently and logs in its own format, so nobody can answer which tool was called with whose credentials or where the monthly spend went. Adding a provider or a tool means touching every caller. With agentgateway in the path, clients speak to one endpoint while routing, auth, budget and telemetry are configured in the gateway.

What's different

The design treats MCP and A2A as first-class traffic rather than ordinary HTTP. An LLM gateway exposes an OpenAI-compatible endpoint across several providers with spend controls, load balancing and failover; an MCP gateway federates tool servers over stdio, HTTP, SSE and Streamable HTTP, including OpenAPI-backed tools and OAuth; an A2A gateway covers discovery and task collaboration between agents. Policy sits around all of it: JWT and API-key auth, OAuth, CEL-based RBAC, rate limiting, TLS and OpenTelemetry output, plus guardrail hooks into regex, OpenAI moderation, Bedrock Guardrails and Model Armor. There is also routing to self-hosted models through Kubernetes Inference Gateway extensions, weighing GPU utilization, KV cache and queue depth.

The trade-off is that you are adopting a proxy, not a helper library. Every request now crosses a component you must configure and keep available, and a misconfigured policy can break every agent at once. The breadth also cuts both ways: some capabilities are environment-specific, so the useful surface for a standalone user is smaller than the README's full list. Claims such as drop-in security or the "first complete" framing are the project's own description, not independent evidence.

Who should try it

Good fit: a platform or infrastructure team already running agents in production that wants one place to issue credentials, cap spend per team and get traces across model and tool calls. Also a reasonable fit for someone experimenting with MCP tool federation who wants a configurable front door rather than wiring OAuth into each client. Poor fit: a single developer calling one model from a script, or anyone looking for an agent framework, since this governs traffic rather than deciding what the agent does. Kubernetes users get an additional documented path with a controller and Gateway API, which is a different setup from the flat-YAML standalone deployment; choose based on whether you already run a cluster.

Requirements and limitations

You need to run a Rust binary, container or Kubernetes deployment and own its configuration. The two setup routes diverge meaningfully: standalone uses flat YAML without the full controller, while the Kubernetes quickstart assumes a cluster and Gateway API. Pick one deliberately, because configuration idioms do not transfer cleanly.

Ongoing work is the real cost. Auth policies, rate limits, guardrails and provider credentials all live in gateway config, so changes affect every consumer; guardrail options also depend on external services such as OpenAI moderation, Bedrock Guardrails or Model Armor, each with its own account and prerequisite. The project describes itself as in active development and points missing features to its issue tracker, so expect release notes to matter.

HotRepo's take

HotRepo's record is thin: a single daily-board observation on 2026-10-27 showed 5,673 stars and +30 that day. That is a snapshot, not a trend, and persistence cannot be judged from it. The repository dates to March 2025 and is presented as a Linux Foundation project, but age and stars say nothing about operational maturity. Before committing, check that the standalone configuration path documents the specific MCP and provider features your agents rely on.