Claude Code Projects Puts Multiple AI Agents to Work in Parallel
Anthropic has redesigned Projects in Claude Code to run multiple agents with shared memory, shared goals, and a common set of files and artifacts. The update is in beta for select Claude Pro and Max subscribers, The Verge reported on Sept. 17.
Each project can run several threads on different tasks at the same time. A coordinator assigns and tracks the work. Users can step into any single thread to work with it directly, or stay at the project level to follow progress and send updates through the main project chat.
Each thread is a Claude Code cloud session with its own branch, which means its own copy of the code repository. That separation lets different lines of work move forward without getting in each other's way, with differences sorted out later at integration. Think of separate workbenches that are joined together at the end. When two threads change the same code, the overlap is handled as a merge conflict, the same way a pull request is handled. A pull request is the standard proposal and review step before code changes are combined. Threads can also split their own work further by delegating to subagents and running loops and workflows under the coordinator.
At launch, threads run only in the cloud. Support for local tools and local code is coming very soon. Anthropic plans to expand Projects access to all Pro, Max, Team, and Enterprise users, as well as to Cowork and regular Claude chats.
The broader context here is a change in what the engineer manages. Single-agent assistants left breaking down tasks, ordering them, and combining results to the developer. Here the system takes on more of that scheduling, and the developer spends more time on review and direction.
In my view, using branches and pull-request style conflicts for coordination is a sensible fit for that audience. Engineers already work daily with isolated branches, diffs, which are line-by-line comparisons, and merges. Reusing those tools for agent output means there is no new system to learn, and the output fits directly into existing review, testing, and CI practices, where CI means automated checking.
What to watch now is how it behaves in daily use rather than on a diagram. How often parallel edits conflict, how reliably shared memory stays consistent across threads, and how well the coordinator keeps track as thread numbers grow will decide whether a project feels like a coordinated team or a pile of competing drafts. Interaction design counts too, because stepping in per thread or from the main chat makes the developer both dispatcher and reviewer.
Looking ahead, the practical payoff if that coordination cost stays low is clear. Small teams could keep several workstreams moving without constant context switching, with agents testing implementations in parallel while people focus on intent, interfaces, and acceptance. I have watched my own children split up school research this way to avoid bottlenecks. That would be a quiet but useful shift in how coding work is divided.
