alt Hacker NewsAgree — that is what the coordinator is. You start a task in a Project, and Claude spins up a thread to work on it. You can then do other work in the project in parallel. When Claude needs you or has a result, it will tell you in the main thread. The cool part of the UX is it feels like a better use of attention — I no longer feel like I’m mentally jumping between contexts.
Replies
Ok, I think I might have misread your first comment. I interpreted it as the Claude Coordinator itself allowing "single-threaded focus".
On a second read, I can see what you actually meant was that the Claude Coordinator helps make multitasking smoother, and if you wanted focus, you can just jump into the individual Claude Code threads instead.
This makes sense and I have been thinking in the same direction for my personal kanban orchestrator. It completes multi-step epic tickets by orchestrating agents and answering their questions, while I can still go interact with individual tickets if I want. The bottleneck is ultimately in the decision-making quality of the coordinator, imo, which limits how much this can actually automate. (Serial runtime is also a big problem)
I have been building my own coordinator system recently, and one of the big problems that I have is keeping track of all of the parallel threads. By that I mean, I can start multiple sessions, each of which will run a workflow or multiple workflows in parallel.
What is your coordinator offering in terms of visualizing the progress being made? I often find an agent getting stuck somewhere somehow, and currently I must traverse the entire tree to spot them.
How does this differ from the existing subagent workflow? I almost exclusively work with Claude in the main thread as a coordinator, and it dispatches subagents in worktrees (and then integrates their changes). Is this essentially nicer UX on top of that pattern?