What Anthropic announced
Anthropic described a beta Claude Code Projects experience on September 17. A user can state a goal, and the product scopes work into parallel threads, coordinates them, reviews outputs, and assembles a result. The announcement describes cloud work that can continue after the user steps away. It is an evolving beta, so buyers should verify plan access and behavior in their own account.
The feature changes the coordination surface, but it does not eliminate coordination. More parallel work can create more dependencies, merge decisions, and places where two agents make incompatible assumptions.
Who can use it and when
This approach is most useful when a task can be divided into independent workstreams with shared instructions and reviewable outputs. Examples might include separate analysis of API, web, and mobile changes. A task with tightly coupled decisions may be easier to handle in sequence.
Before asking a project agent to work across repositories, identify the owner of each codebase, the branch or workspace policy, and the order in which changes should be reviewed. A parallel thread should not become an implicit authority to merge or deploy.
Why coordination becomes central
Parallelism can reduce waiting when tasks are genuinely separable. It can also multiply inconsistency when each worker interprets a goal differently. Shared files, API contracts, naming rules, and acceptance criteria reduce that risk before agents begin.
A coordinator still needs a way to detect conflicts and missing work. Require each subtask to report its inputs, outputs, assumptions, and tests. Do not accept a combined summary as proof that each underlying change is correct.
ShepBuild analysis
Start by splitting the work along stable boundaries, such as independent components or evidence sources. Keep one owner responsible for the full result. Have workers prepare changes or findings, then require a separate integration review that checks interfaces, shared assumptions, and test evidence.
Use narrow tasks for the first evaluation. Compare the parallel result with a sequential baseline on completion rate, review effort, and defects. Avoid assuming that more agents always make work faster or cheaper.
Practical next step
Pick a project with two or three truly independent workstreams. Write the shared goal, constraints, deliverable for each thread, and a single integration checklist. Keep any final merge, customer communication, or deployment behind the usual human approval process.
Review the first run before scaling. Look for duplicate work, missed interfaces, and conflicting interpretations. If the team cannot tell who owns the overall result or how to resolve disagreement, keep the work sequential until that governance is clear.
The comparison should include the coordinator’s overhead. Record how much time was spent writing the shared brief, answering worker questions, reconciling changes, and checking the integrated result. Parallel execution is helpful only when those costs are lower than the waiting or context switching it replaces. A small trial can reveal whether the work divides cleanly before the team gives a cloud project access to sensitive repositories or treats it as a routine delivery path.
The team should distinguish work that can run independently from decisions that need one shared owner. Parallel research can produce useful options, but implementation may depend on a single interface or data contract. Write those dependencies into the brief and have the integrating owner check them explicitly. This makes the review about observable compatibility rather than confidence in the coordinator’s summary.