The moon orchestrates the ocean without touching it. Every wave breaks on its own shore, shaped by its own coastline, unaware of the others. But the rhythm, the pull, the timing of the whole system comes from something far above that sees none of the details and governs all of them. The best way to coordinate machines building software works the same way.
The Problem With Shared Context
Most tools for coordinating machine work treat it like a single ocean. One context window. One long conversation. Engineers will recognize this as the Singleton pattern. Easy to build. Works great at first. Then the cracks show.
You ask a machine to build a feature, and somewhere around the third file it starts forgetting the first. Context bleeds. Old decisions contaminate new ones. The machine tries to hold the whole ocean in its head, and the tide gets confused.
Spawning a sub-agent is better, but not by much. The agent inherits the parent’s context, its assumptions, its drift. It’s still the same body of water.
Separate Shores
The pattern that works is simpler than it sounds. Open a terminal multiplexer. Split it into panes. Launch a fresh session in each one. Give each worker its own git worktree so the filesystem isolation matches the context isolation. No shared state. No shared branches. Each pane operates on its own copy of the code.
Each session starts clean. It reads the project’s instructions from scratch. It knows nothing about the other panes. It has no context from yesterday, no residue from a previous task. Just the codebase, the instructions, and its assignment.
This isolation is the whole point. A wave that knows only its own shore breaks cleanly.
The Moon Doesn’t Swim
One pane watches the others. This is the orchestrator. It never writes code. It reads output, checks progress, spots when a pane is stuck or heading in the wrong direction. When something drifts, it sends a correction. When priorities shift, it redirects.
The orchestrator runs on Opus. The workers run on Sonnet. You don’t need the most expensive mind to lay bricks. You need it to read the blueprint and notice that the east wall is six inches off before the roof goes on.
This is what makes it different from just calling an agent. The orchestrator has persistent visibility. It can scroll through any worker’s output at any time. It watches the build happen in real time, the way a moon watches the whole ocean at once without being in any of it.
Communication flows through signals, not polling. When a worker finishes, it uses tmux send-keys to push a completion message into the orchestrator’s pane. The orchestrator sees it arrive like any other input, reviews the work, and sends feedback back the same way. The cycle repeats until the code is right. No busy-waiting. No sleep loops. Just a pull, a response, and another pull.
Course Correction
The most valuable moment in any build is the one where you realize the plan was wrong. With a single session, that realization comes too late. The context is polluted. The machine has already committed to its path.
With tidal orchestration, the orchestrator spots the problem from above. It pauses one worker. Redirects another. Starts a third on the new approach. No context leak between them. No old assumptions bleeding into the new direction. Each wave breaks fresh.
Repeatability
Each worker session loads the project’s CLAUDE.md on startup. It gets the same grounding every time: the tech stack, the conventions, the voice. This means every pane produces work that belongs to the same project, even though no pane knows the others exist.
The result is a true end-to-end test of your documentation. If a fresh session can’t build the right thing from your instructions alone, the instructions are wrong. The isolation reveals what your docs actually say versus what you think they say.
When the Tide Is Wrong
This pattern isn’t always the right one. Sometimes you want context bleed. A sub-agent that shares the parent’s understanding of a problem can move faster when the task is small and tightly scoped. If you need a quick code review or a function rewritten, spawn an agent. It already knows what you know. That’s the advantage.
Use tmux orchestration when the work is bigger than one mind. When you want full visibility across parallel tasks. When you want to test that your project documentation, your CLIs, your skills actually work in a clean environment with no inherited context propping them up. The isolation isn’t just a coordination strategy. It’s a quality gate.
Getting Started
The setup is straightforward. One tmux session, split into panes. One orchestrator running a capable model. Workers running something faster and cheaper. Give each worker a clear, scoped task. Let the orchestrator watch, correct, and redirect.
I’ve open-sourced the commands that make this work at github.com/BrettHamlin/commands. It handles the pane splitting, worktree creation, signal protocol, and code review cycle. Install it, type a task in plain English, and the system does the rest. The tools are simple. The pattern is what matters.