The reason there’s no good orchestration layer above the base model is that the useful part of orchestration moved into the model. what’s left to bolt on top is negative value when token consumption, latency and usability are factored in.
I’ve spent a great deal of time trying to beat plain Claude Code and Codex with a variety of planner/critic/decomposition orchestration setups. Every one produces less or same quality, 2x+ tokens, more latency and a second system to debug. External orchestration seems like I’m just creating technical debt and the actual value is focusing exclusively on providing clearer specifications (ie statements of intent, constraints and input/output contracts) to the model and just letting the leading frontier model do its thing with reasoning and effort maxed out.
Ironically the real orchestration benefit is on the human side refining intent to model instead of orchestrator to agent, invoking AskUserQuestion and other tools for the model to more deeply disambiguate my requests.
I very much agree with you.
But the value of an orchestrator still seems to exist, just not as another step before claude code.
I think the correct role of an orchestrator is not what most libs seem to be doing: having the "manager" and the "worker" and what not. That is just a system prompt, and as you said it just provides negative value.
But there are a lot of things that an orchestrator still could do, like automatically set up the workspaces and isolate each agent.
Thinking beyond, an orchestrator could actually provide communication between agents, which is something that claude code cannot do yet natively.
I have discussed this already, and was referred to solutions like Agno or Google SDK or other libraries. But there I don't find anything that makes me think "this is better than just having 4 terminals splitted in my pc and toggling between them".
The reason there’s no good orchestration layer above the base model is that the useful part of orchestration moved into the model. what’s left to bolt on top is negative value when token consumption, latency and usability are factored in.
I’ve spent a great deal of time trying to beat plain Claude Code and Codex with a variety of planner/critic/decomposition orchestration setups. Every one produces less or same quality, 2x+ tokens, more latency and a second system to debug. External orchestration seems like I’m just creating technical debt and the actual value is focusing exclusively on providing clearer specifications (ie statements of intent, constraints and input/output contracts) to the model and just letting the leading frontier model do its thing with reasoning and effort maxed out.
Ironically the real orchestration benefit is on the human side refining intent to model instead of orchestrator to agent, invoking AskUserQuestion and other tools for the model to more deeply disambiguate my requests.
I very much agree with you. But the value of an orchestrator still seems to exist, just not as another step before claude code. I think the correct role of an orchestrator is not what most libs seem to be doing: having the "manager" and the "worker" and what not. That is just a system prompt, and as you said it just provides negative value. But there are a lot of things that an orchestrator still could do, like automatically set up the workspaces and isolate each agent. Thinking beyond, an orchestrator could actually provide communication between agents, which is something that claude code cannot do yet natively.
I have discussed this already, and was referred to solutions like Agno or Google SDK or other libraries. But there I don't find anything that makes me think "this is better than just having 4 terminals splitted in my pc and toggling between them".
There are already many good solutions for this, you have the agent OS, which you can use to control all kinds of agents from 1 interface.