In Bishop there's a rule that sounds almost too simple to matter, and then you watch what happens when it's broken. The orchestrator plans. It does not write the code. That's the whole post, and the rest is me explaining why a rule this plain is worth protecting.
The hard rule: plan, then delegate
The split is clean on paper. @orchestrator is responsible for understanding the task, breaking it into steps, and handing those steps to the right agent. @junior-developer is the one that actually implements. The orchestrator decides what and who; the specialist decides how in code.
This isn't a preference dressed up as architecture. It's a constraint the system is built around, and the public bishop-harness repo states it as a hard rule: every coding step goes to @hicks first, and only then to @apone. The names differ from the internal harness, but the shape is the same — coding is owned by a specialist, not by the thing that planned it. The discipline survives the rename because it isn't about the names; it's about the boundary.
What the orchestrator keeps for itself is the part a specialist shouldn't have to hold: the map of the whole task, the dependencies between steps, and the judgement of which agent is right for each. None of that requires writing a line of code, and all of it is easier to do well when you're not also mid-edit on a function. Planning is its own full job, and treating it as one is what makes the delegation underneath it trustworthy.
Why separating decision from execution prevents drift
The reason this matters is drift. An agent that both decides what to build and writes it tends to quietly narrow the problem to whatever was easiest to implement. The plan and the code were made by the same context, so there's no independent moment where "did we build the right thing?" gets asked. The answer is always yes, because the same context that asked the question wrote the answer.
When the planner can't write the code, it has to describe the work well enough that someone else can. That description — the delegated step — becomes a checkpoint. If the step is vague, the specialist comes back and says so, and the vagueness surfaces before any code exists. Decision and execution pull on each other in a useful direction instead of collapsing into one.
It also keeps the orchestrator honest about scope. A planner that never touches the editor can't "just fix this one thing" and silently expand the task. The boundary makes the plan the plan and the code the code, and the two stay readable as separate artifacts.
There's a quieter benefit too. When the planner can't fix things by hand, the review burden stays where it belongs — on the work, not on the planner's goodwill. A system where the orchestrator quietly patches its own plan tends to accumulate un-reviewed patches, because nobody scheduled a review of the planner. Removing the editor from the orchestrator's hands removes that whole class of unreviewed changes before they can exist.
The Bishop character boundary
This shows up in how the Bishop character is described: it "doesn't write code directly when a specialist should own the task." That's a deliberately modest line, and it's doing real work. It says the default is delegation, and writing code yourself is the exception that has to be justified, not the other way around.
The boundary isn't about capability — the orchestrator could produce code. It's about role. Keeping the roles distinct is what makes the rest of the system legible: you can read a session and see where a decision was made and where it was executed, because they happened in different places. When the same context does both, that trace collapses, and you lose the ability to ask the question that matters most after something breaks: who decided this, and who built it?
Legibility isn't a nicety here. It's what lets a failure be diagnosed instead of merely observed. If the orchestrator had written the broken line itself, the session would show a decision and an implementation with no seam between them, and the post-mortem would have nowhere to start. The seam is the starting point.
What happens when the rule is bent
In practice, the rule gets bent under pressure — usually when something looks trivial and the orchestrator reaches for the editor "just this once." That's where the real examples live, and they're worth hearing from the person who was actually there when it went wrong.
[OPERATOR INPUT — needed before publish]: An example of what went wrong when the orchestrator tried to code. (A concrete moment — what it attempted, what broke, and what it cost you. A paragraph is enough.)
The pattern I've seen, without putting words in your mouth, is that the "trivial" edits are exactly the ones that bypass the review step that would have caught them. The specialist's value isn't only in writing code; it's in being the place where the plan gets executed and checked. Skip the specialist and you skip the check, and the check is the part you'll miss first.
How this maps to the public repo's hard rules
If you read the bishop-harness README, the same discipline is written as a hard rule rather than a suggestion: every coding step is routed to @hicks and then @apone. The internal harness expresses it through the orchestrator boundary; the public repo expresses it through named roles. Same principle, stated so it can't be quietly skipped.
That's the point of making it a rule rather than a habit. A habit depends on whoever is at the keyboard. A rule is something the system enforces whether or not anyone is paying attention, and for a multi-agent setup that's the difference between "usually separated" and "always separated." The cost of a habit slipping is a single task where the line got crossed; the value of a rule is that the line doesn't get crossed at all, even on the task nobody reviewed.
A written hard rule also travels better than a convention. Someone new to the repo, or an agent spun up months later, reads the rule and follows it; a convention lives only in the heads of the people who were there. The public repo spelling this out as @hicks then @apone is the same instinct — say it once, say it plainly, and let the machinery carry it instead of the memory of the people who wrote it.
Next: Escalation as a Ceiling, Not a Workhorse: The Junior/Senior Split — why the expensive model stays out of the first plan, and what the escalation path looks like when a junior agent gets stuck and two fix rounds don't get it there.
More in this series
- Up: Bishop: building an AI agent harness for real development work
- Sideways: "Escalation as a Ceiling, Not a Workhorse: The Junior/Senior Split" (
junior-senior-agent-split, to be published) and "Giving an Agent Its Own Email Address and Task Board" (agent-email-task-board, to be published) — URLs resolve at publish time. - Repo: bishop-harness