mrkeyoor.com_
Tue 01 Sept 17:42 UTC
LLM Toolsevaluationupdated 26 Aug 2026

agentgateway review

Agentgateway is a proxy for traffic between agents, language models, MCP tool servers, and other agents using A2A. It centralizes routing, credentials, policy, guardrails, spending controls, and telemetry, with standalone and Kubernetes deployment modes.

+109stars / 7d
Verdict

Our Agentgateway build took 362 seconds, then all 78 measured tests passed in 193 seconds, which is a credible result for a large gateway codebase. Use it when LLM, MCP, and A2A traffic genuinely need one policy and telemetry layer, especially on Kubernetes. A smaller LLM proxy is easier to own if tool federation and agent-to-agent routing are still hypothetical requirements.

We ran it

Lab card: what happened when we ran agentgatewayScreenshot of agentgateway (agentgateway.dev)
Install✓ · 95s447 packages
Build✓ · 362s
Tests✓ · 193s78 passed · 0 failed of 78 (go test)
Repo2401 files~392,255 lines of source · 37.9 MB · 4 CI workflows · Dockerfile

Answers from our run

Does agentgateway build from source?

Dependencies installed in 95 seconds (447 packages), and the build succeeded in 362 seconds. We cloned commit 6cb2e9c into a clean Debian container with 3 CPUs and no project-specific setup.

Do agentgateway's tests pass?

Yes: 78 of 78 passed when we ran the project's own test command (go test). Some failures need services or credentials a bare container does not have.

Who should not use agentgateway?

Teams with one application and one model key that do not need centralized policy: the gateway adds another network hop and configuration surface.

What are the alternatives to agentgateway?

LiteLLM, Envoy Gateway, Kong Gateway. Our Agentgateway build took 362 seconds, then all 78 measured tests passed in 193 seconds, which is a credible result for a large gateway codebase.

Setup3/5Green build and tests, but the build alone took 362 seconds
Docs4/5Standalone and Kubernetes paths are clear; parity gaps remain
Community5/54,552 stars with same-day issue and pull request activity
Maturity4/51.4.1 ships many controls, while core observability gaps are open

Who it’s for

Platform teams proxying several model providers or MCP servers.
Kubernetes operators already using Gateway API and policy resources.
Security teams that need JWT, API key, OAuth, RBAC, TLS, and request controls in one traffic layer.
Organizations prepared to test provider compatibility and failure behavior under their own load.

Who it’s NOT for

Teams with one application and one model key that do not need centralized policy: the gateway adds another network hop and configuration surface.
Buyers assuming guardrail decisions are fully auditable in v1.4.1: issue 3178 reports that some MCP deny and filter actions are absent from access logs.
Operators buffering large request bodies without a memory envelope: issue 3184 reports process OOM kills instead of graceful rejection past the available budget.
Kubernetes users expecting feature parity with standalone providers: issue 3136 says newer native provider types are missing from the Kubernetes CRD.
Anyone wanting the gateway to execute the complete server-side tool loop: issue 3180 requests that capability rather than documenting it as current behavior.

Setup reality

Our sandbox installed 447 Go packages in 95 seconds. The build succeeded in 362 seconds, and tests completed in 193 seconds with 78 passed and 0 failed. The measured checkout contained 2,401 files, about 392,255 source lines, and 37.9 MB before dependencies.

Standalone mode needs flat YAML plus credentials for each LLM, MCP server, identity provider, or guard service. Kubernetes mode adds the controller, Gateway API resources, CRDs, Helm releases, namespaces, and ReferenceGrants. Telemetry needs its own OpenTelemetry destination and retention policy.

The repository includes Rust and Go code; our detected build path used Go. Four CI workflows and a Dockerfile were present, while there was no top-level tests directory. Production rollout still needs TLS, secret storage, timeouts, rate limits, cost catalogs, and failure drills for every upstream.

Agentgateway puts LLM, MCP, and A2A traffic under one policy layer

Agentgateway sits between agent applications and the systems they call. On the model side, it exposes an OpenAI-compatible API and routes to providers such as OpenAI, Anthropic, Gemini, and Bedrock. On the tool side, it federates MCP servers across stdio and network transports. A2A support handles communication between agents. The appeal is one place to apply identity, routing, budget, and telemetry rules across all 3 traffic classes.

That is a platform feature, not an application library. A team can add JWT, API keys, OAuth, TLS, CEL-based RBAC, rate limits, load balancing, failover, and prompt filtering without implementing each control in every agent. Model routing can account for GPU utilization, queue depth, cache state, and adapters when used with Kubernetes inference extensions. The gateway does not remove provider behavior differences; it gives operators a common control point for managing them.

Standalone YAML is simpler than the Kubernetes controller

Standalone mode uses flat YAML and ships a built-in interface for exploring connections. Kubernetes mode adds a controller, CRDs, Helm charts, and Gateway API resources. The latter fits organizations already expressing traffic policy through cluster objects. It is too much machinery for a single service with one model provider and a fixed tool list. Start standalone unless Kubernetes ownership is already present.

