Most tools I tried dumps all the agents into one workspace. Here's the structure I went with instead.
Note: I tried after writing this the Kilo extension on VS Code, which partly does the worktrees separation, so that is an alternative with less work. But that's something already built; I did this to define how the library would work so they are different things, so I wouldn't consider that a fair comparisson.
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".
I think that this is becoming increasingly true only for large, well-known repositories, where the maintainers have a lot to lose by doing anything shady. I don't think the React team could get away with doing something like that, for example.
Most tools I tried dumps all the agents into one workspace. Here's the structure I went with instead.
Note: I tried after writing this the Kilo extension on VS Code, which partly does the worktrees separation, so that is an alternative with less work. But that's something already built; I did this to define how the library would work so they are different things, so I wouldn't consider that a fair comparisson.