Envoy AI Gateway (ahora Agent Router): Una reseña honesta

El cambio de nombre, en un párrafo

Si buscaste «Envoy AI Gateway» y llegaste aquí: estás en el lugar correcto y el producto sigue existiendo. Ahora se llama Agent Router, se encuentra en theagentrouter.ai y es un proyecto independiente dentro de la Agentic AI Foundation (una serie de LF Projects, LLC) en lugar de un subproyecto de Envoy dentro de la CNCF. El anuncio tiene fecha del 9 de septiembre de 2026; la transición se hizo efectiva al día siguiente.

Nada a nivel técnico se rompió. El namespace sigue siendo envoy-ai-gateway-system, el grupo de API sigue siendo aigateway.envoyproxy.io, la CLI sigue siendo aigw y la licencia continúa siendo Apache 2.0. Los manifiestos de tu repositorio siguen funcionando. Lo que cambió es el marco de gobernanza, el dominio de la documentación, la ruta del repositorio y el nombre. En adelante usaremos «Agent Router».

Qué es realmente Agent Router

Agent Router es una capa aditiva sobre Envoy Gateway —no un fork— que le enseña a Envoy a hablar LLM. Su propio planteamiento ofrece la definición más clara de esta categoría: «Agent Router configura. Envoy gestiona el tráfico».

Los mantenedores provienen de Tetrate, Bloomberg, Tencent, Netflix, AMD y Nutanix, según el anuncio de la versión 1.0. Tetrate es el impulsor comercial, gestionando tanto un servicio alojado como un producto enterprise autogestionado sobre él. Tienen reuniones semanales de la comunidad, propuestas de diseño públicas y un canal de Discord.

Historial de versiones

Aproximadamente una versión menor por trimestre: un ritmo saludable. La v1.0 contiene la afirmación más sólida de la documentación del proyecto:

«Nunca romperemos las APIs a menos que haya un problema de seguridad crítico, y siempre proporcionaremos una ruta de migración en las notas de la versión si alguna vez nos vemos obligados a hacerlo».

Ese es un compromiso real, por escrito, y mucho más de lo que la mayoría de los gateways comerciales dejarán plasmado en texto.

Arquitectura

Agent Router se divide claramente en plano de control y plano de datos.

Plano de control. El API Server de Kubernetes es la interfaz de configuración. El AI Gateway Controller gestiona los recursos específicos de IA y configura el External Processor, ajustando xDS a través del mecanismo de servidor de extensión de Envoy Gateway; el Envoy Gateway Controller gestiona la configuración principal del proxy.

Plano de datos. Envoy Proxy, un External Processor (ext-proc) que realiza transformaciones y validaciones específicas de IA, y un Rate Limit Service para la limitación basada en tokens. El MCP gateway es un proxy ligero dentro del sidecar de Agent Router.

Cinco CRDs, todos servidos en v1beta1 y cubiertos por la garantía de estabilidad de la versión 1.0: AIGatewayRoute (enruta el tráfico de LLM y selecciona los backends), AIServiceBackend (declara un proveedor upstream o modelo autoalojado), BackendSecurityPolicy (centraliza las credenciales upstream), GatewayConfig (configuración a nivel de gateway) y MCPRoute (multiplexación de MCP, filtrado de herramientas, autorización).

La configuración se realiza mediante YAML aplicado con kubectl. Los nombres de campos documentados dan una idea de su estructura: modelNameOverride en un backend para virtualización de modelos, credentialOverride para credenciales upstream por solicitud, streamIdleTimeout para esperas de streaming acotadas y, en una MCPRoute:

También debes gestionar una matriz de versiones. La base de la v1.1.0 incluye Go 1.26.4, Envoy Gateway v1.8.1, Envoy Proxy v1.38.1, Gateway API v1.5.1, Inference Extension v1.0.2 y el SDK de MCP para Go v1.7.0. Las actualizaciones de Envoy Gateway se convierten en tu dependencia.

