# Por que a Stripe abandonou o localhost ao rodar centenas de agentes — e depois de testar a noite toda, eu entendi o motivo > Author: Tony Lee > Published: 2026-03-03 > URL: https://tonylee.im/pt/blog/why-stripe-abandoned-localhost-for-agent-fleet/ > Reading time: 5 minutes > Language: pt > Tags: ai, ai-agent, devops, infrastructure, stripe, developer-productivity ## Description Num hackathon de 12 horas construindo um produto apenas com agentes, eu entendi na prática por que a Stripe Minions e o Ramp Inspect escolheram ambientes isolados na nuvem. ## Content Ontem à noite, o hackathon tinha uma regra simples: às 20h eu configurava a especificação e o harness, e às 8h da manhã tirava as mãos do teclado. Doze horas de experimento — produto construído exclusivamente por agentes. Foi nessas 12 horas que entendi, na prática, por que a Stripe declarou "o localhost acabou" ao lançar a [plataforma Minions](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents), e por que a Ramp chegou à mesma conclusão ao descrever a construção do [Inspect, seu próprio agente em background](https://builders.ramp.com/post/why-we-built-our-background-agent). ## Rodar agentes em paralelo no notebook vira briga Quando vários agentes rodam na mesma máquina, o estado começa a colidir. Segredos se sobrepõem, portas conflitam, e se a máquina entrar em modo de suspensão, o loop de 12 horas vai inteiro para o lixo. Quando a Stripe e a Ramp publicaram suas arquiteturas de agentes, havia um ponto em comum: ambas adotaram a estratégia de dar a cada agente uma VM isolada e um container de desenvolvimento próprio. Os Minions da Stripe rodam num ambiente isolado chamado "devbox" — mesmo tipo de máquina que os engenheiros usam, mas completamente isolado dos recursos de produção e da internet. O spin-up leva 10 segundos e suporta execução paralela de tarefas sem o overhead de git worktrees. O Inspect da Ramp foi construído sobre o Modal Sandbox. Cada sessão tem seu próprio stack completo — Postgres, Redis, Temporal, RabbitMQ — sem nenhuma disputa entre sessões. E graças aos snapshots do sistema de arquivos, a inicialização é quase instantânea. Agentes de codificação interativos precisam da sua atenção. Agentes em background não precisam de nenhuma das duas coisas. Durante a madrugada, vi com os próprios olhos o loop inteiro parar por causa de uma única suspensão da máquina. Em uma VM na nuvem, isso simplesmente não acontece. ## Executar tarefas em sequência gera só features simples Esse foi o ponto mais doloroso do hackathon. Rodando agentes de forma sequencial, o CRUD básico sai. O problema começa quando surgem dependências. O que um módulo entregou na frente era constantemente sobrescrito ou quebrado pelo agente que rodava depois. Aqui é onde vale separar dois conceitos: agent fleet e agent swarm. **Agent fleet** é o padrão usado para aplicar uma mesma mudança em vários repositórios ao mesmo tempo. É por isso que a Stripe consegue mergear mais de 1.000 PRs por semana: a mesma migração, a mesma correção de lint, empurrada para centenas de serviços de uma vez. **Agent swarm** é o padrão onde agentes diferentes cuidam de partes distintas e convergem para um único resultado — frontend, backend e testes em agentes separados, integrados via PRs. Sem execução paralela seguida de merge por PR, produtos complexos simplesmente não saem. Testei os dois na prática e a diferença de qualidade entre paralelo com revisão de merge e sequencial foi gritante. ## Rate limit e comunicação entre agentes são problemas de infraestrutura, não de prompt Nas 12 horas de loop, evitar rate limit era impossível. Além disso, o fluxo precisava que um agente revisasse commits feitos por outro e reinterpretasse automaticamente partes ambíguas da especificação. Existe uma frase que resume bem: "escrever 'não delete arquivos' no system prompt é um pedido, não um controle." É exatamente isso. A Stripe resolveu isso na camada de execução. Os Minions têm acesso a recursos de produção e à internet bloqueados na origem — o que permite execução segura sem precisar checar permissões a cada passo. Mais de 400 ferramentas MCP são hospedadas num servidor interno chamado "Toolshed", com conjuntos curados de ferramentas acessíveis por cada agente. A Ramp exige que os PRs sejam criados via GitHub OAuth, vinculados a contas reais de usuário — não a IDs de app. Isso garante estruturalmente que nenhum código seja mergeado sem revisão. Travar o escopo de permissões na camada de execução, manter logs de auditoria e limitar o raio de falha: sem isso, nenhum time de segurança vai aprovar agentes autônomos em produção. ## O indivíduo pode acelerar sem que a organização acelere junto Existe um fenômeno que dá para chamar de "falso cume": você adota agentes de codificação, os PRs explodem, mas o cycle time continua igual. As revisões acumulam, o CI quebra, os conflitos de merge se empilham. No hackathon também foi assim — os agentes geravam código rápido. O gargalo era juntar e validar tudo isso. A Stripe resolve esse gargalo com automação. Os Minions usam uma orquestração híbrida que intercala loops de agente com operações de código determinísticas. Lint, testes e operações git sempre terminam, mas sem sufocar a criatividade do agente. Os testes de CI têm limite de duas tentativas, para evitar loops infinitos. A Ramp usa número de PRs mergeados como métrica central de sucesso. Mais de 50% dos PRs criados pelo Inspect são efetivamente mergeados, e mais de 80% do próprio Inspect foi escrito pelo Inspect. Para a velocidade organizacional acompanhar, agentes em background precisam tratar revisão de PR, análise de falhas de CI e resolução de conflitos de merge antes que um humano precise intervir. A mudança essencial é sair do "in the loop" (controle direto) para o "on the loop" (revisão de resultado). ## A batalha não é sobre velocidade de geração, mas sobre estrutura de integração Gerar código rápido com agentes já é um problema resolvido. A Stripe tem mais de 1.000 PRs por semana criados por agentes; a Ramp tem mais da metade de todos os seus PRs gerados assim. A verdadeira disputa é projetar o sistema que integra com segurança o que esses agentes produzem: ambiente de execução isolado, estrutura de paralelo com merge, governança no nível de infraestrutura e validação automatizada. Sem esses quatro pilares, o agente é só um brinquedo rápido. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/pt/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.