What happens when you run 1,889 concurrent Git worktrees across an agent fleet (and drop the laptop)?

“On paper, this is completely unhinged.”
“Does it work?”
“Yes.”
“…well, shit.”

Most discussions around AI agents focus on reasoning benchmarks, eval harnesses, or context window sizing. But when you move from single-turn chatbot demos to running an autonomous fleet across real codebases, you quickly run into operating system physics.

Over the past few months, I’ve been running an autonomous software factory: one human operator coordinating dozens of concurrent agents across 19 repositories. Last week, this estate was operating across 1,889 active Git repositories and worktrees when the laptop took physical damage.

When the hardware failed, 373 dirty checkouts were trapped mid-flight.

An emergency preservation sweep recovered everything in 45 minutes across 989 remote push operations, 560 unique branches, and 9.4 GB of uncommitted working docs with zero mainline collisions or lost code.

The reason it survived wasn't luck or cloud snapshots. It’s because we stopped treating chat interfaces as the system of record and engineered sovereign systems underneath:

1. The Checkout Custody Standard: Deduplicated .bare/ Git storage where repository history lives exactly once on disk, and every agent execution vector gets a disposable, isolated worktree. No git stash race conditions. No index collisions.
2. P2P Transport: Moving execution payloads, telemetry, and memory across an Iroh QUIC mesh with Bao BLAKE3 content-addressed verification.
3. Hardware-Gated Authority (MFAA): When agents deadlock over competing claims of authorization, the dispute is escalated to physical, hardware-gated ratification. (The agents can argue all they want; the human holds the signing key.)
4. Verifiable Computational Causality: Proving that a claimed state transition was actually executed within an admitted capability boundary.

For those interested in the theoretical and formal verification side of this problem: I published the formal whitepaper and Monte Carlo ablation suite on Zenodo:

The Post-AI Hyperedge Execution Model: Verifiable Computational Causality, Structural Grounding, and the Physics of Admitted State
DOI: zenodo.org/records/23393256
(Proves the Irreducibility of Execution Causality / Pairwise Decomposition Fallacy, showing that standard relational graphs synthesize false transitive executions at a 75% rate, alongside 3.9% silent state corruption under standard POSIX models).

I also wrote an end-to-end architectural narrative detailing the physical hardware incident, the telemetry receipts, and the build of Photon (our native Rust/Metal environment):
1,889 Trees, a Dropped Laptop, and the Sovereign Substrate:
nwalker85.substack.com/p/1889-trees-a-dropped-laptop-and-the

Open schemas & message contracts:
github.com/nwalker85/human-message-schema

Curious how other founders and engineers running multi-agent fleets are handling these problems:

• Git Concurrency: How are you isolating Git index and branch operations when multiple subagents touch the same repository simultaneously?
• Causal Attribution: How do you verify the causal chain between the human prompt, the tool RPC, and the admitted disk state?
• Deadlock & Authority: What is your escalation topology when agents reach contradictory consensus or hallucinate permission?