[CAPTURA DE PANTALLA: Agent Router — diagrama de arquitectura del sitio de documentación que muestra el plano de control (AI Gateway Controller + Envoy Gateway Controller) y el plano de datos (Envoy Proxy + External Processor + Rate Limit Service)]

Inventario de características documentadas

Proveedores — 16 listos para usar: OpenAI, Azure OpenAI, Gemini, Vertex AI, Bedrock, Anthropic, Mistral, Cohere, Groq, Together AI, DeepInfra, DeepSeek, Hunyuan, SambaNova, Grok y Tetrate Agent Router Service. vLLM y Ollama autoalojados son accesibles a través de la CLI.

API unificada. Compatible con OpenAI: chat, completions, embeddings, generación de imágenes, audio y la Responses API, además del endpoint nativo de Anthropic /anthropic/v1/messages. La traducción entre proveedores gestiona casos como transformar mensajes de Anthropic a Bedrock Converse.

Gestión del tráfico. Rate limiting basado en tokens. QuotaPolicy para presupuestos de tokens en intervalos de tiempo. Conmutación por error (failover) automática y rutas alternativas de proveedores. Virtualización de nombres de modelos a través de modelNameOverride, de modo que cambiar de proveedor requiera una modificación de configuración y no de código. Mutaciones de encabezados y cuerpo. En la v1.1, streamIdleTimeout con conmutación por error: si se activa antes de recibir el primer token, un reintento pasa al siguiente backend.

Enrutamiento de inferencia y credenciales. Soporte para InferencePool y Endpoint Picker, tanto a través de HTTPRoute + InferencePool como de AIGatewayRoute + InferencePool —realmente útil si gestionas tus propias GPUs—. BackendSecurityPolicy centraliza la autenticación upstream: claves API, AWS SigV4, Azure y la identidad nativa en la nube de GCP, incluyendo Workload Identity y GKE ADC.

Soporte para MCP sustancial. Multiplexación de servidores tras un único endpoint con herramientas prefijadas automáticamente por el backend (github__issue_read), filtrado de herramientas, OAuth con PKCE según la especificación de autorización de MCP y HTTP con streaming y reconexión mediante Last-Event-ID. La función destacada es la autenticación detallada utilizando CEL sobre declaraciones JWT y contexto MCP (request.mcp.method, request.mcp.tool, request.mcp.params, request.auth.jwt), haciendo que tools/list devuelva únicamente aquello que el emisor tiene permitido usar. Pocos proyectos alcanzan ese nivel de profundidad.

Observabilidad. Métricas de Prometheus siguiendo las convenciones semánticas GenAI de OpenTelemetry, con contabilización separada para tokens de razonamiento. Trazado OTel con compatibilidad para OpenInference. Registros de acceso que contienen metadatos de IA. La v1.1 añade atributos de span gen_ai.* y un panel de control de ejemplo en Grafana dentro del repositorio.

Los guardrails no son una función nativa. No hay una página dedicada a guardrails en la documentación; la sección de capacidades de seguridad consiste mayoritariamente en enlaces a la propia documentación de seguridad de Envoy Gateway. La comparativa de Tetrate categoriza la fila correspondiente a OSS como «hooks de guardrails», ofreciendo los guardrails de IA reales dentro de su producto enterprise.

Los puntos fuertes reales

Un proyecto de nivel merece un análisis riguroso de sus ventajas.

El plano de datos es Envoy. No se trata de un proxy nuevo escrito en Python o Node; es el proxy que ya procesa tráfico en entornos de producción a una escala enorme. El riesgo operativo en el plano de datos es prácticamente el mínimo posible.

La garantía de estabilidad es poco frecuente. Una API de plano de control en v1beta1 con compromiso de estabilidad garantizado por escrito y una ruta de migración asegurada supera la oferta de la mayoría de los proveedores comerciales.

Mantenimiento respaldado por múltiples empresas del sector. Tetrate, Bloomberg, Netflix, AMD, Nutanix y Tencent cuentan con mantenedores en el proyecto. No es un proyecto controlado por un solo proveedor que lleva una etiqueta de código abierto; el factor de riesgo por pérdida de mantenedores (bus factor) ofrece una protección real.

