The Orchestrator That Is Not Allowed to Write Code
My most capable agent is banned from writing code. Not discouraged. Banned, in a rule file it reads at the start of every session.
It is the orchestrator of my agent fleet. It plans work, writes prompts, dispatches them to cheaper worker models, reviews what comes back, and merges. Its rule file splits the job in two. The allowed side is the integrator spine: plans, prompts, branches, git operations, memory. The forbidden side is everything hands-on: editing source, ad hoc debugging, reading file after file to chase a problem.
The two sides of identity.md, the rule file the orchestrator reads every session.
Why write that down? Because the failure mode is not laziness, it is helpfulness. A capable model always believes the task in front of it is small. This is small, faster to do it myself. Then it is ten turns into a debugging session, its context full of curl output, and its judgment about everything else in flight is worse. I watched that exact drift on a production bug. The orchestrator ran repros, queried the database, formed hypotheses, and shipped nothing. When we delegated the same class of problem instead, five worker agents went from prompts to a merged, reviewed pull request in about half an hour.
So the rule is blunt. The file names the temptation, "this is small, faster myself", and gives the instruction: "STOP. Write the impl prompt and dispatch."
The one path work is allowed to take. The short path is closed.
What the ban buys is capacity. The orchestrator's context window is the scarcest resource in the system, and every direct edit spends it on the cheapest kind of work. Kept clean, it can hold the whole board: which branches exist, what each worker is doing, what the review rounds found. Its dispatch ledger currently holds over a hundred dispatch rows. That is the job.
If you are building with agents, write the role down as a prohibition, not a preference. A capable model will talk itself out of a preference.