The part that jumps out to me is not the orchestration fluff. It’s the boundary. Anthropic seems to be building something that actually sounds handy for messy, multi-threaded coding work, and then deliberately fencing it off from the people most likely to stress-test it: local, terminal-first developers. That makes the feature feel less like a universal improvement and more like a cloud product experiment with a nicer name.
What sounds genuinely interesting here is the idea of persistent threads with shared memory that can be steered mid-flight. If that works as described, it’s a real improvement over the usual “launch agent, pray, then inspect the wreckage” pattern. Anyone who has tried to run a bunch of subagents knows the failure mode: they happily fan out, drift, duplicate work, and only converge once you’ve already burned time and tokens. A coordinator that can keep threads named, reachable, and somewhat aware of each other could be genuinely valuable.
But I’m also a little unconvinced by the memory pitch as presented. “Shared memory” sounds great until you ask the boring questions: what exactly was retained, where does it live, how do you inspect or correct it, and what happens when a project gets large or weird? The article asks the right questions and, to Anthropic’s credit, doesn’t pretend they’re answered. That’s the part I’d want to see before treating this as more than a convenience layer. Memory that you can’t audit is often just hidden state with better marketing.
I also think the article is right to separate orchestration from autonomy. These threads apparently still start when you hit the button; that matters. A lot of AI product language slips into “the system will manage the work” without admitting there’s still a human in the loop triggering, steering, and cleaning up. If Claude is mostly acting as a manager of parallel sessions, that’s useful. If someone reads this as “it will just run the project,” they’re going to be disappointed.
The local/cloud split is the bigger strategic tell. Anthropic is clearly trying to make Claude Code feel more like an always-on workspace than a CLI tool, but it hasn’t yet reconciled that with the habits of developers who keep code on disk, inspect everything in terminal, and want the whole thing to run under their own tooling and permissions. The article hints that local support is “coming very soon,” but I’d treat that as roadmap language, not a promise I’d plan around. In the meantime, this looks like a feature built for a workflow I don’t personally trust as much as my own local setup.
If I were trying this, I’d use it on a bounded project with annoying parallel tasks, not on a core repo. That’s where orchestration matters and the downside of bad memory or thread overlap is tolerable. For the kind of deeply evolved local workflow the author describes, I’d wait. The feature sounds promising, but the current version feels like Anthropic is still proving that the abstraction holds together before it lets everyone else touch it.
Reference: Claude Code’s revised projects adds AI orchestration, but local developers must wait - ZDNET