Sin una versión comunitaria mermada. Tetrate lo afirma de manera tajante: «Sin plano de datos propietario, sin una versión comunitaria recortada, sin guardarse nada fuera del proyecto para luego vendértelo». El valor añadido de la versión enterprise reside en la gestión de la flota, no en limitar características del plano de datos: un enfoque open-core honorable. El proyecto también es nativo a los estándares de la industria en todos sus componentes (Gateway API, Inference Extension, convenciones OTel GenAI, OpenInference, MCP), por lo que casi no existen elementos propietarios que generen dependencia (lock-in).

Es verdaderamente fácil de probar. Un solo comando, sin Kubernetes, sin Docker, en Linux o macOS:

OPENAI_API_KEY=sk-... aigw run

Eso despliega un router compatible con OpenAI en localhost:1975. Pocos proyectos de open source AI gateway consiguen ofrecer un endpoint operativo tan rápido.

Empresas que lo han adoptado formalmente. La página principal enumera a Alan by Comma Soft, Bloomberg, LY Corporation, National Research Platform, Nutanix, Paper Compute Co., Simplifai, Stacklok, Tencent Cloud, Tetrate y Unwrap, y la publicación del lanzamiento de la v1.0 agradece específicamente a los tres primeros. No hemos encontrado estudios de caso formales con métricas (los logotipos y las listas de agradecimientos no lo son), pero tres productos comerciales están construidos sobre él (Tetrate Agent Router Service y Enterprise, Nutanix Agent Gateway), lo cual es evidencia suficiente de la calidad de su código para entornos de producción.

[CAPTURA DE PANTALLA: Agent Router — fila de logotipos de clientes de la página principal con las once empresas publicadas]

Donde los equipos encuentran dificultades

Nada de esto busca criticar el código. Se trata de un inventario de lo que el proyecto open-source no incluye, evidenciado por su ausencia en la documentación o por estar presente en la comparativa de pago de Tetrate, verificado a fecha de 25 de septiembre de 2026.

1. No dispone de interfaz de usuario. La navegación de la documentación no incluye ninguna página sobre una consola de administración. Cada incorporación de modelo, rotación de claves y ajuste de cuotas se realiza mediante manifiestos de Kubernetes a través de tu pipeline de GitOps; Tetrate vende «The Management Console» como un componente enterprise. Esto es aceptable para un equipo de plataforma. Para los doce equipos de aplicaciones que desean probar un modelo nuevo el jueves por la tarde, supone abrir un ticket.

2. Sin RBAC de plataforma ni SSO para la administración del gateway. El RBAC de Kubernetes sobre los CRDs no ofrece control de acceso basado en roles sobre los modelos, los servidores de MCP o los equipos. La autenticación de solicitudes en el plano de datos (JWT, OIDC) proviene de Envoy Gateway, pero eso es autenticación del cliente, no control de acceso administrativo. Tetrate incluye el SSO con Okta/Entra/OIDC/SAML y consolas con permisos delimitados como filas de la versión enterprise.

3. La atribución de costes consiste en métricas, no en un modelo de cobro (chargeback). Las métricas de tokens terminan en Prometheus. Convertir eso en un desglose de gastos por equipo con un catálogo de precios y modelos de showback y chargeback es algo que tendrás que desarrollar tú mismo, incluyendo el mantenimiento actualizado del catálogo. Tetrate es transparente: al mezclar GPUs autoalojadas con APIs cobradas por token, «La atribución debe normalizar ambas métricas o las cifras que entregues a finanzas serán pura ficción».

4. Los presupuestos se aplican por gateway, no a nivel de toda la flota. QuotaPolicy permite asignar presupuestos de tokens en diferentes períodos de tiempo, pero la comparativa de Tetrate clasifica el comportamiento de la versión OSS como «por gateway». Si ejecutas gateways en tres regiones distintas, un agente rechazado en una región podría procesar la solicitud con éxito en otra.

