After studying this material, you should be able to:
Before understanding Flux, you need to understand what problem it solves.
Engineers at DoorDash were running AI agents on their laptops. This created three major problems:
Laptop Reality:
├── Fixed CPU cores
├── Limited RAM
├── Shared with all other apps
└── Only works when laptop is ON and connected
Result: Agent work pauses when engineer closes laptop or loses WiFi
Laptop Access:
├── SSH keys
├── VPN sessions
└── Authenticated tools
Problem: Giving an autonomous agent this broad access = large "blast radius"
if something goes wrong
Fragmented execution across many laptops means:
├── Hard to monitor what is running
├── Hard to know WHO triggered it
├── Hard to audit what systems were touched
└── No central oversight
Key Takeaway: Local agents are fine for interactive development but fail for unattended, parallel, secure, and auditable workflows.
DoorDash evaluated hosted (third-party) coding agents but identified a critical tradeoff:
Hosted Agent Tradeoff:
┌─────────────────────────────────────────────────────┐
│ Option A: Send code to third party │
│ → Risk: Sensitive code leaves DoorDash │
│ │
│ Option B: Open internal systems to third party │
│ → Risk: External access to internal infrastructure│
└─────────────────────────────────────────────────────┘
The real challenge was not getting an agent to write code. It was giving the agent:
Control the primitives around the agent, not just the agent itself.
This modular approach means:
Think of Flux like a factory assembly line. Each primitive plays a specific role:
Task Input
│
▼
┌─────────────┐ ┌─────────────────┐
│ PLAYBOOK │────▶│ SANDBOX │
│ (defines │ │ (where work │
│ the work) │ │ happens) │
└─────────────┘ └────────┬────────┘
│
┌────────▼────────┐
│ MCP GATEWAY │
│ (controls what │
│ agent can touch)│
└────────┬────────┘
│
┌────────▼────────┐
│ INVOCATION │
│ SURFACES │
│ (how engineers │
│ trigger work) │
└─────────────────┘
What it is: Isolated cloud environments where agents actually do their work.
Technology: Firecracker micro virtual machines (microVMs)
What each sandbox includes:
Agent Sandbox
├── Cloned repositories
├── Developer tools
├── Secrets (scoped)
└── Runtime dependencies
Why it matters:
Analogy: A sandbox is like a clean, temporary office cubicle that appears instantly, has exactly the tools needed for one job, and disappears when done.
What it is: A centralized control point that manages what systems an agent can access.
Full name: Model Context Protocol (MCP) Gateway — DoorDash calls theirs "Agent Gateway"
Systems agents might need access to:
Internal Systems:
├── CI/CD pipelines
├── Observability platforms
├── Issue trackers (e.g., Jira)
├── Deployment tools
├── Code search
├── Documentation
└── Service metadata
How it works:
Playbook declares required tools
│
▼
Agent Gateway grants ONLY scoped permissions
│
▼
Every action is LOGGED (full audit trail)
What the gateway provides:
Key Principle: Least-privilege access. Agents get only what they need, nothing more.
What it is: A reusable, self-contained definition of an agentic task.
Format: A single YAML markup file
What a playbook packages:
playbook:
task: description of work
inputs: required inputs
context: relevant background
skills: capabilities needed
tools: systems to access
permissions: scoped access rights
validation: how to check output
expected_outputs: what success looks like
safety_boundaries: what agent must NOT do
Key Design Feature — Hybrid Steps:
Playbook Steps:
├── Agentic Steps → Flexible, uses AI judgment
│ (good for ambiguous tasks)
└── Deterministic Steps → Predictable, lower cost
(good for structured tasks)
This hybrid approach lets teams shift logic between AI-driven and conventional code without redesigning the workflow.
Analogy: A playbook is like a recipe. Anyone can follow it, it produces consistent results, and you can swap ingredients (tools/steps) without rewriting the whole recipe.
What it is: The different ways engineers can trigger a playbook.
Available surfaces:
Same Playbook, Multiple Entry Points:
├── Slack → Collaborative delegation with team
├── GitHub → PR and CI automation
├── Cron → Scheduled/recurring maintenance
├── CLI → Direct developer control
└── Skill → Conversational AI interface
Why this matters:
Example: A code review playbook can be triggered automatically when a PR is opened (GitHub) OR manually by typing a command in Slack.
Let's trace a complete example — an automated code review:
1. INVOCATION SURFACE
Engineer opens a Pull Request on GitHub
→ GitHub webhook triggers Flux
2. PLAYBOOK
Flux loads the "code-review" playbook
→ Defines: what to review, what tools to use,
what a good review looks like
3. SANDBOX
Flux spins up a Firecracker microVM in <5 seconds
→ Clones the repo, installs tools, configures agent
4. MCP GATEWAY
Agent requests access to code search + CI results
→ Gateway grants only those scoped permissions
→ All actions logged
5. OUTPUT
Agent completes review, posts results back to PR
→ Sandbox is destroyed
→ Audit log retained
This happens 25,000+ times per week at DoorDash.
Building the platform is only half the battle. Here are three critical lessons:
Wrong approach: Automate everything at once
Right approach: Start with ONE high-frequency, measurable task
DoorDash started with: Automated Code Review
Why it worked:
├── Frequent (easy to gather data)
├── Measurable (quality is visible)
└── Low-stakes enough to experiment
First attempt: Private Slack channels per agent run
→ Useful for individuals, no team habits formed
Better approach: Public threads
→ Engineers see what others delegate
→ Watch agents work in real time
→ Build collective trust
Insight: Visibility creates social proof. When engineers see colleagues successfully delegating work, they adopt the behavior themselves.
Platform alone ≠ Adoption
What actually worked:
├── Workshops → Help teams identify automatable workflows
└── Hackathons → Hands-on playbook creation
Formula: Good primitives + Enablement = Real adoption
FLUX = Cloud-Based Agent Delegation Platform
Problem Solved:
└── Local laptop agents are limited, unsafe, and unauditable
Solution Architecture (4 Primitives):
├── Sandboxes → WHERE agents work (isolated, fast, cloud)
├── MCP Gateway → WHAT agents can access (scoped, logged)
├── Playbooks → WHAT agents do (reusable, hybrid, YAML)
└── Invocation → HOW work is triggered (Slack, GitHub, CLI...)
Results at DoorDash:
├── 130,000 tasks automated in one month
├── 25,000+ automated code reviews per week
└── 300+ unique playbooks in use
Key Principles:
├── Control primitives, not just the agent
├── Least-privilege access always
├── Start narrow, then expand
└── Visibility drives adoption