Claude Code Projects Beta: Agent Teams That Plan and Coordinate Parallel Work

How claude code agent teams relate to the Projects beta

The redesigned projects announcement introduces a project organized around ongoing work: a coordinator directs threads, shared memory carries context between them, and a library collects files and artifacts.

The coordinator has a defined role. It scopes requests, delegates work across parallel threads, reviews what those threads produce, and assembles results. Each thread performs its work in a Claude Code cloud session.

Agent teams already existed before this launch. Claude Code v2.1.32, released February 5, 2026, introduced them as a research preview for multi-agent collaboration. That release described the feature as token-intensive and required an experimental environment variable.

The distinction matters when reading setup instructions. The February CLI feature and the September projects beta have different documented entry points; the projects announcement does not identify the experimental CLI flag as an activation requirement.

For navigation across these features, the Claude Code guide hub provides a starting point. Keep the project coordinator, cloud threads, and subagents distinct when deciding which workflow fits a task.

Access and setup as of September 21

Initial access was limited to selected Pro and Max subscribers using Claude Code cloud sessions who had no existing web or desktop projects. Broader Pro and Max access was planned, with Team and Enterprise access to follow.

The brief does not establish that the broader rollout had finished by September 21. A subscription alone therefore should not be treated as proof that the redesigned projects beta was available to a particular account.

What you configure

Project setup starts with a goal and repository or context. Configuration includes the cloud environment, connectors, plugins, instructions, and model.

For a development task, a useful goal would describe the desired result and the constraints that matter during implementation. For example, you could ask for a feature spanning an API and its interface, then specify acceptance criteria and code areas that need particular care. That is a suggested way to frame work for the coordinator, rather than a documented guarantee about how it will split the request.

You can steer work through the project chat or individual threads, including from a phone. Project chat gives you a place to direct the overall effort; an individual thread gives you a place to steer a specific part of it.

What remains unspecified

The launch announcement does not specify a minimum CLI version, a numerical concurrent-thread cap, or a separate beta price. It also does not establish completed access for every eligible subscription tier by the publication cutoff.

These gaps matter for planning. Avoid building a workflow around an assumed number of simultaneous threads or an assumed rollout date.

How parallel threads execute and where integration still matters

The coordinator scopes the request and delegates parallel threads. Each thread runs as a Claude Code cloud session with its own branch and repository copy, giving the parallel work separate working copies.

Threads can themselves use subagents, loops, and workflows. The project therefore has more than one level of delegation: the coordinator directs threads, and a thread may delegate further work to subagents.

Divide work by deliverable

A practical way to prepare a request is to identify separable deliverables. For a proposed feature, that might mean API implementation, interface changes, and review. Those are illustrative task boundaries, not a promised decomposition rule.

Give each deliverable a clear completion condition. If two parts depend on the same interface, describe that shared contract in the project instructions so the coordinator has it when scoping work.

The earlier February agent-team announcement particularly emphasized independent, read-heavy tasks such as codebase reviews. That positioning remains useful when choosing work to parallelize: consider how much coordination a task requires before splitting it into several assignments.

Separate branches do not eliminate conflicts

The projects announcement explicitly leaves overlapping code changes subject to merge-conflict resolution. Separate branches and repository copies do not remove the integration work when threads edit the same code.

For that reason, review should include how the outputs fit together. A suggested review checklist is whether interfaces agree, overlapping edits have been reconciled, and the assembled result meets the original goal.

The brief does not establish a workflow for coordinating changes across multiple repositories. A thread having its own repository copy is insufficient evidence of supported cross-repository orchestration, so that capability should remain an open question.

Shared memory and the project library

Threads contribute to shared project memory, while the project library collects uploaded files and generated artifacts. These provide two forms of persistent project context: memory contributed by threads and a collection of materials associated with the work.

For developers, the distinction helps organize inputs. A design document or reference file belongs naturally among the project’s materials; information discovered while completing work can contribute to shared memory.

Plan what future work needs

When preparing a project, consider which constraints should remain available as the work continues. Examples might include the intended behavior of an interface, repository conventions, or decisions that affect several deliverables.

Those examples are recommendations for organizing a project. The launch brief does not specify the exact format of shared memory or guarantee that every detail from every thread will be retained.

