The Anatomy of a Ratchet
Dan Lorenc's multiclaude takes a counterintuitive position on multi-agent orchestration: the best way to coordinate AI agents working on the same codebase is to barely coordinate them at all. Instead of building sophisticated protocols to prevent conflicts and duplicate work, multiclaude embraces chaos and lets CI serve as the filter. The result is a system that ships more code precisely because it doesn't try to manage what each agent is doing.
This isn't accidental. The project calls its philosophy "The Brownian Ratchet," borrowing from physics: random motion in one direction, a mechanism that prevents backward movement, and net forward progress despite apparent disorder. The metaphor isn't decoration; it's the architectural blueprint.
Let's trace what actually happens when you run multiclaude work "add rate limiting to the API" and see how each component of the ratchet does its work.
The Brownian Motion⚓︎
Your rate-limiting task spawns a worker agent. But here's what multiclaude doesn't do: it doesn't check whether another agent is already touching the API, doesn't queue your task behind related work, doesn't lock files or coordinate access.
Two other workers are already running. One is refactoring the authentication middleware. Another is adding request logging. All three will touch overlapping code. All three proceed simultaneously.
This looks like a coordination failure. The conventional wisdom in distributed systems says you need locks, queues, or at least awareness of who's doing what. Multiclaude's design document is explicit about rejecting this: "Multiple autonomous agents work simultaneously on overlapping concerns. They may duplicate effort, create conflicting changes, or produce suboptimal solutions."
The key word is "may." Not "will inevitably cause disaster." The bet is that the cost of occasional duplicate work and merge conflicts is lower than the cost of coordination overhead. Every lock is latency. Every queue is a bottleneck. Every "is anyone else working on this?" check is complexity that can fail.
Each agent gets its own git worktree, a feature of git that lets you check out multiple branches simultaneously in separate directories. Your rate-limiter works in ~/.multiclaude/wts/api-repo/happy-platypus/, while the auth refactor runs in ~/.multiclaude/wts/api-repo/clever-otter/. They share the same repository but can't step on each other's files because they're literally working in different directories on different branches.
The worktree isolation means conflicts are deferred, not prevented. They'll surface later, at merge time. And that's exactly where multiclaude wants them.
The Pawl⚓︎
In a mechanical ratchet, the pawl is the component that allows movement in one direction while preventing backward motion. In multiclaude, CI is the pawl.
The design document states this as a hard constraint: "Agents must never weaken or disable CI checks without explicit human approval." This isn't a guideline buried in documentation. It's embedded in every agent's system prompt, repeated as a "Golden Rule," and treated as architecturally sacred.
Play this forward. Your rate-limiter finishes first and creates a PR. CI runs. Tests pass. The merge-queue agent (a specialized agent that does nothing but watch PRs) merges it automatically.
The auth refactor finishes second. Its PR also passes CI. Merged.
The request logging agent finishes third. But now there's a problem: the code it wrote conflicts with the rate-limiting changes that merged while it was working. The tests fail.
In a coordination-heavy system, this would be a failure state requiring human intervention or sophisticated conflict resolution. Multiclaude handles it differently: the merge-queue agent spawns a "fixup worker," a new Claude instance whose only job is to resolve the failing PR.
The fixup worker pulls main, rebases the branch, fixes the conflicts, and pushes. If CI passes now, it merges. If not, another fixup attempt. The ratchet keeps clicking forward.
The system doesn't prevent conflicts; it resolves them after they occur. This is a fundamentally different bet about where to spend complexity. Prevention requires prediction (knowing what will conflict before it does). Resolution only requires reaction (fixing what actually broke).
CI becomes the single source of truth about what's acceptable. If the tests pass, the code can ship. No other criteria, no human judgment required for the merge decision itself. Humans retain control over what the tests check, but the merge-queue agent has autonomy within those constraints.
The Escape Wheel⚓︎
The escape wheel in a mechanical clock regulates energy release, converting the spring's stored power into controlled, measurable increments. In multiclaude, tmux and the filesystem serve this function: they make chaotic parallel execution observable and interruptible.
Every agent runs in its own tmux window within a repository-specific tmux session. When you run multiclaude attach happy-platypus, you're dropped directly into that agent's terminal. You see exactly what Claude sees. You can type commands. You can interrupt, redirect, or take over.
This is a deliberate rejection of abstraction. The design document explains: "Humans can attach to any agent at any time with a single command. No API calls, no log parsing, no dashboard navigation. Just tmux attach."
When your rate-limiter hits a problem (maybe it's unsure how to handle the Redis connection pooling), you attach and watch it think. You see the commands it runs, the files it reads, the decisions it makes. If it's going down the wrong path, you can type directly into the terminal and correct it.
The alternative would be building custom observability: a dashboard showing agent status, log aggregation, maybe a replay system. Multiclaude explicitly lists "web dashboard" as a non-goal. Not because dashboards are bad, but because tmux already exists and developers already know it.
The same philosophy extends to inter-agent communication. Agents send messages to each other via JSON files in ~/.multiclaude/messages/<repo>/<agent>/. The design document's rationale: "Just cat the files to see messages." When debugging why an agent didn't receive a nudge, you don't need specialized tools. You ls the directory and cat the file.
Messages progress through statuses: pending, delivered, read, acknowledged. The daemon delivers them by literally typing into the agent's tmux window using tmux send-keys. No message queue, no pub/sub, no protocol buffers. Just text injection into a terminal.
The 2-minute polling interval for message delivery is noted in the spec as an "acceptable tradeoff." Real-time coordination would require persistent connections, heartbeats, failure detection. Multiclaude accepts higher latency in exchange for simplicity that doesn't break.
The Spring⚓︎
The daemon is the spring: the stored energy that keeps the ratchet moving. It runs five concurrent loops, each on a 2-minute interval:
Health check verifies that agents are actually running. It checks that tmux windows exist and that Claude process PIDs are alive. Dead agents get marked for cleanup (if ephemeral) or restart (if persistent). The distinction matters: workers are ephemeral (they finish a task and disappear), while supervisors and merge-queue agents are persistent (they should always be running).
Message routing scans pending messages and delivers them. Delivery means injecting the message text into the agent's tmux window. The atomic delivery uses a specific tmux command (SendKeysLiteralWithEnter) to avoid race conditions documented in the codebase as a known issue.
Nudge loop sends periodic status checks to agents that have been quiet too long. Your rate-limiter hasn't produced output in 20 minutes? The daemon sends a nudge: "Status check: what's your current progress?" This uses exponential backoff to avoid spamming stuck agents.
Worktree refresh keeps worker branches from drifting too far from main. If main has moved significantly since a worker started, the daemon rebases the worker's branch. This reduces the eventual merge conflict surface.
Socket server handles CLI requests. When you run multiclaude work "add rate limiting", the CLI sends a JSON message over a Unix socket to the daemon, which spawns the worker and responds with the agent name.
State persists to a single JSON file (~/.multiclaude/state.json) using atomic writes: write to temp file, then rename. The spec notes this enables "simple recovery" and, critically, manual editing if something goes wrong. When the daemon restarts, it reads the state file, checks which agents should exist, and restores any that died.
This is infrastructure-as-script, not infrastructure-as-service. No database, no external dependencies beyond tmux and git. The entire system runs locally on a developer's machine.
What the Ratchet Rejects⚓︎
Multiclaude's non-goals reveal as much about its philosophy as its features. Each absence is a bet about where complexity should and shouldn't live.
No web dashboard. Preserves terminal-first philosophy. The assumption is that users are developers comfortable with tmux. A dashboard would require authentication, hosting, state synchronization. The benefit (prettier visualization) doesn't outweigh the cost (maintaining another system).
No cross-repository coordination. Each repository is its own isolated world. If your microservices need coordinated changes across repos, multiclaude won't help. This keeps the state model simple: one daemon, many repos, but no relationships between them.
No multi-user support. Multiclaude assumes a single developer orchestrating agents. Shared access would require authentication, permissions, conflict resolution between humans. The workaround: each developer runs their own daemon.
No automatic restart on crash. If an agent crashes repeatedly, multiclaude doesn't keep retrying. The design document explains this prevents "infinite loops from buggy agents." A crash requires human attention. This is the human-in-the-loop principle applied to failure modes.
No remote daemon. The daemon runs locally, accessed via Unix socket. A remote daemon would need network protocols, authentication, TLS, connection management. Multiclaude sidesteps all of this by assuming you're SSH'd into a machine or using it locally.
Compare this to Gastown, another multi-Claude orchestration project that shares the same technical foundations (Go, tmux, git worktrees). Gastown offers more comprehensive orchestration but targets what multiclaude's README calls "single-player" use. Multiclaude emphasizes "remote-first collaboration," treating software engineering "like an MMORPG where multiple humans and AI agents work together asynchronously."
The distinction isn't that one is better. It's that they're optimizing for different constraints. Gastown bets on a single human directing multiple agents. Multiclaude bets on multiple humans spawning agents and walking away, checking back later to see what shipped.
What This Means for Human Teams⚓︎
Multiclaude is designed for AI agents, but its philosophy has an uncomfortable implication for human engineering teams: code review, as currently practiced, is a form of nostalgia.
Consider what code review actually does. It catches bugs tests miss. It enforces style consistency. It transfers knowledge between team members. It provides a checkpoint where someone other than the author blesses the change. These are valuable functions. But examine them closely and a pattern emerges: most of what review catches could be caught by better tests, better linters, better architectural constraints. The residue, the part that genuinely requires human judgment, is small. Maybe 5% of review comments. The rest is ritual.
This is Svetlana Boym's restorative nostalgia applied to engineering practice. We imagine a golden age when careful human review was the last line of defense against bugs, when senior engineers read every diff and their approval meant something. But that golden age may never have existed. Studies consistently show that code review catches fewer bugs than we think, that most defects slip through regardless, that the real value is knowledge transfer and team cohesion rather than defect detection.
Multiclaude forces the question by making the alternative concrete. If CI is strong enough to arbitrate between agents, each producing PRs in parallel, each potentially conflicting with the others, then CI is strong enough to arbitrate between humans and agents too. The brownian ratchet doesn't need a human reviewer checking the pawl. The pawl is the tests. Either they pass or they don't.
The strong claim: human review should be reserved for the cases where CI genuinely cannot arbitrate. Architectural decisions that shape the system for years. Security boundaries where the consequences of error are catastrophic. Product direction where "correct" depends on judgment no test can encode. For everything else, if the tests pass, the code ships.
This is uncomfortable because it strips away a major source of engineering identity. Being the careful reviewer, the quality guardian, the senior engineer whose approval means something. But that identity may be downstream of scarcity. When one human produces one PR per day, review is feasible. When one human can spawn agents that produce fifty PRs overnight, review becomes the bottleneck that prevents you from using your own tools.
Brian Eno's framing helps here: stop conducting and start creating conditions for scenius. The human role shifts from reviewer to constraint-writer. Your leverage isn't how many bugs you catch in review; it's how many classes of bugs you make impossible through better tests, better types, better architectural boundaries. You don't read diffs. You write the rules that make diff-reading unnecessary.
The engineering teams that will ship at 100x won't look like current teams working faster. They'll look like a different kind of organization entirely. Small groups of humans writing constraints: test suites, type systems, architectural invariants, deployment gates. Agents doing implementation within those constraints. CI arbitrating what ships. Humans intervening only when the ratchet gets stuck, when something genuinely ambiguous arises, when the constraints themselves need to change.
Frantz Fanon asked of colonial systems: who coordinates whom, and what does that do to the coordinated? The current answer for most engineering teams is that humans coordinate agents, treating them as tools to be supervised. But the multiclaude architecture suggests a different answer: the constraint system coordinates everyone, humans and agents alike. Humans aren't above the system managing agents. Humans are participants in the system, subject to the same CI arbiter, differentiated only by what they're good at. Agents implement. Humans define constraints. CI decides what ships.
Going from one PR per day to a hundred isn't about working faster or hiring more agents. It's about accepting that the coordination overhead we've built, the standups and sprint planning and code review rotations and approval workflows, exists to solve problems that dissolve when you trust your tests. The teams that can't make this shift will watch their competitors ship while they're still scheduling review meetings.
The chaos doesn't need human management. It needs human constraints. Write better tests. Define clearer boundaries. Then let the ratchet click.
The Counterintuitive Claim⚓︎
Multiclaude's architecture makes a bet that runs against most distributed systems intuition: less coordination infrastructure can mean more shipped code.
The logic works like this. Coordination has costs: latency (waiting for locks), complexity (protocols that can fail), brittleness (central points of failure). For AI agents working on code, these costs compound. An agent waiting for a lock isn't generating PRs. A coordination failure blocks all agents, not just one.
By contrast, the costs of non-coordination are bounded. Duplicate work wastes compute but produces a PR anyway. Merge conflicts require fixup but are automatically detected by CI. Suboptimal solutions ship and can be improved later.
The ratchet framing clarifies the bet: as long as forward motion (passing PRs) exceeds backward motion (nothing, because CI prevents regression), net progress occurs regardless of the chaos in between.
This doesn't generalize to all multi-agent systems. It works for code specifically because git provides cheap branching, CI provides automated validation, and PRs provide atomic units of reviewable work. The "brownian ratchet" wouldn't work for agents collaborating on a shared document or coordinating physical actions.
But for the problem multiclaude solves, shipping code to a repository, the architecture is a reminder that sometimes the sophisticated solution is to not build the sophisticated solution. Tmux instead of custom terminals. Filesystem instead of message queues. CI instead of coordination protocols. Git worktrees instead of locking.
The system works not despite its simplicity but because of it. Every component is debuggable with standard Unix tools, every failure mode has an obvious recovery path, and the only abstractions are ones developers already understand.
The ratchet clicks forward. The code ships. Whether this philosophy scales beyond codebases, to other domains where CI-like arbiters don't exist, remains the open question. But for now, the chaos was the point.
Sources⚓︎
- Lorenc, multiclaude repository (2025): https://github.com/dlorenc/multiclaude
- multiclaude DESIGN.md: Core philosophy and architectural decisions
- multiclaude SPEC.md: Implementation architecture and component specifications