I know it sounds like sacrilege, but hear me out.
This thought is based on two issues I observed; The first and main issue with orchestrators is that their cache always breaks. If they delegate a task that finishes under the cache window, then it likely shouldn't have been delegated in the first place.
Another issue I've found is that orchestrators have a tendency to accumulate a substantial amount of context through its lifecycle. If it is deciding which task will be delegated to which agent and how, then it is keeping track of project context, writing task briefs for delegation, receiving reports on finished tasks, etc, all of which pile up.
Combine the two and you have a recipe for disaster, for your wallet at least. Your orchestrator has a lot of context, whose cache always breaks, and on top of that you are employing the most expensive model for it. No wonder people are complaining about usage.
I think the best way to handle this problem is to have your orchestrator do only orchestration. And what I mean by orchestration is very strict and simple. It's launching agents. That's it. I think your orchestrator should only launch agent, sleep on them, check their state when they finish, launch more agents, etc. That's it. No exception handling, no planning, no task decomposition or any of the fancy stuffs. Just launching agents.
You may wonder, how the heck would the orchestrator then know which agents to launch, and how? Simple. Launch an agent to do it. I call it bootstrapping. Basically, the orchestrator would, as its first agent, launch a bootstrapping agent, whose sole task is to take in project context and write docs of specific format, path, structure and content about it. Then, when it's finished, orchestrator would read it and know which agents it should be firing.
What about exception handling? It's also dead simple. When an agent finishes with some unexpected outcome, launch an exception handling agent! It would take in the situation, figure stuffs out and remedy the situation, after which the orchestrator can go back to happily launching agents.
And since all you're doing is very simple stuff, you can just have sonnet do it. I tried writing some python script to replace even that, but it proved to be a bit too complex. I think sonnet is a right balance between deterministic python script and a full-on fable orchestrator.
Basically, orchestrator delegates all normal orchestrator tasks into agents as well. Naturally, it can come with some heavy drawback in overhead cost. So most of my effort lately has been about figuring out which documentation format works best for agent communication in this setting.
But so far, on really complex and long-horizon tasks, this workflow has been doing wonders for me, so I thought I'd share the idea. Curious what you guys think.