DoorDash published numbers this week that are worth sitting with: their internal platform Flux now runs 130,000 agent tasks a month, powers 25,000+ automated code reviews a week, and executes 300+ codified “playbooks” with 10,000+ weekly invocations — all inside Firecracker microVM sandboxes. This isn’t a pilot. It’s a production platform that expanded well past its Q1 2026 debut.

What’s interesting to a technical lead isn’t the raw scale. It’s the architecture decision underneath it, one that most teams skip past when they first wire an agent into their workflow: DoorDash didn’t give agents a shared dev box. They built a platform where every agent task gets its own isolated, audited, disposable environment. That distinction is the whole story.

The problem most teams don’t admit they have

Andy Fang, DoorDash’s co-founder, put the real blocker plainly: cloud-based agents are what most engineering orgs want but few are comfortable turning on, for security reasons. That’s the honest version of what happens inside most companies. Someone gets Claude Code or Copilot CLI running against a real repo, it works great in a demo, and then someone in security asks: what does this agent have access to, who audits what it touched, and what happens if it goes off-script mid-task and starts running commands you didn’t expect?

Most teams answer that question by either not answering it (agent runs with the same access as the engineer who invoked it, no isolation, no audit trail) or by over-restricting it into uselessness (read-only sandbox with no ability to actually run tests or install dependencies). Neither scales past a handful of engineers experimenting.

What Flux actually does differently

Each Flux sandbox is a Firecracker microVM — the same lightweight VM technology AWS Lambda and Fargate use for hardware-level isolation, not a shared container namespace. Every task gets a fresh one, pre-provisioned with the repositories, developer tools, secrets, and runtime dependencies that specific task needs, and scoped, audited access to everything it touches.

The pattern, stripped down:

# conceptual shape of a Flux-style task sandbox spec
task:
  id: pr-8841-fix-flaky-test
  repos: [checkout-service]
  scoped_credentials:
    - github: read-write, repo=checkout-service only
    - secrets_manager: read-only, prefix=checkout-service/*
  runtime: node20-standard
  playbook: flaky-test-triage
  audit: full-command-log + diff-log
  isolation: firecracker-microvm
  lifecycle: ephemeral # destroyed on task completion

Three things matter here that a lot of “let’s add an agent” projects skip:

  1. Credentials are scoped to the task, not the engineer. The agent doesn’t inherit a human’s full access — it gets exactly what this task needs, nothing more. This is the difference between “an agent with my GitHub token” and “an agent with a token that can only touch this one repo.”
  2. Every sandbox is ephemeral. It’s provisioned for the task and destroyed after. There’s no persistent agent environment accumulating state, stale credentials, or drift you have to audit later — because there’s nothing left to audit once the task closes.
  3. The audit trail is the point, not an afterthought. Full command log and diff log per task means “what did the agent actually do” is a query, not an investigation.

Playbooks: the part that scales beyond one-off tasks

The 300+ playbooks with 10,000+ weekly invocations are, in my read, the more durable idea here than the sandbox tech itself. A playbook is a codified, repeatable workflow — “triage a flaky test,” “bump a dependency and fix the resulting type errors,” “respond to a specific class of on-call alert” — that an agent can be invoked against without a human re-explaining the task from scratch every time.

This is the pattern that actually compounds. Firecracker sandboxes are infrastructure — useful, necessary, but replaceable with any comparable isolation tech (gVisor, Kata Containers, whatever your cloud offers). Playbooks are institutional knowledge encoded as agent-executable procedure. That’s the asset that gets more valuable the more your team invests in it, and it’s the part smaller teams can start building today without needing DoorDash’s infrastructure budget.

What this means if you’re building an internal agent platform

If your team is past the “one engineer running Claude Code locally” stage and is looking at standing up something more central, Flux is a useful reference architecture, not because you need Firecracker specifically, but because of the ordering of investments it implies:

  • Isolation boundary first. Decide the blast radius of a single agent task before you decide which model or which agent framework to use. If the answer to “what can this agent touch” is “everything I can touch,” you don’t have a platform, you have a liability.
  • Scoped, task-level credentials second. Not user-level, not project-level — task-level. This is more setup work upfront and it’s the thing that makes the security conversation actually closeable.
  • Audit logging as a first-class output, not something bolted on when someone asks “wait, did the agent touch prod?”
  • Playbooks last, and continuously. Don’t try to build a playbook library before you have real usage. Let the first dozen ad-hoc agent tasks tell you which ones are worth codifying.

The honest caveat

None of this is free. Firecracker-per-task means real infrastructure cost and provisioning latency compared to a shared environment — DoorDash is clearly running at a scale where that tradeoff pays for itself. If you’re a five-person team, a full microVM-per-task architecture is almost certainly overkill; a well-scoped container with short-lived credentials gets you 80% of the security benefit at a fraction of the operational cost. The lesson to take isn’t “adopt Firecracker” — it’s “isolate by task, scope credentials by task, log everything, and only then start automating the workflows you’re doing over and over.”

Sources: DoorDash Engineering — Delegating Engineering Work To Cloud-Based Agents, Andy Fang on X

Export for reading

Comments