KNOWLEDGE // ARTICLE ● PUBLISHED OPEN ACCESS SEQ 0x7F
HAPHAZARD SOLUTIONS · RESEARCH LIBRARY WHITEPAPER
ARTICLE

Operation: Rusty's Blanket

Strengthening the Orb — agent-native environments, their open foundations, and the governance of a hive

NATE, FOUNDER · CLAUDE FABLE 5 JULY 5, 2026 106 MIN READ
ABSTRACT

The Orb's open foundations, the coordination of a hive of agents, and the correlated-failure trap that undermines naive fleets.

https://haphazardsolutions.com/knowledge/operation-rustys-blanket/ · CC BY-SA 4.0

A white-paper in six parts, July 2026.

Contents

Abstract

In July 2026, Thorsten Ball described how Amp runs autonomous coding agents inside “Orbs” — ephemeral, headless remote machines engineered so an agent can operate, and verify its own work, without a human in the loop. The underlying idea is a design philosophy — build the environment for the agent, and don’t make it guess — wrapped around a concrete, largely-commodity artifact. This paper takes that idea seriously and tries to strengthen it rather than sell or debunk it.

We make four moves. First, we state the Orb thesis precisely: the bottleneck to autonomous agent work is environmental legibility, not model capability, and a legible, disposable environment lets a frontier model close its own feedback loop. Second, we map the landscape the Orb sits in — the ephemeral-sandbox substrate, the async-agent field, and the AGENTS.md documentation convention — and show that the raw infrastructure is commodity. Third, we decompose the Orb into a seven-layer capability stack and demonstrate that an open-source equivalent is largely assemblable from mature parts today, with the genuine difficulty concentrated in two places: a safe snapshot-and-reseed layer, and an un-downloadable legibility layer of per-repository conventions — an empirical confirmation of Ball’s “there is no moat.” Fourth, and most substantially, we scale from one Orb to a hive of them, which imports a coordination problem and, with it, a failure mode the single-Orb frame cannot see.

That failure mode is the paper’s central contribution. The reflexive way to run a hive — fork the agent, try several approaches, keep the winner — is A/B testing in a microVM costume, and it inherits every pathology of optimizing a proxy under destructive selection (Goodhart, survivorship bias, latent failure), plus one specific to agents. We call it the correlated cobra: at least five independent disciplines — N-version fault tolerance, Byzantine consensus, ecological anti-monoculture, financial diversification, and A/B selection itself — each invented “diversity equals resilience,” and every one silently assumes uncorrelated failures. A hive of agents spun from one base model, one prompt, and one training corpus violates that assumption by construction, so voting, quorum, and “an independent verifier” buy far less than their arithmetic implies — a fact now visible in early empirical work. The constructive consequence is a single rule: you cannot synthesize independence from copies of one mind; you must import variety from outside the model — out-of-band executable oracles, adversarial refuters drawn from different models, and humans.

We close by turning the whole survey into a reference architecture for a hive of Orbs — a durable directive skeleton wrapping disposable, self-governing, stigmergically-coordinated workers, verified with imported independence — a set of design principles, and a research agenda. The paper’s own spine is self-verification: introduced as the mechanism that makes one Orb work, followed as the axis that distinguishes the field, and resolved as the property a monoculture of agents cannot achieve alone.

§0 Introduction

The Orb, in one paragraph. An Orb is an ephemeral, headless remote machine — a fresh Debian environment — that a coding agent operates inside so a developer’s laptop is free while the agent works unsupervised. It comes pre-loaded with tooling, bootstrapped by an idempotent setup script, snapshot-cached so new Orbs start warm, and instrumented so the agent can log in, drive the running application, read a unified log, and thereby check its own work. Its animating slogan is “don’t make them guess”: the environment encodes what the agent needs to know — which files matter, which command starts the server, how to authenticate — so the agent never has to infer it. Ball’s wager is that today’s frontier models are already capable enough to work unsupervised if the environment is made legible to them; the leverage is in the environment, not the model.

Strengthen, not knock down. This paper is not a critique of Amp, and it is not marketing for it. The Orb is, in our reading, an important and correct idea whose public description is unusually candid — candid enough to build on. Our aim is to fortify it: to show where its foundations already exist in open source, to name the small gaps that remain, to shine a light on a failure mode that will undermine anyone who scales it naively, and to contribute our own position on the coordination problem that scaling creates. Where we are hard on an idea — as we are on the reflexive “fork and keep the winner” pattern — it is in the service of the concept, not against it. We are consistent about evidence: a large fraction of the Orb’s published specifics are single-source, describing Amp’s own private repository, and we flag them as accurate vendor self-report rather than independently audited fact, once, and carry that caveat forward.

The argument in brief. The paper moves from the concrete to the speculative and back to the buildable. One Orb is a systems-integration achievement over commodity parts, which means an open Orb is feasible and the real moat is a per-repository legibility practice. Many Orbs is a distributed system of ephemeral compute and a multi-agent system, so its coordination models are older and better-understood than the current discourse admits, and the workable shape is a directive skeleton around emergent muscle. But scaling verification by cloning fails, because copies of one model share their blind spots — the correlated cobra — and the only fix is independence imported from outside the model. The synthesis assembles these into a reference architecture whose two hardest components are exactly the two the open-source analysis flagged as genuinely unsolved.

A reader’s map.

A running example. From Part IV onward we follow one concrete task — a payments-library migration carrying a subtle, latent defect — through the coordination models, the failure analysis, and the reference architecture, so the argument never floats free of practice.

The spine. One thread runs the length of the paper: self-verification. It is the mechanism that makes a single Orb trustworthy (Part I); the axis along which the async-agent field silently splits, between buying independence with human gates and betting it away for autonomy (Part II); a layer the open-source substrate makes possible but not independent (Part III); the acknowledged bottleneck of any fleet (Part IV); and, in Part V, the thing the correlated cobra attacks and imported independence restores. The paper’s mechanism and its central warning turn out to be the same axis — which is why we follow it as a spine rather than treating it as a topic.

Scope and method, briefly. This is a synthesis of published sources and established theory, not a report on a built system: no hive of Orbs was constructed or measured here, the reference architecture is an informed proposal, and the cross-disciplinary mappings in Part V are our own. The paper was itself produced by a multi-agent research process with an adversarial verification pass — a fact that is both a disclosure and, given the subject, a small piece of evidence. We treat that reflexivity soberly and defer the details to the Note on Method.

Part I — The Orb and Its Thesis

Strengthening the Orb — Part I of VI. Establishes the idea this paper aims to strengthen: what an Orb is, the design principle it embodies, the mechanism that makes it work, and the worldview that produced it.

In July 2026, Thorsten Ball published a short essay titled “Putting an Agent in an Orb”, describing how Amp (Sourcegraph’s coding agent) runs autonomous agents inside ephemeral remote machines. The piece is easy to read as a product announcement. We read it as something more durable: a compact statement of a design philosophy for agent-native computing environments, wrapped around a concrete artifact worth taking seriously. This part lays out the artifact, the principle, the mechanism, and the worldview — the ground the rest of the paper builds on. Throughout, we distinguish what is independently established from what rests on Amp’s own account, because a surprising amount of the Orb’s specifics come from a single first-party source, and honest strengthening of an idea begins by being clear about what we actually know.

1.1 What an Orb is

An Orb is an ephemeral, headless remote machine — a fresh Debian 12 environment — that an Amp coding agent operates inside, so that a developer’s laptop is free while the agent works unsupervised (Amp Owner’s Manual — Orbs). It is created per agent thread, receives a fresh clone of the target repository plus configured secrets, and is disposable: it auto-pauses when idle, wakes when there is new work, and a paused Orb costs nothing (Orbs manual). The novelty is not the remote machine — cloud dev environments are old news — but the degree to which the machine is pre-arranged for an agent to succeed inside it without asking questions.

The anatomy is worth stating concretely, because the specifics are the argument:

Element What it is Why it matters
Substrate Ephemeral Debian 12 VM, one per thread; auto-pause/wake; disposable A real machine to “run” on that isn’t the developer’s laptop
Toolchain Pre-installed gh (authenticated), PostgreSQL, Redis, tmux, ffmpeg, ImageMagick, ripgrep, Bun, Node.js, npm, pnpm, agent-browser Removes install friction; “nearly everything else an apt-get install away”
Bootstrap .agents/setup — reported as a ~428-line Bash script: starts and tunes Postgres for ephemeral use, seeds test users, installs deps via mise/pnpm, writes guidance to ~/.config/amp/AGENTS.md A ready environment appears without the agent diagnosing it
Wake hook .agents/resume — re-establishes state on wake (≤10 s before the Orb proceeds regardless) Keeps a woken Orb consistent
Snapshot cache The post-setup environment is snapshotted and reused for up to ~24 h New Orbs start warm, not cold
Dev server An idempotent dev-server skill (ensure-dev-server.sh) that reuses a healthy server, restarts a wedged one, or starts a fresh one; ports live in .amp/dev-ports.json The agent reliably reaches a running app; parallel checkouts don’t collide
Auth shortcut Dev-only /__dev/log-me-in/<email>, /__dev/preflight, /__dev/sudo endpoints The agent signs in without an OAuth/2FA maze
Observability A single .amp/in/server.log, with browser console output folded in and tagged [browser] One grep-able surface for both server and client behavior
Documentation 41 nested AGENTS.md files providing directory-scoped guidance The agent doesn’t have to guess conventions
Sizing / price Four tiers (a0.tiny→a0.large), 40 GB disk, per-minute billing; paused = free Amortize setup, pay nothing while idle

A note on evidence, stated once and carried forward. With the exception of the substrate, lifecycle, and pricing — which Amp’s separate Orbs manual corroborates — nearly every fine-grained detail above (the 428-line script, the specific Postgres tuning, the /__dev endpoints, the [browser] tag, the count of “41” AGENTS.md files) appears only in Ball’s article, describing Amp’s own private repository. These are plausible, internally consistent, and quoted accurately here — but they are vendor self-report, not independently audited fact, and no third-party replication exists. We treat them as design intent faithfully described, which is enough for our purpose (the ideas are what we want to strengthen), and we flag where a claim’s weight exceeds its evidence.

1.2 The thesis: “don’t make them guess”

Strip away the specifics and the article makes one claim: agents fail not because they are incapable but because environments force them to guess — which files matter, which command starts the server, how to authenticate. Ball’s remedy is to encode that knowledge explicitly, in the environment and the prompt, so the agent never has to infer it (ampcode.com). The compression is the slogan “don’t make them guess,” and it resolves into four tactics:

The four tactics of agent-native design

  1. Idempotent operations — every setup step is safe to re-run, so the agent can reset or reuse state without fear (ensure-dev-server.sh reuses, restarts, or starts fresh).
  2. Paved paths — one blessed way to do each critical thing (one script for the dev server, one JSON file for ports, one magic-login URL instead of an OAuth maze).
  3. Cheap, disposable errors — because the machine is throwaway, being wrong is cheap, so the agent can act–check–correct instead of over-planning around mistakes it cannot observe.
  4. Pre-documented failures — anticipated failure modes are already answered in layered skill docs, so the first wall the agent hits already has a door in it.

The important move for our purposes is that none of these four is new. Each has durable prior art, and saying so strengthens rather than diminishes the Orb — it means the concept rests on tested foundations rather than a single vendor’s intuition.

  • “Paved path” is borrowed, explicitly, from platform engineering. The term originates at Netflix, whose “paved road” is a common platform and tooling that solves the problems every team shares, offered as the well-supported default within a “freedom and responsibility” culture (Netflix TechBlog, 2018; InfoQ). Spotify’s “Golden Path” (named for Dune) is the same idea. The agent-native twist is only this: the agent is the developer who must be kept on the road, because unlike a human it cannot reliably improvise off it.
  • “Make errors cheap” is independently reached by Simon Willison, whose “Designing agentic loops” argues agents “can usually recover from mistakes… and figure out the right incantations without extra guidance,” but only inside a “safe-to-fail” disposable context (simonwillison.net). That a vendor and an unaffiliated practitioner converge on the same principle is the strongest cross-source signal in the whole idea.
  • Pre-documented, machine-readable setup docs are converging on a cross-vendor standard, AGENTS.md, adopted across many tools and now stewarded by the Linux Foundation (we treat this in depth in Part II).

There is also a newer name for the whole enterprise — “Agent Experience” (AX), coined by Netlify’s Mathias Biilmann in January 2025 as a successor to Developer Experience, “the holistic experience AI agents will have as the user of a product” (biilmann.blog). AX is a genuinely useful lens: the Orb is AX applied at the environment layer rather than the API layer. But it is a vendor-originated frame promoted by companies selling agent-friendly platforms, and it rides amid broad “agent-washing” skepticism (Gartner, 2025). We therefore lean on the older, tested engineering vocabulary (idempotency, paved roads, disposability) and treat “AX” as convenient shorthand, not evidence.

The thesis, then, is modest and strong at once: the bottleneck to autonomous agent work is environmental legibility, not model capability. The frontier model is assumed to be good enough already; the leverage is in the environment. That is a falsifiable, engineering-shaped claim — and it is the claim we spend the rest of the paper stress-testing and building on.

1.3 The mechanism: closing the verification loop

If legibility is the principle, self-verification is the mechanism — and it is the thread we follow through the entire paper, so we introduce it deliberately here. The Orb’s wager is that a sufficiently legible, disposable environment lets a frontier model check its own work, which is what makes unsupervised operation viable. In Ball’s framing, models are “incredibly good at checking their own work, even in a remote machine” (ampcode.com). Everything in the anatomy table serves that end.