5. No hay registro de prompts ni respuestas. Los registros de acceso contienen nombres de modelos y conteo de tokens; no existe una captura, retención, búsqueda o reproducción documentada de prompts o completados. La v0.6 añadió la redacción del cuerpo de las solicitudes: la tendencia del desarrollo se orienta hacia eliminar el contenido de los cuerpos, no a almacenarlo.

6. Sin aprobación humana (human-in-the-loop) y los guardrails corren por tu cuenta. La autorización de MCP aprueba o deniega en el momento de la solicitud; nada bloquea una llamada destructiva a una herramienta exigiendo una aprobación previa. Tetrate vende un interruptor de emergencia para agentes (kill switch), pero no existe un flujo de aprobación por llamada. Tampoco hay detección de PII, filtrado de inyección de prompts, moderación de contenidos ni escaneo de secretos en el proyecto OSS.

7. Kubernetes es un requisito previo para producción. aigw run está pensado para entornos locales. Pasarlo a producción requiere un clúster, además de Envoy Gateway, el controlador de AI Gateway y un Rate Limit Service. Si no operas Kubernetes con Gateway API hoy en día, tendrás que completar un proyecto técnico considerable antes de poder enrutar tu primer token.

8. Quién atiende las incidencias a las 3 de la mañana. El soporte de la comunidad se gestiona a través de GitHub, Discord, Slack y una reunión semanal los lunes. Tetrate Enterprise vende soporte 24/7 con SLA, un equipo de cuenta dedicado, compilaciones con parches para CVEs en un ciclo de entregas mantenido, distribución para entornos aislados (air-gapped) y un catálogo de modelos actualizado. Su tabla comparativa resume la columna OSS como «tú lo mantienes»: todo el análisis en cuatro palabras.

¿Quieres el punto de control sin tener que construirlo desde cero?

Enruta solicitudes a más de 1.000 modelos, con atribución de costes, presupuestos y RBAC ya integrados.

Empieza gratis

Crear o comprar, explicado con claridad

Si tu equipo de plataforma gestiona Envoy Gateway y cuenta con la capacidad necesaria, la columna de la derecha representa una hoja de ruta que pueden ejecutar. De lo contrario, es un producto que terminarás construyendo sin haberlo planeado. Evalúa el coste de la misma manera que analizarías cualquier decisión de crear o comprar: en meses-persona de trabajo, no en licencias.

Dónde se sitúa TrueFoundry

No pretendemos afirmar que Agent Router sea un mal producto. La diferencia radica en el alcance y en quién asume la carga operativa.

El AI Gateway de TrueFoundry parte de la misma idea arquitectónica —un único punto de control frente al tráfico de modelos y herramientas—, pero incluye la plataforma periférica en lugar de delegar su desarrollo en ti. Añade apenas 3-4 ms de latencia, gestiona más de 350 RPS por vCPU y da acceso a más de 1.000 LLMs mediante una única API compatible con OpenAI.

Una consola y un sistema RBAC con significado práctico. La incorporación de modelos, la rotación de claves y las modificaciones de cuota se realizan mediante una interfaz gráfica con trazabilidad de auditoría, permitiendo que los equipos avancen sin necesidad de solicitar tickets a la plataforma. Los sujetos de acceso pueden ser usuarios, equipos, cuentas virtuales o agentes; los recursos cubren desde cuentas de proveedores y servidores MCP hasta agentes, clústeres y entornos de trabajo, cada uno con su propio esquema de roles. Admite SSO mediante OIDC o SAML 2.0, con aprovisionamiento SCIM.

Atribución de costes y presupuestos adaptados a las exigencias financieras. Presupuestos con límite mediante Budget Limiting V2 asignados por cliente o equipo, delimitados por sujeto, modelo, cuenta de proveedor o metadatos, con un modo de advertencia sin bloqueo. El seguimiento de costes utiliza un catálogo de precios open-source (github.com/truefoundry/models) con tarifas por región y por tramos de uso; la atribución se procesa mediante X-TFY-METADATA. Este es el déficit que más tiempo requiere solucionar por cuenta propia —consulta atribución de costes y presupuestos por equipo.