It also does not define retention periods, storage limits, or precise rules for when remembered information reaches another thread. The supported claim is narrower: threads contribute to shared memory, and the library collects uploaded files and generated artifacts.

Review generated artifacts as part of assessing the assembled result. Their presence in the library establishes that they are collected there; it does not, by itself, establish their correctness.

Subagents and the earlier CLI agent-team workflow

Claude Code subagents supported parallel development before the projects beta. Anthropic’s September 29, 2025 announcement included the example of a subagent building a backend API while the main agent built the frontend.

In redesigned projects, a thread can invoke subagents. This makes subagents part of the execution available within a thread, while the coordinator handles project-level scoping, delegation, and assembly.

The subagents guide is a useful companion when planning that inner layer of delegation. Keep its configuration separate from the question of whether your account has access to the projects beta.

The experimental CLI flag has a specific scope

The February v2.1.32 release required this environment variable for its agent-teams research preview:

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

The September projects announcement does not name that variable as a beta activation requirement. Enabling it should therefore not be presented as an instruction for obtaining redesigned projects access.

The February launch also documented direct takeover through Shift+Up/Down or tmux. Those are launch-era controls for the earlier agent-team workflow; they should not be assumed to describe the redesigned project interface.

Avoid outdated subagent setup instructions

By v2.1.198 on July 1, 2026, the /agents wizard had been removed. The dated changelog directs users to ask Claude to create or manage subagents, or to edit .claude/agents/ directly.

A September guide should use those methods rather than tell readers to open the older wizard. This is a concrete example of why dated release information matters when combining instructions for projects, agent teams, and subagents.

Usage, model choices, and local execution

Parallel project sessions consume usage limits faster. The projects announcement lets users inspect project usage and choose coordinator and worker models and effort, but it does not provide a numerical cost multiplier for parallel work.

That makes scope an important planning choice. Before adding threads, consider whether the work has enough independent parts to justify the extra activity. Use the available model and effort choices alongside project usage information when assessing the workflow.

The September limits change

The Claude Code weekly-limits notice states that, from September 14, weekly limits became permanently 25% higher than pre-promotion levels for Pro, Max, Team, and seat-based Enterprise.

The preceding 50% promotion ran from May 13 through September 13, ending at 11:59 PM PT. It did not change five-hour limits, and Free and consumption-based Enterprise seats were excluded.

Claude Code provides this CLI command for checking usage:

/usage

The rate-limits guide can help with the surrounding usage concepts. Higher weekly limits do not remove the projects announcement’s warning that parallel sessions consume limits faster.

Local execution was still forthcoming

The September announcement described local execution as forthcoming. As of September 21, the documented projects workflow used cloud sessions, with steering through project chat or individual threads.

A local Claude Code workflow and the redesigned cloud-project beta should therefore be evaluated separately. The brief supplies no local-project launch date or completed local rollout.

Key takeaways

• Redesigned projects launched in beta on September 17, with a coordinator that scopes requests, delegates parallel threads, reviews outputs, and assembles results.
• Claude Code agent teams predate the beta: v2.1.32 introduced the separate CLI research preview on February 5.
• Each project thread has its own cloud session, branch, and repository copy; overlapping changes still require merge-conflict resolution.
• Threads contribute to shared project memory, and a library collects uploaded files and generated artifacts.
• Initial access was restricted to selected Pro and Max subscribers meeting the announced conditions. Parallel work consumes limits faster, and local execution remained forthcoming.

FAQ

How do I access the redesigned projects beta?

Initial access covered selected Pro and Max subscribers using Claude Code cloud sessions who had no existing web or desktop projects. Broader Pro and Max access was planned, followed by Team and Enterprise, but the brief does not establish a completed broader rollout by September 21.

How do projects, agent teams, and subagents differ?

A redesigned project has a coordinator that directs cloud-session threads and assembles their results. Agent teams were introduced earlier as a separate CLI research preview, while subagents perform delegated work and can be invoked within project threads.

What happens when two threads edit the same code?

Each project thread works on its own branch and repository copy. Overlapping code changes still require merge-conflict resolution; the projects announcement does not promise automatic reconciliation.

Can project threads run locally, and how do I steer them?

As of September 21, the documented beta used Claude Code cloud sessions, and local execution was announced as forthcoming. You can steer work through project chat or individual threads, including from a phone.