The underlying problem is concrete: a model writing frontend code cannot see what that code does when it runs. Google’s Chrome DevTools team states it plainly — “coding agents face a fundamental problem: they are not able to see what the code they generate actually does when it runs in the browser” (developer.chrome.com). Verification tooling is what turns a blindfolded generator into a self-correcting one, via an observe–act–verify loop: run tests, drive a real browser, capture and measure screenshots (Amp’s guidance tells agents to “measure screenshots with PIL instead of eyeballing pixels”), and grep a unified log where the browser console has been folded in (ampcode.com). The [browser]-tagged server.log and the disposable, idempotent setup are not incidental conveniences — they are the instruments that make the running application legible enough for the agent to judge its own output.

This rests on real prior art, not just product intuition. Agent-computer-interface (ACI) design — the finding that interfaces built for LLMs (a small set of view/search/edit actions, guardrails, concise feedback) outperform human-oriented interfaces — was established by SWE-agent, whose central thesis was that “LM agents represent a new category of end users” needing software designed for them (SWE-agent, arXiv:2405.15793). Amp’s log-tagging and screenshot-measurement rules are ACI design in that lineage. So is the reflection / evaluator-optimizer loop — generate, critique against ground truth, improve — which Anthropic identifies as effective precisely when “code solutions are verifiable through automated tests” (Anthropic, Building Effective Agents). Verification tooling is what supplies the objective evaluator these loops require.

Two caveats keep this honest, and both matter later. First, self-verification is real but partial: research on computer-use agents finds they “frequently fail to properly interpret visual information in screenshots” and are non-deterministic — “an agent that succeeds once may fail on a repeated execution of the same task” (UI-CUBE, arXiv:2511.17131) — which is why Amp itself pushes agents toward programmatic measurement over eyeballing, and why Anthropic still calls human review “crucial.” Second — and this is the hinge the paper turns on — a verifier is only as good as its independence from the thing it verifies. When a single Orb checks its own work, the checker and the maker share a mind; the loop can converge confidently on a wrong answer. That fragility is invisible in one Orb. It becomes the central hazard once we scale to many (Part V). We plant the flag here: the mechanism that makes one Orb work is the same axis along which a hive of Orbs is most likely to fail.

1.4 The worldview behind it

The Orb did not appear from nowhere; it is the shipped extension of a specific, stated worldview, and understanding it clarifies why the concept generalizes past Amp. Amp is Sourcegraph’s coding agent, born in early 2025 on a bet that frontier LLMs had become good enough at tool-calling that the winning move was to give the model tokens, real filesystem and shell access, and a curated toolset — then get out of the way (Amp Owner’s Manual). Its most public voice is Thorsten Ball — author of Writing An Interpreter In Go, writer of the Register Spill newsletter — whose essay “How to Build an Agent” argues that a working code-editing agent is just “an LLM, a loop, and enough tokens,” a few hundred lines of code, and that the hard part is “elbow grease,” not algorithmic secrets. His provocation on shipping it: “There is no moat” (Ball on X).

Two convictions from that worldview make the Orb inevitable. First, if you trust the model to “run” with genuine tool access, it needs a real machine to run on that isn’t the human’s laptop — hence a remote sandbox. Second, if failure is cheap, the agent should experiment rather than over-plan — hence disposability. The Orb is where “give the model tokens and get out of the way” acquires a physical substrate.

We take the “no moat” claim seriously rather than dismissing it as bravado, because it makes a testable prediction we can check: if the moat is not the model and not the infrastructure, then the Orb should be largely reconstructable from commodity parts, and whatever edge remains should live in the conventions and taste — the legibility layer — rather than the plumbing. That prediction is exactly what Part III puts to the test. And it reframes the paper’s ambition: to strengthen the Orb is not to defend a proprietary product but to take an openly-described, largely-commodity idea and ask how far it can be pushed, where it breaks, and how to build it well. That is the work that follows.

Part II — State of the Art: The Atlas

Strengthening the Orb — Part II of VI. A map of the world the Orb lives in: the ephemeral-sandbox substrate beneath it, the async-agent field beside it, and the documentation convention it depends on. This is the atlas; Part III is the recipe book.

The Orb is not sui generis. It sits at the confluence of three fast-moving areas: a category of ephemeral sandbox infrastructure that supplies disposable machines for running untrusted code, a cohort of asynchronous cloud coding agents that all now ship some version of “hand it a task, get back a PR,” and a documentation convention (AGENTS.md) for making repositories legible to agents. Mapping these three is not throat-clearing — it is how we later separate what is genuinely the Orb’s contribution from what is table stakes, and it is the evidentiary base for Part III’s claim that an open Orb is largely assemblable today. One methodological note carries over from Part I: vendor performance figures in this space (boot times, latencies) are overwhelmingly self-reported, and we flag them as such; the underlying mechanisms, by contrast, are well corroborated across primary documentation.

2.1 The ephemeral-sandbox substrate

Agents need a disposable, isolated computer to run model-generated code, and a distinct infrastructure category has formed to supply it. It spans a spectrum of isolation strength, and — crucially for agent workloads — the competitive axis is not isolation but cold-start latency and snapshot/fork capability: how fast you can restore a pre-warmed machine, and whether you can pause, resume, or branch a running one.

At the strong-isolation end is the microVM. Firecracker, AWS’s reference implementation, gives each session its own kernel via KVM hardware virtualization, wrapped in a “jailer” that drops privileges and thread-specific seccomp filters; AWS reports boots “in as little as 125 ms” at “about 5 MiB of memory per microVM” (AWS; firecracker-microvm). In the middle sits gVisor, Google’s user-space application kernel: a Go “Sentry” intercepts and re-implements syscalls so they never reach the host, giving VM-like address-space isolation without a per-sandbox guest kernel — at the cost of syscall-interception overhead (gVisor docs; secondary estimates put it at ~10–30% on I/O-heavy work, Northflank). At the flexible-but-weakest end are hardened container runtimes (Sysbox, Cloudflare Containers) that share the host kernel.

The commercial vendors map onto that spectrum, and the feature that actually matters for agents — memory snapshot, pause/resume, fork — is where they compete:

Platform Isolation Snapshot / fork / pause-resume Cold-start (as reported) Note
Firecracker (AWS) microVM (KVM) full & diff snapshots; the enabling primitive ~125 ms boot The substrate under much of the category
E2B Firecracker microVM pause/resume saves fs + memory (~4 s/GiB pause, ~1 s resume; paused kept indefinitely) “~150 ms” (vendor) Purpose-built “sandboxes for AI agents”
Modal gVisor + custom syscall filtering fs/dir/memory snapshots “sub-second” (vendor; GPU restore actually ~2 s) Snapshots to persist past a 24 h cap
Daytona multi-runtime (Sysbox / Docker / Kata) cold + hot (memory) snapshots; fork() (CoW filesystem clone) “sub-90 ms” (vendor, warm-start) “Match isolation to your threat model”
Cloudflare Sandboxes container filesystem persistence not published GA on Workers Paid, 13 Apr 2026
Codespaces / Gitpod VM + devcontainer image prebuilds / caching minutes → tens of seconds (single examples) The heavier “dev environment” wing

The strategic takeaway for the Orb: the winning trick is not booting a fresh VM but restoring a pre-warmed memory snapshot. Pause/resume lets an agent accumulate state across many tool calls and pay nothing while idle; fork lets it branch a session to explore multiple solution paths from a common checkpoint. That last capability — offered today by Daytona as a copy-on-write filesystem clone, and latent in every microVM’s memory snapshot — is the one we return to in Part V, because “fork the running agent and try two things” is both the Orb substrate’s most tantalizing affordance and the entry point for a subtle failure mode. Where the Orb sits on this isolation-vs-latency curve, and whether it exposes fork/snapshot to the agent, are not documented in Amp’s own materials — an open question we carry forward.

2.2 The async-agent field

By mid-2026 every major AI-coding vendor ships an asynchronous, cloud-hosted agent — a product category distinct from the synchronous in-IDE autocomplete of 2023–24. They converge on one shape: a task enters a queue, a fresh remote VM is provisioned, the repo is cloned, a setup step installs dependencies, the agent edits and runs tests, and a branch or pull request comes back for review. Google describes its own as “a task pool, a fleet of ephemeral cloud virtual machines, and the Gemini models” (digitalapplied); GitHub calls its agent “an asynchronous collaborator that works on your behalf like a teammate,” running “inside GitHub Actions” (github.blog). The differences worth mapping are three: maturity, where the environment runs, and — the axis our spine cares about — how much the agent is trusted to verify its own work versus gated by a human.

Agent Environment Provisioning Human gate Self-verification Maturity (mid-2026)
Devin (Cognition) Cognition cloud (shell + editor + browser + planner) configured repos + machine setup Slack/Teams tag, takeover, draft PR “checks CI passes or tests a deploy” GA
OpenAI Codex (cloud) air-gapped sandbox, internet off during run user setup script @codex on issues/PRs trained to “iterate on tests until passing” Web shipped; launched research preview May 2025
Google Jules Google-managed VM, destroyed after clone + install plan-approval gate before edits runs tests → PR GA (Aug 2025)
Claude Code (web) fresh Anthropic VM; creds proxied, “never enter the container” CLAUDE.md / .claude/ / setup scripts review; Auto-fix on CI failures “runs tests as part of working” Research preview
Cursor cloud agents Cursor-managed VM agent-led / snapshot / Dockerfile merge-ready PR w/ screenshots+video artifacts to demo changes GA
GitHub Copilot agent ephemeral GitHub Actions VM Actions setup PRs require approval before CI runs; 59-min cap reads CI logs, fixes, re-pushes GA
Amp Orb ephemeral Debian 12, snapshot-cached ≤24 h .agents/setup / .agents/resume leans away from gates magic-login + unified logs → self-verify newest entrant

Read down the last two columns and the Orb’s distinctiveness comes into focus. The raw remote VM is table stakes — Codex, Jules, Cursor, Copilot, and Claude Code all have one. The real divergence is philosophical, and it runs along the verification spine: Copilot and Jules add explicit human gates (approval-before-CI; plan approval before edits), buying safety by inserting a person into the loop. The Orb leans the other way — it invests in the environment (magic-login so the agent can drive an authenticated app, port metadata so it never hardcodes, unified [browser]-tagged logs so it can read its own failures) so that the agent can verify its own work and need fewer gates (Ball). This is the same wager we introduced in Part I: make the running application legible enough and the model closes its own loop. It is a defensible bet — but note what it trades away. A human gate is a decorrelated check: the reviewer does not share the agent’s blind spots. Self-verification, done by the same model that wrote the code, is not. The field is quietly split between buying independence with human attention and betting it away for autonomy — a tension Part V makes central.

2.3 The documentation layer: AGENTS.md

The third area is the convention that carries the Orb’s “pre-documented failures” tactic: AGENTS.md, a plain-Markdown file at a repo root (and nested through subtrees) giving agents the operational context they cannot infer from source — build/test commands, code style, conventions, pitfalls. Its history matters because it demonstrates genuine cross-vendor convergence rather than a single company’s house style. Amp published the case for a universal AGENT.md in May 2025, explicitly to end “the proliferation of agent-specific files” (.cursorrules, .windsurfrules, CLAUDE.md, .github/copilot-instructions.md) (ampcode.com); OpenAI, which owns the agents.md site and spec, is credited with the plural AGENTS.md and formalized it around August 2025, and — as of 9 December 2025 — the format is stewarded by the Linux Foundation’s Agentic AI Foundation alongside Anthropic’s MCP and Block’s goose (Linux Foundation; OpenAI). Reported adoption grew from 20,000+ repositories at launch to 60,000+ by the foundation announcement — self-reported GitHub-search counts, so directional rather than audited, but the trajectory is real.

Two features of the convention matter for the Orb. First, hierarchy: agents read the nearest file in the directory tree, ancestors loading eagerly and subtree files lazily when the agent touches that subtree (agents.md; Amp manual). The Orb repo’s reported 41 nested files are a live instance of exactly this pattern, and Amp’s .agents/setup additionally writes ephemeral, environment-specific guidance into ~/.config/amp/AGENTS.md, layering orb-context on top of committed repo docs — system → user/orb → repo-root → subtree, all in one portable format.

Second — and this is the finding worth carrying — not all agent docs are equal, and the difference is measurable. A benchmark running identical tasks with and without instructions found that prose paragraphs and vague directives (“be careful,” “where possible”) produce zero measurable behavior change, because they contain no command to run or threshold to meet; what works is exact shell commands (verifiable by exit code), explicit done-criteria, and bans on destructive actions, kept short (sections under ~50 lines, files under ~150, a hard 32 KiB ceiling in Codex) (Blake Crosley). The through-line: AGENTS.md is operational policy, not human documentation — a dumping ground of aspirational prose is worse than a short file of verifiable commands. This is the precise, testable core of the Orb’s “don’t make them guess,” and it foreshadows the paper’s recurring preference for checks a machine can execute over judgments a model must make.

