Autores del post: @SantoshPraneeth y @jeffizhungry
Flux es la plataforma de agentes en la nube de DoorDash para ingenieros. En un solo mes de 2026, usamos Flux para automatizar 130,000 tareas de ingeniería. Desde su debut en el primer trimestre de 2026, Flux ha crecido rápidamente y ya impulsa flujos de trabajo en segundo plano de alto volumen en toda DoorDash, incluyendo más de 25,000 revisiones de código automatizadas cada semana, así como más de 300 playbooks distintos y más de 10,000 invocaciones utilizadas cada semana. Estos flujos de trabajo pueden ejecutarse sin supervisión, en paralelo, las 24 horas del día.
Repasaremos las limitaciones que nos impulsaron a ir más allá de las cargas de trabajo de agentes locales en laptops, por qué decidimos construir Flux internamente en lugar de depender únicamente de agentes de codificación alojados, y los primitivos de la plataforma, como los sandboxes de agentes, el gateway MCP, los playbooks y las superficies de invocación, para hacer que la delegación de agentes sea repetible y segura.
Casos de uso de flujos de trabajo en segundo plano de Flux
Una muestra del uso de Flux en DoorDash durante un solo mes, que abarca revisiones de código automatizadas, ejecuciones de playbooks y finalización de tareas en segundo plano
Por dónde empezamos
Durante el último año, los usuarios que ejecutan cargas de trabajo de agentes en sus laptops se han topado rápidamente con limitaciones:
- Recursos y disponibilidad. Una laptop tiene una cantidad fija de núcleos de CPU, memoria limitada y una batería, todo compartido con cada aplicación instalada. Los flujos de trabajo de agentes a menudo necesitan ejecutar tareas de cómputo intensivo, como compilaciones, pruebas y búsquedas grandes, en paralelo, lo que hace que las laptops se queden sin capacidad rápidamente. Los flujos de trabajo también dependen de que el dispositivo esté encendido, conectado y disponible; el trabajo se pausa cuando un ingeniero cierra la laptop, pierde conectividad o se aleja.
- Controles de seguridad. Las laptops suelen tener acceso amplio a credenciales y sistemas sensibles, incluyendo claves SSH, sesiones VPN y herramientas autenticadas. Darle a un agente autónomo ese mismo nivel de acceso crea un riesgo innecesario y un posible radio de impacto grande. Los entornos locales también dificultan delimitar con precisión a qué puede acceder un agente y por cuánto tiempo.
- Visibilidad y auditabilidad. Cuando las cargas de trabajo se ejecutan en laptops individuales, la ejecución está fragmentada y es difícil de monitorear. Se vuelve más difícil entender qué se está ejecutando, dónde se ejecuta, en nombre de quién y qué sistemas o archivos ha tocado.
Nuestra tesis para abordar estos problemas es simple:
Delegar tareas a agentes de codificación autónomos y seguros para que los ingenieros puedan dedicar más energía a la innovación, el pensamiento crítico y la resolución de problemas complejos.
Por qué construimos Flux internamente
Los agentes de codificación alojados son útiles, pero imponen una disyuntiva difícil: o envías código sensible y contexto de ejecución a un tercero, o abres una vía de ese tercero hacia los sistemas internos. Para DoorDash, el problema más difícil no era solo lograr que un agente escribiera código; eso ya está mayormente resuelto. Era darle a ese agente el entorno, las herramientas, los permisos, las integraciones y las restricciones adecuados.
Nuestra estrategia es controlar los primitivos alrededor del agente, incluyendo la orquestación, los sandboxes, los flujos de trabajo, los permisos, las integraciones y el contexto específico de DoorDash que los agentes necesitan para trabajar de manera efectiva. También diseñamos esos primitivos para que sean modulares, lo que nos da la flexibilidad de usar la mejor herramienta de terceros para cada tarea o de construir internamente cuando la seguridad, la integración, el rendimiento o el control de la experiencia de usuario importan más.
Estos primitivos democratizan la creación de flujos de trabajo y hacen que los sistemas sean más adaptables a casos de uso futuros. Debido a que se pueden componer de diferentes maneras, los equipos pueden crear nuevos flujos de trabajo de agentes sin rehacer la infraestructura subyacente ni prescribir cómo cada ingeniero debe estructurar su flujo de trabajo. Por ejemplo, ejecutamos las evaluaciones de nuestra revisión de código en la infraestructura de Flux.
Primitivos, no flujos de trabajo
Los cuatro primitivos de la plataforma que componen Flux — sandboxes, el gateway MCP, los playbooks y las superficies de invocación — y cómo se conectan para convertir una tarea en trabajo que un agente puede realizar de forma segura
Como se muestra arriba, Flux está construido alrededor de cuatro primitivos de la plataforma: sandboxes, el gateway de protocolo de contexto de modelo (MCP), playbooks y superficies de invocación. Juntos, hacen que la delegación de agentes sea repetible. Un playbook define el trabajo. Un sandbox en la nube le da al agente un lugar real para hacerlo. Un gateway de agentes controla a qué sistemas puede acceder el agente. Y las superficies de invocación permiten a los ingenieros iniciar y recibir trabajo desde los lugares que ya usan.
Los sandboxes proporcionan el entorno de ejecución
Los agentes locales funcionan bien para el desarrollo interactivo, pero son una mala opción para flujos de trabajo sin supervisión. Dependen de las laptops de cada ingeniero, compiten por recursos locales, son difíciles de auditar y no escalan de manera eficiente en tareas paralelas.
Flux mueve la ejecución a sandboxes en la nube aislados, respaldados por micro máquinas virtuales (microVMs) de Firecracker para un aislamiento a nivel de hardware. Cada sandbox se aprovisiona con los repositorios, herramientas de desarrollo, secretos y dependencias de ejecución que la tarea requiere, dándoles a los agentes un espacio de trabajo de ingeniería completo, mientras le proporciona a DoorDash un modelo consistente de ejecución, seguridad y observabilidad.
Controlar esta capa nos permite dar soporte a flujos de trabajo de ingeniería reales, incluyendo cambios en múltiples repositorios y múltiples solicitudes de extracción (pull requests) desde una sola sesión. Flux tiene un objetivo de nivel de servicio (SLO) en el percentil 95 de menos de cinco segundos para la configuración completa de extremo a extremo — desde iniciar la microVM hasta clonar los repositorios requeridos, instalar las herramientas de compilación y configurar los harnesses de agentes de codificación compatibles.
El gateway MCP proporciona acceso regulado
Los agentes necesitan acceso a los sistemas que los ingenieros usan todos los días, incluyendo integración continua (CI), plataformas de observabilidad, sistemas de seguimiento de incidencias, herramientas de despliegue, búsqueda de código, documentación y metadatos de servicios. Pero otorgar acceso amplio y sin restricciones no debería ser la opción predeterminada.
Flux conecta a los agentes con los sistemas internos a través de un gateway MCP interno llamado Agent Gateway. Cada playbook declara las herramientas que requiere, y Flux otorga solo los permisos delimitados necesarios para esa tarea. Cada acción se registra, creando un rastro de auditoría claro.
Esta arquitectura de gateway nos da un punto de control centralizado para autenticación, autorización, observabilidad, seguimiento de uso y aplicación de políticas, todo lo cual hace que el acceso de los agentes sea más seguro y más fácil de operar a escala.
Los playbooks definen el trabajo
Un playbook es una unidad reutilizable de trabajo de agentes — el equivalente de un contenedor Docker para habilidades y tareas impulsadas por agentes en la plataforma Flux. Definido en un solo archivo YAML de marcado, empaqueta la tarea, entradas, contexto, habilidades, herramientas, permisos, validación, resultados esperados y límites de seguridad necesarios para ejecutar el trabajo de manera consistente.
Los playbooks pueden combinar pasos de agentes, que ofrecen flexibilidad y criterio, con pasos deterministas, que ofrecen previsibilidad, menor costo y validación más fácil. Esto permite a los equipos mover la lógica entre la ejecución impulsada por agentes y el código convencional a medida que los requisitos evolucionan, sin rediseñar el flujo de trabajo.
Las superficies de invocación llegan a los desarrolladores donde están
El mismo playbook se puede activar desde Slack, GitHub, cron, la CLI o una habilidad conversacional. Eso significa que los equipos pueden definir un flujo de trabajo una vez e invocarlo desde la superficie que mejor se ajuste al momento:
- Slack para delegación colaborativa
- GitHub para automatización de PR y CI
- Cron para mantenimiento recurrente
- CLI para control directo del desarrollador, o invocada a través de una habilidad
Esto es lo que hace que Flux sea fácil de adoptar.
Lecciones aprendidas
Construir Flux nos enseñó tanto sobre adopción de productos como sobre infraestructura, incluyendo:
- Empieza de forma acotada para ganar confianza. Comenzamos con la revisión de código automatizada en lugar de intentar automatizar todo el ciclo de vida del desarrollo de software. La revisión de código era frecuente, medible y fácil de evaluar para los ingenieros. Nos dio un flujo de trabajo de producción donde pudimos ajustar la calidad, la latencia, el costo y el comportamiento antes de expandirnos al triaje de CI, las tareas de guardia, los playbooks de mantenimiento y el desarrollo impulsado por tickets.
- Haz que el trabajo sea visible. Nuestra primera integración con Slack creó canales privados para cada ejecución de agente. Eso hizo que Flux fuera útil para individuos, pero no creó hábitos de equipo. Mover el trabajo a hilos públicos cambió el patrón de adopción. Los ingenieros podían ver lo que otros delegaban, observar cómo Flux progresaba, revisar el resultado y generar confianza juntos.
- Los playbooks necesitan habilitación. Los flujos de trabajo reutilizables no aparecen solo porque la plataforma existe. Talleres y hackathons ayudaron a los equipos a convertir trabajo operativo repetido en playbooks. Los primitivos hicieron posible la automatización; la habilitación ayudó a los equipos a reconocer qué flujos de trabajo valía la pena codificar.
Lo que viene
Profundizaremos en los primitivos de la plataforma que hacen que Flux funcione y en la experiencia del desarrollador para construir nuevos flujos de trabajo. También hablaremos de las aplicaciones que hemos construido sobre la plataforma, incluyendo Flux Responder, nuestro agente interno de Slack.
Agradecimientos
Gracias 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 y Volanda Zhu por sus contribuciones a la plataforma y a este post.
