El stack de Ingeniería de IA que Cloudflare construyó internamente usando sus propios productos
La Ingeniería de IA dejó de ser teoría para convertirse en rutina en el día a día de desarrollo de Cloudflare. Y no estamos hablando de un proyecto piloto o de una PoC que quedó olvidada en el backlog.
En los últimos 30 días, el 93% del equipo de I+D de la empresa usó herramientas de codificación con IA de forma activa, en un entorno construido de punta a punta con los propios productos que Cloudflare ofrece al mercado.
Eso por sí solo ya sería un dato interesante, pero lo que hace este caso aún más relevante es el camino recorrido para llegar hasta ahí. Fueron once meses de trabajo real, un equipo dedicado llamado iMARS (Internal MCP Agent/Server Rollout Squad) y una arquitectura pensada en tres capas distintas, cada una resolviendo un problema específico de adopción de IA a escala corporativa.
¿El resultado? Casi 48 millones de solicitudes de IA en un solo mes, 295 equipos usando agentes activamente, más de 3.683 usuarios internos y un salto en el volumen de merge requests que la empresa nunca había visto en un solo trimestre. 📈
En este artículo nos sumergimos a fondo en cómo se construyó este stack, qué productos forman parte de él, cómo Workers AI está siendo utilizado para recortar costos hasta un 77% en comparación con modelos propietarios y por qué esta arquitectura puede servir de referencia para cualquier equipo que quiera tomarse en serio los agentes de IA en el proceso de desarrollo.
El equipo que hizo todo esto posible: quién es iMARS
Antes de hablar de tecnología, vale la pena entender quién estaba detrás de las decisiones. iMARS, sigla de Internal MCP Agent/Server Rollout Squad, es el grupo multidisciplinario que reunió ingenieros de varias áreas de Cloudflare para poner en marcha todo este stack de Ingeniería de IA. Este equipo no fue creado para estudiar IA en entornos controlados ni publicar whitepapers. Existe para resolver problemas reales de productividad, escala y seguridad dentro de una empresa que tiene más de 6.100 colaboradores, de los cuales aproximadamente 3.683 son usuarios activos de herramientas de IA.
El trabajo de iMARS comenzó con un diagnóstico honesto: ¿cómo garantizar que las herramientas de IA fueran adoptadas de forma segura, sin que los ingenieros necesitaran saltarse políticas de seguridad o usar soluciones externas no auditadas? La respuesta llegó en forma de una arquitectura por capas, donde cada parte del sistema resuelve un problema específico sin crear nuevos riesgos.
Después del esfuerzo inicial, la responsabilidad de mantenimiento continuo quedó en manos del equipo de Dev Productivity, que ya era dueño de buena parte del herramental interno de la empresa, incluyendo CI/CD, sistemas de build y automatización. Esto garantizó que el proyecto no muriera después del hype inicial. iMARS no trabajó aislado: operó en colaboración directa con los equipos de producto, seguridad e infraestructura, lo que explica por qué la adopción fue tan rápida y la adhesión tan alta. 🤝
La arquitectura en tres capas que sostiene todo
El stack interno de Cloudflare fue organizado en tres actos bien definidos, como la propia empresa lo describe: la capa de plataforma, la capa de conocimiento y la capa de enforcement. Entender cada una de ellas es esencial para comprender por qué el sistema funciona tan bien a escala.
Capa de plataforma: acceso, enrutamiento e inferencia
Todo comienza con la autenticación. Cloudflare Access se encarga de toda la parte de identidad y políticas de Zero Trust. Cada ingeniero que accede a cualquier herramienta de IA necesita autenticarse vía SSO corporativo, sin excepciones. No hay tokens compartidos, no hay accesos sin trazabilidad y no existe forma de usar un modelo de lenguaje sin que eso quede registrado y sea auditable.
Una vez autenticado, toda solicitud a modelos de lenguaje pasa por el AI Gateway, que funciona como un punto centralizado para gestionar claves de proveedores, seguimiento de costos y políticas de retención de datos. En términos prácticos, esto significa que la empresa sabe exactamente cuánto está gastando con cada modelo, por equipo y por caso de uso.
Los números del AI Gateway en los últimos 30 días son impresionantes: 20,18 millones de solicitudes y 241,37 mil millones de tokens enrutados. De los proveedores utilizados, los modelos de frontera como OpenAI, Anthropic y Google responden por el 91,16% de las solicitudes mensuales, mientras que Workers AI ya cubre el 8,84% y está en crecimiento constante.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Una decisión de arquitectura que resultó fundamental fue enrutar todo a través de un único proxy Worker desde el primer día. El equipo podría haber permitido que los clientes se conectaran directamente al AI Gateway, lo que habría sido más sencillo de configurar inicialmente. Pero centralizar por un Worker significó que funcionalidades como atribución por usuario, gestión del catálogo de modelos y control de permisos pudieron añadirse después sin tocar ninguna configuración de cliente. Este patrón de proxy crea un plano de control que las conexiones directas simplemente no ofrecen.
Cómo funciona en la práctica: una sola URL lo configura todo
La experiencia del ingeniero comienza con un único comando de login. Ese comando dispara una cadena que configura proveedores, modelos, servidores MCP, agentes, comandos y permisos, todo sin que el usuario necesite tocar ningún archivo de configuración manualmente.
El flujo funciona así: el cliente busca la configuración de un endpoint de descubrimiento servido por un Worker. Ese endpoint devuelve un bloque de autenticación indicando cómo autenticarse, junto con un bloque de configuración que contiene proveedores, servidores MCP, agentes y permisos por defecto. El usuario se autentica con el mismo SSO que usa para todo en Cloudflare, recibe un JWT firmado, y listo. Cada solicitud posterior lleva ese token automáticamente.
El Worker proxy hace tres cosas: sirve la configuración compartida compilada en tiempo de deploy, hace proxy de las solicitudes hacia el AI Gateway validando el JWT y reescribiendo headers, y mantiene el catálogo de modelos actualizado mediante un cron trigger que se ejecuta cada hora. Ninguna clave de API existe en las máquinas de los usuarios. El Worker inyecta las claves reales del lado del servidor. 🔐
Para el rastreo anónimo, el Worker mapea el email del usuario a un UUID usando D1 para almacenamiento persistente y KV como caché de lectura. El AI Gateway solo ve el UUID anónimo, nunca el email. Esto permite el seguimiento de costos por usuario sin exponer identidades a proveedores de modelos o logs del Gateway.
El Portal MCP: un único OAuth para múltiples herramientas
El portal interno de servidores MCP de Cloudflare agrega 13 servidores de producción que exponen más de 182 herramientas cubriendo Backstage, GitLab, Jira, Sentry, Elasticsearch, Prometheus, Google Workspace, un gestor de releases interno y más. Todo unificado en un único endpoint y un único flujo de autenticación vía Cloudflare Access.
Cada servidor MCP está construido sobre la misma base: McpAgent del Agents SDK, workers-oauth-provider para OAuth y Cloudflare Access para identidad. Todo vive en un monorepo con infraestructura de autenticación compartida. Añadir un nuevo servidor es básicamente copiar uno existente y cambiar la API que encapsula.
Code Mode: resolviendo el problema de overhead de tokens
MCP es el protocolo correcto para conectar agentes de IA a herramientas, pero tiene un problema práctico: cada definición de herramienta consume tokens de la ventana de contexto antes incluso de que el modelo empiece a trabajar. Conforme crece el número de servidores y herramientas, el overhead de tokens crece con ellos.
El servidor MCP de GitLab, por ejemplo, exponía originalmente 34 herramientas individuales. Esos 34 schemas consumían aproximadamente 15.000 tokens de la ventana de contexto por solicitud. En una ventana de 200K tokens, eso es un 7,5% del presupuesto desperdiciado antes siquiera de hacer una pregunta.
Code Mode resuelve esto a nivel del portal. En lugar de exponer cada definición de herramienta upstream hacia el cliente, el portal colapsa todo en solo dos herramientas de nivel portal: búsqueda y ejecución. El modelo descubre y llama herramientas mediante código en lugar de cargar todos los schemas por adelantado. Sin Code Mode, cada nuevo servidor MCP añadía más overhead a cada solicitud. Con Code Mode en el portal, el cliente sigue viendo solo dos herramientas, independientemente de cuántos servidores estén conectados por detrás. Menos contexto desperdiciado, menor costo de tokens y una arquitectura más limpia en general. ⚡
La capa de conocimiento: cómo los agentes entienden los sistemas
Backstage como el grafo de conocimiento de la ingeniería
Antes de construir servidores MCP que fueran realmente útiles, el equipo necesitó resolver un problema más fundamental: datos estructurados sobre servicios e infraestructura. Los agentes necesitaban entender contexto fuera de la base de código, como quién es dueño de qué, cómo los servicios dependen unos de otros, dónde vive la documentación y con qué bases de datos se comunica cada servicio.
Cloudflare ejecuta Backstage, el portal de desarrolladores open source creado originalmente por Spotify, como catálogo de servicios. Los números de ese catálogo dan una dimensión del tamaño del desafío: 2.055 servicios, 167 bibliotecas, 122 paquetes, 228 APIs con definiciones de schema, 544 sistemas (productos) en 45 dominios, 1.302 bases de datos, 277 tablas ClickHouse, 173 clusters, 375 equipos y 6.389 usuarios con mapeos de ownership, además de grafos de dependencia conectando servicios a las bases de datos, tópicos Kafka y recursos de cloud de los que dependen.
El servidor MCP de Backstage, con sus 13 herramientas, está disponible a través del Portal MCP. Un agente puede consultar quién es dueño de un servicio, verificar sus dependencias, encontrar specs de API relacionadas y obtener scores de Tech Insights, todo sin salir de la sesión de codificación. Sin esos datos estructurados, los agentes trabajan a ciegas. El catálogo transforma repositorios individuales en un mapa conectado de toda la organización de ingeniería.
AGENTS.md: preparando miles de repositorios para IA
Al inicio del despliegue, el equipo detectó un patrón de fallo recurrente: los agentes de codificación producían cambios que parecían plausibles pero estaban equivocados para el repositorio específico. El problema generalmente era contexto local. El modelo no sabía el comando de test correcto, las convenciones actuales del equipo o qué partes del codebase no debían ser alteradas.
Eso llevó a la creación de AGENTS.md: un archivo corto y estructurado en cada repositorio que le dice a los agentes de codificación cómo funciona realmente la base de código. Un archivo típico incluye información sobre el runtime, comandos de test y lint, cómo navegar por el codebase, convenciones del equipo, límites que no deben traspasarse y dependencias del servicio.
El pipeline de generación extrae metadatos de entidades del catálogo Backstage, analiza la estructura del repositorio para detectar lenguaje, sistema de build, framework de testing y layout de directorios, mapea el stack detectado a patrones relevantes del Engineering Codex, y un modelo capaz genera el documento estructurado. El sistema abre un merge request para que el equipo responsable pueda revisar y refinar.
Se procesaron cerca de 3.900 repositorios de esta forma. La primera pasada no fue siempre perfecta, especialmente para repos políglotas o setups de build poco comunes, pero incluso esa base ya era mucho mejor que pedirle a los agentes que infirieran todo desde cero. Y para mantener estos archivos actualizados, el AI Code Reviewer puede señalar cuándo los cambios en el repositorio sugieren que el AGENTS.md necesita actualización. 📋
La capa de enforcement: calidad a escala
El AI Code Reviewer que analiza el 100% de los merge requests
Todo merge request en Cloudflare recibe una revisión de código por IA. La integración es directa: los equipos añaden un único componente CI al pipeline, y a partir de ahí cada MR es revisado automáticamente.
El revisor está implementado como un componente GitLab CI que, cuando un MR se abre o se actualiza, ejecuta OpenCode con un coordinador multi-agente. Ese coordinador clasifica el MR por nivel de riesgo (trivial, leve o completo) y delega a agentes de revisión especializados: calidad de código, seguridad, conformidad con el Codex, documentación, rendimiento e impacto de release.
Cada agente se conecta al AI Gateway para acceder a los modelos, extrae reglas del Engineering Codex de un repositorio central y lee el AGENTS.md del repositorio para obtener contexto. Los resultados se publican como comentarios estructurados en el MR, divididos por categorías como Seguridad, Calidad de Código y Rendimiento, con niveles de severidad como Crítico, Importante, Sugerencia u Observación Opcional.
El revisor mantiene contexto entre iteraciones. Si señaló algo en una ronda anterior que ya fue corregido, lo reconoce en lugar de levantar el mismo problema de nuevo. Y cuando un hallazgo se corresponde con una regla del Engineering Codex, cita el ID específico de la regla, transformando una sugerencia de IA en una referencia a un estándar organizacional.
En los últimos 30 días, el revisor operó con 100% de cobertura en todos los repositorios del pipeline CI estándar, consumiendo 5,47 millones de solicitudes del AI Gateway y procesando 24,77 mil millones de tokens. Workers AI responde por cerca del 15% del tráfico del revisor, principalmente para tareas de revisión de documentación donde modelos como Kimi K2.5 rinden bien a una fracción del costo de los modelos de frontera.
Engineering Codex: estándares de ingeniería como habilidades de agentes
El Engineering Codex es el nuevo sistema interno de estándares de Cloudflare, donde viven los estándares centrales de ingeniería de la empresa. Pasa por un proceso de destilación por IA en múltiples etapas, que produce un conjunto de reglas en formato condicional, del tipo si necesitas X, usa Y o debes hacer X si estás haciendo Y o Z.
Esta skill está disponible para que los ingenieros la usen localmente mientras desarrollan, con prompts como cómo debo manejar errores en mi servicio Rust o revisa este código TypeScript en cuanto a conformidad. El equipo de Network Firewall de la empresa, por ejemplo, auditó rampartd usando un proceso de consenso multi-agente donde cada requisito fue clasificado como CONFORME, PARCIAL o NO-CONFORME con detalles específicos de violación y pasos de remediación, reduciendo lo que antes requería semanas de trabajo manual a un proceso estructurado y repetible.
La integración entre Backstage, AGENTS.md, el AI Code Reviewer y el Engineering Codex es lo que hace que el sistema sea mayor que la suma de sus partes. Cuando un agente puede extraer contexto del catálogo de servicios, leer el AGENTS.md del repositorio que está editando y ser revisado contra reglas del Codex por la misma toolchain, el primer borrador generalmente ya está lo suficientemente cerca como para ser enviado. Esto no era así hace seis meses.
Herramientas que usamos a diario
Workers AI y su papel central en la reducción de costos
Workers AI es la plataforma de inferencia serverless de Cloudflare que ejecuta modelos open source en GPUs distribuidas por la red global de la empresa. Además de las mejoras masivas de costo en comparación con modelos de frontera, una ventaja clave es que la inferencia queda en la misma red que tus Workers, Durable Objects y almacenamiento. Sin saltos entre clouds, lo que reduce latencia, elimina inestabilidad de red y disminuye la configuración adicional de networking necesaria.
En los últimos 30 días, Workers AI procesó 51,47 mil millones de tokens de entrada y 361,12 millones de tokens de salida. Kimi K2.5, lanzado en Workers AI en marzo de 2026, es un modelo open source de escala de frontera con ventana de contexto de 256K, llamada de herramientas y salidas estructuradas. Un agente de seguridad de Cloudflare procesa más de 7 mil millones de tokens por día usando Kimi. En un modelo propietario de nivel medio, eso costaría un estimado de US$ 2,4 millones al año. En Workers AI, sale un 77% más barato. 💰
Además de seguridad, Workers AI se usa para revisión de documentación en el pipeline de CI, para generar archivos AGENTS.md en miles de repositorios y para tareas de inferencia ligeras donde la latencia en la misma red importa más que la capacidad pico del modelo. A medida que los modelos open source continúan mejorando, la expectativa es que Workers AI absorba una porción cada vez mayor de las cargas de trabajo internas.
Los números que resumen el impacto
Desde el lanzamiento del esfuerzo hasta alcanzar el 93% de adopción en I+D pasó menos de un año. Aquí va el panorama completo de los últimos 30 días:
- 3.683 usuarios activos usando herramientas de codificación con IA (60% de la empresa entera, 93% de I+D)
- 47,95 millones de mensajes de IA
- 295 equipos utilizando agentes y asistentes de codificación
- 27,08 millones de mensajes vía OpenCode
- 434,9 mil mensajes vía Windsurf
- 20,18 millones de solicitudes en el AI Gateway
- 241,37 mil millones de tokens enrutados por el AI Gateway
- 51,83 mil millones de tokens procesados en Workers AI
El promedio móvil de 4 semanas de merge requests subió de aproximadamente 5.600 por semana a más de 8.700. En la semana del 23 de marzo, el número alcanzó 10.952, casi el doble de la baseline del Q4. Este es probablemente el indicador más concreto de que las herramientas de IA están teniendo un impacto real en la velocidad de desarrollo.
Lo que viene después: agentes en background
La próxima evolución del stack interno incluye agentes en background, que pueden ser iniciados bajo demanda con las mismas herramientas disponibles localmente (Portal MCP, git, runners de tests) pero ejecutándose completamente en la nube. La arquitectura usa Durable Objects y el Agents SDK para orquestación, delegando a containers Sandbox cuando el trabajo exige un entorno de desarrollo completo, como clonar un repositorio, instalar dependencias o ejecutar tests.
El Sandbox SDK entró en disponibilidad general durante la Agents Week, y los agentes de larga duración ahora están soportados nativamente en el Agents SDK. Esto resuelve el problema de sesión durable que antes requería workarounds. El SDK ahora soporta sesiones que corren por períodos extendidos sin eviction, tiempo suficiente para que un agente clone un repositorio grande, ejecute una suite de tests completa, itere sobre fallos y abra un MR en una sola sesión. 🔄
Lo que este caso enseña sobre adopción de IA a escala
Mirando el conjunto, lo que más llama la atención en este caso no es la tecnología en sí, sino el proceso de adopción. Conseguir que el 93% del equipo de I+D de una empresa del tamaño de Cloudflare use herramientas de IA activamente en menos de un año es un resultado que la mayoría de las organizaciones ni se acercan a lograr. Y el motivo es casi siempre el mismo: falta de confianza en las herramientas, preocupaciones con la seguridad de datos o simplemente herramientas que no encajan en el flujo real de trabajo de los ingenieros.
Cloudflare resolvió esos tres problemas de forma sistemática. La confianza vino del hecho de que las herramientas fueron construidas internamente, con los mismos estándares de seguridad que la empresa aplica en sus productos comerciales. Las preocupaciones de seguridad fueron abordadas por el modelo de Zero Trust, que garantiza trazabilidad total. Y el problema del encaje en el flujo de trabajo fue resuelto por las integraciones directas en los editores y por el enriquecimiento automático de contexto.
Un detalle que merece destacarse: toda la infraestructura mencionada, con excepción de Backstage, está compuesta por productos que Cloudflare vende comercialmente. Esto significa que cualquier empresa puede replicar esta arquitectura usando las mismas herramientas. No es infraestructura interna propietaria. Es producto público, probado a escala por la propia empresa que lo construyó.
Para equipos que están pensando en construir algo parecido, la lección más valiosa de este caso es probablemente esta: empezar por los problemas reales de los ingenieros, no por las capacidades de los modelos. Cloudflare no preguntó qué puede hacer la IA, sino dónde están perdiendo más tiempo nuestros ingenieros, y trabajó hacia atrás a partir de eso. Este tipo de orientación por problema, en lugar de orientación por tecnología, es lo que separa una adopción exitosa de un proyecto más que se quedó en piloto para siempre. 🎯
