Autores del post: @SantoshPraneeth y @jeffizhungry
Flux es la plataforma de agentes basada en la nube de DoorDash para ingenieros. En un solo mes de 2026, usamos Flux para automatizar 130 000 tareas de ingeniería. Tras su rápido crecimiento desde su debut en el primer trimestre de 2026, Flux ya impulsa flujos de trabajo en segundo plano de alto volumen en toda DoorDash, incluidas más de 25 000 revisiones de código automatizadas cada semana, y más de 300 playbooks únicos 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.
Examinaremos las limitaciones que nos llevaron a ir más allá de las cargas de trabajo de agentes locales basadas en portátiles, por qué elegimos construir Flux internamente en lugar de depender únicamente de agentes de codificación alojados, y las primitivas de la plataforma, como los sandboxes de agentes, la puerta de enlace 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 los flujos de trabajo en segundo plano de Flux
Una instantánea del uso de Flux en DoorDash en un solo mes, que abarca revisiones de código automatizadas, ejecuciones de playbooks y finalizaciones 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 portátiles se han topado rápidamente con limitaciones:
- Recursos y disponibilidad. Un portátil tiene un número fijo de núcleos de CPU, memoria limitada y una batería, todo ello compartido con todas las aplicaciones instaladas. Los flujos de trabajo de agentes a menudo necesitan ejecutar tareas de alto consumo computacional, como compilaciones, pruebas y búsquedas grandes, en paralelo, lo que hace que los portátiles se queden sin capacidad rápidamente. Además, los flujos de trabajo dependen de que el dispositivo esté encendido, conectado y disponible; el trabajo se pausa cuando un ingeniero cierra el portátil, pierde la conexión o se ausenta.
- Controles de seguridad. Los portátiles suelen tener un amplio acceso a credenciales y sistemas sensibles, incluidas claves SSH, sesiones VPN y herramientas autenticadas. Dar a un agente autónomo ese mismo nivel de acceso crea un riesgo innecesario y un radio de explosión potencialmente amplio. Los entornos locales también dificultan delimitar con precisión a qué puede acceder un agente y durante cuánto tiempo.
- Visibilidad y auditabilidad. Cuando las cargas de trabajo se ejecutan en portátiles individuales, la ejecución queda fragmentada y es difícil de monitorear. Resulta más complicado entender qué se está ejecutando, dónde, en nombre de quién, y qué sistemas o archivos ha tocado.
Nuestra tesis para abordar estos problemas es sencilla:
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: enviar código sensible y contexto de ejecución a un tercero, o abrir un camino desde 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 está prácticamente resuelto. Era darle a ese agente el entorno, las herramientas, los permisos, las integraciones y las restricciones adecuadas.
Nuestra estrategia es controlar las primitivas que rodean al agente, incluyendo orquestación, sandboxes, flujos de trabajo, permisos, integraciones y el contexto específico de DoorDash que los agentes necesitan para trabajar de manera eficaz. También diseñamos esas primitivas 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 importan una mayor seguridad, integración, rendimiento o propiedad de la experiencia de usuario.
Estas primitivas democratizan la creación de flujos de trabajo y hacen que los sistemas sean más adaptables a futuros casos de uso. Al poder combinarse de diferentes maneras, los equipos pueden crear nuevos flujos de trabajo de agentes sin tener que rehacer la infraestructura subyacente ni prescribir cómo debe estructurar cada ingeniero su flujo de trabajo. Por ejemplo, ejecutamos tanto las evaluaciones de nuestra revisión de código en la infraestructura de Flux.
Primitivas, no flujos de trabajo
Las cuatro primitivas de la plataforma que componen Flux — los sandboxes, la puerta de enlace 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 se construye en torno a cuatro primitivas de la plataforma: sandboxes, la puerta de enlace del protocolo de contexto de modelo (MCP), playbooks y superficies de invocación. Juntas, 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. Una puerta de enlace 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 utilizan.
Los sandboxes proporcionan el entorno de ejecución
Los agentes locales funcionan bien para el desarrollo interactivo, pero no son adecuados para flujos de trabajo sin supervisión. Dependen de los portátiles de cada ingeniero, compiten por los recursos locales, son difíciles de auditar y no escalan de manera eficiente entre tareas paralelas.
Flux traslada la ejecución a sandboxes aislados en la nube respaldados por micro máquinas virtuales (microVMs) de Firecracker para lograr un aislamiento a nivel de hardware. Cada sandbox se aprovisiona con los repositorios, herramientas de desarrollo, secretos y dependencias de ejecución que requiere la tarea, lo que les da a los agentes un espacio de trabajo de ingeniería completo y, a la vez, le proporciona a DoorDash un modelo coherente de ejecución, seguridad y observabilidad.
Controlar esta capa nos permite soportar flujos de trabajo de ingeniería reales, incluidos cambios en múltiples repositorios y múltiples pull requests desde una sola sesión. Flux tiene un objetivo de nivel de servicio en el percentil 95 de menos de cinco segundos para la configuración completa de extremo a extremo, desde el arranque de la microVM hasta la clonación de los repositorios necesarios, la instalación de herramientas de compilación y la configuración de los harnesses de agentes de codificación compatibles.
La puerta de enlace MCP ofrece acceso gobernado
Los agentes necesitan acceso a los sistemas que los ingenieros usan a diario, incluidos integración continua (CI), plataformas de observabilidad, rastreadores de incidencias, herramientas de despliegue, búsqueda de código, documentación y metadatos de servicios. Pero otorgar un 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 una puerta de enlace MCP interna llamada Agent Gateway. Cada playbook declara las herramientas que requiere, y Flux otorga únicamente los permisos acotados necesarios para esa tarea. Cada acción se registra, creando un rastro de auditoría claro.
Esta arquitectura de puerta de enlace 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 a un contenedor Docker para habilidades y tareas impulsadas por agentes en la plataforma Flux. Definido en un único archivo YAML de marcado, agrupa la tarea, las entradas, el contexto, las habilidades, las herramientas, los permisos, la validación, los resultados esperados y los límites de seguridad necesarios para ejecutar el trabajo de manera consistente.
Los playbooks pueden combinar pasos de agentes, que aportan flexibilidad y criterio, con pasos deterministas, que ofrecen previsibilidad, menor costo y una validación más sencilla. Esto permite a los equipos mover la lógica entre la ejecución impulsada por agentes y el código convencional a medida que evolucionan los requisitos, sin rediseñar el flujo de trabajo.
Las superficies de invocación llegan a los desarrolladores donde están
El mismo playbook puede activarse desde Slack, GitHub, cron, la CLI o una skill conversacional. Esto significa que los equipos pueden definir un flujo de trabajo una sola vez e invocarlo desde la superficie que mejor se adapte al momento:
- Slack para la delegación colaborativa
- GitHub para la automatización de PR y CI
- Cron para el mantenimiento recurrente
- CLI para el control directo de los desarrolladores, o invocada mediante una skill
Esto es lo que hace que Flux sea fácil de adoptar.
Lecciones aprendidas
Construir Flux nos enseñó tanto sobre la adopción de productos como sobre infraestructura, en particular:
- Empezar con un alcance reducido 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 en 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.
- Hacer visible el trabajo. Nuestra primera integración con Slack creaba canales privados para cada ejecución de agente. Eso hizo que Flux fuera útil para las personas, pero no creó hábitos de equipo. Trasladar el trabajo a hilos públicos cambió el patrón de adopción. Los ingenieros podían ver qué delegaban otros, observar el progreso de Flux, revisar el resultado y generar confianza en conjunto.
- Los playbooks necesitan habilitación. Los flujos de trabajo reutilizables no aparecen solo porque la plataforma exista. Los talleres y hackatones ayudaron a los equipos a convertir el trabajo operativo repetido en playbooks. Las primitivas hicieron posible la automatización; la habilitación ayudó a los equipos a reconocer qué flujos de trabajo valía la pena codificar.
Qué viene después
Profundizaremos en las primitivas de la plataforma que hacen funcionar Flux y en la experiencia de desarrollo para crear nuevos flujos de trabajo. También hablaremos de las aplicaciones que hemos construido sobre ella, incluido 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.
