Envoy policy is the reason to choose Agent Router
Agent Router puts provider credentials, routing and quotas behind a common API, with Envoy handling the traffic. It is worth evaluating when several application teams need shared access policy and a platform team can own that service.
The README describes an OpenAI-compatible API spanning hosted providers, self-hosted inference and MCP servers. Centralizing those requests also centralizes responsibility for configuration changes and upgrades. A small application forwarding requests to one provider should identify what shared enforcement would save before adding another service.
What happened when we ran it
On October 16, 2026, our sandbox installed Agent Router commit ca3e516 in 69 seconds and recorded 541 dependencies. Our Agent Router build succeeded in 326 seconds; tests failed with exit 1 after 712 seconds, with 23 passed and 16 failed out of 39 in the supplied Go summary.
The visible tail names TestUpgrade and TestCRDVersionUpgrade, followed by a failure in github.com/envoyproxy/ai-gateway/tests/e2e-upgrade. Several internal helper packages show successful results nearby. The excerpt contains no assertion text or underlying setup diagnostic for those upgrade failures, so it cannot establish whether infrastructure, fixtures or project code caused them.
The recorded sandbox configuration was 3 CPUs, 8 GB RAM and image golang:1.24-bookworm. That image name does not verify actual runtime or operating-system versions. The evidence contains no traffic benchmark or successful cluster-upgrade result. Compilation succeeded in this run; deployment and upgrade behavior still need evaluation.
Start with the documented standalone route
The README documents aigw run with a provider API key and directs OpenAI-compatible clients to http://localhost:1975/v1. This offers a starting point for checking an application's requests before attempting a cluster deployment. The supplied sandbox measurements do not establish that this endpoint was started or exercised.
For cluster deployment, the README points to Kubernetes with Envoy Gateway. Its two-tier pattern separates a centralized entry point from ingress into a self-hosted model-serving cluster. Evaluate that arrangement against the policy boundaries your organization needs.
Version 1.2.0 needs an explicit session transition
The supplied v1.2.0 release notes say the Helm chart replaces its well-known default MCP session encryption seed with a random seed, stores it in a Secret and reuses it on later upgrades. By default, this seed transition ends active MCP sessions and requires clients to initialize again.
The release also documents a way to preserve sessions temporarily during the upgrade: set controller.mcp.sessionEncryption.fallback.seed=default-insecure-seed, then remove it once clients have reconnected. This is upgrade guidance from the project, not a result reproduced by our sandbox. Include the fallback's removal and the client's reconnect behavior in the upgrade rehearsal.
When rendering the chart with helm template, the release instructs operators to configure controller.mcp.sessionEncryption.existingSecret or seed. Otherwise every render generates a new seed. Configure persistent seed storage before deploying rendered releases.
Separate OAuth rejection from backend credential expiry
Version 1.2.0 checks MCP OAuth tokens against the configured issuer. A missing or different issuer, including a trailing-slash mismatch, returns 401. Review the configured issuer against the identity provider's token claims before upgrading.
Cross-namespace backend credentials have a separate permission change. The release requires ReferenceGrant permission for the cross-namespace Secret references listed in its breaking changes; a missing grant marks the policy NotAccepted. Already-issued backend credential tokens can keep working until they expire, so failures caused by these Secret permissions may appear later. That expiry warning concerns backend credential tokens, not a grace period for mismatched MCP OAuth issuers.
The release also changes MCP authorization and backend-selection CEL expression errors to deny access. Expressions that read optional request headers therefore need review. Exercise rejected requests as well as allowed requests, and check session reuse across different users. These are recommended evaluation cases, not tests completed in the supplied sandbox.
Alternatives offer different integration routes
LiteLLM provides a Python SDK as well as a proxy server. Evaluate it when direct Python library integration is the first requirement. This is an interface-based selection criterion; the supplied evidence contains no comparative gateway measurement.
Portkey AI Gateway documents a local gateway requiring Node.js and npm. Its README also describes configurable retries and fallback. Evaluate it when that runtime fits the team maintaining the service. The evidence does not establish that either alternative is faster or easier to operate than Agent Router.
Agent Router's reason to remain on an Envoy team's shortlist is its shared traffic policy role. Before adoption, map the deployment identifiers too: the README says the aigw command, API group and Go module retain their Envoy AI Gateway names. Then rehearse the exact upgrade and client session transition you intend to operate.