DoorDash Engineering · Cloud-Based Agents Platform
Flux is DoorDash’s cloud-based agents platform for engineers. It hands tasks to secure, autonomous coding agents — so engineers can focus on innovation, critical thinking, and the complex problems that deserve them.
Where we started
Over the past year, engineers running agentic workloads on their laptops hit the same three walls — each one structural, none of them fixable with a faster machine.
A laptop has a fixed number of cores, limited memory, and a battery — shared with everything else on board. Agentic work wants parallel builds, tests, and large searches, and it stops cold when the lid closes, the network drops, or the engineer steps away.
work pauses when the laptop closes
Laptops carry broad access to sensitive credentials and systems — SSH keys, VPN sessions, authenticated tools. Handing an autonomous agent that same blast radius is unnecessary risk, and local environments make it hard to tightly scope what an agent can touch, and for how long.
broad credentials, large blast radius
When execution is fragmented across hundreds of individual devices, no one can answer the basic questions: what is running, where, on whose behalf, and which systems or files it has touched.
fragmented execution, no audit trail
Before — agents on laptops
After — agents on Flux
Why we built it in-house
Option A
Send sensitive code and execution context to a third-party hosted agent.
Code leaves the building.
Option B
Open a path from that third party back into internal systems.
The network opens the door.
“Getting an agent to write code is mostly solved. The harder problem was giving that agent the right environment, tools, permissions, integrations, and constraints.”
— the Flux thesis, from the DoorDash engineering post
So DoorDash controls the primitives around the agent — orchestration, sandboxes, workflows, permissions, integrations, and DoorDash-specific context — designed to be modular: the best third-party tool for each job, built in-house where deeper security, integration, performance, or UX ownership matters.
Primitives, not workflows
A playbook defines the work. A cloud sandbox gives the agent a real place to do it. Agent Gateway controls what systems the agent can reach. Invocation surfaces let engineers start and receive work where they already are. Because these are primitives — composable, not prescribed — teams build new agent workflows without reworking any infrastructure.
A task packet travels the loop — triggered from any surface, defined by a playbook, governed by the gateway, executed in an isolated sandbox. Select a stage to inspect it.
Flux moves execution into isolated cloud sandboxes backed by Firecracker microVMs — hardware-level isolation for every run. Each sandbox is provisioned with the repositories, developer tools, secrets, and runtime dependencies the task requires: a complete engineering workspace with a consistent execution, security, and observability model.
Controlling this layer is what lets Flux support real engineering workflows — including changes across multiple repositories and multiple pull requests from a single session.
End-to-end sandbox setup
p95 SLO < 5s
From starting the microVM to cloning the required repositories, installing build tools, and configuring the supported coding-agent harnesses — the full end-to-end setup holds a 95th-percentile service-level objective under five seconds.
Agents need the systems engineers use every day — CI, observability platforms, issue trackers, deployment tools, code search, documentation, service metadata. Granting broad, unrestricted access should never be the default.
Flux connects agents to internal systems through an in-house MCP gateway called Agent Gateway. Each playbook declares the tools it requires, and Flux grants only the scoped permissions that task needs. Every action is logged, creating a clear audit trail.
A playbook is a reusable unit of agentic work — the equivalent of a Docker container for skills and agent-driven tasks on Flux. One markup YAML file packages the task, inputs, context, skills, tools, permissions, validation, expected outputs, and safety boundaries.
Playbooks mix agentic steps — flexibility and judgment — with deterministic steps — predictability, lower cost, easier validation. Teams move logic between agent-driven execution and conventional code as requirements evolve, without redesigning the workflow.
task: review pull request
inputs: repo, pr_number
context: service metadata, prior reviews
skills: code-reading, test-analysis
tools: github.read, ci.query # scoped by Agent Gateway
permissions: least-privilege, time-boxed
steps:
- agentic: judge risk of the diff
- deterministic: lint + style gates
validation: expected outputs, quality checks
outputs: review comments, summary
safety: no merges w/o human approvalThe same playbook can be triggered from Slack, GitHub, cron, the CLI, or a conversational skill. Define a workflow once — invoke it from whichever surface matches the moment. That is what makes Flux easy to adopt.
Invocation surfaces
No new dashboard to adopt, no portal to remember. The same playbook fires from the place the work already happens — and the results come back to that same place.
Collaborative delegation. Engineers see what others delegate, watch Flux make progress, and review the output — together, in public threads.
@eng flux: review the payments-service PR queue
flux ● 3 playbooks invoked — posting reviews in thread…
illustrative exchange
PR and CI automation. Reviews, triage, and follow-ups attach to the pull request where the work is already happening.
flux reviewed #4812 · 2 suggestions · tests green
✓ ci / build — passing
illustrative automation
Recurring maintenance that never sleeps — scheduled monitoring and upkeep playbooks firing around the clock, unattended.
0 6 * * 1 # weekly dependency sweep
*/15 * * * * # scheduled monitoring
illustrative schedules
Direct developer control. Invoke any playbook from the terminal, or through a conversational skill when the moment is more fluid.
$ flux run code-review --repo payments --pr 4812
▸ sandbox ready in 4.1s · agent running
illustrative invocation
A conversational skill can invoke the same playbook — the fifth surface, for when delegation is a dialogue rather than a command.
@eng “triage last night’s CI failures and file follow-ups”
flux ● CI-triage playbook invoked
illustrative exchange
Flux at scale
These workflows run unattended, in parallel, around the clock — high-volume background work across all of DoorDash engineering.
A snapshot of Flux background-workflow usage across DoorDash in a single month — rebuilt live from the post’s Table 1. Category shares are proportional; the original figure published without axis values.
Lessons learned
Flux began with automated code review — not the entire software development life cycle. Review was frequent, measurable, and easy for engineers to evaluate: a production workflow where quality, latency, cost, and behavior could be tuned before expanding into CI triage, on-call tasks, maintenance playbooks, and ticket-driven development.
code review → CI triage → on-call → maintenance → ticket-driven development
The first Slack integration created private channels for each agent run — useful for individuals, but it never created team habits. Moving work into public threads changed the adoption pattern: engineers could see what others delegated, watch Flux make progress, review the output, and build trust together.
private channels → public threads → team habits
Reusable workflows don’t appear just because the platform exists. Workshops and hackathons helped teams translate repeated operational work into playbooks. The primitives made automation possible; enablement helped teams recognize which workflows were worth encoding.
primitives make it possible — enablement makes it real
What’s next
An internal Slack agent built on Flux — one of the applications the team will go deeper on, along with the platform primitives themselves and the developer experience for building new workflows.
DoorDash already runs the evals for its AI code reviewer on Flux infrastructure — the same primitives carrying the platform’s own quality bar. Read how the AI code reviewer was built and how engineers learned to trust it.
The full story
They came from treating delegation as a platform: primitives instead of workflows, governance instead of blind trust, and surfaces engineers already live in. Read the engineers’ own telling of how Flux got here.
As published in the original post
