Auteurs de l'article : @SantoshPraneeth et @jeffizhungry
Flux est la plateforme d'agents cloud de DoorDash destinée aux ingénieurs. En un seul mois en 2026, nous avons utilisé Flux pour automatiser 130 000 tâches d'ingénierie. En pleine expansion depuis ses débuts au premier trimestre 2026, Flux alimente déjà des workflows d'arrière-plan à fort volume chez DoorDash, notamment plus de 25 000 revues de code automatisées chaque semaine, plus de 300 playbooks distincts et plus de 10 000 invocations utilisées chaque semaine. Ces workflows peuvent s'exécuter sans supervision, en parallèle, 24 heures sur 24.
Nous allons passer en revue les limites qui nous ont poussés à aller au-delà des charges de travail agentiques locales exécutées sur ordinateur portable, les raisons pour lesquelles nous avons choisi de développer Flux en interne plutôt que de nous appuyer uniquement sur des agents de codage hébergés, ainsi que les primitives de la plateforme — telles que les sandboxes d'agents, la passerelle MCP, les playbooks et les surfaces d'invocation — qui rendent la délégation aux agents reproductible et sécurisée.
Cas d'usage des workflows d'arrière-plan de Flux
Un aperçu de l'utilisation de Flux chez DoorDash en un seul mois, couvrant les revues de code automatisées, les exécutions de playbooks et l'achèvement de tâches d'arrière-plan.
D'où nous sommes partis
Au cours de l'année écoulée, les utilisateurs qui exécutent des charges de travail agentiques sur leurs ordinateurs portables se sont rapidement heurtés à des limites :
- Ressources et disponibilité. Un ordinateur portable dispose d'un nombre fixe de cœurs CPU, d'une mémoire limitée et d'une batterie, le tout partagé avec chaque application installée. Les workflows agentiques doivent souvent exécuter des tâches gourmandes en calcul, comme les builds, les tests et les recherches volumineuses, en parallèle, ce qui épuise rapidement la capacité de l'ordinateur. Les workflows dépendent également de l'appareil : il doit être allumé, connecté et disponible ; le travail s'interrompt lorsqu'un ingénieur ferme son ordinateur, perd la connexion ou s'éloigne.
- Contrôles de sécurité. Les ordinateurs portables disposent généralement d'un accès large à des identifiants et des systèmes sensibles, notamment les clés SSH, les sessions VPN et les outils authentifiés. Accorder à un agent autonome le même niveau d'accès crée un risque inutile et un rayon d'impact potentiellement important. Les environnements locaux rendent également plus difficile le contrôle précis de ce qu'un agent peut atteindre et pendant combien de temps.
- Visibilité et auditabilité. Lorsque les charges de travail s'exécutent sur des ordinateurs portables individuels, l'exécution est fragmentée et difficile à superviser. Il devient plus difficile de comprendre ce qui s'exécute, où cela s'exécute, au nom de qui, et quels systèmes ou fichiers ont été touchés.
Notre conviction pour résoudre ces problèmes est simple :
Déléguer les tâches à des agents de codage autonomes et sécurisés afin que les ingénieurs puissent consacrer plus d'énergie à l'innovation, à la réflexion critique et à la résolution de problèmes complexes.
Pourquoi nous avons développé Flux en interne
Les agents de codage hébergés sont utiles, mais ils imposent un compromis difficile : soit envoyer du code sensible et le contexte d'exécution à un tiers, soit ouvrir un chemin depuis ce tiers vers les systèmes internes. Pour DoorDash, le problème le plus difficile n'était pas seulement d'amener un agent à écrire du code ; cela est en grande partie résolu. Il s'agissait de donner à cet agent le bon environnement, les bons outils, les bonnes permissions, les bonnes intégrations et les bonnes contraintes.
Notre stratégie consiste à contrôler les primitives autour de l'agent, notamment l'orchestration, les sandboxes, les workflows, les permissions, les intégrations et le contexte spécifique à DoorDash dont les agents ont besoin pour travailler efficacement. Nous avons également conçu ces primitives pour être modulaires, ce qui nous donne la flexibilité d'utiliser le meilleur outil tiers pour chaque tâche ou de développer en interne lorsque la sécurité, l'intégration, la performance ou la maîtrise de l'expérience utilisateur exigent un contrôle plus profond.
Ces primitives démocratisent la création de workflows et rendent les systèmes plus adaptables aux futurs cas d'usage. Comme elles peuvent être composées de différentes manières, les équipes peuvent créer de nouveaux workflows d'agents sans retravailler l'infrastructure sous-jacente ni imposer la façon dont chaque ingénieur doit structurer son workflow. Par exemple, nous exécutons à la fois les évaluations de notre revue de code sur l'infrastructure Flux.
Des primitives, pas des workflows
Les quatre primitives de la plateforme qui composent Flux — les sandboxes, la passerelle MCP, les playbooks et les surfaces d'invocation — et la manière dont elles se connectent pour transformer une tâche en travail qu'un agent peut effectuer en toute sécurité.
Comme illustré ci-dessus, Flux est construit autour de quatre primitives de plateforme : les sandboxes, la passerelle du protocole de contexte de modèle (MCP), les playbooks et les surfaces d'invocation. Ensemble, elles rendent la délégation aux agents reproductible. Un playbook définit le travail. Une sandbox cloud donne à l'agent un véritable espace où l'accomplir. Une passerelle d'agents contrôle les systèmes auxquels l'agent peut accéder. Et les surfaces d'invocation permettent aux ingénieurs de lancer du travail et d'en recevoir les résultats depuis les outils qu'ils utilisent déjà.
Les sandboxes fournissent l'environnement d'exécution
Les agents locaux fonctionnent bien pour le développement interactif, mais ils sont mal adaptés aux workflows sans supervision. Ils dépendent des ordinateurs portables individuels des ingénieurs, entrent en concurrence pour les ressources locales, sont difficiles à auditer et ne passent pas efficacement à l'échelle pour les tâches parallèles.
Flux déplace l'exécution dans des sandboxes cloud isolées, basées sur des micro machines virtuelles (microVM) Firecracker pour une isolation au niveau matériel. Chaque sandbox est provisionnée avec les dépôts, les outils de développement, les secrets et les dépendances d'exécution requis par la tâche, offrant ainsi aux agents un espace de travail d'ingénierie complet tout en fournissant à DoorDash un modèle cohérent d'exécution, de sécurité et d'observabilité.
Contrôler cette couche nous permet de prendre en charge de véritables workflows d'ingénierie, notamment des modifications sur plusieurs dépôts et plusieurs pull requests à partir d'une seule session. Flux a un objectif de niveau de service au 95e percentile de moins de cinq secondes pour la configuration complète de bout en bout — du démarrage de la microVM au clonage des dépôts requis, à l'installation des outils de build et à la configuration des harnais d'agents de codage pris en charge.
La passerelle MCP fournit un accès encadré
Les agents ont besoin d'accéder aux systèmes que les ingénieurs utilisent au quotidien, notamment l'intégration continue (CI), les plateformes d'observabilité, les gestionnaires de tickets, les outils de déploiement, la recherche de code, la documentation et les métadonnées de services. Mais l'octroi d'un accès large et sans restriction ne devrait pas être la norme par défaut.
Flux connecte les agents aux systèmes internes via une passerelle MCP interne appelée Agent Gateway. Chaque playbook déclare les outils dont il a besoin, et Flux n'accorde que les permissions ciblées nécessaires à cette tâche. Chaque action est journalisée, ce qui crée une piste d'audit claire.
Cette architecture de passerelle nous offre un point de contrôle centralisé pour l'authentification, l'autorisation, l'observabilité, le suivi d'utilisation et l'application des politiques, ce qui rend l'accès des agents à la fois plus sûr et plus facile à exploiter à grande échelle.
Les playbooks définissent le travail
Un playbook est une unité réutilisable de travail agentique — l'équivalent d'un conteneur Docker pour les compétences et les tâches pilotées par des agents sur la plateforme Flux. Défini dans un seul fichier YAML, il regroupe la tâche, les entrées, le contexte, les compétences, les outils, les permissions, la validation, les résultats attendus et les limites de sécurité nécessaires pour exécuter le travail de manière cohérente.
Les playbooks peuvent combiner des étapes agentiques, qui offrent flexibilité et jugement, avec des étapes déterministes, qui offrent prévisibilité, coût réduit et validation plus facile. Cela permet aux équipes de faire basculer la logique entre l'exécution pilotée par des agents et le code conventionnel à mesure que les exigences évoluent, sans repenser le workflow.
Les surfaces d'invocation vont à la rencontre des développeurs
Le même playbook peut être déclenché depuis Slack, GitHub, cron, la CLI ou une compétence conversationnelle. Cela signifie que les équipes peuvent définir un workflow une seule fois et l'invoquer depuis la surface la plus adaptée au moment :
- Slack pour la délégation collaborative
- GitHub pour l'automatisation des PR et de la CI
- Cron pour la maintenance récurrente
- CLI pour le contrôle direct des développeurs, ou invoquée via une compétence
C'est ce qui rend Flux facile à adopter.
Enseignements tirés
Construire Flux nous a autant appris sur l'adoption produit que sur l'infrastructure, notamment :
- Commencer petit pour gagner la confiance. Nous avons commencé par la revue de code automatisée au lieu d'essayer d'automatiser l'ensemble du cycle de vie du développement logiciel. La revue de code était fréquente, mesurable et facile à évaluer pour les ingénieurs. Elle nous a offert un workflow de production dans lequel nous pouvions ajuster la qualité, la latence, le coût et le comportement avant de nous étendre au triage de la CI, aux tâches d'astreinte, aux playbooks de maintenance et au développement piloté par les tickets.
- Rendre le travail visible. Notre première intégration Slack créait des canaux privés pour chaque exécution d'agent. Cela rendait Flux utile pour les individus, mais ne créait pas d'habitudes d'équipe. Déplacer le travail vers des fils publics a changé la dynamique d'adoption. Les ingénieurs pouvaient voir ce que les autres déléguaient, observer Flux progresser, examiner les résultats et renforcer la confiance ensemble.
- Les playbooks nécessitent de l'accompagnement. Les workflows réutilisables n'apparaissent pas simplement parce que la plateforme existe. Des ateliers et des hackathons ont aidé les équipes à transformer leur travail opérationnel répétitif en playbooks. Les primitives ont rendu l'automatisation possible ; l'accompagnement a aidé les équipes à identifier les workflows qui méritaient d'être codifiés.
La suite
Nous approfondirons les primitives de la plateforme qui font fonctionner Flux, ainsi que l'expérience développeur pour créer de nouveaux workflows. Nous aborderons également les applications que nous avons construites par-dessus, notamment Flux Responder, notre agent Slack interne.
Remerciements
Merci à 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 et Volanda Zhu pour leurs contributions à la plateforme et à cet article.
