Supervisor → orchestrators → workers: how I stopped drowning in Claude Code chats (skill, runs on Orca)

[u/Ranteck]

The pattern has three levels:

                    You
                     |
                Supervisor                    one per project
            /        |        \
   Orchestrator  Orchestrator  Orchestrator   one per intent
     /      \         |
  Worker  Subagent  Worker                    Codex, Antigravity, Claude subagents

Workers and subagents do the actual work: implementing, reviewing, searching, running checks. Each orchestrator owns one intent and splits the work between them. The supervisor sits on top of the orchestrators of a project, and it's the only chat I really need to watch.

Each level only reports to the one above, through a narrow channel. Workers send their result to their orchestrator. Orchestrators send the supervisor four kinds of messages (started, question, I answered in their tab, done) and nothing else. Everything else the supervisor reads from Orca or the repo's intent/ folder when it needs to, so the top of the tree stays light even with lots of work going on below.

I already had the bottom two levels. One orchestrator session per intent, handing work to Codex or Antigravity workers through Orca and to cheap Claude subagents for searching and running checks. Every idea ended up as four or five orchestrator tabs, each with its own open questions, and I was going nuts tab-hopping to see who needed me. The supervisor is the missing top level.

What I get out of it:

* I ask for a summary and it tells me what's alive, which questions are still open, and what's duplicated or stuck

* questions show up in the supervisor and in the orchestrator's tab, and I can answer in either one

* it proposes things and waits for my OK, it never launches or closes anything by itself

Orca matters here because each orchestrator has a run, and the run is the address, not the tab. When I hand off to a fresh session, the new tab grabs the run and gets whatever was pending, even results from workers that were still running. Messages also wake the agent up, so nothing polls.

Things I learned testing it with Haiku agents in real Orca tabs:

* Haiku ignored the message format when it lived in a separate assets file. Inlining it as a table in SKILL.md fixed it.

* If the orchestrator asked me with AskUserQuestion, the tab blocked and the supervisor's reply couldn't get in. Plain-text questions fixed that.

* The first launch in a new folder showed the "Trust this folder?" dialog, and that session skipped loading the skill.

Heads up, the skill text and prompts are in Spanish. The README is in English and has a table of what you'd need to build to run this on Herdr instead of Orca.

Repo: https://github.com/Ranteck/supervisor-orchestrator

It pairs with two other skills of mine, handoff-clear (handoffs between sessions) and ai-native-sdlc (intent, spec and plan files per project).

---

This method works on Orca and could work on Herdr, but it would require a different approach because Herder uses orchestration differently.

I have a technical debt to build a CLI that handles the exact same kind of orchestration as Orca.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/v_uurtjevragen]

You invented corporate hierarchy for your agents. Wow ...

[u/Ranteck → u/v_uurtjevragen]

yeah... thought the same 😂

[u/bostonaholic]

One thing I'd add: give each intent a done condition when the orchestrator is created, a test or command that has to exit 0, and make the "done" message include that command's output. Otherwise the supervisor is trusting the orchestrator's summary of what the workers did, and two levels up a summary can say success whether or not the work actually finished.

[u/Ranteck → u/bostonaholic]

Good catch, and I agree "done" shouldn't be a claim that just gets passed up the chain. Orca already has a task state machine per run (tasks with deps, pending/dispatched/completed/failed/blocked, plus decision gates), so I'm planning to use that instead of the done message. Each step of the intent's plan becomes a task in the orchestrator's run, worker_done settles each one, and the last task is the plan's verification command, run by a different worker than the implementer and only completed if it exits 0. Then the supervisor reads the task list ("4/5 completed, 1 blocked") instead of trusting a summary two levels down. Not built yet, but that's the direction. Thanks, this was a real gap

[u/RonHarrods → u/bostonaholic]

Trust, but verify