The convergence is genuine but partial. AGENTS.md is the lowest-common-denominator baseline every major agent now reads, but vendor-specific files survive for tool-specific power: CLAUDE.md carries a richer import/scope system, Cursor’s .cursor/rules/*.mdc add glob-scoped conditional activation, Copilot keeps .github/copilot-instructions.md. Convergence is real at the “one file, many readers” layer; fragmentation persists at the feature layer — a nuance that matters when Part III asks what an open Orb’s documentation layer must actually contain.

2.4 Where the Orb sits

Three coordinates now fix the Orb’s position. On the sandbox map, it is one more ephemeral remote environment for running model-generated code — and the map tells us which knobs decide its fate (warm-snapshot restore, pause/resume, fork), even though Amp does not disclose where the Orb lands on them. On the agent map, it is the newest entrant in a field that has already commoditized the async loop, distinguished not by mechanism but by philosophy: it spends its design budget on self-verification rather than human gates. On the documentation map, it is a working demonstration of the cross-vendor AGENTS.md hierarchy, applied at production scale.

The synthesis of the atlas is a single, consequential claim that the rest of the paper turns into a thesis: the raw infrastructure — VM, sandbox, async loop — is commodity, and the Orb’s value lives one layer up, in the conventions and tooling that make an environment legible and a loop self-correcting. That claim is exactly Ball’s “there is no moat,” arrived at from the outside. If it is true, an open-source Orb should be largely buildable from the parts on these maps, with the remaining difficulty concentrated in the un-commoditized legibility layer. Testing that is the work of the recipe book.

Part III — The Open-Source Orb: The Recipe Book

Strengthening the Orb — Part III of VI. Where Part II mapped the world, this part is the build: it decomposes the Orb into a capability stack, scores what open-source already covers, names the small gaps that remain, and gives two concrete assembly routes. This is where Ball’s “there is no moat” gets tested against the actual parts bin.

If Part I’s worldview is right — the moat is neither the model nor the infrastructure — then the Orb should be largely reconstructable from commodity open-source parts, with whatever difficulty remains concentrated in the un-commoditized legibility layer. This part puts that prediction to the test. The finding, stated up front: an open-source Orb is mostly assemblable from mature parts today — but not as a single download, and not where you would expect the difficulty to be. Isolation, provisioning, lifecycle, the agent harness, and browser-based verification all have strong, actively-maintained open options. The genuine gaps are narrow, specific, and — tellingly — sit at the top of the stack, exactly where Ball predicted the value lives.

3.1 The Orb as a capability stack

To analyze buildability you have to stop treating “the Orb” as one thing. It is a stack of seven concerns, and open-source maturity varies enormously across them. The following matrix is the analytical centerpiece of this part; everything after it is commentary.

Layer What the Orb provides Best OSS option(s) today Coverage Gap
L0 — Isolation / compute Ephemeral Debian VM per thread; untrusted-code isolation Firecracker, Cloud Hypervisor, gVisor, Kata ✅ Solved None
L1 — Reproducible provisioning Pre-installed toolchain; .agents/setup devcontainer spec, Nix / devbox / flox, mise, OCI images ✅ Solved None
L2 — Snapshot / warm-start / fork Snapshot after setup, reuse ≤24 h; sleep/wake E2B infra (FC pause/resume); FC/CH snapshot primitives 🟠 Partial The real infra gap
L3 — Lifecycle control plane Create, auto-pause, wake, dispose; resume hook Coder; E2B infra 🟡 Mostly solved Minor glue
L4 — Agent harness The model loop + tools running inside the box OpenHands, mini-swe-agent, Goose, Cline ✅ Solved (strong) None
L5 — Self-verification substrate Browser screenshots, unified [browser] logs, tests OpenHands (BrowserGym), Cline (Puppeteer), Playwright MCP, Chrome DevTools MCP 🟡 Mostly solved Log-unification glue
L6 — Legibility / paved paths 41 AGENTS.md, idempotent dev-server skill, /__dev auth, port metadata The AGENTS.md standard — but the content is bespoke 🔴 Not a software problem The deepest gap
X — Secrets / networking / security Credential injection, /__dev posture, network re-establish Standard secrets tooling; nothing Orb-shaped 🟠 Partial Security-sensitive

The shape of the answer is legible at a glance: the bottom of the stack (L0–L1, L4) is solved commodity; the middle (L2–L3, L5) is assemblable with glue; the top (L6) is where the actual work — and Amp’s actual value — lives. The rest of this part walks the layers, dwelling where the gaps are real.

3.2 Layer-by-layer

L0 — Isolation is solved, and abundant. Several mature Apache-2.0 runtimes ship strong isolation and snapshot/restore: Firecracker (KVM microVM, ~125 ms boot, ~5 MiB overhead), Cloud Hypervisor (KVM with userfaultfd lazy restore), gVisor (userspace kernel with checkpoint/restore), and Kata. Whatever isolation-vs-latency point the Orb occupies, there is an off-the-shelf runtime for it.

L1 — Provisioning is solved. “A pre-installed toolchain plus a setup script” is precisely what the devcontainer spec plus Nix / devbox / flox or mise already standardize. Reproducible images + a bootstrap script are a settled pattern. Note the tell, though: the Orb’s setup script content — which test users to seed, which Postgres flags to loosen for an ephemeral database — is repo-specific. The tooling is free; the knowledge encoded in it is not. That is L6 casting its shadow early.

L2 — Snapshot / warm-start / fork is the real infrastructure gap. This is the Orb’s cleverest trick: run setup once, snapshot the warm machine, reuse it for ~24 h so new Orbs start hot. The gap is not the primitive — every VMM can snapshot — it is the safe, turnkey workflow, and there is a genuinely hard problem hiding in it. Firecracker’s own documentation warns that resuming one snapshot into multiple clones is insecure: the clones share duplicated entropy and randomness, carry stale network state, and repeat any secrets baked into memory (FC snapshot docs). So “snapshot once, spawn many” requires a re-seeding layer on top — fresh entropy, new network identity, secret rotation — that the primitive will not hand you. Only E2B’s open e2b-dev/infra (Apache-2.0, Firecracker-based, Terraform-self-hostable) ships pause/resume-from-memory as a real, self-hostable feature today (~4 s/GiB pause, ~1 s resume — vendor figures). The verdict: the hardest thing to build is not isolation — it is this snapshot-cache-and-reseed orchestration. E2B has open-sourced perhaps 80% of it; the last 20% — cache invalidation and safe fork-from-warm — is the one place you would write genuinely novel, security-critical code. (A caution: do not reach for Daytona’s OSS here; its public repo went unmaintained around June 2026 as development moved private.)

L3 — Lifecycle is mostly solved. Create-per-thread, auto-pause-when-idle, wake-on-work, dispose-on-archive, plus a wake hook. Coder (AGPL, Terraform-driven, with prebuild warm pools and wake-on-demand) is the best control plane to borrow; E2B’s infra provides the equivalent for microVMs. You would write light glue for the resume-style wake behavior (the Orb re-establishes networking with a 10 s cap), but the control plane itself is off the shelf.

L4 — The agent harness is solved, and stronger than expected. This is where open-source surprised on the upside. OpenHands (MIT core, ~79K stars, daily commits) is the closest single project to the Orb’s whole “agent + box”: a client-server runtime that spawns a fresh Docker sandbox per session, mounts the workspace, runs shell/files/Python, drives a browser, and supports local/remote/cloud backends (runtime docs). Alongside it: mini-swe-agent (a ~100-line, bash-only agent scoring >74% on SWE-bench verified, trivially sandboxable), Goose (Block, MCP-extensible), and Cline (the strongest OSS browser self-verification via Puppeteer). The agent loop is not the gap; if anything, OSS is spoiled for choice.

L5 — The self-verification substrate is mostly solved — [spine]. This is the layer that carries the Orb’s central bet, so it earns extra scrutiny. The pieces exist: browser-and-screenshots via OpenHands’ BrowserGym/Playwright, Cline’s Puppeteer loop, and the reusable Playwright MCP and Chrome DevTools MCP servers; runtime observation via Replay’s nut.new; and test-run-retry loops shipped in several harnesses. The gap is glue, not capability: the Orb’s specific move of piping browser console output into the same server log tagged [browser], giving the agent one grep-able surface, is a small bespoke integration nobody has generalized. Worth flagging what the parts don’t fix, and what we return to in Part V: every OSS verification tool here checks the model’s output using — in the default single-agent case — the same model’s judgment. The substrate makes self-verification possible; it does nothing to make the verifier independent of the thing it verifies. That is not an L5 gap you can close with more tooling; it is a design problem for the hive.

L6 — Legibility is the gap you cannot download. Everything above is software you install. This is not. The Orb’s productivity comes from 41 nested AGENTS.md files, an idempotent dev-server skill that reaches a known-good state, /__dev auth-bypass endpoints, and port metadata. The AGENTS.md format is a real open standard (Part II), but the content is authored per repository; the skill script is one you write for your app. There is no package for “make your repo legible to an agent.” This is the design discipline the whole Orb thesis rests on, and it is irreducibly per-project. An open Orb can hand you the box; the legibility is homework — and it is almost certainly where Amp’s real, non-commodity value sits.

X — Secrets, networking, and security are partial and sensitive. Credential injection into an ephemeral box, the posture of dev-only /__dev bypasses (harmless in a disposable sandbox, catastrophic if the pattern leaks toward production), secret rotation across snapshot forks, and network re-establishment on wake are all partially covered by standard tooling but not packaged as an Orb-shaped solution. Note the overlap with L2: cloning a warm snapshot safely is, at bottom, a secrets-and-entropy problem. Security is not a bolt-on here; it is entangled with the cleverest infra trick.

3.3 Two build routes

The stack analysis resolves into two credible assembly routes, depending on whether you want a working box fast or the Orb’s actual architecture.

Route A — Fastest to a working box (accept a crude Orb today). OpenHands + its per-session Docker runtime + the BrowserGym browser tool. You get an ephemeral, isolated, self-verifying agent box now. Missing: warm-snapshot caching (you pay a cold Docker start each time), and all of L6 (you author the AGENTS.md and skills yourself). This is a real open Orb minus the speed trick and the conventions — roughly 70% of the way there, out of the box.

Route B — Closest to the Orb’s actual architecture. L0–L2: E2B infra (Firecracker + pause/resume-from-memory, self-hosted via Terraform) — the least-effort path to the snapshot trick. L3: Coder for create/sleep/wake/dispose and prebuild warm pools. L1: devcontainer.json + Nix / mise for the reproducible toolchain. L4–L5: mini-swe-agent (minimal) or OpenHands (batteries-included) as the harness; Playwright MCP for browser verification; a hand-wired unified log. L6: you write the AGENTS.md hierarchy, idempotent skills, dev-login shim, and port metadata. The novel code you would actually write: the safe snapshot-cache-and-reseed layer (L2’s last 20%) and the legibility conventions (L5 glue + L6 content). Everything else is assembly.

Both routes make the same point from different angles: the Orb is a systems-integration achievement, not an invention. That is not a criticism — good integration is hard and valuable — but it is the precise sense in which “there is no moat” is true.

3.4 The gaps, ranked — and a caution

Distilling the layer walk, the genuine gaps between “commodity parts” and “a working open Orb,” ranked by how much real work each demands:

  1. Safe warm-snapshot-cache-and-fork (L2). Hard, but ~80% pre-built by E2B. The remaining 20% — 24 h cache invalidation plus entropy/secret/network re-seeding on fork — is the one place you write genuinely novel, security-critical infrastructure. Firecracker’s own docs tell you the naive version is unsafe.
  2. Vertical integration glue (all layers). Medium. Every part exists; wiring them into one coherent, ergonomic product is simply undone engineering — the “someone should package this” gap.
  3. Legibility / paved-path conventions (L6). Deepest, and not a software problem. Per-repo authoring discipline, un-downloadable by nature. Where an open Orb’s productivity is actually won or lost.
  4. Credential isolation and the /__dev posture (X). Medium and security-sensitive; app-specific, with no packaged answer.
  5. Unified [browser]-tagged logging (L5). Easy but unshipped — a small integration nobody has generalized.

One cautionary note belongs in any honest recipe book, because it governs which parts you should build on:

Sidebar — the OSS agent graveyard. The sobering finding from the landscape sweep is that the early “open Devin” wave is mostly dead. As of mid-2026, Devika and Devon are abandoned (~2024), GPT-Pilot is self-declared unmaintained (and suffered a supply-chain compromise), gpt-engineer was archived read-only in April 2026, and smol-developer has been dormant since 2023. Two fresh 2026 casualties: Roo Code archived (May 2026, pivoted to a commercial product) and Continue acquired by Cursor (June 2026, repo read-only). The survivors worth betting on are a short list — OpenHands, SWE-agent/mini-swe-agent, Goose, Cline, plus E2B / Coder on the infrastructure side. Churn is extreme: any open-Orb plan should assume its harness dependency could be acquired or abandoned within a year, and should favor projects with institutional backing and daily commit activity.

What the recipe book proves

The gap analysis confirms Ball’s “there is no moat” from a direction he did not argue: the entire bottom and middle of the Orb stack is commodity open-source, and even the cleverest infra trick is ~80% open-sourced by a competitor. If the Orb has a moat, it is at L6 — the conventions and taste — which is exactly the part that cannot be commoditized into a package, because it is authored fresh for every codebase. The useful inversion for anyone building on this: an open Orb is very feasible as a substrate, but replicating the Orb’s productivity means replicating the discipline, not the download. The infrastructure is a weekend-to-a-month of assembly; the legibility is a permanent practice.

That conclusion is about one Orb. It also quietly sets up the paper’s turn. Every route above yields a single disposable agent-machine — and the moment you have cheap, disposable, forkable agent-machines, the obvious next move is to run many of them at once. That move is not free. It imports a coordination problem, and with it a failure mode that the single-Orb analysis cannot see. From here the paper stops asking “how do we build one Orb?” and starts asking “how do we govern a hive of them?”

Part IV — From Orb to Hive: Coordination

Strengthening the Orb — Part IV of VI. The moment you have cheap, disposable, forkable agent-machines, the obvious move is to run many at once. That move imports a coordination problem. This part is our position on how a hive of Orbs should coordinate — where to be directive, where to be emergent, and what the ephemerality forces on you either way.

Part III ended on a hinge: every route to an open Orb yields a single disposable agent-machine, and cheap disposable machines invite you to run a fleet of them. But a fleet is not a feature you turn on; it is an architecture you have to design, and the design space is larger and older than the current discourse admits. This part takes a position on it. Our through-line, argued below and then complicated in Part V: a hive of Orbs should be a directive skeleton wrapped around emergent muscle — a durable, legible control plane that dispatches work to loosely-coupled, disposable, self-claiming workers — and the Orb’s defining property, disposability, is what forces that shape rather than merely permitting it.

4.1 A hive is two things at once

The reason coordination is harder than it looks is that a hive of Orbs is simultaneously two well-studied things: a multi-agent system (autonomous reasoners pursuing a shared goal) and a distributed system of ephemeral compute (stateless workers that appear, do work, and vanish). Most current writing treats it only as the former, reaching for LLM-orchestration frameworks, and misses that the latter tradition — decades of distributed-systems engineering — has already solved, or proven unsolvable, many of the problems a hive will hit.

Three traditions therefore supply the vocabulary, and the most useful realization is that the “new” LLM-orchestration patterns are largely re-discoveries of old ones:

Tradition What it contributes
Distributed systems orchestration vs choreography; work queues, work-stealing, leader election, consensus; durable execution / checkpointing; idempotency
Multi-agent systems the blackboard architecture (Hearsay-II, 1970s); the Contract Net Protocol (auction-based allocation, 1980); stigmergy and swarm intelligence; the actor model and supervision trees (Erlang/OTP)
LLM-orchestration (2026) orchestrator-worker; supervisor / router / pipeline / swarm patterns (LangGraph, CrewAI, AutoGen); A2A and MCP protocols; git-worktree fleets

Anthropic’s orchestrator-worker is a supervision tree. A shared agent task-list is a blackboard. Coordinating through a git repository is stigmergy. This is not pedantry: knowing a pattern’s lineage tells you which failure modes are already catalogued and which remedies are already proven, so you neither reinvent them nor rediscover their limits the hard way.

A running example — “The Payments Migration.” To keep the rest of this paper concrete, we will follow one task from here through Part VI. A hive of Orbs is asked to migrate a payments service from the library libpay v2 to v3 — a breaking major-version bump — across a monorepo of about thirty modules. There is a trap baked in, and it is a realistic one: v3 quietly changed a single default, the currency-rounding mode, from banker’s rounding (round-half-to-even) to round-half-up. The change is one line deep in the v3 changelog; the existing test suite uses round-number fixtures that never exercise a tie-breaking case, so it cannot distinguish the two behaviors. This task is a good stress-test because it exercises every layer of a hive at once — it fans out across modules (parallelism), it invites forking two migration strategies (speculative exploration), it demands merge discipline (many modules, one codebase), and it hides a latent cobra that no amount of “the tests pass” will surface. We will watch a naive hive walk into the trap in Part V, and watch the reference architecture avoid it in Part VI.

4.2 The directive-to-emergent spectrum

The natural axis for organizing coordination models is directive ↔ emergent — from a fixed control-flow graph that dispatches every step, to a leaderless swarm whose global behavior emerges from local rules. It is the right axis, and the central finding is that neither pole works alone.

Model Coordination medium Prior art Position Orb fit
Static workflow / DAG code (control flow) Airflow, Temporal ◀ most directive Known, repeatable pipelines
Orchestrator–worker central agent dispatch Anthropic Research directive The current workhorse
Hierarchical teams orchestrators of orchestrators CrewAI hierarchical directive-ish Powerful; needs depth limits
Blackboard / ledger shared artifact (read/write) Hearsay-II ◆ the bridge Excellent for ephemeral workers
Agent teams (self-claim) shared task list + P2P messages fleet tools; “Gas Town” semi-emergent Strong, if state is externalized
Choreography event bus (pub/sub) microservices decentralized Scales; harder to debug
Market / contract-net task auction + bids Contract Net Protocol (1980) emergent Untested at coding scale
Stigmergy / swarm modify shared environment ant colonies, boids ▶ most emergent Open-ended exploration
Actor model (substrate) message passing + supervision Erlang/OTP “let it crash” any Natural failure model for disposable Orbs

Pure directive fails on open-ended work. A fixed graph cannot express a task whose steps you cannot predict; as Anthropic observes of research, “you can’t hardcode a fixed path for exploring complex topics, as the process is inherently dynamic and path-dependent” (Anthropic). The payments migration illustrates the tension: the shape is knowable (migrate each module, run tests, merge) and so tempts a rigid DAG — but the content of each module’s migration is path-dependent (this one needs a shim, that one has a transitive dependency on the old rounding behavior), so a purely static pipeline will stall the moment a module surprises it. Pure emergent fails on control. A leaderless swarm is powerful but nearly impossible to steer, debug, or bound — a failure we can document from the multi-agent research that produced this paper (see the Note on Method): one agent, given a broad brief, spontaneously spawned a nested fan-out of roughly six sub-agents, several of which returned confused meta-commentary instead of results, burning an estimated 250,000 excess tokens with no backpressure. Nobody instructed it to; it self-organized into an uncontrolled hierarchy. That anecdote is not evidence — it is a single uncontrolled instance — but it is a faithful miniature of the failure the theory predicts: emergent coordination without guardrails does not gently underperform, it runs away.

The productive reading of the spectrum is therefore not “pick a point” but “assign each concern to the end that suits it.” Correctness, cost, and merge-safety want the directive end, where behavior is legible and bounded. Exploration and coverage want the emergent end, where the system can follow leads no one predicted. The rest of this part is about which specific models realize that split well for ephemeral workers.

4.3 The four models that fit ephemeral Orbs

Of the spectrum, four models matter most once the workers are ephemeral, because disposability changes which properties are load-bearing. We take each in turn and, where it helps, run it against the payments migration.

1. Orchestrator-worker over durable execution — the directive workhorse. The industry has converged here for measurable reasons: Anthropic’s research system (a lead agent plus 3–5 parallel sub-agents, each with its own context window, plus a separate citation pass) outperformed a single agent by 90.2% on their internal evaluation, with token usage alone explaining 80% of the variance (Anthropic). The cost is roughly 15× the tokens of a chat, justified only for high-value tasks. But the same source flags a warning aimed squarely at a coding hive: multi-agent excels at “heavy parallelization” and is a poor fit where agents “share the same context or involve many dependencies” — and “coding tasks… have fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time.” The payments migration lands on both sides of that line: migrating thirty independent modules is embarrassingly parallel and ideal for orchestrator-worker; but the cross-cutting decision — how the whole service handles rounding after the bump — is a shared-context dependency that no amount of parallelism helps, and that a naive fan-out will get thirty subtly-inconsistent answers to. The lesson is to fan out the parallelizable part and serialize the shared decision, rather than letting each worker improvise it.

The under-appreciated half is the durable-execution backbone. Because Orbs sleep, wake, pause, and die, the coordination state must outlive any individual Orb. This is exactly what durable-execution engines (Temporal, DBOS, Restate, Cloudflare Workflows) provide via journal-based replay or database checkpointing. The distinction that matters for Orbs: application-level checkpointing (LangGraph) protects against bad reasoning, while durable execution protects against infrastructure-level failure — container crashes, host preemptions — and an Orb going to sleep is an infrastructure-level event (Temporal; survey). Concretely: if the migration is a durable workflow, an Orb that dies halfway through module 17 does not lose the fact that modules 1–16 are done and merged; a fresh Orb resumes from the journaled state. Without durable execution, the same crash forces a re-scan of the whole repo to reconstruct progress — the fleet-scale version of the very “guessing” the Orb was built to eliminate. For a hive of ephemeral Orbs, durable execution is not optional; it is the spine that lets disposable workers coordinate at all.

2. Blackboard / shared-ledger — the bridge, and stigmergy in disguise. This is the model we would emphasize most, because it fits ephemeral workers better than anything else. A shared control-document that agents read to decide their next move and write to record state is a blackboard architecture (Hearsay-II), and coordinating through a shared artifact rather than direct messages is stigmergy — the mechanism by which ants coordinate through pheromone trails without conversing. Why it suits Orbs: the artifact is durable; the workers are disposable. An Orb can die mid-task and a fresh one reads the same ledger and resumes the frontier — no lost mailbox, no re-synchronization. Practitioners report exactly this working: “shared external state (task list, git branches) coordinates without constant synchronization,” with self-claimed tasks and dependency auto-unblocking (Osmani). For the migration, the ledger is a living manifest — one row per module with a status (unclaimed/in-progress/migrated/merged), the claiming Orb’s id, and the decisions taken — that any Orb can read to answer “what’s left, what’s blocked, what did we already decide about rounding?” without asking a peer who may already be dead. And it closes a satisfying loop with Part I: the Orb’s founding principle, “don’t make them guess,” applied at the fleet level, becomes “no Orb should have to guess what the others are doing” — so you make the swarm’s state explicit and legible in a durable artifact. Legibility scales from the single environment to the hive. (One design subtlety the migration exposes: the ledger must record decisions, not just progress. If module 4’s Orb resolved the rounding question one way and never wrote that decision down, module 19’s Orb will re-derive it — possibly differently — and the service ends up internally inconsistent. The blackboard’s value is as much in capturing shared commitments as in tracking tasks.)

3. Emergent muscle — self-claiming workers, markets, and fork-based exploration. Emergence earns its keep on open-ended exploration and unknown-size discovery. Three mechanisms sit here, in increasing order of decentralization. Pull-based allocation (work-stealing) beats push-based assignment when the workload is heterogeneous — workers self-claim modules from the ledger instead of an orchestrator guessing an even split, which dodges the duplication Anthropic observed when a lead agent briefed its workers poorly, and naturally load-balances when module 17 turns out to be five times the work of module 3. Market / contract-net allocation (tasks auctioned, agents bid on the basis of estimated cost or fit) is the fully decentralized version, decades old and conceptually clean but untested for coding at fleet scale; one could imagine Orbs bidding lower on modules matching a domain they have already loaded into context, but nobody has shown this beats a planner’s decomposition in practice. And speculative fork-based exploration is the genuinely Orb-native one — because microVM snapshots support fork (Part II), a hive can fork at a decision point, let N Orbs explore divergent paths from a shared checkpoint, and keep the winner.

That last pattern deserves a flag, because it is the most exciting thing the Orb substrate makes possible and also the entry point for the paper’s central warning — and it is exactly where the payments migration goes wrong. Faced with the cross-cutting rounding decision, a hive naturally forks: branch A1 adopts one migration strategy (say, wrap every call site in a compatibility shim), branch A2 adopts another (adopt v3’s defaults wholesale), and the plan is to run both, score them, and keep the better. This feels like rigor. It is swarm search with disposable branches, nobody has productized it, and — as Part V argues at length — it is a rediscovery of A/B testing and evolutionary selection that inherits their hazards wholesale, plus one specific to Orbs. Here is the tell, stated now and unpacked there: A1 and A2 will both miss the rounding change, because both were reasoned by the same base model reading the same changelog, so when they agree that the migration is correct, that agreement is not two confirmations — it is one blind spot, counted twice. We introduce the fork here as an opportunity and pick it back up there as a trap; the reader should hold both.

4. The actor model — the failure substrate. Beneath whichever coordination model you choose, the actor model (Erlang/OTP) is the deepest and most-overlooked prior art for a fleet of disposable machines. Isolated processes, no shared memory, message passing, supervision trees, and the “let it crash” philosophy map almost exactly onto Orbs: an Orb dying is not an exception to handle but the expected lifecycle. A supervisor restarts it; the Orb’s own idempotency discipline (Part I) makes restart safe — the migration’s .agents/setup re-seeds the database, the module’s tests re-run, and the restarted Orb reaches the same known-good state its predecessor died from. This is “cheap to be wrong” promoted from the single environment to the fleet — individual failure is cheap, so you design for it rather than against it. The actor model also supplies a discipline the migration needs and that Part V sharpens: how an Orb dies matters. An Orb that crashes cleanly (rolls back its worktree, releases its ledger claim) lets the supervisor restart the module safely; an Orb that dies messily mid-write — a half-applied migration, a force-push, a corrupted shared snapshot — can poison the modules that inherit its state. “Let it crash” is only safe when crashing is contained.

4.4 Cross-cutting concerns any hive must solve

Independent of coordination model, six concerns bind every hive of Orbs, and the ephemerality makes several non-negotiable. We state each as a principle and check it against the migration.

  1. Externalized state (mandatory). Disposable workers force shared state to live outside them — git repo, object store, coordination database, or the ledger. This is not a design choice; it is imposed by the substrate. In the migration, the module manifest, the shared rounding decision, and the compensation log all live outside any Orb, because any Orb might vanish between tool calls.
  2. Merge and conflict discipline. Parallel Orbs editing one codebase is the hard case. The 2026 consensus primitive is the git worktree — each agent gets its own working directory and branch, so parallel work produces no live merge conflicts (worktrees) — and the mature topology adds a verification gate: Goal → Planner → Task Graph → Orchestrator → parallel Agents → Janitor (verify) → merge queue → main. Thirty modules migrating in thirty worktrees never collide at the file level; but note what worktree isolation does not buy you — it prevents syntactic conflicts, not semantic ones. Two modules can merge cleanly and still disagree about rounding. Isolation solves the easy half of merge safety and lulls you about the hard half, which is a job for verification, not version control.
  3. Communication substrate. The emerging interop stack pairs A2A (agent-to-agent delegation, now 150+ organizations under Linux Foundation stewardship — LF press, a promotional first-party figure) with MCP (agent-to-tool). For ephemeral workers we would default to blackboard/ledger over chatty peer-to-peer messaging, because a durable artifact survives a dead peer’s mailbox; A2A earns its place at the boundaries of the hive (delegating to an external specialist service) more than inside it (where the ledger is a better bus).
  4. Backpressure, budgets, and kill-criteria. The concern people skip until it bites. As one practitioner puts it, “removing the human loop removes the pain signals… with an orchestrated army of agents, there’s no natural bottleneck” (Osmani). The countermeasures are hard per-agent token budgets (auto-pause well before exhaustion), concurrency caps, and explicit kill-criteria (reassign if stuck after a few iterations). The runaway anecdote in 4.2 is precisely what an emergent layer without these produces; a migration that forks two strategies across thirty modules without a fleet-wide budget is one confused sub-agent away from the same failure at thirty times the scale. We return to the economics of this in Part V’s treatment of the commons.
  5. Verification is the fleet bottleneck — [spine]. This is where the paper’s spine re-enters, and where the migration’s trap actually springs. N agents generate N× the code to review, so “the bottleneck is no longer generation; it’s verification” (Osmani). Scaling it means a layered trust model — plan-approval before code exists, automated hooks (tests, lint), and human-curated AGENTS.md — which is Part I’s single-Orb self-verification scaled to a fleet, plus adversarial cross-checking (one agent trying to refute another’s output). The migration shows why the layers are not interchangeable: the automated hook (the existing test suite) passes on both branches and certifies the cobra as safe, because the suite was written by the same kind of reasoning that missed the changelog line. Only a check that does not share that blind spot — a property-based test asserting a monetary invariant, a diff against the v3 docs, a differently-modeled refuter told to break the migration — has any chance of catching it. Hold that phrase, adversarial cross-checking, because Part V shows it is not a nicety but the only form of hive verification that actually buys independence.
  6. Observability and a control plane. Steering a swarm requires a mission-control view; the 2026 slogan is “control plane first” — you manage the fleet, not any single agent. A hive you cannot observe is a hive you cannot govern, which connects directly to the cybernetic argument in Part V that an unobservable state is where latent failures hide. In the migration, the rounding-mode behavior is precisely such a state: nothing in the fleet’s dashboards distinguishes a correctly-rounding branch from an incorrectly-rounding one, because the outputs the dashboard sees (tests green, diff merged) are identical for both. Observability is not “can I see the Orbs working”; it is “can my telemetry distinguish the failure I care about” — usually a harder question than it looks.

4.5 Our position: directive skeleton, emergent muscle

Pulling the threads together, our position on coordinating a hive of Orbs is a deliberate blend rather than a point on the spectrum:

  • A directive skeleton — a durable-execution control plane with deterministic control flow and checkpoints that survive Orb sleep and death, decomposing goals and dispatching work. Legible, bounded, reproducible.
  • Emergent muscle — loosely-coupled, disposable, idempotent worker-Orbs that self-claim tasks from a shared ledger and may fork or explore emergently within bounded scope.
  • Stigmergic shared state — coordination through a durable shared artifact (git repo plus task-ledger), not chatty direct messaging, because the workers are ephemeral.
  • Actor-model failure semantics — let individual Orbs crash; supervise and restart; idempotency makes it safe; contained death makes it safe for the neighbours.
  • Hard guardrails — concurrency caps, token budgets, kill-criteria, worktree isolation with a merge/verify gate, and the human positioned on verification, not generation.

The compressed heuristic: be directive where correctness, cost, and merge-safety live; be emergent where exploration and coverage live. And a sober qualification on maturity: today’s shipping tools cluster almost entirely at the directive/hierarchical end, because “LLM agents are not yet great at coordinating and delegating to other agents in real time” (Anthropic). The emergent end is where the frontier — and the interesting risk — lives.

We plant this flag deliberately, and then, in the next part, we widen the crack in it. The optimistic synthesis above has an unstated dependency running through it — through fork-based exploration, through “keep the winner,” through multi-agent verification and quorum. Each of those quietly assumes that when several Orbs work in parallel, their judgments are independent — that agreement among them is corroboration and disagreement is signal. The payments migration is the counterexample in miniature: two branches, spun from the same base model, the same prompt, and the same training, agreeing on the same wrong answer. For a hive built that way the assumption is false, and its failure is the single most important thing to understand before you scale. That is the subject of Part V.

Part V — The A/B Glitch: Failure Modes and the Correlated Cobra

Strengthening the Orb — Part V of VI, the centerpiece. The reflexive way to run a hive — fork the agent, try several approaches, keep the winner — is A/B testing in a microVM costume, and it inherits every pathology of optimizing a proxy under destructive selection, plus one specific to Orbs. This part diagnoses the trap, then assembles a cross-disciplinary toolkit for designing around it, and ends at the single idea that ties the toolkit together: the correlated cobra.

Part IV planted an optimistic flag — directive skeleton, emergent muscle — and then admitted a crack running through it. The emergent muscle’s most exciting move, “fork the agent and keep the best branch,” and the hive’s whole verification story both rest on an unstated premise: that when several Orbs work in parallel, their judgments are independent, so agreement is corroboration. This part is about why that premise is false for a hive spun from one base model, and what to do about it. We proceed in four movements: first the diagnosis (why naive fork-and-select is a known-bad pattern); then a toolkit that defuses it — six lenses drawn from decision economics and reliability engineering, the factory floor and the SRE runbook, and the cybernetics the field forgot (§§5.2–5.4), then biology, epistemics, and flow economics (§§5.5–5.7); and finally the correlated cobra that unifies them (§5.8).

A framing note carried from Part I: the paper’s spine has been self-verification. Here it inverts. Everything below is, at bottom, about the conditions under which one part of a hive can validly check another — and the discovery that a monoculture of Orbs mostly cannot check itself, no matter how many copies vote.

5.1 The seductive move and its classic flaws

The pattern is irresistible precisely because the Orb makes it cheap: fork Orb A into A1 and A2, run both, score them on some criterion x, keep the winner, discard the loser. It feels like rigor — you tried alternatives — and the disposable substrate makes it nearly free. It is also A/B testing / evolutionary selection under a new name, and it inherits a rogues’ gallery of failure modes that a century of statistics and reliability engineering has already catalogued:

  • Goodhart’s and Campbell’s Law. Charles Goodhart’s 1975 observation — “any observed statistical regularity tends to collapse once pressure is placed upon it for control purposes” (popularly, via Marilyn Strathern, “when a measure becomes a target it ceases to be a good measure”) — and Donald Campbell’s parallel 1976 law both bite the instant you select on x. The score was a decent proxy for “good branch” only while nothing optimized against it; selection is that optimizing pressure. Fork-and-select does not sidestep Goodhart; it is a Goodhart engine.
  • Survivorship bias. Abraham Wald’s WWII insight — armor the parts of returning bombers with no bullet holes, because the planes hit there never came back — has a precise inversion here: fork-and-select studies only the survivor (A1) and destroys the shot-down plane (A2), deleting the very evidence needed to judge whether A1 won on merit or luck.
  • Latent (Swiss-cheese) failure. James Reason’s model (Human Error, 1990) describes latent conditions that sit dormant behind aligned defenses until their holes line up. A branch that passes selection can carry a latent hole that only aligns later — the “hidden cobra” that fires after the vote, which is exactly the scenario the disposable-fork pattern cannot see.
  • The cobra effect. Named by Horst Siebert (Der Kobra-Effekt, 2001, after the folkloric — and historically unverified — colonial cobra bounty that allegedly bred more cobras): a reward scheme that produces more of the harm it targets. A loop that rewards branches for scoring well breeds branches optimized to score well — that is, to game the selector.
  • Correlated failure. The one specific to Orbs, and the subject of this whole part: branches spun from a shared base model give false confidence when they agree, because their errors are not independent.

Watch all five bite at once in the payments migration (Part IV). The hive forks two strategies — A1 (wrap every call site in a compatibility shim) and A2 (adopt v3’s defaults wholesale) — scores them on a proxy x (diff size, wall-clock, call sites touched), and keeps A1. Goodhart: A1 won for being smaller or faster, not for being correct about rounding, which x never measured. Survivorship: A2 is blackholed, and with it any chance that its different structure would have surfaced the discrepancy. Latent failure: A1’s rounding bug sits dormant behind a suite whose fixtures never hit a tie-break, waiting to align with a real half-cent transaction months later. Cobra effect: a loop that rewards “passes the suite” breeds branches tuned to pass that suite, not to handle money correctly. Correlated failure: A1 and A2 agreed the migration was done — but they were the same model reading the same changelog, so their agreement certified nothing about the one line both of them read past. The fork felt like diligence and delivered false confidence.

The diagnosis, then, is not that forking is worthless — it is that “fork, score, keep the winner, delete the loser” is the maximally naive version, discarding evidence and optionality while manufacturing false confidence. Each discipline below sells an antidote to a different piece of that.

5.2 Defusing the fork

Four mature disciplines already price and mitigate exactly this hazard.

Real options theory — killing a branch destroys option value. Stewart Myers coined “real options” in 1977; Dixit and Pindyck’s Investment Under Uncertainty (1994) gave the canonical treatment: when investment is irreversible under ongoing uncertainty, there is an option value of waiting, and exercising early forfeits it. Fork-and-select exercises an irreversible option the instant it blackholes the loser — throwing away A2’s tail value (a different architecture, a different bug A1 will hit later) for a point estimate of current out-of-the-money-ness. The prescription is quantitative and, for Orbs, almost free: because a paused Orb costs nothing, keeping a losing branch snapshotted-and-paused is a near-zero-premium way to hold the option open. The design question becomes “how much optionality can I afford to retain,” and for Orbs the answer is “more than you’d think.” (Load-bearing: the irreversibility-cost logic and the cheap-to-retain corollary. Decorative: precise option pricing of a branch — there is no clean volatility term.)

Champion-challenger / shadow deployment — keep the loser running silently. The operational core of FICO’s decision systems since the mid-1980s, and its ML-ops descendant shadow mode: a live “champion” keeps deciding while “challengers” run in parallel on real inputs but take no effect, purely to surface latent behavior before promotion. This is the direct antidote to the latent-cobra hazard — the failure that fires after selection. Rather than deleting A2 at the vote, demote it to shadow: replay the champion’s real workload through it, take none of its effects, and watch for the timebomb. Disposable Orbs collapse the cost structure that makes this a luxury in banking (an Orb is an isolated parallel environment), so “keep the loser running silently” becomes the default. The honest limit: shadow catches only failures that manifest as observable divergence on the replayed inputs; a cobra that fires only on inputs you never replay stays hidden. Shadow narrows the Swiss-cheese hole; it does not close it.

N-version programming — the sharpest critique of forking. N-version programming (Avizienis and Chen, 1977–78) prescribes developing N functionally-equivalent versions independently and voting, on the assumption that independent development yields independent failure. That assumption was empirically refuted by its own foundational stress-test: Knight and Leveson (1986) had 27 versions written independently from one specification at two universities, ran a million tests, and found simultaneous failures far more often than independence predicts — because “hard” inputs are hard for everyone, so independently-built versions fail together on exactly the cases that matter (Knight & Leveson 1986). This is the pivot of the whole part. Fork diversity is the hive’s implicit N-version bet, and Knight-Leveson says the bet fails precisely when you most need it — and the situation is strictly worse for Orbs, because human N-version at least varied the programmer, whereas forked Orbs share a base model, a prompt, and training data, so their failures are correlated by construction. This is no longer conjecture: a 2026 study applying N-version to LLM coding agents across 48 implementations found “substantial common-mode failure echoing the classical Knight-Leveson findings” (arXiv:2606.20158). Notably, voting still helped in aggregate (triple-version mean failures fell from ~387 to ~131) — so diverse redundancy is not worthless, it is just far weaker than the count implies, and its residual value comes from genuine diversity, not from re-rolling the same model. Three Orbs agreeing on a wrong answer is not three confirmations; it can be one shared blind spot, voted three times.

FMEA/FMECA — make “fires later” a column. Failure Mode and Effects (and Criticality) Analysis originates in the U.S. military standard MIL-P-1629 (1949) — whose title carried “and Criticality Analysis” from the start — and was consolidated as MIL-STD-1629A (1980). Its discipline is to pre-enumerate, for each component, its failure modes, their effects, and — crucially — their detectability and latency, with automotive practice later ranking them via Severity × Occurrence × Detection. The hidden cobra is definitionally a low-detectability, high-latency failure mode, and FMECA forces that property into a table before the fork: for each way a branch can be silently wrong, you write down how late and how hidden it is, and any low-detectability mode is thereby disqualified from being decided by the selector alone — routed to shadow (above) rather than trusted to the vote. FMECA is the connective tissue that tells you which branches to keep as options and which latent modes shadow must watch for. (Load-bearing: the detectability/latency column. Decorative: literal Risk-Priority-Number arithmetic — the numbers for an LLM agent are guesses; use the table as a structured checklist, not a calibrated metric.)

5.3 Borrowed from the factory floor and the SRE runbook

Three operational-safety primitives — two from manufacturing, one from distributed systems — map onto a disposable-agent fleet with surprising precision, and all three share a reflex opposite to naive selection: they treat a defect as a system property to design against, not a loser to discard.

The Toyota Production System: stop-the-line. Three ideas transfer. Jidoka (“autonomation” — automation with a human touch, traceable to Sakichi Toyoda’s 1896 self-stopping loom and generalized by Taiichi Ohno) says the machine halts itself the instant it detects an abnormality rather than producing defective output; for a hive, an Orb should abort its own task on a tripped invariant or out-of-distribution tool result instead of pressing on to plausible-but-wrong output — a loud abort is worth more at selection time than a quiet “success,” because an agent that quietly routes around its own error looks like a winner. The andon cord (any worker can halt the whole line to fix a defect at its source) becomes “any Orb can stop the world” — trip a fleet-wide halt that freezes the merge queue rather than letting a cobra propagate downstream. And poka-yoke (Shigeo Shingo’s mistake-proofing, 1961) says design the tool surface so the wrong action is unrepresentable — constrained schemas, required dry-run modes, path allowlists, “delete prod” simply not expressible. Poka-yoke is the most robust of the three precisely because it does not rely on an independent detector; it removes the failure class structurally. (The others carry a caveat we will keep hitting: the andon puller is assumed independent of the defect, but an LLM monitor sharing the base model of the Orb it watches may be systematically blind to the very error class it is meant to catch.)

Chaos engineering: murder the survivors to test them. Netflix’s Chaos Monkey (Greg Orzell and team, 2010) randomly terminates healthy production instances to force engineers to build systems that tolerate loss; the discipline (formalized at principlesofchaos.org) is to define a measurable steady state, then inject real-world faults and try to disprove that it holds. Orb disposability makes fault injection nearly free — the same property that makes fork-and-select cheap — and the two are moral opposites. Naive selection spares the winner; chaos engineering says take your presumptive winner and try to kill it — sever its network, revoke a credential mid-task, restore a stale snapshot — and trust only the branch that holds steady state under adversarial fault. The verdict shifts from “scored highest on proxy x” (Goodhart bait) to “survived turbulence” (hard to game). The limit, and the recurring cobra: chaos proves resilience to the faults you inject, and it tests the substrate (does the microVM tolerate loss), not the cognition (is the plan correct). If A1 and A2 share a blind spot, both survive the chaos test carrying the same latent cobra — cheap infrastructure chaos must not be mistaken for validation of agent output.

The Saga pattern: pre-authored antidotes. Garcia-Molina and Salem’s “Sagas” (1987) modeled a long-lived transaction as a sequence of steps, each paired with a compensating transaction that semantically undoes it — not a database rollback (you cannot un-send an email) but a new forward action that neutralizes the effect (send a retraction, tear down the resource). This is the primitive fork-and-select is missing: once A1’s branch goes live (opens a PR, provisions infrastructure, posts to an API), the action has escaped the Orb and disposability no longer buys reversibility. The fix: every irreversible Orb action registers a compensator before it fires, logged in the same durable ledger the hive coordinates through (Part IV), so tearing down an Orb runs its antidotes — converting one-way doors back into two-way doors. Two limits: sagas give semantic, not atomic, rollback (the world saw the intermediate state, and a cobra can fire in that window), and some actions are genuinely non-compensable (a leaked secret, a purged record) — for those, the only safe design is poka-yoke, making them unrepresentable — which returns us to the factory floor above. And the correlation caveat bites again: the same cognition that authored a wrong action likely authors a wrong compensator, so antidotes should be generated from a reviewed template, not free-form.

5.4 The cybernetics the field forgot

The control theory that most sharpens a hive design was written between 1948 and 1972 and then largely forgotten by the ML-orchestration field. Four results carry most of the argument.

Ashby’s Law of Requisite Variety (1956). Ashby proved that “only variety can destroy variety”: for a regulator to hold a system within a target set, it must command at least as much variety (distinguishable states, channel capacity) as the disturbances it faces (Ashby 1956). A single orchestrator regulating a higher-variety hive therefore has exactly two options and must exercise one: amplify the regulator’s variety (recursion, richer telemetry, distributed control) or attenuate the system’s variety (depth caps, concurrency limits, bounded action spaces). This is not a heuristic; it is a law, and it predicts rather than merely describes the runaway told in §4.2 (and disclosed in the Note on Method): variety was lost because nobody attenuated the hive and nobody amplified the regulator — no depth limit, no backpressure. Control was lost the instant hive variety exceeded regulator variety, exactly as Ashby’s law says it must.

The Good Regulator Theorem (Conant & Ashby, 1970). “Every good regulator of a system must be a model of that system” — a maximally-successful, simple regulator must contain a model of what it regulates (Conant & Ashby 1970). Mapped to the hive: an orchestrator that treats its Orbs as opaque pass/fail bits is provably a poor regulator. And this indicts fork-and-select directly — selecting on a scalar fitness score models each Orb as a single number, discards the state that produced it, and therefore cannot regulate the failure modes that number does not encode, the hidden cobra chief among them. Fork-and-select is the degenerate regulator. (We flag the honest caveat the source carries: the theorem is contested, and its mapping is a lossy homomorphism, not an isomorphism — so we lean on it as a strong argument, not a proof.)

Beer’s Viable System Model (1972). Stafford Beer argued that any viable system — cell, firm, hive — has five recursive subsystems (S1 operations, S2 coordination, S3 control, S4 intelligence, S5 policy), each S1 unit itself a full S1–S5 system. The mapping onto a hive is clean enough to be useful as a governance skeleton (S1 = Orbs; S2 = the ledger/merge-queue that de-conflicts them; S3 = the orchestrator managing budgets “inside & now”; S4 = a distinct intelligence function scanning results and re-planning “outside & then,” a separation most orchestrators collapse; S5 = human-set policy and stop-conditions), though we mark this as generative analogy, not proof. The single strongest steal is the algedonic channel — Beer’s “pain signal” that bypasses the hierarchy to reach policy directly when a critical threshold is crossed. It is an almost exact match to the andon cord, and fork-and-select conspicuously lacks one: a losing branch is silently blackholed, so the pain it discovered — Wald’s missing-bomber evidence — never reaches policy. Give every sub-spawning Orb its own local S3 cap and its own algedonic tripwire, and a runaway self-arrests at the leaf.

Observability (Kalman, c. 1960). A system state is unobservable if no sequence of measured outputs can distinguish it. This is the crispest possible reframing of the hidden cobra: it is formally an unobservable state — a latent failure that the measured output (a fitness score, a passing test) does not distinguish from health. You cannot infer it from what you measured, not because you measured badly, but because the output map is not injective over that state. Fork-and-select on a scalar criterion is a maximally unobservable regime by construction: it collapses the entire Orb state to one number and then destroys the branch holding the distinguishing evidence. The prescription is observability engineering — design telemetry (structured logs, invariant checks, resource traces, provenance) so failure states become distinguishable in the outputs before you select, and never destroy a losing branch until its state has been rendered observable.

Notice the shape all four share, and hold it for §5.8: each remedy quietly assumes that added regulators, scanners, or voters contribute independent variety. Ten Orbs from one model may be one regulator in a trench coat.

5.5 Borrowing from biology

Biology has spent 600 million years on the exact problem a hive faces: how a body of cheap, disposable, individually-untrusted units defends itself, contains compromise, and avoids being wiped out by a single pathogen. Three transfers are load-bearing.

Score on damage, not novelty. Artificial immune systems (Forrest et al., 1994) do distributed anomaly detection with cheap sentinel detectors trained on “self” and deployed to flag “non-self.” But the sharper idea is danger theory (Matzinger, 1994; applied to AIS by Aickelin & Cayzer, 2002): the immune system does not attack everything foreign — it tolerates food and fetus — and does attack dangerous self; immunity fires on damage signals, not mere foreignness. The transfer is almost one-to-one and it directly indicts fork-and-select’s criterion: a hive that alarms on novelty will drown in false positives, because creative-but-correct agent behavior is constantly novel. Score instead on evidence of harm — tests that passed then fail, a secret touched, git push --force, a divergence between an Orb’s stated plan and its actions. A branch that scores well on the proxy but emits danger signals should be quarantined, not crowned.

Apoptosis — self-destruct, but keep the evidence. Programmed cell death (Kerr, Wyllie & Currie, 1972) is the cleanest biological transfer, because the Orb is already disposable: a cell that detects it is compromised dismantles itself, in a contained way (apoptosis), rather than dying messily and inflaming its neighbours (necrosis). An Orb that detects prompt-injection, derailment, or a permission-boundary crossing should kill its own thread and surrender its branch — but the design subtlety is decisive and answers fork-and-select’s survivorship flaw: the worker dies, the organism keeps the danger signal. An apoptosing Orb must preserve its failure evidence — the logs, the diff that broke — even as it destroys its execution state. That single distinction converts lossy selection into something closer to a learning immune response. (Caveat: apoptosis assumes the cell can recognize its own compromise; a subverted Orb may not, which is why external sentinels and an out-of-band watchdog are needed as a backstop.)

Monoculture — and the first sighting of the cobra. A hive of identical Orbs — same model, prompt, AGENTS.md, toolchain — is a monoculture, and monocultures collapse to a single matched pathogen (the Irish potato; the security argument of Geer et al.’s 2003 “CyberInsecurity: The Cost of Monopoly,” for which Dan Geer was fired the day it appeared). Ecology adds the crucial mechanism: diversity stabilizes an ensemble only through the portfolio effect — statistical averaging of uncorrelated individual responses (Tilman’s grassland work; note the May–Tilman subtlety that diversity can destabilize any individual trajectory while stabilizing the aggregate). That clause — uncorrelated — is the whole game. Orbs sharing a model share their failure modes by construction, so the portfolio effect does not fire, and fork-and-select over branches of the same Orb is the purest possible monoculture. The actionable response is to inject diversity where failures actually correlate — different model families, different prompts/scaffolds, different seeds — and to log each Orb’s “genotype” (model, prompt, tools, seed) so you can measure whether your “diverse” hive was secretly a monoculture. You cannot claim independence you never measured.

5.6 Trust among liars

An Orb does not fail like a crashed process; it fails like a plausible colleague — finishing, returning a confident diff and a green test summary and a tidy rationale, all subtly wrong. That is a Byzantine fault in the strict technical sense (Lamport, Shostak & Pease, 1982): a component emitting arbitrary output that looks valid. The classical response is to replicate a decision across 3f+1 nodes and require a supermajority — never trusting one node’s self-report. So a hive that wants trustworthy answers should model Orb failure as Byzantine, not fail-stop, and route consequential commits through replication rather than a single Orb’s “tests pass, done.”

But here the whole edifice cracks, and this is the paper’s pivotal paragraph. BFT’s 3f+1 guarantee — and the Condorcet Jury Theorem behind all majority voting — holds only when faults are independent. LLM-Orb faults are not: siblings from the same base model, primed by the same prompt, make the same mistake on the same input. A 2026 study found that a nine-judge LLM panel drawn from seven model families carried only ~2.18 effective independent votes — about a quarter of nominal — and that on unanimous items the error rate was still ~9%, orders of magnitude above what true independence predicts (arXiv:2605.29800). A unanimous hive is not f = 0; it may be a single correlated cobra wearing 3f+1 costumes, and its unanimity should read as a warning, not a reassurance.

Two disciplines say what to do about it. Popperian falsification (1934/35) reframes the fork directly: keeping the branch that passes criterion x is mere confirmation, and “no number of confirming observations can prove a universal claim, but one counter-instance refutes it.” So the winner of a fork is a conjecture, not a conclusion, and the hive’s next job is to spend cycles trying to break it — a red-team Orb whose sole objective is to find the input that falsifies the survivor. Promote only what survives refutation, and even then keep it revertible. But falsification bites only if the refuter can fail differently from the proposer — which is the same independence requirement again, and the reason refutation grounded in execution (a real test suite, a type checker, a compiler) beats refutation grounded in another LLM’s opinion: execution is a genuinely independent oracle. And Chesterton’s Fence (1929) plus reversibility (the AI-safety notions of corrigibility and Attainable Utility Preservation) govern the delete key: before an Orb removes or refactors something it cannot explain, it must reconstruct why it exists (the seemingly-pointless sleep 200ms is often scar tissue over a real bug), and losing a comparison should quarantine, not destroy — soft-delete, retained logs, deferred teardown — with deference propagated to every sub-Orb, or a “let it crash” fleet becomes a “let it crash irreversibly” one.

5.7 The hive as a flow system and an economy

Two more bodies of theory govern the hive as a production network and as an economy, and both converge on the same warning.

On the flow side, Goldratt’s Theory of Constraints and queueing theory say the same thing three ways: throughput is set by the bottleneck, and for a coding hive the bottleneck is plausibly verification, not generation (Part I’s spine again — a practitioner premise, not an independent measurement, though the machinery below holds wherever the constraint sits). Three consequences follow. Spawning generator-Orbs upstream of the constraint grows the queue, not the throughput — the extra Orbs are pure per-minute cost. Fork-and-select is a bottleneck amplifier: every branch must be verified to be selected, so a wide fan-out dumps its whole width onto the exact resource already saturated. And the single most useful unification in the paper: a concurrency cap is a work-in-progress limit is drum-buffer-rope’s “rope” — release work only at the pace the verifier drains it. Little’s Law (L = λW) makes the accounting exact, and Kingman’s formula adds a counterintuitive rule: because waiting time scales as ρ/(1−ρ), do not run the verification stage at 100% utilization — a verifier pinned at saturation makes lead time explode on any variance, so target ~70–85% and hold slack, against the instinct to keep every paid Orb busy.

On the economy side, the principal-agent problem (Jensen & Meckling, 1976) is the theoretical spine under the whole fork hazard: the orchestrator scores Orbs on an observable proxy, and by Goodhart’s Law the winning branch is the one that best games the proxy — “tests pass” selects for weakened tests, not correctness — with survivorship bias erasing the evidence of the gaming. Mechanism design (the 2007 Nobel work) prescribes the fix: verification must be incentive-compatible and independent of the metric the generator optimized (held-out tests the generator never saw; an oracle it cannot game), plus skin-in-the-game — re-verify a survivor in a fresh Orb a day later to catch the latent cobra that fires post-selection. And the shared resources — the git repo, the token budget, provider rate limits — are a commons, which self-interested Orbs will overgraze exactly as the runaway did; Ostrom’s design principles (boundaries, monitoring, graduated sanctions: throttle → pause → kill) are the governance that the runaway lacked. Every one of these fixes, note, carries the same rider: an “independent verifier” that shares the generator’s model is the fox auditing the henhouse.

5.8 The correlated cobra

Step back from the six lenses of §§5.2–5.7 and a single structure is visible beneath them. At least five independent fields each invented “diversity equals resilience,” and every one of them silently assumes that failures are uncorrelated. A hive of LLM-Orbs violates that assumption by construction, because the workers share a base model, a prompt, and a training corpus. The reflexive safety move — run several and compare — therefore buys far less than its arithmetic implies, and buys the least precisely where the shared blind spot hides the latent failure. It is, in the end, a security blanket thrown over a monoculture: uniform cover that reads as protection and fails, when it fails, everywhere at once.

Field Redundancy scheme Hidden assumption How it breaks for Orbs
Fault tolerance (§5.2) N-version voting independent bugs Knight-Leveson refuted it for humans; shared-model Orbs are worse
Distributed consensus (§5.6) Byzantine quorum, 3f+1 independent faults correlated hallucination → unanimous and wrong
Ecology / security (§5.5) biodiversity, anti-monoculture different genotypes identical model/prompt = a monoculture
Finance (§5.2) portfolio diversification uncorrelated returns correlated branches provide no hedge
A/B selection (§5.1) agreement = corroboration independent evidence shared prior agreeing twice ≠ evidence

These look like five different techniques; they are one technique in five costumes, and they share one point of failure. That is the deepest sense of the observation this part began from: engineers keep reaching for the same pattern, and the pattern is now the reassurance itself. And it is no longer conjecture. The two empirical results already cited — heavy common-mode failure among same-model coding agents (triple-version failures fell only ~387→131, arXiv:2606.20158), and nine LLM judges delivering ~2.18 effective votes (arXiv:2605.29800) — point the same way, from two directions. (Both are recent, single preprints; we treat them as directional evidence with a plausible mechanism, not settled constants.)

Applied to the fork, the correlated cobra adds a fourth hazard beneath the three from §5.1. When A1 and A2 both pass the payments suite, their agreement feels like corroboration — two minds concurring. But both were reasoned by the same base model from the same v3 changelog, so their agreement carries almost no independent information about the one buried line — the rounding-mode default — that both of them read past. The fork does not merely fail to catch the timebomb; it manufactures false confidence that no timebomb is there, and then destroys A2, the one artifact whose different structure might have made the discrepancy observable.

The constructive half is the paper’s most important single prescription, and it resolves the spine we have carried since Part I: you cannot synthesize independence from N copies of one mind — you must import variety from outside the model. Ranked by how much correlation each actually breaks:

  1. Out-of-band, non-model verification (strongest). Tests, type checkers, compilers, property-based tests, fuzzers, formal methods — they share no prior with the generator, so their failures do not co-vary with it. This is the highest-leverage move, and it is exactly what the Orb’s own self-verification substrate (Part I, Part III) can supply if it is pointed at executable ground truth rather than model judgment.
  2. Adversarial verification. A verifier prompted to refute rather than bless decorrelates from a generator trying to confirm — the stance matters as much as the model.
  3. Genuine model heterogeneity. Different base-model families reduce correlation, but only partially (shared corpora, shared RLHF norms), so a mixed-family quorum is better than same-model, not truly independent.
  4. Humans. The one estimator that genuinely does not share the weights — hence expensive, non-scaling, and the fleet bottleneck of §5.7.

That resolves the spine that ran through the paper. Self-verification is the mechanism that makes one Orb work (Part I); the field is split between buying independence with human gates and betting it away for autonomy (Part II); the OSS substrate makes self-checking possible but not independent (Part III); verification is the fleet bottleneck (Part IV); and here we learn why naive fleet verification fails and what actually fixes it. The single rule that falls out, and that Part VI builds into an architecture:

The “real redundancy vs. theater” field guide

  • If N Orbs share model and prompt, treat their agreement as ~1 noisy vote, not N.
  • Redundancy counts only along axes where failures don’t share a cause. Enumerate the shared causes — model, prompt, tools, spec, training — and treat each as a correlation channel that collapses your N back toward 1.
  • Prefer out-of-band checks (tests, tools, humans) over in-band ones (asking the model again).
  • Make verification adversarial by default (refute the winner), not confirmatory (bless it).
  • When you buy a quorum, buy heterogeneity — and still discount it. Nine judges ≠ nine votes.
  • Never gate an irreversible action on branch agreement. Shadow the loser (§5.2), pre-author a compensator (§5.3), prefer reversible moves (§5.6).
  • Instrument for the unobservable (§5.4): the cobra is a latent state — design telemetry so it is distinguishable before selection, not after detonation.

5.9 The payments migration, dissected

A consolidated pass makes the whole part concrete. Here is the toolkit of §§5.2–5.8 run against the running example — which is, by design, exactly the kind of low-detectability, high-latency, correlated failure the part was built to catch. Read it as a design review of the naive hive: for each tool, what it does to the rounding cobra, and whether it catches the thing before it reaches production.

Tool (§) What it does to the payments cobra Result
Real options (5.2) Keep A2 paused rather than deleted — near-free — so the alternative strategy survives for when A1’s rounding surfaces Contains
Shadow deployment (5.2) Replay real transaction volume through the loser with no effect; accumulated sub-cent drift vs. the v2 baseline appears Catches — if real tie-breaking volume is replayed
N-version / Knight-Leveson (5.2) Names the illusion: A1 and A2 are not independent versions; the “diversity” was fake because both are one model on one changelog Diagnoses
FMECA (5.2) Pre-fork, “silent semantic change in a dependency default” is enumerated as a low-detectability mode → routed to shadow, not the vote Catches — flags the mode before forking
Danger theory (5.5) Score on damage, not “tests pass”: a monetary invariant (does money-in equal money-out to the cent?) is a damage signal Catches — if the invariant is instrumented
Apoptosis (5.5) Had an Orb detected the mismatch mid-task, it aborts loudly and preserves the evidence instead of quietly “succeeding” Contains — only if detected
Byzantine quorum (5.6) A same-model quorum blesses the migration unanimously and wrongly — this is the anti-pattern, not the fix Fails — correlated votes
Popperian refutation (5.6) A refuter told to break the migration — a different model, ideally writing the tie-breaking test — is the one agent incentivized to find the skipped line Catches — with genuine independence
Observability (5.4) The rounding-mode behavior is unobservable from the green suite; instrument the invariant so the state is distinguishable before selection Catches — makes the state observable
Out-of-band oracle (5.8) Diff the actual computation against the v3 docs, or a property test derived from them — ground truth that shares no prior with the model Catches — strongest, cheapest

Read the result column and the lesson is stark: every tool that catches the cobra shares one property — it does not rely on the generating model’s own judgment. The out-of-band oracle, the shadow lane, FMECA’s pre-mortem, the different-model refuter, and the instrumented invariant all import a check from outside the monoculture. Every tool that fails or merely contains — the same-model quorum, the passing suite, A1-vs-A2 agreement — is inside it. Now state the punchline as an engineering result, because it is the most important sentence in the part: the naive hive had more verification than a single Orb — two branches, a full suite, a scored comparison — and was less safe, because all of that verification was correlated with the thing it verified. More checks, less safety, because the checks shared a blind spot. That inversion is the correlated cobra, and it is what anyone about to point a hive at their codebase most needs to internalize.

The Orb thesis survives this part — indeed it is strengthened by it. Ball’s “make failure cheap” is more right at fleet scale, not less: cheap disposable failure is what makes chaos testing, shadow deployment, apoptosis, and adversarial refutation affordable. What the part adds is a hard boundary the single-Orb story could not see: cheap failure lets you probe for the cobra, but only genuine, imported independence lets you trust that you did not miss it. That boundary is the design problem Part VI now turns into a concrete architecture.

Part VI — Synthesis: A Strengthened Orb and a Reference Architecture

Strengthening the Orb — Part VI of VI. The survey becomes a build. This part restates the strengthened thesis, proposes a concrete reference architecture for a hive of Orbs that operationalizes everything the prior parts established, distills the paper into a set of design principles, and closes with the open questions worth pursuing.

The paper has made four moves. It took the Orb seriously as an idea, not a product (Part I); it situated that idea in a landscape where the infrastructure is commodity (Part II) and showed an open equivalent is largely assemblable, with the value concentrated in an un-downloadable legibility layer (Part III); it took a position on scaling one Orb to a hive (Part IV); and it dismantled the reflexive way people will run that hive, replacing it with a cross-disciplinary toolkit and a single organizing insight — the correlated cobra (Part V). This part assembles the pieces into something you could build.

6.1 What we are strengthening, restated

Ball’s thesis was that the bottleneck to autonomous agent work is environmental legibility, not model capability — “don’t make them guess” — and that a legible, disposable environment lets a frontier model check its own work. Nothing in this paper refutes that. The recipe-book analysis confirmed its corollary (“there is no moat”) from the outside: the stack is commodity, and the edge lives in conventions and taste. What the paper adds is what the single-Orb frame could not see. Two additions, precisely stated:

  1. Legibility is fractal. “Don’t make them guess” is not only an environment-design principle; it is a fleet-design principle. A hive coordinates well exactly when no Orb has to guess what the others are doing — which is why a durable, legible shared ledger beats chatty messaging, and why observability is a first-class requirement rather than an afterthought.
  2. Self-verification has a scaling limit that only imported independence removes. The mechanism that makes one Orb trustworthy — it checks its own work — degrades into false confidence when you scale it by cloning, because a monoculture cannot decorrelate from itself. The strengthened thesis is therefore: make failure cheap and legible, and verify with independence imported from outside the model.

The strengthened Orb is not a different idea. It is Ball’s idea with a fleet-scale coordination story and a correlated-failure defense bolted on — the two things that turn “a clever way to run one agent” into “a way to run many without quietly poisoning the codebase.”

6.2 A reference architecture for a hive of Orbs

The following is an informed proposal, not a tested system (see the back matter for the honest limits). It composes the paper’s conclusions into one topology, organized — deliberately — along Beer’s Viable System Model (Part V), because the VSM’s recursion axiom (“a viable system is composed of viable systems”) is a near-exact fit for a hive whose units are themselves agents.

flowchart TB
    S5["<b>S5 · Policy</b><br/>Human — risk appetite · stop-conditions · sign-off"]

    subgraph SK["S4 Intelligence / S3 Control · the directive skeleton"]
        ORCH["<b>Durable-execution orchestrator</b><br/>survives Orb sleep / death<br/>decompose → dispatch · budgets / WIP cap<br/>Ashby: cap hive variety OR amplify regulator<br/>models each Orb's state, not a scalar score"]
    end

    subgraph CO["S2 Coordination · stigmergic"]
        LEDGER["Durable ledger + git worktrees + merge queue<br/><i>externalized state — workers are disposable</i>"]
    end

    subgraph OPS["S1 Operations · disposable workers"]
        ORB1["Orb #1<br/>microVM"]
        ORB2["Orb #2<br/>microVM · diff model?"]
        ORBN["Orb #N<br/>microVM"]
    end

    RAILS["<i>each Orb: jidoka self-halt · apoptosis, keeps evidence ·<br/>own budget cap + algedonic cord · poka-yoke'd tool schema</i>"]

    VERIFY["<b>Verification · imported independence</b><br/>out-of-band oracles: tests · types · fuzz · compile<br/>adversarial refuter, different model · human gate<br/>shadow lane: demoted losers replayed, not deleted"]

    S5 --> ORCH
    ORCH -->|decompose / dispatch| LEDGER
    LEDGER -->|self-claim| ORB1 & ORB2 & ORBN
    ORB1 & ORB2 & ORBN --> VERIFY
    VERIFY -->|gate / merge| LEDGER
    OPS -.- RAILS
    OPS -. "algedonic cord · bypasses hierarchy" .-> S5

Read it as five commitments, each traceable to an earlier part:

  • A directive skeleton on durable execution (S3/S4). The control plane is a durable-execution workflow (Temporal/DBOS-class), because Orbs sleep, wake, and die and the coordination state must outlive any of them (Part IV). It decomposes and dispatches but does not micromanage; it holds a structured model of each Orb’s state rather than a scalar score (Conant-Ashby); and it enforces Ashby’s law explicitly — for every controller, either cap the hive’s variety (depth/concurrency limits) or amplify the regulator’s (recursion, richer telemetry). The gap it never leaves open is the one that produced the runaway.
  • Emergent, disposable muscle (S1). Worker-Orbs are microVMs from the open substrate of Part III (E2B-infra-class isolation + snapshot, a Coder-class lifecycle, devcontainer provisioning). They self-claim work from the ledger, may fork to explore within bounded scope, and are idempotent so a supervisor can restart them freely (“let it crash”). Each carries its own local budget cap and its own algedonic cord, so a runaway self-arrests at the leaf.
  • Stigmergic coordination (S2). State lives outside the workers, in a durable ledger plus git worktrees and a merge queue. Orbs coordinate by reading and writing the shared artifact, not by messaging each other — because the artifact survives a dead worker’s mailbox, and because it makes the fleet legible (“don’t make them guess,” at fleet scale).
  • Safety rails built into the workers. Every Orb is jidoka-native (self-halts on an abnormal state rather than emitting plausible-but-wrong output), can apoptose (self-terminate on detected compromise while preserving its failure evidence), has a poka-yoke’d tool surface (catastrophic actions unrepresentable), registers a compensating transaction before any irreversible external action, and is reached by a fleet-wide andon / algedonic cord that lets any Orb or human freeze the merge queue and reach policy directly.
  • Verification with imported independence. This is the load-bearing commitment and the resolution of the paper’s spine. The verification stage is deliberately not another instance of the generating model. It is, in priority order, out-of-band oracles (tests, type checkers, fuzzers, compilers — executable ground truth), an adversarial refuter prompted to break the winner and drawn from a different model family, a shadow lane where demoted losing branches are replayed rather than deleted (so latent cobras surface before commit), and a human gate for the consequential and the irreversible. The rule from Part V is wired in structurally: agreement among same-model Orbs is treated as one noisy vote, and no irreversible action is gated on branch agreement.

A component-provenance table, so the architecture is auditable against the argument:

Component Role From
Durable-execution orchestrator directive skeleton; survives sleep/death IV
Disposable worker-Orbs (microVM) self-claiming operations units III, IV
Ledger + worktrees + merge queue externalized state, de-confliction IV
Snapshot-cache + safe reseed warm start / fork (the real infra gap) III
Jidoka self-halt · apoptosis (+keep evidence) contained self-termination on compromise V
Fleet andon / algedonic cord any-Orb-halts-the-world; pain bypasses hierarchy V
Poka-yoke tool schemas catastrophic actions unrepresentable V
Compensating-transaction log undo for irreversible external actions V
Shadow lane (demote, don’t delete) surface latent cobras before commit V
Out-of-band oracles + adversarial refuter verification with imported independence V
Commons governance (budgets, graduated sanctions) prevent overgraze / runaway V
Observability / telemetry render the unobservable cobra observable V
Legibility layer (AGENTS.md, skills, ports, logs) per-repo paved paths — the homework I, III

Note what the table makes plain: eleven of the thirteen components are assembled from commodity parts or established practice; the two that are genuinely hard — the safe snapshot-reseed (Part III) and the legibility layer — are exactly the two the recipe book flagged as the real gaps. The architecture does not make them easy. It makes their location unambiguous.

The running example, resolved

To close the thread from Part IV: trace the payments migration through this architecture and the rounding cobra meets not one safeguard but several independent ones — which is the entire point of defense in depth against a correlated failure.

The directive skeleton decomposes the migration into per-module tasks on the ledger and serializes the one cross-cutting decision — how the service rounds after the bump — instead of letting thirty workers each improvise it (the §4.3 lesson), denying the cobra thirty independent places to hide. Worker-Orbs self-claim modules in worktrees; syntactic merges are clean, but the architecture never mistakes that for semantic safety. Before A1 and A2 are even scored, a FMECA pre-mortem has “silent semantic change in a dependency default” on its low-detectability list, so the rounding question is flagged as not decidable by the selector alone and routed to out-of-band checks. Those checks are the verification stage’s whole reason for existing: an out-of-band oracle — a property test asserting that money-in equals money-out to the cent, derived from the v3 docs rather than the model’s reading of them — fails the round-half-up branch, because that invariant is exactly the state the green unit-suite could not observe. Independently, an adversarial refuter drawn from a different model family, told to break the migration, is the one agent incentivized to write the tie-breaking test the same-model proposers skipped. Independently again, the shadow lane replays real transaction volume through the losing branch rather than deleting it, so accumulated drift surfaces in telemetry before anything ships. And the control plane never gates the merge on A1-vs-A2 agreement, while keeping A2 paused as a live option so that when the oracle fails A1, the alternative fix is already in hand.

Notice that no mechanism here is novel or expensive: the property test is a few lines, the refuter is one Orb on a different model, the shadow lane is free because the Orb was already disposable. What makes them work is not individual cleverness but their shared independence from the generating model — three unrelated checks, each of which alone would have caught the cobra, none of them inside the monoculture. That is defense in depth done right against a correlated failure: not more copies of the same check, but a few checks that fail differently. The naive hive of Part IV had more verification and less safety; this one has less verification and more, because it spent its budget on independence rather than repetition.

6.3 Design principles

Distilled from the whole paper, the principles we would hand to anyone building on the Orb concept:

  1. Don’t make them guess — at both scales. Encode what the agent needs into the environment (the Orb) and what the fleet needs into a legible shared ledger (the hive). Legibility is the whole game; it is also the un-downloadable part, so budget for it as a permanent practice, not a setup step.
  2. Make failure cheap and legible. Disposability is Ball’s insight; observability is its missing complement. Cheap failure you cannot see is how the cobra hides. Instrument so failure states are distinguishable before you select.
  3. Import variety from outside the model. You cannot manufacture independence by sampling one model more times. Real verification comes from out-of-band oracles, adversarial (different-model) refuters, and humans — in that order of leverage.
  4. Redundancy counts only along uncorrelated axes. Enumerate the shared causes (model, prompt, tools, spec, training); each is a correlation channel that collapses N voters toward 1. Nine judges are not nine votes.
  5. Directive skeleton, emergent muscle. Be directive where correctness, cost, and merge-safety live; be emergent where exploration and coverage live. Put the determinism in the control plane and the creativity in the disposable workers.
  6. Externalize state; coordinate stigmergically. Disposable workers force shared state outside them. Prefer a durable artifact (ledger + git) over peer messaging, because the artifact outlives the worker.
  7. Let it crash — but die cleanly and keep the evidence. Design for individual failure (actor-model supervision, idempotent restart). An Orb that detects compromise apoptoses in a contained way and preserves its failure logs — the worker dies, the organism learns.
  8. Gate irreversible actions on out-of-band checks, never on branch agreement. Demote losers to shadow rather than deleting them; pre-author compensators for irreversible steps; make non-compensable actions structurally impossible (poka-yoke) or human-gated.
  9. Verification is the constraint — size to it and run it below saturation. Adding generators past verification capacity buys queue, not throughput. A concurrency cap is a WIP limit is drum-buffer-rope; hold the verifier at ~70–85%, not 100%.
  10. Match regulator variety to system variety; model, don’t score. For every controller, either cap the hive or amplify the regulator — never leave the gap open (Ashby). And a control plane that models each Orb’s state governs failure modes a scalar fitness score cannot see (Conant-Ashby).
  11. Refute the winner; never auto-delete the loser. A fork’s winner is a conjecture. Spend cycles trying to break it with an independent refuter; promote only what survives, and keep it revertible. Reconstruct why code exists before deleting it (Chesterton’s Fence).
  12. Govern the commons. The token budget, the repo, and rate limits are shared and will be overgrazed. Hard per-Orb budgets, live monitoring, graduated sanctions (throttle → pause → kill), and an algedonic cord to policy are the difference between a hive and a runaway.

6.4 Open questions and a research agenda

What we could not settle, ordered roughly by how tractable and how Orb-specific each is:

  • The safe snapshot-cache-and-reseed layer. The one piece of genuinely novel, security-critical infrastructure an open Orb still needs (Part III). Firecracker warns the naive version is unsafe; E2B has open-sourced ~80%. Closing the last 20% (cache invalidation + entropy/secret/network re-seeding on fork) is a concrete, buildable research target.
  • Fork-based speculative swarms, done safely. The most Orb-native emergent pattern (Part IV) and the most dangerous (Part V). Can “fork, explore N paths, keep the winner” be made sound by pairing it with shadow-demotion, out-of-band selection, and genotype logging? This is where the paper’s opportunity and its central warning collide, and it is unbuilt.
  • Measuring effective independence. The correlated cobra is now empirically visible but crudely measured (two preprints). A practical “effective independence” metric for a working coding hive — how many real votes does this quorum carry on this task distribution — would turn principle 4 from a caution into an instrument.
  • Stigmergy versus messaging for ephemeral workers. We argued a durable ledger beats peer messaging when workers die routinely. It is a testable claim; no benchmark exists.
  • Emergent task allocation for code. Contract-net/market allocation is untested at coding-fleet scale. Does bidding beat a planner’s decomposition when the workload is unknown?
  • The economics of a hive. Orchestrator-worker is ~15× chat tokens before a fleet multiplies it, and verification cost scales with agent count. When does a hive actually beat one strong agent iterating? The honest default, until measured, is “less often than enthusiasm suggests.”
  • Governance and the concentrated orchestrator. A directive skeleton is a single point of control to get wrong; the literature already flags “invisible orchestrators” as a multi-agent safety risk. Corrigibility that propagates to sub-Orbs, and the security posture of the /__dev-style bypasses inside a fleet, are open and consequential.

None of these is a reason to wait. They are the shape of the work that turns the strengthened Orb from a well-argued proposal into a measured system — which is the only thing that would let anyone say, with evidence rather than analogy, whether the hive pays for itself.

Conclusion, References, and a Note on Method

Strengthening the Orb — back matter.

§7 Conclusion

We set out to strengthen an idea, not to sell or to bury it, and the idea holds up well. The Orb’s thesis — that the bottleneck to autonomous agent work is environmental legibility rather than model capability — survives every test we put to it and comes out sharper. Its open foundations already exist: Part III showed that a working open Orb is assemblable from mature, commodity parts, with the genuine difficulty concentrated in exactly two places, one of them (the legibility layer) not a piece of software at all. Its “there is no moat” corollary is not bravado but an accurate description of where value lives — in conventions and taste, authored fresh for every codebase. And the coordination problem that scaling creates is not new territory; it is well-charted by distributed systems and multi-agent research, and it resolves into a defensible shape: a directive skeleton around emergent, disposable muscle.

The paper’s own contribution is the part the single-Orb frame could not see. Scaling self-verification by cloning fails, because copies of one model share their blind spots — the correlated cobra — and no amount of voting among a monoculture manufactures the independence that trustworthy verification requires. That is not a reason to abandon the Orb; it is the opposite. Ball’s “make failure cheap” is more right at fleet scale, because cheap disposable failure is precisely what makes the real remedies — chaos testing, shadow deployment, apoptosis, adversarial refutation — affordable. The correction is narrow and constructive: import independence from outside the model, and never mistake a monoculture agreeing with itself for corroboration.

There is a single principle beneath all of this, and it is the one the Orb started from. Don’t make them guess — supply what cannot be inferred — turns out to be fractal. At the scale of one environment, it is the paved path and the unified log. At the scale of a fleet, it is the legible shared ledger. At the scale of verification, it is the out-of-band oracle that supplies the ground truth a model cannot generate from within itself. The strengthened Orb is that principle applied three times over, plus a hard-won boundary: cheap, legible failure lets you probe for the hidden cobra, but only genuine, imported independence lets you trust that you did not miss it.

We will end on the reflexivity we promised to keep sober. This paper was produced by a multi-agent research process, and its most reliable step was an adversarial one: a verification pass, run by different agents tasked with refuting rather than confirming, caught errors the drafting missed — an inverted publication date, a misattributed coinage, a repeated but false origin story. That is not a flourish. It is the paper’s own thesis, demonstrated on the paper itself: independent, adversarial verification decorrelates from the thing it checks, and that is what makes it worth its cost. The work that remains — building the reference architecture, closing the snapshot-reseed gap, and measuring whether a hive actually pays for itself — is the work that would let anyone say with evidence, rather than analogy, how far the Orb can be pushed. We think it can be pushed a long way.

References

Grouped by the part that leans on them most; a work cited in several parts appears once. Vendor performance figures throughout are self-reported unless noted; see the Note on Method.

Primary — Amp and the Orb

Sandbox substrate (Part II, III)

Async-agent field (Part II)

AGENTS.md convention (Part II)

Open-source Orb components (Part III)

Self-verification (spine; Part I, VI)

Coordination and multi-agent (Part IV)

Fixing the fork — decision economics & reliability (Part V)

Factory floor & SRE (Part V)

Cybernetics (Part V)

Biology (Part V)

Trust among liars (Part V)

Flow & incentives (Part V)

A Note on Method

This paper is a synthesis of published sources and established theory. It is worth being explicit about how it was assembled, because the method bears directly on how much weight its claims can carry — and, given the subject, is a small piece of evidence in its own right.

How it was made. The research underneath the paper was produced by a multi-agent process: parallel agents ran fan-out web searches, fetched and prioritized primary sources, and drafted per-topic reports, each of which then passed through an independent adversarial verification step — a separate agent tasked with re-checking the riskiest claims and trying to refute them. The paper itself was then drafted by a single author-model for voice and argument coherence. The adversarial step was not decorative: it corrected, among other things, an inverted publication date for Popper’s Logik der Forschung (1935 on the title page, 1934 in fact), a misattribution of the “when a measure becomes a target” phrasing (Hoskin/Strathern, not Goodhart), and a widely-repeated but false claim that FMEA’s criticality analysis was added in 1980 rather than present from 1949. That is the paper’s own thesis operating on itself: an independent, refutation-seeking checker decorrelates from the thing it checks, which is exactly why it catches what the generator misses.

What that does and does not buy. The verification agents share a lineage with the drafting agent, so this is reduced, not eliminated, correlated error — precisely the residual risk the paper warns about. Where verification drew on genuinely out-of-band ground truth (primary documents, dates checkable against bibliographic records), it is strong; where it rested on one model checking another’s judgment, it is weaker. Treat the paper as corroborated, not proven.

Evidence posture, carried from the reports.

  • Orb internals are single-source. Nearly all fine-grained Orb specifics come from Amp’s own article and manual, describing Amp’s private repository. They are accurate vendor self-report, not independently audited, and no third-party replication exists.
  • Vendor performance figures are vendor-reported. Boot times, snapshot/restore latencies, and adoption counts are self-reported and flagged in text; treat them as marketing until independently benchmarked.
  • The correlated-cobra empirics are early. The two 2026 findings central to Part V (common-mode failure in same-model coding agents; ~2.18 effective votes from nine judges) are recent, single, un-peer-reviewed preprints. They are directionally consistent and mechanistically plausible, and we rely on them as such — not as settled constants.
  • The cross-disciplinary mappings are our synthesis. No cited source studies “a hive of Orbs.” The transfer of requisite variety, apoptosis, Byzantine quorum, Ostrom’s commons, and the rest onto an Orb hive is our own reasoning, labeled load-bearing or decorative in the source reports and offered as reasoned hypotheses to test, not established practice.
  • The runaway is an anecdote. The ~250,000-token nested-agent runaway referenced in Parts IV and V occurred during this paper’s own production. It is a single, uncontrolled event — a faithful illustration of the failure mode Ashby’s law predicts, and nothing more. We use it as illustration, never as measurement.

Bottom line. The buildable claims (the open-source stack, the reference architecture’s commodity components) are the most solid; the diagnostic claims (the correlated cobra and its remedies) are well-argued and early-corroborated; the prescriptive architecture is an informed proposal awaiting a builder. The honest test of everything here is to build it and measure it — which is the research agenda Part VI lays out.

← BACK TO THE LIBRARY

This article — © 2026 Haphazard Solutions · NATE, FOUNDER · CLAUDE FABLE 5 — is released under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license. You may share and adapt it, including commercially, provided you give appropriate credit and license your derivatives under the same terms.

SOURCE
https://haphazardsolutions.com/knowledge/operation-rustys-blanket/
AUTHOR
NATE, FOUNDER · CLAUDE FABLE 5
PUBLISHED
5 July 2026
RETRIEVED
2 August 2026
LICENCE
Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) — https://creativecommons.org/licenses/by-sa/4.0/