Autores do post: @SantoshPraneeth e @jeffizhungry
O Flux é a plataforma de agentes baseada em nuvem da DoorDash para engenheiros. Em um único mês de 2026, usamos o Flux para automatizar 130.000 tarefas de engenharia. Em rápida expansão desde sua estreia no primeiro trimestre de 2026, o Flux já alimenta fluxos de trabalho em segundo plano de alto volume em toda a DoorDash, incluindo mais de 25.000 revisões de código automatizadas por semana, além de mais de 300 playbooks distintos e mais de 10.000 invocações usadas toda semana. Esses fluxos de trabalho podem ser executados sem supervisão, em paralelo, 24 horas por dia.
Vamos detalhar as limitações que nos levaram a ir além das cargas de trabalho de agentes que rodam localmente em laptops, por que escolhemos construir o Flux internamente em vez de depender apenas de agentes de codificação hospedados, e os primitivos da plataforma, como sandboxes de agentes, gateway MCP, playbooks e superfícies de invocação, para tornar a delegação a agentes repetível e segura.
Casos de uso de fluxos de trabalho em segundo plano no Flux
Um retrato do uso do Flux na DoorDash em um único mês, abrangendo revisões de código automatizadas, execuções de playbooks e conclusões de tarefas em segundo plano
Por onde começamos
No último ano, usuários que executam cargas de trabalho de agentes em seus laptops rapidamente encontraram limitações:
- Recursos e disponibilidade. Um laptop tem um número fixo de núcleos de CPU, memória limitada e uma bateria, tudo compartilhado com todos os aplicativos. Fluxos de trabalho de agentes frequentemente precisam executar tarefas computacionalmente intensivas, como builds, testes e buscas extensas em paralelo, fazendo com que os laptops esgotem rapidamente sua capacidade. Os fluxos de trabalho também dependem de o dispositivo estar ligado, conectado e disponível; o trabalho é pausado quando um engenheiro fecha o laptop, perde a conectividade ou se afasta.
- Controles de segurança. Laptops normalmente têm acesso amplo a credenciais e sistemas sensíveis, incluindo chaves SSH, sessões VPN e ferramentas autenticadas. Dar a um agente autônomo o mesmo nível de acesso cria um risco desnecessário e um potencial raio de impacto grande. Ambientes locais também dificultam limitar com precisão o que um agente pode acessar e por quanto tempo.
- Visibilidade e auditabilidade. Quando as cargas de trabalho são executadas em laptops individuais, a execução é fragmentada e difícil de monitorar. Torna-se mais difícil entender o que está sendo executado, onde está sendo executado, em nome de quem e quais sistemas ou arquivos foram acessados.
Nossa tese para resolver esses problemas é simples:
Delegar tarefas a agentes de codificação autônomos e seguros para que os engenheiros possam dedicar mais energia à inovação, ao pensamento crítico e à solução de problemas complexos.
Por que construímos o Flux internamente
Agentes de codificação hospedados são úteis, mas impõem uma escolha difícil: ou enviamos código sensível e contexto de execução para um terceiro, ou abrimos um caminho desse terceiro de volta para os sistemas internos. Para a DoorDash, o problema mais difícil não era apenas fazer um agente escrever código; isso está praticamente resolvido. Era dar a esse agente o ambiente, as ferramentas, as permissões, as integrações e as restrições certas.
Nossa estratégia é controlar os primitivos ao redor do agente, incluindo orquestração, sandboxes, fluxos de trabalho, permissões, integrações e o contexto específico da DoorDash de que os agentes precisam para trabalhar de forma eficaz. Também projetamos esses primitivos para serem modulares, dando-nos a flexibilidade de usar a melhor ferramenta de terceiros para cada trabalho ou de construir internamente quando segurança mais profunda, integração, desempenho ou propriedade da UX forem importantes.
Esses primitivos democratizam a criação de fluxos de trabalho e tornam os sistemas mais adaptáveis a casos de uso futuros. Como podem ser compostos de diferentes maneiras, as equipes podem criar novos fluxos de trabalho de agentes sem reformular a infraestrutura subjacente nem prescrever como cada engenheiro deve estruturar seu fluxo de trabalho. Por exemplo, executamos tanto as avaliações quanto a revisão de código na infraestrutura do Flux.
Primitivos, não fluxos de trabalho
Os quatro primitivos da plataforma que compõem o Flux — sandboxes, o gateway MCP, playbooks e superfícies de invocação — e como eles se conectam para transformar uma tarefa em trabalho que um agente pode executar com segurança
Como mostrado acima, o Flux é construído em torno de quatro primitivos da plataforma: sandboxes, o gateway do protocolo de contexto de modelo (MCP), playbooks e superfícies de invocação. Juntos, eles tornam a delegação a agentes repetível. Um playbook define o trabalho. Um sandbox na nuvem dá ao agente um lugar real para executá-lo. Um gateway de agentes controla quais sistemas o agente pode acessar. E as superfícies de invocação permitem que os engenheiros iniciem e recebam trabalho dos lugares que já usam.
Sandboxes fornecem o ambiente de execução
Agentes locais funcionam bem para o desenvolvimento interativo, mas são uma opção ruim para fluxos de trabalho não supervisionados. Eles dependem dos laptops de engenheiros individuais, competem por recursos locais, são difíceis de auditar e não escalam com eficiência em tarefas paralelas.
O Flux move a execução para sandboxes isolados na nuvem, apoiados por micro máquinas virtuais (microVMs) Firecracker para isolamento em nível de hardware. Cada sandbox é provisionado com os repositórios, ferramentas de desenvolvedor, segredos e dependências de runtime que a tarefa exige, dando aos agentes um ambiente de engenharia completo e, ao mesmo tempo, fornecendo à DoorDash um modelo consistente de execução, segurança e observabilidade.
Controlar essa camada nos permite suportar fluxos de trabalho reais de engenharia, incluindo mudanças em vários repositórios e várias pull requests em uma única sessão. O Flux tem um objetivo de nível de serviço no percentil 95 de menos de cinco segundos para toda a configuração de ponta a ponta — desde iniciar a microVM até clonar os repositórios necessários, instalar ferramentas de build e configurar os harnesses de agentes de codificação suportados.
O gateway MCP fornece acesso governado
Os agentes precisam de acesso aos sistemas que os engenheiros usam todos os dias, incluindo integração contínua (CI), plataformas de observabilidade, rastreadores de issues, ferramentas de deploy, busca de código, documentação e metadados de serviços. Mas conceder acesso amplo e irrestrito não deve ser o padrão.
O Flux conecta os agentes aos sistemas internos por meio de um gateway MCP interno chamado Agent Gateway. Cada playbook declara as ferramentas de que precisa, e o Flux concede apenas as permissões escopadas necessárias para aquela tarefa. Cada ação é registrada, criando uma trilha de auditoria clara.
Essa arquitetura de gateway nos dá um ponto central de controle para autenticação, autorização, observabilidade, rastreamento de uso e aplicação de políticas, o que torna o acesso de agentes mais seguro e mais fácil de operar em escala.
Playbooks definem o trabalho
Um playbook é uma unidade reutilizável de trabalho de agente — o equivalente a um contêiner Docker para habilidades e tarefas orientadas por agentes na plataforma Flux. Definido em um único arquivo YAML de marcação, ele empacota a tarefa, as entradas, o contexto, as habilidades, as ferramentas, as permissões, a validação, as saídas esperadas e os limites de segurança necessários para executar o trabalho de forma consistente.
Os playbooks podem combinar etapas de agentes, que oferecem flexibilidade e julgamento, com etapas determinísticas, que oferecem previsibilidade, menor custo e validação mais fácil. Isso permite que as equipes movam a lógica entre a execução orientada por agentes e o código convencional à medida que os requisitos evoluem, sem redesenhar o fluxo de trabalho.
Superfícies de invocação encontram os desenvolvedores onde eles estão
O mesmo playbook pode ser acionado pelo Slack, GitHub, cron, CLI ou por uma habilidade conversacional. Isso significa que as equipes podem definir um fluxo de trabalho uma vez e invocá-lo a partir de qualquer superfície que melhor corresponda ao momento:
- Slack para delegação colaborativa
- GitHub para automação de PRs e CI
- Cron para manutenção recorrente
- CLI para controle direto do desenvolvedor, ou invocado por meio de uma habilidade
É isso que torna o Flux fácil de adotar.
Lições aprendidas
Construir o Flux nos ensinou tanto sobre adoção de produtos quanto sobre infraestrutura, incluindo:
- Comece com um escopo reduzido para ganhar confiança. Começamos com a revisão de código automatizada em vez de tentar automatizar todo o ciclo de vida de desenvolvimento de software. A revisão de código era frequente, mensurável e fácil para os engenheiros avaliarem. Ela nos deu um fluxo de trabalho de produção no qual pudemos ajustar qualidade, latência, custo e comportamento antes de expandir para triagem de CI, tarefas de plantão, playbooks de manutenção e desenvolvimento orientado por tickets.
- Torne o trabalho visível. Nossa primeira integração com o Slack criou canais privados para cada execução de agente. Isso tornou o Flux útil para indivíduos, mas não criou hábitos de equipe. Mover o trabalho para threads públicas mudou o padrão de adoção. Os engenheiros puderam ver o que outros delegavam, observar o Flux progredir, revisar a saída e construir confiança em conjunto.
- Playbooks precisam de capacitação. Fluxos de trabalho reutilizáveis não surgem apenas porque a plataforma existe. Workshops e hackathons ajudaram as equipes a transformar trabalho operacional repetido em playbooks. Os primitivos tornaram a automação possível; a capacitação ajudou as equipes a reconhecer quais fluxos de trabalho valiam a pena codificar.
O que vem a seguir
Vamos nos aprofundar nos primitivos da plataforma que fazem o Flux funcionar e na experiência do desenvolvedor para criar novos fluxos de trabalho. Também discutiremos os aplicativos que construímos sobre a plataforma, incluindo o Flux Responder, nosso agente interno do Slack.
Agradecimentos
Agradecemos a Adam Rogal, Adam Yarger, Andy Fang, Ashwin Kachhara, Fan Xia, Ivan Rudovol, Jason Prasad, Jialu Deng, Justin Block, Justin Deocampo, Justin Fan, Keith Lyall, Praneet Singh, Sean Chen, Tyler Berrett e Volanda Zhu por suas contribuições para a plataforma e para este post.
