Meta-orchestration: the layer above your agent orchestrator
Meta-orchestration is orchestrating the orchestrators. One agent splits a task and runs workers inside a project. A meta-orchestrator sits a level above that: it watches every project at once, decides which one needs you, and hands work to the orchestrator already running there. It writes no code itself.
If you run agents in one repo, you do not need this. The layer starts to pay off somewhere around the third or fourth project running at the same time. Where exactly depends on how much you can hold in your head.
Orchestration handles one project. Then you have six.
Agent orchestration is a solved shape by now. You give one agent a task, it splits the task into pieces, spawns workers, watches them, and merges what comes back. Most tools call this a lead, a supervisor, or a manager. crystl calls it an anointed agent or a Ruler. The names differ and the shape does not.
That shape has a boundary built into it: one orchestrator, one project.
Run four projects and you have four orchestrators. Each one is doing its job well. None of them can see the other three. So the question that used to be “what is my agent doing” becomes “which of these four things needs me first”. You answer it by clicking through four windows and reading four screens.
That clicking is the problem meta-orchestration exists to remove.
Orchestration and meta-orchestration, side by side
| Orchestration | Meta-orchestration | |
|---|---|---|
| Scope | One project | Every open project |
| Job | Split a task, run workers, merge results | Survey projects, classify state, route what is blocked |
| Writes code | Through its workers | Never |
| Dispatches into a project | Yes, directly | Hands the work to that project’s orchestrator |
| Answers | “Is this task done?” | “Which project needs me right now?” |
| You need it when | One task is too big for one agent | Too many projects are moving to track by hand |
The row that matters most is the last one. These are not competing approaches and you do not pick between them. A meta-orchestrator with no orchestrators under it has nothing to route work to.
The rule that makes it work: it must not do the job itself
A meta-orchestrator that starts fixing a bug has stopped being a meta-orchestrator. It now has one project’s context loaded, one project’s problem in its head, and the other five projects have gone unwatched.
This is the failure mode, and it is a strong pull. Any capable agent looking at a broken build wants to fix the broken build.
So the constraint is worth stating plainly: a meta-orchestrator owns no codebase, writes no line of code, and never orchestrates a single project’s work. When a project already has a lead running, it hands that project’s work to the lead rather than dispatching into the project directly. When a project has no lead, its job is to tell you, not to become one.
Give it that constraint and you get a layer that stays useful. Leave the constraint out and you get a sixth agent doing the same work as the other five, with worse context.
What it actually produces
A meta-orchestrator produces a decision set. It writes no code, and it does not hand you a status report to read.
It surveys every open project and sorts what it finds into four buckets:
- working: an agent is mid-task, nothing needed from you
- finished: work is done and waiting to be reviewed or merged
- blocked on you: an approval, a question, a decision
- broken: a failed build, a crashed agent, a stalled worker
Three of those four buckets need nothing from you. The fourth is the one you open. Instead of four windows and four screens, you get one list of the things only you can unblock.
Deus, as a worked example
In crystl, the meta-orchestrator is a hero called Deus. Every other orchestration role is scoped to one gem, which is crystl’s word for a project workspace. An anointed agent runs that gem’s workers. A court seats a crown and a hand together inside one gem. A crystl quest is a party of agents coordinating as peers, still inside one gem.
Deus is the role that is not scoped to a gem. It surveys every open gem, sorts what it finds into the four buckets above, and turns anything blocked into one set of decisions instead of a project-by-project chase. It can dispatch a worker into any project without leaving the one it is in. It never orchestrates a project’s work itself, because that is the job of the anointed agent, the Ruler, or the court’s hand already sitting in that gem.
You summon it the way you summon any hero:
crystl hero summon deusThe full decision guide for picking between these roles is in the orchestration docs.
When you do not need it
Most people do not, and a page arguing the concept is useful should say so.
You do not need a meta-orchestrator if you work in one project at a time. You do not need one if your agents finish fast enough that nothing sits blocked while you are elsewhere. You do not need one if two projects is your ceiling, because two windows is a glance, not a chase.
The layer is worth it when the cost of checking exceeds the cost of running another agent. That crossover is different for everyone, and the honest test is whether you have caught yourself asking “wait, what happened to that other thing” more than once in a day.
Why the word is worth having
“Meta-orchestration” is not a term anyone searches for yet. Nobody is typing it into Google, and a page defining it will not bring traffic this quarter.
The word is still useful, because the alternative is describing the layer every time. “The thing that watches the orchestrators but does not orchestrate” is accurate and nobody says it twice. Having a name for the layer is what lets you notice you need one.
Some people will call it super-orchestration. Same layer, and the distinction is not worth arguing about. What matters is the shape: a level above the orchestrator, scoped to everything, writing nothing.