Autoren des Beitrags: @SantoshPraneeth und @jeffizhungry
Flux ist die Cloud-basierte Agentenplattform von DoorDash für Entwickler. In einem einzigen Monat im Jahr 2026 haben wir mit Flux 130.000 Entwicklungsaufgaben automatisiert. Nach seinem Start im Q1 2026 wächst Flux rasant und unterstützt bereits hochvolumige Background-Workflows in ganz DoorDash – darunter mehr als 25.000 automatisierte Code-Reviews pro Woche sowie über 300 verschiedene Playbooks und mehr als 10.000 Aufrufe pro Woche. Diese Workflows können unbeaufsichtigt, parallel und rund um die Uhr laufen.
Wir gehen auf die Einschränkungen ein, die uns über lokale, laptopbasierte Agent-Workloads hinausgetrieben haben, erklären, warum wir Flux lieber intern entwickelt haben, als uns ausschließlich auf gehostete Coding-Agenten zu verlassen, und stellen die Plattform-Primitive vor – Agent-Sandboxes, MCP-Gateway, Playbooks und Aufrufschnittstellen –, die Agent-Delegation wiederholbar und sicher machen.
Anwendungsfälle für Flux-Background-Workflows
Ein Überblick über die Flux-Nutzung bei DoorDash in einem einzigen Monat – von automatisierten Code-Reviews über Playbook-Ausführungen bis hin zu abgeschlossenen Hintergrundaufgaben.
Unser Ausgangspunkt
Im vergangenen Jahr sind Nutzer, die agentische Workloads auf ihren Laptops ausgeführt haben, schnell an Grenzen gestoßen:
- Ressourcen und Verfügbarkeit. Ein Laptop hat eine feste Anzahl von CPU-Kernen, begrenzten Arbeitsspeicher und einen Akku – all das teilt er sich mit jeder installierten Anwendung. Agentische Workflows müssen oft rechenintensive Aufgaben wie Builds, Tests und umfangreiche Suchen parallel ausführen, wodurch Laptops schnell an ihre Kapazitätsgrenzen stoßen. Die Workflows hängen zudem davon ab, dass das Gerät eingeschaltet, verbunden und verfügbar ist; die Arbeit pausiert, wenn ein Entwickler den Laptop zuklappt, die Verbindung verliert oder weggeht.
- Sicherheitskontrollen. Laptops haben in der Regel weitreichenden Zugriff auf sensible Zugangsdaten und Systeme, einschließlich SSH-Schlüsseln, VPN-Sitzungen und authentifizierten Tools. Einem autonomen Agenten dieselbe Zugriffsebene zu gewähren, schafft unnötige Risiken und einen potenziell großen Schadensradius. Lokale Umgebungen machen es außerdem schwieriger, präzise festzulegen, worauf ein Agent zugreifen kann und wie lange.
- Sichtbarkeit und Auditierbarkeit. Wenn Workloads über einzelne Laptops verteilt laufen, ist die Ausführung fragmentiert und schwer zu überwachen. Es wird schwieriger nachzuvollziehen, was läuft, wo es läuft, in wessen Auftrag und welche Systeme oder Dateien berührt wurden.
Unsere These zur Lösung dieser Probleme ist einfach:
Delegiere Aufgaben an sichere, autonome Coding-Agenten, damit Entwickler mehr Energie in Innovation, kritisches Denken und die Lösung komplexer Probleme stecken können.
Warum wir Flux intern entwickelt haben
Gehostete Coding-Agenten sind nützlich, aber sie erzwingen einen schwierigen Kompromiss: Entweder man sendet sensiblen Code und Ausführungskontext an einen Drittanbieter, oder man öffnet einen Weg von diesem Drittanbieter zurück in interne Systeme. Für DoorDash bestand das schwierigere Problem nicht nur darin, einen Agenten zum Schreiben von Code zu bringen – das ist weitgehend gelöst. Es ging darum, dem Agenten die richtige Umgebung, die richtigen Tools, Berechtigungen, Integrationen und Einschränkungen zu geben.
Unsere Strategie besteht darin, die Primitive rund um den Agenten zu kontrollieren, einschließlich Orchestrierung, Sandboxes, Workflows, Berechtigungen, Integrationen und der DoorDash-spezifischen Kontext-Agenten, die für effektives Arbeiten erforderlich sind. Wir haben diese Primitive außerdem modular aufgebaut, was uns die Flexibilität gibt, für jede Aufgabe das beste Drittanbieter-Tool einzusetzen oder eigene Lösungen zu entwickeln, wenn tiefere Sicherheit, Integration, Performance oder UX-Verantwortung entscheidend sind.
Diese Primitive demokratisieren die Workflow-Erstellung und machen Systeme anpassungsfähiger für zukünftige Anwendungsfälle. Da sie auf unterschiedliche Weise kombiniert werden können, können Teams neue Agent-Workflows erstellen, ohne die zugrunde liegende Infrastruktur umzubauen oder vorzuschreiben, wie jeder Entwickler seinen Workflow strukturieren soll. So betreiben wir beispielsweise sowohl die Evaluierungen für unser Code-Review auf der Flux-Infrastruktur.
Primitive, keine Workflows
Die vier Plattform-Primitive, aus denen Flux besteht – Sandboxes, das MCP-Gateway, Playbooks und Aufrufschnittstellen – und wie sie zusammenwirken, um aus einer Aufgabe Arbeit zu machen, die ein Agent sicher ausführen kann.
Wie oben gezeigt, ist Flux um vier Plattform-Primitive herum aufgebaut: Sandboxes, das Model Context Protocol (MCP)-Gateway, Playbooks und Aufrufschnittstellen. Zusammen machen sie Agent-Delegation wiederholbar. Ein Playbook definiert die Arbeit. Eine Cloud-Sandbox gibt dem Agenten einen realen Ort, um sie zu erledigen. Ein Agent-Gateway kontrolliert, auf welche Systeme der Agent zugreifen kann. Und Aufrufschnittstellen ermöglichen es Entwicklern, Arbeit von den Orten aus zu starten und zu empfangen, die sie bereits nutzen.
Sandboxes bieten die Ausführungsumgebung
Lokale Agenten eignen sich gut für die interaktive Entwicklung, sind aber schlecht für unbeaufsichtigte Workflows geeignet. Sie hängen von den Laptops einzelner Entwickler ab, konkurrieren um lokale Ressourcen, sind schwer zu auditieren und lassen sich bei parallelen Aufgaben nur ineffizient skalieren.
Flux verlagert die Ausführung in isolierte Cloud-Sandboxes, die auf Firecracker-Micro-Virtual-Machines (MicroVMs) basieren und so Isolation auf Hardware-Ebene bieten. Jede Sandbox wird mit den Repositories, Entwickler-Tools, Secrets und Laufzeitabhängigkeiten ausgestattet, die die Aufgabe erfordert. So erhalten Agenten eine vollständige Engineering-Arbeitsumgebung, während DoorDash ein konsistentes Ausführungs-, Sicherheits- und Beobachtbarkeitsmodell bekommt.
Die Kontrolle über diese Ebene ermöglicht es uns, echte Engineering-Workflows zu unterstützen, einschließlich Änderungen über mehrere Repositories und mehrere Pull Requests aus einer einzigen Sitzung. Flux hat ein Service-Level-Ziel (SLO) von unter fünf Sekunden beim 95. Perzentil für das vollständige End-to-End-Setup – vom Starten der MicroVM über das Klonen der benötigten Repositories und die Installation der Build-Tools bis zur Konfiguration der unterstützten Coding-Agent-Harnesses.
MCP-Gateway für kontrollierten Zugriff
Agenten benötigen Zugriff auf die Systeme, die Entwickler täglich nutzen, darunter Continuous Integration (CI), Observability-Plattformen, Issue-Tracker, Deployment-Tools, Codesuche, Dokumentation und Service-Metadaten. Aber weitreichenden, uneingeschränkten Zugriff zu gewähren, sollte nicht die Standardeinstellung sein.
Flux verbindet Agenten über ein internes MCP-Gateway namens Agent Gateway mit internen Systemen. Jedes Playbook deklariert die Tools, die es benötigt, und Flux erteilt nur die für die jeweilige Aufgabe erforderlichen, eingegrenzten Berechtigungen. Jede Aktion wird protokolliert, wodurch ein klarer Audit-Trail entsteht.
Diese Gateway-Architektur bietet uns einen zentralen Kontrollpunkt für Authentifizierung, Autorisierung, Observability, Nutzungsverfolgung und die Durchsetzung von Richtlinien – all das macht den Agentenzugriff sicherer und im großen Maßstab einfacher zu betreiben.
Playbooks definieren die Arbeit
Ein Playbook ist eine wiederverwendbare Einheit agentischer Arbeit – das Äquivalent zu einem Docker-Container für Fähigkeiten und agentengesteuerte Aufgaben auf der Flux-Plattform. Es wird in einer einzigen Markup-YAML-Datei definiert und bündelt die Aufgabe, Eingaben, Kontext, Fähigkeiten, Tools, Berechtigungen, Validierung, erwartete Ausgaben und Sicherheitsgrenzen, die für eine konsistente Ausführung der Arbeit erforderlich sind.
Playbooks können agentische Schritte, die Flexibilität und Urteilsvermögen bieten, mit deterministischen Schritten kombinieren, die Vorhersagbarkeit, geringere Kosten und einfachere Validierung liefern. So können Teams Logik zwischen agentengesteuerter Ausführung und konventionellem Code verschieben, wenn sich Anforderungen ändern, ohne den Workflow neu zu gestalten.
Aufrufschnittstellen holen Entwickler dort ab, wo sie sind
Dasselbe Playbook kann über Slack, GitHub, Cron, die CLI oder einen Konversations-Skill ausgelöst werden. Das bedeutet, dass Teams einen Workflow einmal definieren und über die Schnittstelle aufrufen können, die am besten zum jeweiligen Moment passt:
- Slack für kollaborative Delegation
- GitHub für PR- und CI-Automatisierung
- Cron für wiederkehrende Wartungsarbeiten
- CLI für direkte Entwicklerkontrolle oder Aufruf über einen Skill
Genau das macht Flux leicht einsetzbar.
Lessons Learned
Der Aufbau von Flux hat uns ebenso viel über Produktadoption gelehrt wie über Infrastruktur, darunter:
- Eng anfangen, um Vertrauen aufzubauen. Wir begannen mit automatisiertem Code-Review, statt zu versuchen, den gesamten Software-Entwicklungszyklus zu automatisieren. Code-Review war häufig, messbar und für Entwickler leicht zu bewerten. Es gab uns einen Produktions-Workflow, in dem wir Qualität, Latenz, Kosten und Verhalten optimieren konnten, bevor wir auf CI-Triage, Bereitschaftsaufgaben, Wartungs-Playbooks und ticketgetriebene Entwicklung expandierten.
- Arbeit sichtbar machen. Unsere erste Slack-Integration erstellte private Kanäle für jede Agentenausführung. Das machte Flux für Einzelpersonen nützlich, schuf aber keine Teamgewohnheiten. Die Verlagerung der Arbeit in öffentliche Threads veränderte das Adoptionsverhalten. Entwickler konnten sehen, was andere delegierten, Flux bei der Arbeit zuschauen, die Ergebnisse prüfen und gemeinsam Vertrauen aufbauen.
- Playbooks brauchen Enablement. Wiederverwendbare Workflows entstehen nicht einfach, nur weil die Plattform existiert. Workshops und Hackathons halfen Teams, wiederkehrende operative Arbeit in Playbooks zu übersetzen. Die Primitive machten Automatisierung möglich; Enablement half Teams zu erkennen, welche Workflows es wert waren, kodifiziert zu werden.
Ausblick
Wir werden tiefer in die Plattform-Primitive eintauchen, die Flux zum Funktionieren bringen, sowie in die Developer Experience für die Erstellung neuer Workflows. Außerdem werden wir die darauf aufbauenden Anwendungen besprechen, darunter Flux Responder, unseren internen Slack-Agenten.
Danksagungen
Danke an 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 und Volanda Zhu für ihre Beiträge zur Plattform und zu diesem Artikel.
