How DoorDash runs cloud engineering agents on four primitives

DoorDash's account of Flux argues that getting an agent to write code is the mostly solved part, and that the hard part is the environment, tools, permissions and limits around it (engineering post). Flux is DoorDash's in-house cloud platform for running engineering agents, written up by SantoshPraneeth and jeffizhungry. DoorDash says it used Flux to automate 130,000 engineering tasks in a single month in 2026, and that it now runs more than 25,000 automated code reviews a week and more than 300 playbooks with over 10,000 invocations weekly, in workflows that can run unattended and in parallel.

Engineers' laptops were where agents started and where the problems showed. A laptop has limited cores, memory and battery, work stops when the lid closes, and the machine holds broad access to SSH keys, VPN sessions and other credentials that an autonomous agent should not inherit. Hosted coding agents posed a different tradeoff in DoorDash's telling: either send sensitive code and context to a third party, or open a path from that third party back into internal systems. So DoorDash built and kept control of the pieces around the agent.

Flux has four parts. A playbook, a single YAML file, defines a reusable unit of work: the task, inputs, context, skills, tools, permissions, validation, expected outputs and safety boundaries, and it can mix agent-driven steps with ordinary deterministic code. A sandbox, an isolated Firecracker micro virtual machine provisioned with the repositories, tools and secrets the task needs, gives the agent a place to run, with a target of full setup in under five seconds at the 95th percentile. Agent Gateway, an in-house gateway for the Model Context Protocol (MCP) that agents use to reach tools, grants only the permissions a playbook declares and logs every action. Invocation surfaces let the same playbook start from Slack, GitHub, cron, the command line or a conversational skill.

The figures are DoorDash's own and count volume, not time saved or quality. The post's lessons are about adoption: Flux started with code review because it was frequent and easy for engineers to judge, and moving agent runs from private Slack channels into public threads let engineers see what colleagues delegated and build trust in the output.