I’ve been doing this kinda thing manually. I have an /orchestrate skill. I throw ideas at that agent, it figures out how to batch things, and then it opens new Rex splits where it gets a new agent to do the work of that batch. It’s like subagents but I can still open them and interact with them directly, keep planning more batches later, etc.

I agree with the problem of complexity and context switching, but I don't see how having a single orchestrator agent helps with this problem.

Nowadays, agents run for hours on a serial task, so after telling the agent to start working on something, you simply cannot work on it anymore for a few hours. I don't see how there's anything you can do that rescues you from having to switch to something else then back a few hours later.

I think accepting that context switching will happen, and simply optimizing the UI/UX to make context switching as fast as possible, will be the way to go in the future. This will involve some form of cross-task aggregation, and eventually it will pay to have an agent decide what you should pay attention to next, but I think it will not be one regular agent you talk to, but some kind of specialized UI where you go through a backlog of pending tasks and decisions.

Has this changed the way the code harness decides on whether to send sub agents on a task? I noticed in my last few sessions that the opened sessions have much more liberally sent out agents (often with the justification of preserving context in their session).

So far I would say it’s a welcome new behavior, but a noticeable change (Opus-5-5 at xhigh).

I'm excited to have a version of this I don't have to maintain myself anymore! My co-founder was just questioning me today if it was worth the effort to maintain.

I've found that the next two bottlenecks above broad project co-ordination across agents like this are 1) specifying a project in enough detail that you are actually happy with the results 2) predicting the costs in terms of tokens and time.

How are you managing these? I've found without getting a lot better at 1 and 2, parallel project management like this has questionable returns on tokens and time.

I’m personally a massive fan of it and it’s my main driver. Now having the coordinator more in the mix is a welcomed add and helps with the workflow when running multiple projects. At some stage, would love to have projects be able to talk / handoff to each other and a single dashboard across all projects to see where threads are up to.

Great feature; I feel like I've been trying to do this in different ways all year, from skills or sub agent config where the root agent supports similar orchestration, or trying to stuff agent status or outcomes into shared memory (and each agent having behaviors to surface it).

So much cognitive overhead just managing that, this is so much better.

Where are the worktrees? I often run multiple AI workloads in the same repo, whether it be a monorepo or working on multiple feature requests for a single product. IMO this is the biggest miss I have from CC today, and the primary reason I run herdr to manage my agents.

I like this workflow so much that I actually built my own tool to do exactly that. https://github.com/endthestart/poundlock-dispatch And in the Claude desktop app I force all sessions to communicate through a Project Manager session. But it’s always been a pain due to the 10 message limit and having to schedule it to check on other sessions to ensure everything is still moving a long.

Your description matches my experience, though i'm here on raw claude code over many sessions in parallel. I'd be happy to hear how I can set this "projects" thing up and give it a spin, is this a cloud-only or desktop-app only thing?

Hi Boris, I've been having a great time with Fable 5.2 as the head-orch to spin up sub orchs that spin up sub sub workers as needed.

Besides the nicer UI, what other advantages are there over my current flow?

As far as I can see, this is not available via Claude Code CLI. Are there plans for it?

This is such an insightful view of the user experience. The user story you present is very familiar!

Funny coincidence cursor came up with the exact same concept and names.

How is this different from having a coordinator open side sessions that report to it?

> "You do your work in Projects, then talk to your project’s coordinator, which then delegates work to threads when needed."

Correct me if I'm wrong, but you skipped a layer: Projects use a coordinator → worker → threads pattern.

This is the reason I only tried Projects once and then went back to my previous way of working: Threads in the current UI aren't easy to track or to watch over. Apparently if you want to know what they're doing you're supposed to ask your coordinator. That's crazyville.

It may not be "correct" but I like to use Fable as a coordinator/orchestrator/planner/assistant and validator. I chat with it constantly. I've banned it from doing any implementation or research work on its own. Instead it always fires off Opus subagents to do the work and then it validates their work when they're done and then updates me.

This way, the Fable thread is always available for me to chat with, plan, brainstorm, answer questions, etc. Yes, just like a Project's coordinator, but I always know what it's doing and workers are just one step away. The way the Projects are set up seems way more hands-off.

Working this way in the Desktop GUI, I can easily see all the subagents and subtasks that are running and I can drop in and check out what they're doing/thinking/etc. with a single click. This has helped numerous times as they can get stuck, or I can see that I've given the wrong instructions, or something else. I also have the main Fable session set timers so it can monitor for stuck agents as well (waiting for a test suite to return that never does, for example). I don't have anywhere near the same control and visibility into threads.

Projects instead defaults to a less advanced coordinator/orchestrator (I know you can change it but the point is that the system is designed for a dumber coordinator), then the smarter worker subagents start, but I don't get to talk to them directly unless I hunt them down, and then they fire off threads which I have NO visibility at all into and have no idea what they're doing.

You guys at Anthropic need to think about us poor schmucks that don't have unlimited tokens to work with. I can't have threads out there sucking up tokens/usage allowance only to find out later that they were wasting their time.

Hi Boris. We need the ability to run orchestrators on the local machine. Right now they run on the cloud which means they cannot access files and resources on the developer’s machine. This makes projects infeasible for many types of workloads.

At the moment I’m using a “regular” session as an orchestrator and have it start and manage its sessions (which it refers to as “lanes”, each of which runs Opus). Once each lane is done, the orchestrator (Fable) does its own review to make sure it “fits” the broader feature context. But the experience is clunky and nowhere as nice as how things work in projects. It may also be not as token efficient.

I recently asked Claude what was the best Discord bot library and it spawned 7 sub-agents and ran me completely out of usage in about 10 minutes. I think this won't be particularly helpful until we solve the problem of usage exploding like that.

Can we please have something like the live voice in chat in code! Seems like this would fit this orchestrator setup like a glove.

(and exposed to the SDK ideally!)

Babling about something in the UI or the UX then asking it to figure out some options has yielded me some insane results.

It's pointless to talk about because it's not widely available.

[flagged]

[flagged]