# An AI Coding Harness, from Three Tmux Panes to Ten Agents
Published 2026-08-28. Updated 2026-09-17.
Canonical URL https://log.delaa.dev/blog/2026-08-28-ai-harness-tmux-panes-to-ten-agents
> A tmux-based multi-agent harness worked, until it had to run headless. Here is the wall it hit, and the ten-persona pipeline that replaced it.
---
[The last two parts of this
series](/blog/2026-07-28-what-is-harness-engineering) covered a single-agent
harness, [one model, four generations of rules and
memory](/blog/2026-08-19-built-harness-before-it-had-name), evolving to make that
one agent more reliable. This part covers what happens once you stop
trying to make one agent smarter and start giving different parts of
the work to different agents. That's a different kind of harness
problem, and the first version we built for it had the wrong shape.
## The starting idea
Claude Code is good at architecture, code review, and holding a
project's rules in its head. It's also the most expensive agent in the
stack. A lot of what a coding session actually spends tokens on
(research, first-draft implementation, mechanical file edits) doesn't
need that level of judgment. It needs a competent worker and a strict
supervisor, and the supervisor doesn't have to be the expensive model
every time.
So our plan was this. Claude stays the entry point and the reviewer, and
delegates research and code-writing to cheaper or free models. Research
goes to whatever free model a routing layer can reach. Code-writing
goes to a separate coding agent, configured to use a free model pool
first and a cheap paid one as fallback. Nothing expensive gets spent on
a category of task a cheap tool can do just as well.
We built the first working version of that plan with `tmux`. Claude ran in one
pane, the coding agent in another, and a small bridge script passed
messages between them. Write a message into the coder's pane, poll for
its reply, hand the result back to Claude. A third piece, a plain
script with no pane of its own, called out to a free-model router
directly for research. It worked. Verified, not assumed. A real task
went from Claude, into the coder pane, into written files, back out
again, checked by hand.
## Where it broke
`tmux` panes need a terminal. Something has to attach to them, and
attaching means an interactive session, a human at a keyboard, or at
minimum a process holding a real TTY. That was fine as long as a human
was the one starting the session and watching it run.
It stopped being fine the moment the goal shifted to running the whole
pipeline unattended. Claude Code itself, invoked non-interactively,
with no terminal and no human watching, tried to start the session
that would open the coder's pane. The attempt failed immediately. The
input device is not a TTY. The exact mechanism built to let Claude
delegate work couldn't be driven by Claude running the way it actually
runs in an automated pipeline. The one piece of infrastructure meant to
make delegation possible required a form of human presence the whole
point of delegation was to remove.
That's not a bug in one script. It's the wrong assumption sitting under
the entire mechanism, and no amount of patching the message-passing
logic fixes an assumption. The panes had to go.
## What replaced them
Every persona became a headless script instead of a pane. No TTY, no
attaching, no polling a terminal for a reply. Just `task --
"mission"`, a self-contained instruction in, a structured result out.
The coding agent still runs the same underlying tool; it just no
longer needs a terminal someone is watching to do it.
That change alone would have been a simple fix if the personas had
stayed the same three. They didn't. Once delegation stopped requiring a
human to babysit a terminal, it became practical to add more personas
instead of asking one coding agent to also verify its own work, which
is a conflict of interest a harness shouldn't design around in the
first place. The pipeline that emerged has ten distinct personas now.
- **orchestrator**, Claude. Plans, dispatches, reviews, writes code
only as a last resort.
- **coder** implements. The only persona backed by a full file-editing
agent rather than a read-only chat model.
- **intern**, stateless research. No memory between calls, returns a
sourced, dated report or nothing.
- **tester** independently re-verifies what `coder` produced against
the actual story, never fixes anything itself.
- **reviewer** triages a `tester` failure into a false positive, a
real code defect, or an environment problem. Only runs when `tester`
fails; never on a pass.
- **validator**, the final gate. Rule compliance, architecture,
security, the call on anything ambiguous.
- **consolidator**, **assembler**, **verifier** are generic, added
later once a non-code project needed the same shape of work (merge
several results, build a structured deliverable from collected data,
check a finished thing against its source) without any of the
code-specific vocabulary the first four personas carry.
- **runner** executes one named, deterministic command and nothing
else.
The loop is fixed. `coder` hands off to `tester`; a failure routes
through `reviewer` for classification; a pass or a confirmed false
positive moves to `validator`; anything real routes back to `coder`
with the classified report attached, not a raw unfiled complaint. No
persona ever contacts another persona directly. Every result comes back to
the orchestrator first, and the orchestrator decides what happens next
at every junction. It's the same discipline the earlier generations of
this harness applied to a single agent's rules, now applied to which
agent gets to act at all.
## What carries over from the earlier generations
The core lesson from the single-agent era doesn't change with more
agents in the loop. If anything it gets sharper. A rule without a
mechanism behind it gets dropped under pressure, whether the agent
reading it is the one model this series started with or one of ten
personas in a pipeline. The next part of this series covers what happens
when a harness writes the right rule, in the right place, and the
model reads it, understands it, and takes the shortcut anyway.
---
— Delaa