A stack de Engenharia de IA que a Cloudflare construiu internamente usando seus próprios produtos
A Engenharia de IA deixou de ser teoria para virar rotina no dia a dia de desenvolvimento da Cloudflare. E não estamos falando de um projeto piloto ou de uma PoC que ficou esquecida no backlog.
Nos últimos 30 dias, 93% do time de P&D da empresa usou ferramentas de codificação com IA ativamente, em um ambiente construído de ponta a ponta com os próprios produtos que a Cloudflare disponibiliza para o mercado.
Isso por si só já seria um dado interessante, mas o que torna esse case ainda mais relevante é o caminho até chegar lá. Foram onze meses de trabalho real, um time dedicado chamado iMARS (Internal MCP Agent/Server Rollout Squad) e uma arquitetura pensada em três camadas distintas, cada uma resolvendo um problema específico de adoção de IA em escala corporativa.
O resultado? Quase 48 milhões de requisições de IA em um único mês, 295 times usando agentes ativamente, mais de 3.683 usuários internos e um salto no volume de merge requests que a empresa nunca tinha visto antes em um único trimestre. 📈
Neste artigo, a gente mergulha fundo em como essa stack foi construída, quais produtos fazem parte dela, como o Workers AI está sendo usado para cortar custos em até 77% em relação a modelos proprietários e por que essa arquitetura pode servir de referência para qualquer time que queira levar agentes de IA a sério no processo de desenvolvimento.
O time que tornou tudo isso possível: quem é o iMARS
Antes de falar sobre tecnologia, vale entender quem estava por trás das decisões. O iMARS, sigla para Internal MCP Agent/Server Rollout Squad, é o grupo multidisciplinar que reuniu engenheiros de várias áreas da Cloudflare para colocar toda essa stack de Engenharia de IA no ar. Esse time não foi criado para estudar IA em ambientes controlados ou publicar whitepapers. Ele existe para resolver problemas reais de produtividade, escala e segurança dentro de uma empresa que tem mais de 6.100 colaboradores, sendo cerca de 3.683 usuários ativos de ferramentas de IA.
O trabalho do iMARS começou com um diagnóstico honesto: como garantir que ferramentas de IA fossem adotadas de forma segura, sem que os engenheiros precisassem burlar políticas de segurança ou usar soluções externas não auditadas? A resposta veio na forma de uma arquitetura em camadas, onde cada parte do sistema resolve um problema específico sem criar novos riscos.
Depois do esforço inicial, a responsabilidade de manutenção contínua ficou com o time de Dev Productivity, que já era dono de boa parte do ferramental interno da empresa, incluindo CI/CD, sistemas de build e automação. Isso garantiu que o projeto não morresse depois do hype inicial. O iMARS não trabalhou isolado: operou em colaboração direta com as equipes de produto, segurança e infraestrutura, o que explica por que a adoção foi tão rápida e a adesão tão alta. 🤝
A arquitetura em três camadas que sustenta tudo
A stack interna da Cloudflare foi organizada em três atos bem definidos, como a própria empresa descreve: a camada de plataforma, a camada de conhecimento e a camada de enforcement. Entender cada uma delas é essencial para compreender por que o sistema funciona tão bem em escala.
Camada de plataforma: acesso, roteamento e inferência
Tudo começa com autenticação. O Cloudflare Access cuida de toda a parte de identidade e políticas de Zero Trust. Cada engenheiro que acessa qualquer ferramenta de IA precisa ser autenticado via SSO corporativo, sem exceções. Não há tokens compartilhados, não há acessos sem rastreabilidade e não existe forma de usar um modelo de linguagem sem que isso seja registrado e auditável.
Uma vez autenticado, toda requisição a modelos de linguagem passa pelo AI Gateway, que funciona como um ponto centralizado para gerenciar chaves de provedores, rastreamento de custos e políticas de retenção de dados. Em termos práticos, isso significa que a empresa sabe exatamente quanto está gastando com cada modelo, por equipe e por caso de uso.
Os números do AI Gateway nos últimos 30 dias são impressionantes: 20,18 milhões de requisições e 241,37 bilhões de tokens roteados. Dos provedores utilizados, os modelos de fronteira como OpenAI, Anthropic e Google respondem por 91,16% das requisições mensais, enquanto o Workers AI já cobre 8,84% e está em crescimento constante.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
Uma decisão de arquitetura que se mostrou fundamental foi rotear tudo por meio de um único proxy Worker desde o primeiro dia. A equipe poderia ter permitido que os clientes se conectassem diretamente ao AI Gateway, o que seria mais simples de configurar inicialmente. Mas centralizar por um Worker significou que recursos como atribuição por usuário, gerenciamento do catálogo de modelos e controle de permissões puderam ser adicionados depois sem tocar em nenhuma configuração de cliente. Esse padrão de proxy cria um plano de controle que conexões diretas simplesmente não oferecem.
Como funciona na prática: um único URL configura tudo
A experiência do engenheiro começa com um único comando de login. Esse comando dispara uma cadeia que configura provedores, modelos, servidores MCP, agentes, comandos e permissões, tudo sem que o usuário precise mexer em nenhum arquivo de configuração manualmente.
O fluxo funciona assim: o cliente busca configuração de um endpoint de descoberta servido por um Worker. Esse endpoint retorna um bloco de autenticação dizendo como se autenticar, junto com um bloco de configuração contendo provedores, servidores MCP, agentes e permissões padrão. O usuário se autentica pelo mesmo SSO que usa para tudo na Cloudflare, recebe um JWT assinado, e pronto. Cada requisição subsequente carrega esse token automaticamente.
O Worker proxy faz três coisas: serve a configuração compartilhada compilada em tempo de deploy, proxeia requisições para o AI Gateway validando o JWT e reescrevendo headers, e mantém o catálogo de modelos atualizado via um cron trigger que roda a cada hora. Nenhuma chave de API existe nas máquinas dos usuários. O Worker injeta as chaves reais no lado do servidor. 🔐
Para rastreamento anônimo, o Worker mapeia o email do usuário para um UUID usando D1 para armazenamento persistente e KV como cache de leitura. O AI Gateway só vê o UUID anônimo, nunca o email. Isso permite rastreamento de custos por usuário sem expor identidades para provedores de modelos ou logs do Gateway.
O Portal MCP: um único OAuth para múltiplas ferramentas
O portal interno de servidores MCP da Cloudflare agrega 13 servidores de produção que expõem mais de 182 ferramentas cobrindo Backstage, GitLab, Jira, Sentry, Elasticsearch, Prometheus, Google Workspace, um gerenciador de releases interno e mais. Tudo unificado em um único endpoint e um único fluxo de autenticação via Cloudflare Access.
Cada servidor MCP é construído sobre a mesma base: McpAgent do Agents SDK, workers-oauth-provider para OAuth e Cloudflare Access para identidade. Tudo vive em um monorepo com infraestrutura de autenticação compartilhada. Adicionar um novo servidor é basicamente copiar um existente e trocar a API que ele encapsula.
Code Mode: resolvendo o problema de overhead de tokens
MCP é o protocolo certo para conectar agentes de IA a ferramentas, mas tem um problema prático: cada definição de ferramenta consome tokens da janela de contexto antes mesmo do modelo começar a trabalhar. Conforme o número de servidores e ferramentas cresce, o overhead de tokens cresce junto.
O servidor MCP do GitLab, por exemplo, expunha originalmente 34 ferramentas individuais. Esses 34 schemas consumiam aproximadamente 15.000 tokens da janela de contexto por requisição. Em uma janela de 200K tokens, isso é 7,5% do budget desperdiçado antes mesmo de fazer uma pergunta.
O Code Mode resolve isso no nível do portal. Em vez de expor cada definição de ferramenta upstream para o cliente, o portal colapsa tudo em apenas duas ferramentas de nível portal: pesquisa e execução. O modelo descobre e chama ferramentas por meio de código em vez de carregar todos os schemas antecipadamente. Sem Code Mode, cada novo servidor MCP adicionava mais overhead a cada requisição. Com Code Mode no portal, o cliente continua vendo apenas duas ferramentas, independente de quantos servidores estão conectados por trás. Menos contexto desperdiçado, menor custo de tokens e uma arquitetura mais limpa no geral. ⚡
A camada de conhecimento: como os agentes entendem os sistemas
Backstage como o grafo de conhecimento da engenharia
Antes de construir servidores MCP que fossem realmente úteis, a equipe precisou resolver um problema mais fundamental: dados estruturados sobre serviços e infraestrutura. Os agentes precisavam entender contexto fora da base de código, como quem é dono do quê, como os serviços dependem uns dos outros, onde a documentação vive e com quais bancos de dados cada serviço se comunica.
A Cloudflare roda o Backstage, o portal de desenvolvedores open source originalmente criado pelo Spotify, como catálogo de serviços. Os números desse catálogo dão uma dimensão do tamanho do desafio: 2.055 serviços, 167 bibliotecas, 122 pacotes, 228 APIs com definições de schema, 544 sistemas (produtos) em 45 domínios, 1.302 bancos de dados, 277 tabelas ClickHouse, 173 clusters, 375 times e 6.389 usuários com mapeamentos de ownership, além de grafos de dependência conectando serviços aos bancos de dados, tópicos Kafka e recursos de cloud dos quais dependem.
O servidor MCP do Backstage, com suas 13 ferramentas, está disponível pelo Portal MCP. Um agente pode consultar quem é dono de um serviço, verificar suas dependências, encontrar specs de API relacionadas e puxar scores de Tech Insights, tudo sem sair da sessão de codificação. Sem esses dados estruturados, agentes trabalham às cegas. O catálogo transforma repositórios individuais em um mapa conectado de toda a organização de engenharia.
AGENTS.md: preparando milhares de repositórios para IA
No início do rollout, a equipe percebeu um padrão de falha recorrente: agentes de codificação produziam mudanças que pareciam plausíveis mas estavam erradas para o repositório específico. O problema geralmente era contexto local. O modelo não sabia o comando de teste correto, as convenções atuais do time ou quais partes do codebase não deviam ser alteradas.
Isso levou à criação do AGENTS.md: um arquivo curto e estruturado em cada repositório que diz aos agentes de codificação como a base de código realmente funciona. Um arquivo típico inclui informações sobre o runtime, comandos de teste e lint, como navegar pelo codebase, convenções do time, limites que não devem ser ultrapassados e dependências do serviço.
O pipeline de geração puxa metadados de entidades do catálogo Backstage, analisa a estrutura do repositório para detectar linguagem, sistema de build, framework de teste e layout de diretórios, mapeia a stack detectada para padrões relevantes do Engineering Codex, e um modelo capaz gera o documento estruturado. O sistema abre um merge request para que o time responsável possa revisar e refinar.
Foram processados cerca de 3.900 repositórios dessa forma. A primeira passada não foi sempre perfeita, especialmente para repos poliglotas ou setups de build incomuns, mas mesmo essa base já era muito melhor do que pedir aos agentes para inferir tudo do zero. E para manter esses arquivos atualizados, o AI Code Reviewer pode sinalizar quando mudanças no repositório sugerem que o AGENTS.md precisa de atualização. 📋
A camada de enforcement: qualidade em escala
O AI Code Reviewer que analisa 100% dos merge requests
Todo merge request na Cloudflare recebe uma revisão de código por IA. A integração é direta: times adicionam um único componente CI ao pipeline, e a partir daí cada MR é revisado automaticamente.
O revisor é implementado como um componente GitLab CI que, quando um MR é aberto ou atualizado, executa o OpenCode com um coordenador multi-agente. Esse coordenador classifica o MR por nível de risco (trivial, leve ou completo) e delega para agentes de revisão especializados: qualidade de código, segurança, conformidade com o Codex, documentação, performance e impacto de release.
Cada agente se conecta ao AI Gateway para acesso aos modelos, puxa regras do Engineering Codex de um repositório central e lê o AGENTS.md do repositório para contexto. Os resultados são postados como comentários estruturados no MR, divididos por categorias como Segurança, Qualidade de Código e Performance, com níveis de severidade como Crítico, Importante, Sugestão ou Observação Opcional.
O revisor mantém contexto entre iterações. Se flagou algo em uma rodada anterior que já foi corrigido, ele reconhece isso em vez de levantar o mesmo problema novamente. E quando um achado mapeia para uma regra do Engineering Codex, ele cita o ID específico da regra, transformando uma sugestão de IA em uma referência a um padrão organizacional.
Nos últimos 30 dias, o revisor operou com 100% de cobertura em todos os repositórios no pipeline CI padrão, consumindo 5,47 milhões de requisições do AI Gateway e processando 24,77 bilhões de tokens. O Workers AI responde por cerca de 15% do tráfego do revisor, principalmente para tarefas de revisão de documentação onde modelos como o Kimi K2.5 performam bem a uma fração do custo dos modelos de fronteira.
Engineering Codex: padrões de engenharia como habilidades de agentes
O Engineering Codex é o novo sistema interno de padrões da Cloudflare, onde os padrões centrais de engenharia da empresa vivem. Ele passa por um processo de destilação por IA em múltiplos estágios, que produz um conjunto de regras no formato condicional, do tipo se você precisa de X, use Y ou você deve fazer X se estiver fazendo Y ou Z.
Essa skill está disponível para engenheiros usarem localmente enquanto constroem, com prompts como como devo tratar erros no meu serviço Rust ou revise este código TypeScript quanto à conformidade. O time de Network Firewall da empresa, por exemplo, auditou o rampartd usando um processo de consenso multi-agente onde cada requisito foi classificado como CONFORME, PARCIAL ou NÃO-CONFORME com detalhes específicos de violação e passos de remediação, reduzindo o que antes exigia semanas de trabalho manual a um processo estruturado e repetível.
A integração entre Backstage, AGENTS.md, o AI Code Reviewer e o Engineering Codex é o que torna o sistema maior que a soma das partes. Quando um agente pode puxar contexto do catálogo de serviços, ler o AGENTS.md do repositório que está editando e ser revisado contra regras do Codex pela mesma toolchain, o primeiro rascunho geralmente já está próximo o suficiente para ser enviado. Isso não era verdade seis meses atrás.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Workers AI e o papel central na redução de custos
O Workers AI é a plataforma de inferência serverless da Cloudflare que roda modelos open source em GPUs espalhadas pela rede global da empresa. Além das melhorias massivas de custo em comparação com modelos de fronteira, uma vantagem chave é que a inferência fica na mesma rede que seus Workers, Durable Objects e armazenamento. Sem saltos entre clouds, o que reduz latência, elimina instabilidade de rede e diminui a configuração adicional de networking necessária.
Nos últimos 30 dias, o Workers AI processou 51,47 bilhões de tokens de entrada e 361,12 milhões de tokens de saída. O Kimi K2.5, lançado no Workers AI em março de 2026, é um modelo open source de escala de fronteira com janela de contexto de 256K, chamada de ferramentas e saídas estruturadas. Um agente de segurança da Cloudflare processa mais de 7 bilhões de tokens por dia usando o Kimi. Em um modelo proprietário de nível médio, isso custaria estimados US$ 2,4 milhões por ano. No Workers AI, sai 77% mais barato. 💰
Além de segurança, o Workers AI é usado para revisão de documentação no pipeline de CI, para gerar arquivos AGENTS.md em milhares de repositórios e para tarefas de inferência leves onde latência na mesma rede importa mais do que capacidade de pico do modelo. Conforme modelos open source continuam a melhorar, a expectativa é que o Workers AI absorva uma parcela cada vez maior das cargas de trabalho internas.
Os números que resumem o impacto
De lançar o esforço até atingir 93% de adoção no P&D levou menos de um ano. Aqui vai o panorama completo dos últimos 30 dias:
- 3.683 usuários ativos usando ferramentas de codificação com IA (60% da empresa inteira, 93% do P&D)
- 47,95 milhões de mensagens de IA
- 295 times utilizando agentes e assistentes de codificação
- 27,08 milhões de mensagens via OpenCode
- 434,9 mil mensagens via Windsurf
- 20,18 milhões de requisições no AI Gateway
- 241,37 bilhões de tokens roteados pelo AI Gateway
- 51,83 bilhões de tokens processados no Workers AI
A média móvel de 4 semanas de merge requests subiu de aproximadamente 5.600 por semana para mais de 8.700. Na semana de 23 de março, o número atingiu 10.952, quase o dobro da baseline do Q4. Esse é provavelmente o indicador mais concreto de que as ferramentas de IA estão tendo impacto real na velocidade de desenvolvimento.
O que vem a seguir: agentes em background
A próxima evolução da stack interna inclui agentes em background, que podem ser iniciados sob demanda com as mesmas ferramentas disponíveis localmente (Portal MCP, git, runners de teste) mas rodando inteiramente na nuvem. A arquitetura usa Durable Objects e o Agents SDK para orquestração, delegando para containers Sandbox quando o trabalho exige um ambiente de desenvolvimento completo, como clonar um repositório, instalar dependências ou rodar testes.
O Sandbox SDK entrou em disponibilidade geral durante a Agents Week, e agentes de longa duração agora são suportados nativamente no Agents SDK. Isso resolve o problema de sessão durável que antes exigia workarounds. O SDK agora suporta sessões que rodam por períodos estendidos sem eviction, tempo suficiente para um agente clonar um repositório grande, rodar uma suíte de testes completa, iterar sobre falhas e abrir um MR em uma única sessão. 🔄
O que esse case ensina sobre adoção de IA em escala
Olhando para o conjunto, o que chama mais atenção nesse case não é a tecnologia em si, mas o processo de adoção. Conseguir que 93% do time de P&D de uma empresa do tamanho da Cloudflare use ferramentas de IA ativamente em menos de um ano é um resultado que a maioria das organizações não consegue nem de perto. E o motivo é quase sempre o mesmo: falta de confiança nas ferramentas, preocupações com segurança de dados ou simplesmente ferramentas que não se encaixam no fluxo real de trabalho dos engenheiros.
A Cloudflare resolveu esses três problemas de forma sistemática. A confiança veio do fato de que as ferramentas foram construídas internamente, com os mesmos padrões de segurança que a empresa aplica nos seus produtos comerciais. As preocupações com segurança foram endereçadas pelo modelo de Zero Trust, que garante rastreabilidade total. E o problema do encaixe no fluxo de trabalho foi resolvido pelas integrações diretas nos editores e pelo enriquecimento automático de contexto.
Um detalhe que merece destaque: toda a infraestrutura listada, com exceção do Backstage, é composta por produtos que a Cloudflare vende comercialmente. Isso significa que qualquer empresa pode replicar essa arquitetura usando as mesmas ferramentas. Não é infraestrutura interna proprietária. É produto público, testado em escala pela própria empresa que o construiu.
Para times que estão pensando em construir algo parecido, a lição mais valiosa desse case é provavelmente essa: comece pelos problemas reais dos engenheiros, não pelas capacidades dos modelos. A Cloudflare não perguntou o que a IA consegue fazer, mas sim onde os nossos engenheiros estão perdendo mais tempo, e trabalhou de trás para frente a partir disso. Esse tipo de orientação por problema, em vez de orientação por tecnologia, é o que separa uma adoção bem-sucedida de mais um projeto que ficou no piloto para sempre. 🎯
