Cloudflare ha fusionado Workers AI y AI Gateway en un único control plane. Quien gestiona agentes en producción ahora tiene observabilidad, facturación y routing dinámico sobre GPU gestionadas y proveedores externos desde una sola interfaz, con bindings unificados y model-first routing.

Por qué te importa. Si estás llevando agentes a producción, el reto real es gestionar quién llama a qué, cuánto cuesta cada llamada y qué pasa cuando un proveedor falla, más que elegir qué modelo usar. Hasta ahora, quien usaba Cloudflare debía tratar la inferencia gestionada (Workers AI) y el gateway de routing (AI Gateway) como dos cosas separadas: dos sistemas de logs, dos contadores, dos configuraciones.

Ahora el routing decide en tiempo de ejecución según el modelo solicitado y el estado de los proveedores. Si un endpoint es lento o tiene un rate limit activo, la solicitud se redirige a otra ruta sin que el agente se entere. Para quien tiene agentes corriendo toda la noche, esto significa menos pipelines personalizados y menos tiempo persiguiendo logs dispersos.

Este movimiento se alinea con la línea que hemos seguido esta semana: el 5 de agosto Cloudflare había presentado el modelo zero trust para llevar agentes a producción, y el 7 de agosto había cerrado la pila infraestructural con navegadores sin estado, MCP sin estado y pagos. El control plane unificado es la pieza que mantiene cohesionados governance y routing: la última capa de esa misma arquitectura.

Si quieres probarlo. La documentación del control plane unificado está en el blog de Cloudflare. Antes de configurar los bindings unificados en tus agentes, vale la pena verificar la disponibilidad real de los modelos que usas en las GPU gestionadas de Cloudflare, porque el catálogo no coincide con el de los proveedores externos.

En detalle

Cómo era antes.

Workers AI y AI Gateway eran dos productos con dos propósitos. Workers AI ejecutaba modelos open-weight en las GPU de Cloudflare en el edge: inferencia gestionada, precio por token, nada que orquestar. AI Gateway era un proxy frente a proveedores externos (OpenAI, Anthropic, Google) para añadir caching, rate limiting, logging y fallback. Quien quería ambos debía gestionarlos manualmente: dos dashboards, dos lógicas de routing, dos sistemas de facturación.

Qué cambia.

La unificación lleva todo bajo un único control plane. Los conceptos clave para quien no desarrolla:

• Bindings unificados. En Cloudflare Workers, un binding es cómo el código se conecta a un servicio. Ahora un único binding da acceso tanto a los modelos gestionados en las GPU de Cloudflare como a los proveedores externos. Adiós a dos configuraciones separadas.
• Model-first routing. En lugar de especificar un endpoint y un proveedor, solicitas un modelo por nombre. El sistema descubre automáticamente dónde servirlo: en tu propia infraestructura, en un proveedor externo, o en ambos con fallback.
• Observabilidad y facturación en un lugar. Logs, métricas y facturación convergen en una sola vista. Para quien tiene agentes en producción, esto resuelve el problema práctico de entender cuánto cuesta realmente cada llamada y dónde falla.

Cómo encaja en el panorama.

Cloudflare está construyendo una pila completa para agentes en producción: runtime, navegadores sin estado, MCP sin estado, pagos autónomos, zero trust. El control plane unificado es la capa de governance que mantiene cohesionadas las otras. Si el runtime decide dónde corre el agente y el protocolo decide cómo habla con las herramientas, el control plane decide qué modelo responde y cuánto cuesta.

Limitaciones y preguntas abiertas.

El catálogo de Workers AI (modelos gestionados en las GPU de Cloudflare) sigue siendo más pequeño que el de los proveedores externos. Si un agente necesita un modelo específico de última generación, el model-first routing lo encamina al proveedor externo, pero la ventaja del panel único se reduce a governance, sin reducción en costos de inferencia. El post no entra en detalles sobre cómo el routing dinámico evalúa latencia y disponibilidad en tiempo real, ni sobre cuán transparente es el fallback entre proveedores para el agente o si requiere gestión de estado.

Como con todos los anuncios de esta semana, la práctica dirá si la unificación es real en facturación y logs o si es solo un nivel cosmético sobre dos sistemas aún separados.