AI NewsInfrastructureReported

DoorDash's Flux platform ran 130,000 engineering tasks with agents in a month

DoorDash's Flux platform automated 130,000 engineering tasks in one month, including more than 25,000 automated code reviews a week, using Firecracker microVMs with a 95th percentile sandbox setup under five seconds.

AI News

Editorial2 min read

LinkedInX
The Flux architecture diagram

Image: InfoQ

Why it mattersAn agent running on a laptop has whatever access that developer has. Moving it to a sandbox with scoped permissions is the difference between an agent and an audited one.

DoorDash moved its engineering agent workloads off developer laptops onto a platform called Flux. InfoQ's Leela Kumili reported the numbers on 31 August: 130,000 engineering tasks automated in a single month, more than 25,000 automated code reviews a week, more than 300 playbooks and more than 10,000 weekly invocations.

These are DoorDash's own figures, published on its engineering blog. They are the kind of numbers a company reports about itself, so read them as a description of scale rather than an audited result.

Why they moved

The reasons given for abandoning local execution are worth listing, because most teams still run their agents on laptops.

A laptop limits the CPU and memory available. The work depends on the machine staying connected. And an agent running there can use every credential and internal system that developer can already reach.

DoorDash also says local execution makes it harder to see where agents are running, what they access, and on whose behalf. Radoslav Krehlik, a security architect, summarised it as being built after laptop-based agents ran into limits on power, uptime and security.

The four pieces

Cloud sandboxes, on Firecracker micro virtual machines, each provisioned with the repositories, tools, secrets and runtime a task needs. DoorDash reports a 95th percentile objective of under five seconds for end-to-end setup, including starting the microVM, cloning repositories, installing build tools and configuring the agent harness.

An MCP gateway, called Agent Gateway, giving scoped permissions and logging agent activity for audit and policy.

Playbooks, defined in YAML, specifying the task, the tools, the permissions, the validation and the safety boundaries. They can mix agent-driven steps with plain deterministic code where predictable execution matters.

Ways to start a task: Slack, GitHub, cron, the command line, or a conversation.

The main point

Duy Nguyễn, co-founder of TOP GROUP Vietnam, put it well in a comment quoted by InfoQ: once agents handle background work, code review, internal tools and concurrent execution, the hard problem shifts from model choice to control. Identity, permissions, sandboxing, audit logs, quotas, and a real way to stop an agent at once.

That is the whole change in one line. Every debate about which model to use assumes the agent runs somewhere with sensible boundaries, and on a laptop it does not.

What other teams can copy

Under five seconds to a working sandbox is the number that makes the rest possible. If provisioning takes two minutes, nobody uses the sandbox and the agent goes back to the laptop.

The playbook idea is the other part other teams can copy: a YAML file naming the task, the permitted tools and the validation step, with deterministic code where the answer must be predictable. That is a smaller thing to build than a platform, and it is where the safety checks actually are.

The direction is general rather than specific to DoorDash. GitHub supports cloud sandbox environments for Copilot with controls over filesystem, network and system access.

Source

Reported byInfoQ

This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.

Share
LinkedInX
Start a project