Claude Code relaunches Projects to manage multiple AI agents under one roof

Key takeaways

• Claude Code Projects now run multiple AI agents in parallel threads, each working on its own branch in the cloud.
• A coordinator agent splits the work and manages shared memory, goals, and files across all threads.
• Overlapping edits are resolved as standard Git merge conflicts, just like pull requests from human developers.
• This works best for well-scoped, multi-file tasks like refactoring or scaffolding, not exploratory work.
• Each thread runs as a separate cloud session, which likely increases API and compute costs.

# Claude Code relaunches Projects to manage multiple AI agents under one roof

What shipped

On September 17, Anthropic relaunched the Projects feature in Claude Code (https://www.theverge.com/ai-artificial-intelligence/997134/anthropic-claude-code-projects) with a new architecture that lets developers run multiple AI agents in parallel, all under one roof. Instead of managing a single coding assistant, you now get a coordinated team.

Each Project has a shared memory, a set of goals, and a library of files and artifacts. Inside, the work splits into "threads," each running a different task in parallel. A coordinator agent directs traffic, deciding which thread handles what. Under the hood, each thread is a Claude Code cloud session working on its own branch and copy of the repo. (https://www.theverge.com/ai-artificial-intelligence/997134/anthropic-claude-code-projects) When threads touch the same code, the overlap is resolved as a merge conflict, just like any other pull request. Each thread can further split its delegated work as needed.

This is similar to Grok Bot and other tools that manage groups of AI agents, but it's now native to Claude Code and fully cloud-based.

How it works

When you create a Project in Claude Code, you define the scope: the repository, the goals, and any shared context or files. The coordinator agent then breaks down the work and assigns chunks to individual threads.

Each thread runs in its own cloud session and works on a separate branch. That means multiple agents can write code, run tests, and make changes simultaneously without stepping on each other's toes. If two threads do modify overlapping lines, the system treats it like a standard Git merge conflict. You resolve it the same way you would when merging branches from human developers.

The coordinator keeps work organized, (https://www.theverge.com/ai-artificial-intelligence/997134/anthropic-claude-code-projects) but it doesn't serialize everything. Threads run in parallel, and each can spawn additional sub-threads if the task warrants it. That recursive delegation is what makes the system feel less like a single assistant and more like a small engineering team.

Because everything runs in the cloud, you're not managing local environments or worrying about which machine has the right dependencies. Each session spins up with the context it needs, does its work, and commits to its branch.

What it changes for builders

This shift changes the unit of work. Instead of prompting a single agent to write a feature, you can now scope a Project that touches multiple files, runs tests, updates documentation, and refactors in parallel. The coordinator decides how to split the effort.

For teams already using Claude Code, this means you can tackle larger tasks without bottlenecking on a single assistant. If you're building a new API endpoint, one thread can draft the handler, another can write the integration tests, and a third can update the OpenAPI spec. They all share the same context and goals, so the work stays coherent.

For teams new to AI-assisted coding, this makes the tool more useful out of the gate. You're not limited to autocomplete or single-file edits. You can describe a multi-step project and let the system decompose it.

The cloud-native design also removes friction. You don't need to set up local agents or manage multiple terminal sessions. Everything lives in Claude Code's cloud environment, and you interact through the same interface you'd use for a single assistant.

Gotchas and limits

Merge conflicts are still merge conflicts. The system resolves overlapping edits the same way Git does, which means you'll need to review and reconcile them. If your Project scope is too broad or poorly defined, you may end up with more conflicts than you'd like.

The coordinator is only as good as the goals and context you provide. Vague instructions will produce vague splits. If you don't seed the Project with enough shared knowledge, threads may drift or duplicate work.

Our read is that this works best for well-scoped projects with clear boundaries. If you're refactoring a module or building a feature that touches a known set of files, the parallelism is a win. If you're exploring an unfamiliar codebase, you may spend more time reconciling than you save.

There's also the question of cost and speed. Running multiple cloud sessions in parallel will burn through more API credits and compute time than a single assistant. Anthropic hasn't published pricing details specific to Projects, but our assumption is that each thread runs as a separate session and bills accordingly.

Finally, this is a relaunch, not a beta. The feature is live, but documentation and best practices are still catching up. Expect to iterate on your Project setup as you learn what scope and granularity work best.

How we would use it

We'd start by testing Projects on internal refactoring tasks where the scope is clear and the risk is low. For example, migrating a set of API routes from one framework to another, or updating a batch of components to use a new design token system. Both are repetitive, multi-file efforts with well-defined goals and limited ambiguity.

We'd define a Project with the old and new patterns as shared context, then let the coordinator split the work by route or component. Each thread would handle one piece, run the tests, and commit to its branch. We'd review the PRs, resolve any conflicts, and merge.

For client work, we'd use Projects to speed up scaffolding and boilerplate. Spinning up a new service with database models, API handlers, tests, and documentation is a perfect fit for parallel agents. We'd provide the schema and endpoint specs, then let the system generate the pieces in parallel.

We'd avoid using Projects for exploratory work or tasks that require a lot of back-and-forth. The strength here is parallelism, not conversation. If the task needs iterative refinement or creative problem-solving, a single assistant is still the better tool.

We'd also keep a close eye on merge conflicts and coordinator decisions. The first few Projects will teach us how to scope and structure the work to minimize friction. That learning curve is part of the cost, but the payoff is a tool that can take on larger chunks of work without constant supervision.