Feature parity is incomplete. Issue 3136 says standalone had 13 newer native provider types in v1.4.1, while the Kubernetes AgentgatewayBackend CRD exposed only the original set. The reporter routed Mistral through a generic OpenAI adapter, which then attributed cost metrics to the wrong provider. A gateway evaluation should compare required providers and policies in the exact deployment mode, not only read the combined feature list.

What happened when we ran it

Our sandbox installed 447 Go packages in 95 seconds. The build succeeded in 362 seconds, and the measured tests finished in 193 seconds with 78 passed and 0 failed. This is the only project in this batch whose full test step completed cleanly. The 650 seconds across install, build, and tests also show that source work starts before deployment is configured.

commit 6cb2e9c contained 2,401 files, about 392,255 lines of source, and a 37.9 MB checkout. GitHub identifies Rust as the primary language, while the lab detected and exercised a Go build path. The repository had 4 CI workflow files and a Dockerfile, with no top-level tests directory. Those facts fit a mixed gateway and controller codebase rather than a small single-language proxy.

The sandbox had 3 CPUs and 8 GB of RAM, used an unprivileged Go 1.24 Debian container, and had no secrets. Passing tests do not cover real model keys, OAuth exchanges, Kubernetes policies, remote MCP servers, or upstream timeouts. Run an integration matrix with your providers and identity system before treating the green 78-test result as production evidence.

Version 1.4.1 tightened protocol and authentication behavior

Release 1.4.1 shipped on July 29, 2026. It added MCP Tasks support, validated upstream response types, logged asynchronous MCP errors, and changed fail-open federation so an all-upstream failure returns an error rather than empty success. OAuth token exchange now fails closed when its configured subject token is missing. These are consequential changes for a component that decides which agent requests cross a trust boundary.

The release also carries upgrade work. Standalone LLM and MCP listeners can no longer share a top-level port unless attached to the same gateway. Some custom model-catalog keys need renaming, and OAuth configurations relying on an implicit JWT fallback must select the raw validated token explicitly. Pin the release, read upgrade notes, and test configuration rendering before replacing a running gateway.

Guardrails can block traffic without proving the audit trail

Agentgateway supports regex checks, OpenAI moderation, Bedrock Guardrails, Google Model Armor, and custom webhooks. That range lets an operator choose deterministic or provider-backed checks. A guardrail must be evaluated on false positives, bypasses, latency, and what happens when its service is unavailable. The word guardrail does not by itself establish that unsafe traffic is blocked or that an allowed request is safe.

Issue 3178 reports an audit gap in MCP guardrails at commit 6cb2e9c. A request-phase denial could return a JSON-RPC error to the client while the native access log lacked an MCP error or guardrail decision field. A filtered tool list could look like an ordinary 200 response. Security teams requiring evidence of every deny or mutation should reproduce the case and wait for or carry a fix.

Buffered bodies need a process-wide memory limit

Policies that inspect request bodies must buffer data. Issue 3184 reports that v1.4.1 enforced a per-request maxBufferSize but lacked an aggregate cap across concurrent requests. Under the reporter's held-request load, memory grew with bytes in flight until the process was killed, then recovered. Their numbers describe that issue's environment, not our sandbox, so they should guide a reproduction rather than become a universal capacity claim.

Set conservative body limits, pod memory limits, request timeouts, and upstream concurrency controls. Then hold responses while sending the largest permitted bodies and observe rejection behavior. A proxy should shed load with a controlled status before its memory budget is exhausted. This matters more when CEL rules or guard services inspect full prompts, attachments, or tool payloads.

Active development is both reassurance and upgrade work

GitHub recorded the last push on August 25, 2026. The repository had 4,552 stars and 351 combined open issues and pull requests when fetched. The project is under the Linux Foundation and publishes binaries, container images, and Helm charts. Daily issue and pull request activity shows attention across authentication, telemetry, Kubernetes resources, provider import, and MCP behavior.

Choose Agentgateway when those layers already exist as separate problems. The 78 passing tests support a trial, while the 362-second build, open audit gap, memory-overload report, and standalone-versus-Kubernetes differences set the due-diligence list. If the team only needs a shared model endpoint, LiteLLM or another focused proxy will take less policy and cluster expertise to operate.

Alternatives

ProjectWhat it isPick it when
LiteLLM gh↗A model gateway centered on an OpenAI-compatible API, provider routing, budgets, and keys.pick this instead when LLM provider unification is the main job and MCP or A2A policy is secondary.
Envoy Gateway gh↗A Kubernetes Gateway API implementation for general application traffic.pick this instead when standard HTTP and service networking matter more than AI-native protocol handling.
Kong Gateway gh↗A mature API gateway with a large plugin and deployment ecosystem.pick this instead when enterprise API management and conventional service traffic outweigh built-in MCP and A2A support.

What people are saying

  1. [github-trending] agentgateway/agentgateway

Sources

  1. Agentgateway README
  2. Agentgateway v1.4.1 release
  3. MCP guardrail logging report
  4. Buffered request memory report
  5. Kubernetes provider parity report

More llm tools reviews

rig · open-knowledge · graphiti · cve-mcp-server · minimind · SillyTavern · the whole board →