Claude Code Subagents for Client Work: How I Run Two Builds in Parallel

The Short Answer

Define a subagent for each independent piece of a client build, give each one its own instructions and its own file surface, and run them inside the same project so their work lands in one place. That is the whole idea. The primary session stays in charge of the plan and the review; the subagents each go do one bounded piece of it, in parallel, instead of you or one long session doing the backend, then the tests, then the docs, in a row.

The win is not that Claude Code gets smarter with subagents. It does not. The win is wall-clock time on work that was always going to happen anyway, just spread across parallel tracks instead of stacked in a queue. That only pays off when the pieces genuinely do not depend on each other finishing first, which is the test that decides whether subagents help a specific build or just get in the way.

What a Subagent Actually Is (and Is Not)

A subagent in Claude Code is a role you define once, usually as its own file under a project's agent configuration, with its own name, its own scoped instructions, and often its own restricted set of tools. You invoke it from the primary session for a specific task, it does that task inside the same project, and it hands the result back. It has less context than the primary session by default, which is a feature: a subagent whose whole job is writing tests does not need to be carrying the marketing copy from earlier in the conversation.

This is a different tool from running several terminal sessions across several client folders, which is a workspace-isolation problem covered in [how to run multiple Claude Code client projects at once](/blog/run-multiple-claude-code-client-projects-at-once). That earlier setup is about keeping Client A and Client B from ever touching each other. Subagents operate inside one client's project, splitting one engagement into parallel pieces. You will likely use both: isolated folders across clients, and subagents inside any single client's build that is large enough to decompose.

The Setup I Run for a Client Build

The primary session never writes code directly once a build is big enough to split. It writes the plan, breaks the plan into pieces that do not depend on each other's output, and dispatches each piece to a subagent scoped to exactly that piece. For a typical client build this lands on two or three roles, not ten. More than that and you are spending more time coordinating than you are saving.

1. A build subagent scoped to the feature code itself, with instructions naming the exact files and directories it owns, and nothing else.
2. A test subagent scoped to the test suite only, dispatched once the build subagent's interface is settled, so it is writing against a real shape instead of guessing.
3. A docs or client-update subagent scoped to a changelog or a client-facing summary, which can run the moment there is a diff to describe, in parallel with the test work.

The rule that keeps this from turning into a mess is that each subagent's scoped instructions name the specific files or directories it is allowed to touch, and no two subagents are ever given overlapping ownership. That is the entire discipline. Get that one rule right and parallel work stays clean. Skip it and you get the exact failure mode described below.

When This Actually Saves Time

Subagents pay off on builds that decompose into pieces with a clean interface between them and no real dependency on each other's output mid-task. A feature with an API layer and a UI layer that only needs to agree on a request and response shape is a good candidate: define the shape first, then let one subagent build the endpoint and another build the interface against it, at the same time.

They also pay off on the boring-but-necessary work that has zero creative dependency on the main build: writing tests once an interface exists, generating a client-facing changelog once a diff exists, running a lint or accessibility pass once code exists. None of that needs to wait in line behind the next feature, and none of it needs the full context the primary session is carrying.

When It Just Adds Overhead

Skip subagents on anything where the scope is still being discovered. If you cannot yet describe the interface between two pieces of a build, there is nothing to hand to a second subagent yet, and splitting early just means both roles are guessing at a shape that has not been decided. Do the discovery in the primary session first, and only fan out once there is a real boundary to fan out across.

Skip them too on tightly coupled changes, where a decision in one file forces a change in three others you cannot predict in advance. That is exactly the situation a single session with full context handles better than two scoped agents that would spend more time reconciling their outputs than either spent producing them. A small refactor across a shared data model is almost always faster run straight, not split.

The Coordination Failure Mode

The way parallel subagents go wrong is two roles ending up with overlapping file ownership, so agent one's output half-overwrites agent two's, or agent two starts working against a version of a shared file that agent one is mid-edit on. This looks like a tooling bug the first time you hit it. It is almost always a scoping mistake made when you defined the roles, not a limitation of the feature itself.

The fix is the same file-ownership rule from the setup section, applied strictly: write it into each subagent's instructions in plain language, not just implied by the task description. Named boundaries, checked before you dispatch, not discovered after two agents have already collided.

What This Changes About What You Can Quote

Parallel execution on a well-scoped build is real time back, and real time back is a pricing conversation, not just a workflow tweak. If a build that used to take three serial days now runs closer to two because the test suite and the client-facing changelog were happening alongside the feature work instead of after it, that changes your estimate for the next build of that shape, which is exactly the estimating discipline covered in [how to estimate a Claude Code build so you do not lose money](/blog/estimate-a-claude-code-build).

It also changes what you can promise on a rush job, which connects directly to [how to charge a rush fee without losing the client](/blog/charge-a-rush-fee-without-losing-the-client). A build that decomposes cleanly into parallel subagent tasks is a build where a tighter deadline is genuinely achievable, not just a deadline you agreed to and hoped Claude Code would bail you out of.

Join the Profit Room

Inside the Claude Code Profit Room we share the actual subagent configurations builders run on paying client work, including which roles are worth defining and which ones are not worth the coordination cost. Join us at https://www.skool.com/claudecodeprofitroom/about and bring the build you are trying to figure out how to parallelize.