Catálogo de guardrails integrado, no solo hooks. Nueve integrados (protección de secretos, seguridad de código, desinfección de SQL, expresiones regulares, inyección de prompts, PII, moderación de contenidos, Cedar, OPA) más 17 proveedores externos, aplicables en cuatro puntos: entrada al LLM, salida del LLM, evaluación previa a la herramienta en MCP y evaluación posterior.

Una aclaración transparente: los guardrails para moderación de contenido, PII e inyección de prompts funcionan únicamente cuando TrueFoundry aloja el gateway, no en infraestructuras autogestionadas. El resto de guardrails funcionan en cualquiera de las modalidades.

Gobernanza de MCP con flujo de aprobación humana. Activación o desactivación por herramienta, anotaciones para operaciones de solo lectura o destructivas, y aprobación humana (human-in-the-loop) con alcances configurables por nombre, por acción destructiva o globales, caducidad de permisos y notificaciones por correo electrónico, Slack, PagerDuty o Teams. La documentación de Agent Router no contiene un equivalente a esta función.

Observabilidad y despliegue listos para usar, sin proyectos adicionales. Trazas y métricas OTel sobre HTTP o gRPC, recolección con Prometheus para entornos autogestionados y APIs de métricas para modelos, MCP, guardrails, caché y enrutamiento. Se ejecuta como SaaS en más de 12 regiones y tres proveedores cloud, o autogestionado en tu propia VPC, localmente o en entornos aislados (air-gapped): el tráfico se mantiene en tu infraestructura y TrueFoundry no interviene en la ruta crítica del tráfico.

Pruébalo directamente con tu tráfico real.

Dirige una carga de trabajo hacia el gateway y comprueba por ti mismo las métricas de coste y latencia.

Empieza gratis

Comparativa directa

Un detalle a destacar: el sistema de autorización para MCP mediante CEL en Agent Router es excelente, y la licencia Apache 2.0 sin restricciones en el plano de datos representa un valor permanente que ningún producto comercial puede ofrecer.

Lecturas relacionadas

• Qué es un LLM Gateway: definición de la categoría
• El mejor AI Gateway en 2026: panorama general del mercado
• Alternativas a Envoy Proxy: la capa de infraestructura subyacente
• Coste total de propiedad (TCO) para infraestructura de GenAI: cómo calcular el coste del desarrollo propio
• Qué es un MCP Gateway: la gestión del tráfico entre herramientas

Conclusión

Agent Router —el proyecto que quizás sigas reconociendo como Envoy AI Gateway— representa uno de los avances más destacados en la infraestructura de IA de código abierto. El plano de datos está impulsado por Envoy. La API es estable y los mantenedores lo han garantizado formalmente por escrito. Seis empresas colaboran activamente para mantenerlo vivo. El modelo de autorización para MCP supera al de la mayoría de las alternativas comerciales. Además, su estrategia open-core es transparente y honesta.

La razón para decantarse por otra solución no radica en la calidad del código, sino en la distribución de las responsabilidades. Agent Router te proporciona la capa de enrutamiento. La consola de gestión, el sistema RBAC de plataforma, la atribución de costes por equipo, los presupuestos globales para la flota, los registros de prompts, los flujos de aprobación, el catálogo de guardrails y las incidencias de soporte a medianoche quedan bajo tu responsabilidad, constituyendo la mayor parte del trabajo de implementación. Un equipo de plataforma con amplios conocimientos en Kubernetes y recursos para mantener esa arquitectura puede asumir su desarrollo. Es una opción totalmente válida y este análisis no pretende desaconsejarla.

Si prefieres no embarcarte en un desarrollo de esa envergadura, la alternativa es optar por un gateway que ya incluya todo ese trabajo resuelto.

Enruta tu primera carga de trabajo con TrueFoundry

Comience gratis