Autores do post: @SantoshPraneeth e @jeffizhungry
O Flux é a plataforma de agentes 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 1º trimestre de 2026, o Flux já alimenta workflows de alto volume em segundo plano em toda a DoorDash, incluindo mais de 25.000 revisões de código automatizadas por semana, mais de 300 playbooks exclusivos e mais de 10.000 invocações usadas semanalmente. Esses workflows podem ser executados sem supervisão, em paralelo, 24 horas por dia.
Vamos abordar as limitações que nos levaram a ir além dos workloads de agentes locais baseados em laptops, por que escolhemos construir o Flux internamente em vez de depender apenas de agentes de codificação hospedados, e as primitivas da plataforma — como sandboxes de agentes, gateway MCP, playbooks e superfícies de invocação — para tornar a delegação de agentes repetível e segura.
Casos de uso de workflows em segundo plano do Flux
Visão geral do uso do Flux em toda a 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 workloads agênticos 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 do dispositivo. Workflows agênticos geralmente precisam executar tarefas com uso intensivo de computação, como builds, testes e buscas extensas em paralelo, fazendo com que os laptops fiquem sem capacidade rapidamente. Os workflows também dependem de o dispositivo estar ligado, conectado e disponível; o trabalho pausa quando um engenheiro fecha o laptop, perde a conexão ou se afasta.
- Controles de segurança. Laptops normalmente têm amplo acesso a credenciais e sistemas sensíveis, incluindo chaves SSH, sessões de VPN e ferramentas autenticadas. Dar a um agente autônomo esse mesmo nível de acesso cria risco desnecessário e um raio de impacto potencialmente grande. Ambientes locais também dificultam o controle rigoroso do que um agente pode acessar e por quanto tempo.
- Visibilidade e auditabilidade. Quando workloads são executados em laptops individuais, a execução fica 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 um trade-off difícil: enviar código sensível e contexto de execução a um terceiro, ou abrir 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 já está praticamente resolvido. Era dar a esse agente o ambiente, as ferramentas, as permissões, as integrações e as restrições adequados.
Nossa estratégia é controlar as primitivas em torno do agente, incluindo orquestração, sandboxes, workflows, permissões, integrações e o contexto específico da DoorDash de que os agentes precisam para trabalhar de forma eficaz. Também projetamos essas primitivas para serem modulares, dando-nos flexibilidade para usar a melhor ferramenta de terceiros para cada tarefa ou para construir internamente quando segurança mais rigorosa, integração, desempenho ou controle sobre a experiência do usuário (UX) importam.
Essas primitivas democratizam a criação de workflows e tornam os sistemas mais adaptáveis a casos de uso futuros. Como podem ser compostas de diferentes maneiras, as equipes podem criar novos workflows de agentes sem reformular a infraestrutura subjacente nem prescrever como cada engenheiro deve estruturar seu workflow. Por exemplo, executamos os evals da nossa revisão de código na infraestrutura do Flux.
Primitivas, não workflows
As quatro primitivas da plataforma que compõem o Flux — sandboxes, gateway MCP, playbooks e superfícies de invocação — e como elas 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 primitivas da plataforma: sandboxes, gateway do protocolo de contexto de modelo (MCP), playbooks e superfícies de invocação. Juntas, elas tornam a delegação de agentes repetível. Um playbook define o trabalho. Um sandbox na nuvem dá ao agente um lugar real para executar o trabalho. 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 desenvolvimento interativo, mas não se encaixam bem em workflows sem supervisão. Eles dependem dos laptops de cada engenheiro, competem por recursos locais, são difíceis de auditar e não escalam de forma eficiente para tarefas paralelas.
O Flux move a execução para sandboxes isolados na nuvem, baseados em micro máquinas virtuais (microVMs) Firecracker para isolamento em nível de hardware. Cada sandbox é provisionado com os repositórios, ferramentas de desenvolvimento, segredos e dependências de runtime que a tarefa exige, dando aos agentes um workspace de engenharia completo e proporcionando à DoorDash um modelo consistente de execução, segurança e observabilidade.
Controlar essa camada nos permite dar suporte a workflows de engenharia reais, incluindo alterações em vários repositórios e vários pull requests a partir de uma única sessão. O Flux tem um objetivo de nível de serviço no 95º percentil de menos de cinco segundos para toda a configuração de ponta a ponta — desde a inicialização da microVM até a clonagem dos repositórios necessários, a instalação das ferramentas de build e a configuração dos 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ço. Mas conceder acesso amplo e irrestrito não deveria 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 com escopo restrito necessárias para aquela tarefa. Cada ação é registrada, criando uma trilha de auditoria clara.
Essa arquitetura de gateway nos dá um ponto centralizado de controle para autenticação, autorização, observabilidade, rastreamento de uso e aplicação de políticas — tudo o que torna o acesso dos agentes mais seguro e mais fácil de operar em escala.
Playbooks definem o trabalho
Um playbook é uma unidade reutilizável de trabalho agêntico — o equivalente a um container Docker para skills e tarefas conduzidas por agentes na plataforma Flux. Definido em um único arquivo YAML, ele empacota a tarefa, as entradas, o contexto, as skills, 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 agênticas, 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 conduzida por agentes e o código convencional à medida que os requisitos evoluem, sem redesenhar o workflow.
Superfícies de invocação vão até onde os desenvolvedores estão
O mesmo playbook pode ser acionado pelo Slack, GitHub, cron, CLI ou por uma skill conversacional. Isso significa que as equipes podem definir um workflow uma única vez e invocá-lo a partir da superfície que melhor se adequar 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 skill
É isso que torna o Flux fácil de adotar.
Lições aprendidas
Construir o Flux nos ensinou tanto sobre adoção de produto quanto sobre infraestrutura, incluindo:
- Comece pequeno para conquistar confiança. Começamos com revisão de código automatizada em vez de tentar automatizar todo o ciclo de vida do desenvolvimento de software. A revisão de código era frequente, mensurável e fácil de avaliar pelos engenheiros. Ela nos deu um workflow em 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 a 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 podiam ver o que outros delegavam, acompanhar o progresso do Flux, revisar o resultado e construir confiança juntos.
- Playbooks precisam de capacitação. Workflows reutilizáveis não surgem apenas porque a plataforma existe. Workshops e hackathons ajudaram as equipes a transformar trabalho operacional recorrente em playbooks. As primitivas tornaram a automação possível; a capacitação ajudou as equipes a reconhecer quais workflows valiam a pena ser codificados.
O que vem a seguir
Vamos nos aprofundar nas primitivas da plataforma que fazem o Flux funcionar e na experiência do desenvolvedor para criar novos workflows. Também vamos discutir os aplicativos que construímos sobre elas, 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 à plataforma e a este post.
