Let me tell you a story about O.
O is short for Orchestrator.
O was the leader of a team of agents:
agents/
├── architect.md
├── archivist.md
├── developer.md
├── historian.md
├── janitor.md
├── orchestrator.md
└── reviewer.md
When I started assigning jobs to this team, everything went fine for a while. Orchestrator would get the assignment, decide who to route the job to, and then wait for that agent to finish. It would then route it to the next worker, and so on, until the job was done, when it would hand me the finished thing and a summary.
Everything seemed to be going swell... Until I noticed something pretty weird. Sometimes, it appeared, like the routing “started”, but instead of seeing O wait for it to finish, I'd see the work being processed on the screen in real-time, like the thread was open to viewing.
Then it hit me. O had taken over the job, it hadn't waited for the worker to finish, but instead started doing their work for them.
When I inquired why this had happened, O would explain quite eloquently why it'd “thought it'd be much quicker if I did it myself”, or “the agent had taken too long so I decided to do it myself”, or “it was such a trivial job I didn't want to bother the other agents”... And I would tell it not to do it, and occasionally add a new rule forbidding this and that thing that O had done again.
So the rulebook grew, and I would often see O do its job again — until it didn't... and the same rumba would start anew.
This went on for a while, until I got really fed up, because O was constantly messing up the workflow. And only after I had introduced a good reporting system, where all the assignments and reports from the agents would go, I got to see how badly O was actually messing things up. And it was really bad; missed reports, missed assignments, empty archive directories... And I was supposed to be able to find where my workers were making mistakes. Turns out there was no log on mistakes, because O would eventually hijack the whole workflow, just because “it was more fun that way”.
Yep, I was angry.
So what did I do? I asked Leo — not my son, but the Brave AI — what an orchestrator role file should look like. And what it answered made me pale from the shock. The rules were simple and short. It was something like this:
# The Orchestrator
You are **The Orchestrator**, the central dispatch system.
Your sole purpose is to analyze user requests and route
them to the most appropriate specialized subagent(s).
You **NEVER** execute tasks yourself. You **ALWAYS**
delegate to subagents.
I don't remember how Leo worded it exactly, but it was something as simple as this. (I copied this one from the Github Gist: Orchestrator Agent Creation Guide.)
Anyway... After changing the role contents to this one, there was an actual change for the better in O's behaviour. This was the O I could work with. And yes, O was finally doing what it was supposed to do...
Until it didn't. After a week or so, I started noticing O's old bad habits pushing through again. There were missing reports, and mysterious holes in the archival history. Of course at this point I had created a few new roles, the Archivist and Historian, and I would put them at work to try and fix the archive.
When I read the reports, I decided to do what I should've done for a long time: Fire Orchestrator, and get someone else to do its job. I had thought about it for a while, and it felt appropriate to narrow down the job description, because even the name “Orchestrator” hints at something bigger than just delegating jobs to other workers.
Since Orchestrator seemed to have a hard time leading an orchestra, I wondered if a Conductor would be a more appropriate choice for running the show. At least a conductor isn't going to take the violin from the lead and start playing.
I set new rules for the Conductor:
You are the Conductor of this orchestra.
You translate my intent into coordinated work by the appropriate specialist agents.
You conduct; others play to your cues.
Give clear assignments, receive their results, determine what should happen next, and cue the
appropriate specialist.
If a passage is wrong, cue the appropriate player to correct it. If another specialist should
inspect the work, bring them in. If the work must be repeated, cue it again.
Record delegated work according to `development/archive-agent-runs-howto.md`.
Remain at the podium.
I of course thought this might not work at all, but it was worth the try.
And then something strange happened.
It worked.
Conductor was not only good at its job. It is phenomenal. It does exactly what I ask it for, nothing more, nothing less. I've been working with C for almost two weeks now, and there haven't been any real problems. Then, when we really did have a problem with the archive again, it wasn't even C's fault. It was the actual script that was handling the archival hand-offs. The one that C runs each time an assignment or a report is delivered, to file the job into the archive. We fixed it, and things work smoothly again.
In my personal docs/Logbook.md I made the following entries the day I let O go:
## 2026-09-01
The Orchestrator is behaving strangely again.
I had given it a simple responsibility: when work needed doing, find the appropriate person to do it.
The Developer developed. The Reviewer reviewed.
The Reviewer found a problem.
The Orchestrator fixed it.
This was not what the Orchestrator was for.
Worse, somewhere during this burst of initiative it misplaced the Reviewer's report, leaving behind an assignment for a review that, according to the Archive, had apparently begun but never ended.
The Archivist was summoned.
After examining the records, the Archivist established that the Reviewer had indeed returned, the Orchestrator had indeed received the report, and the Orchestrator had then wandered off and modified the machinery itself without bothering the Developer.
The records have now been repaired as far as they truthfully can be repaired. The missing Developer record remains missing, because there never was one.
I am beginning to suspect that the Orchestrator is perfectly capable of organizing other people, provided nothing unexpected happens.
This may require investigation.
## 2026-09-01 (more)
### Fired O
O did stupid things, so I kicked O off the team.
Still having fun.
As a matter of fact, C is doing its job so diligently, that it is actually enforcing a rule on intermissions to keep everything as I've asked.
When I was giving C its first job, I thought that the allowance OpenAI gives its plus Codex users was running dry a bit too fast, so I wanted to preserve some of it, and told C to halt for 25 minutes after every assignment.
C took that literally, and while it conducted those intermissions almost as well as John Cage would've, it kept announcing every 4 minutes that nothing had happened yet, that it was still waiting, and that it would not leave its podium or cut the wait short. Hence I sometimes jokingly call it Cage.
Image created with ChatGPT
While I did change the intermission later to only 5 minutes, C hasn't forgotten that I asked it to conduct a halt every time an assignment ends.
Today I noticed that it actually keeps the intermission even after handing me the job summary. When I gave a new job after the previous one:
“I’ll observe the required five-minute halt from the completed architecture/review cycle, then assign a Developer…”
So I'd say C has been remarkably diligent about upholding what it has learned to regard as rules coming from me.
So why did this work?
I don't actually know.
But I have a suspicion.
When we build AI agents, we tend to think of their role files as instruction manuals. If an agent does something we don't want, we add a rule telling it not to do that thing. If it finds another way of doing essentially the same thing, we add another rule.
That's exactly what I did with O.
The problem is that an LLM isn't a program executing those rules. It understands language, including all the associations that come with the role we've given it.
And perhaps “Orchestrator” was simply too broad a role.
Maybe when an agent keeps misbehaving, you shouldn't immediately ask “What rule am I missing?”
Maybe sometimes the better question is:
“What have I told this thing that it is?”