Industry case studies
MAGE did not run at this company. This page reads an independent practitioner report through MAGE’s vocabulary, to see how cleanly an outside system maps onto the theory. Every correspondence below is the book’s reading of the source, never a claim the company makes about MAGE.
These cases are practitioner reports, not replications of MAGE and not causal tests. A correspondence cell states how cleanly the source's described behavior maps onto a MAGE construct as the BOOK reads it — never a claim Cloudflare (or any site) makes about MAGE, and never proof. not-described means the SOURCE is silent; absence from a report is NOT evidence the company lacks the practice.
Meet the case
Docker began from a question about trust: how much freedom can you give an agent whose behavior you cannot fully predict? Its answer moved the boundary off the prompt and into the runtime, giving each agent a disposable microVM where the forbidden thing is simply absent (the home SSH directory is not in the agent's world, rather than a rule telling it not to look), so inside the box it can install, run, and modify freely. On that footing Docker ran a small team of role-specialized agents on CI, each free to investigate the unexpected, with an independent reviewer and a human standing between every pull request and the main branch. It is the youngest system in the set, so read it for its architecture and authority story rather than for long-run outcomes.
Distinctive starting point: authority boundaries + autonomous fleet + evaluation loops
What the case shows
Docker made authority itself an engineered property of the runtime - a hard microVM boundary placed outside the reasoner rather than asserted in prompts - then built a seven-role autonomous fleet and a worker/reviewer loop on top, giving MAGE its sharpest Alignment-Principle instance and the lesson that hard boundaries enable more autonomy, not less, while keeping a human on every merge under the shortest evidence horizon in the set.
What the agents do
A 7-role CI fleet: exploratory CLI testing (52+ scenarios / 14 tiers), performance and upgrade testing, reactive bug-fix (agent-fix label -> PR ~1h), a proactive weekly quality scan (5 findings -> 3 parallel runners -> 3 PRs), issue triage/dedup, project-board maintenance, and release-note generation. Roles are open-ended (investigate the unexpected, not compare to a fixed output - Docker's stated reason for roles over scripts). Agents open PRs, file issues, and manage the board; agents do NOT merge.
Setting: single-team · brownfield
Scale, as the source reports it:
- 7 autonomous roles on CI (cli-tester, performance-tester, upgrade-tester, software-engineer, project-manager, product-owner, /build-engineer) over 20 skills (13 foundational + 7 role)
- cli-tester: 52+ scenarios across 14 tiers
- worker/reviewer loop up to 5 iterations by default (worker = Opus; reviewer = Opus with 1M context evaluating the full diff)
- proactive software-engineer: weekly architect-mode scan -> up to 5 findings -> 3 parallel runners -> 3 PRs
- reactive agent-fix: first draft often within ~1 hour
- ~2-week build horizon; ~2-week run horizon at report (small-sample; no aggregate dataset)
The engineered environment
Object territory
source-code specs incident-reports
Representations
informal-knowledge spec tests
Mechanisms observed
constrained-api deterministic-lint llm-reviewer merge-gate retrieval-layer provenance
Where authority sits
Two boundaries, both OUTSIDE the agent. Runtime: each agent runs in a dedicated microVM sandbox with its own filesystem/workspace, network boundary (allow/deny lists), and Docker daemon; only the project workspace is mounted, no host reach; inside the box the agent has broad freedom (install/run/modify/execute unattended). Admission: agents create PRs but do not merge; architecture, priority, scope, and merge stay human. The boundary lives in the state space, not in prompts ('~/.ssh is not in the agent's world', not 'don't touch ~/.ssh'); delegation to parallel runners does not widen authority. Docker's stated product philosophy (product posts, corroborated by internal adoption in the Fleet report): guardrails enforced outside the agent, a true bounding box, and inside it move fast - hard boundaries enable MORE autonomy.
Mapping into MAGE
Each row is one MAGE construct, the strength of the correspondence, and how the book reads the source against it. The note is the book’s reading; the strength is not a score.
| MAGE construct | Correspondence | How the book reads the case |
|---|---|---|
| Alignment | ✓ strong | the book reads this as the sample's sharpest Alignment instance: microVM sandbox, network allow/deny, role-scoped tools, CI, tests, and human admission place authority outside the reasoner |
| Modeling | ◐ partial | the book reads rich soft knowledge (13 foundational skills carrying architecture/design/security) but no invariant-bearing system/process models - the sample's weakest Modeling site |
| Bootstrap | ✓ strong | the book reads the sandbox substrate + foundational skills + build/testing knowledge (the /build-engineer foundation) as seeding E(0) before roles run; the 'foundation first' lesson names it |
| Conversion | ✓ strong | the book reads noisy-detection->triage/dedup via the project-manager and missing-foundations->reusable-skills as a textbook small-scale conversion |
| Determinization | ~ tension | the book reads Docker as the determinization counter-case: deterministic tests give harder evidence where available, but the admission gate is DELIBERATELY kept probabilistic (an independent reviewer) + human, so the construct fits Docker awkwardly - though Docker does not disconfirm it (it determinizes tests, only declines to determinize admission) |
| Reasoning horizon | ✓ strong | the book reads the Ralph loop's fresh-context iterations + durable external task/artifact state as clean context banking, with skill composition bounding per-role context |
| Engineer's seat | ✓ strong | the book reads humans keeping architecture/priority/scope and a human on every merge as the engineer's seat - agents do the work, the team decides what matters |
| Graduated governance | ◐ partial | the book reads skills maturing local->CI before receiving unattended authority as a graduation, but no soft->hard mechanism-strengthening lifecycle is documented (contrast Cloudflare's approved->enforced) |
The theory the case appears to hold
The book reads Docker as holding that autonomous agents are useful because they investigate and act without continuous permission, so preserve that autonomy rather than suppress it: put hard execution boundaries outside the reasoner, give each agent a bounded sandbox + explicit role + project knowledge + only role-appropriate tools, compose reusable skills over monolithic prompts, use an iterative worker/reviewer loop instead of expecting first-pass correctness, run roles in CI but keep architecture/priority/scope/merge human, and when the fleet gets noisy improve the reusable substrate rather than patching each output.
What the case adds to MAGE
MAGE connects Docker's separately-named sandbox / roles / skills / testers / project-manager / worker-reviewer loop / CI / tests / merge as constraint + sensor + validator + gate + soft-conditioning + feedback + capital inside ONE governed environment, and names the structural-diagnosis question Docker performs but never states (the fix for false-positive overload was triage/confirmation, a missing mechanism, not a better tester prompt).
hard-boundaries-enable-more-autonomy authority-as-runtime-property-two-boundary-model skills-encode-roles-not-procedures durable-progress-outside-context-window autonomous-sensors-need-triage-economics generation-not-equal-evaluation bootstrap-follows-dependency-structure
What MAGE adds that this case does not reach
MAGE is a theory of the engineering ENVIRONMENT ITSELF as the object of engineering: everyone else engineers an agent, a runtime, a policy engine, or a model; MAGE engineers the governed environment in which commodity intelligence operates.
None of the external cases we examined describes the following machinery in the generalized form MAGE does. Not 'nobody in industry has ever done this.'
Honest bounds
The limitations the analysis records, and the falsifiable hypotheses the case bears on:
no-invariant-bearing-system-model-described no-model-territory-drift-gate admission-gate-stays-probabilistic-plus-human per-merge-human-oversight-not-amortized-h6-boundary no-false-positive-or-reviewer-veto-rates short-evidence-horizon-~2-weeks no-soft-to-hard-promotion-lifecycle no-reconcile-retire-evidence
H2-governance-moderation H3-mechanized-assurance H7-conversion-conditions H6-oversight-amortization H8-learning-propagation
Source
| Field | Value |
|---|---|
| Citation | delapena2026fleet |
| Source type | practitioner-report |
| Independence | independent |
| Account type | architectural |
| Evidence horizon | weeks |
| Author role | engineering (Staff SWE internal-practice account: de la Pena; supporting Docker product posts) |
Theory coverage at a glance
Where the source’s described behavior maps onto each MAGE construct: ✓ strong · ◐ partial · ~ tension · ✗ counterexample · — not described.
| MAGE construct | Correspondence |
|---|---|
| Alignment | ✓ strong |
| Modeling | ◐ partial |
| Knowledge rep | — not-described |
| Bootstrap | ✓ strong |
| Conversion | ✓ strong |
| Determinization | ~ tension |
| Reasoning horizon | ✓ strong |
| Engineer's seat | ✓ strong |
| Graduated governance | ◐ partial |