For most of last year, I worked Claude the way everyone does. One big session. Dump in context, ask for a feature, watch it think, fix the parts it broke, repeat. It worked. It also wasted hours.
The shift happened when I stopped treating Claude like a developer and started treating it like a small team. Specialized roles. Clear handoffs. Each one doing one thing well. Output roughly doubled. Bugs went down. I stopped babysitting.
Here is the pattern we run at 47 Industries now, and how to set it up without buying anything fancy.
The Problem With One Big Session
When you ask one agent to plan, code, test, and review, three things go wrong:
- Context pollution. The planning conversation bleeds into the implementation. By the time it is writing tests, it has forgotten half the constraints.
- Mediocre judgment. A model in build mode does not want to tell you the plan is bad. It just builds.
- No real review. Asking the same session to review its own code is theater. It will find typos, not architecture problems.
Splitting the work fixes all three. Each sub-agent gets a clean context, a narrow job, and a clear definition of done.
The Four Sub-Agents We Actually Use
We do not run twenty agents. We run four. More than that and you spend more time orchestrating than building.
1. The Planner
Reads the ticket or feature request. Reads the relevant files. Produces a plan as a markdown file. No code. The plan includes which files will change, what new files get created, edge cases, and questions for me.
The planner runs in a fresh context every time. It does not see previous implementations. This keeps it honest. If the plan reads weird, I rewrite the prompt, not the code.
2. The Builder
Takes the approved plan and executes. That is it. It does not redesign. It does not second-guess. If it hits something the plan did not cover, it stops and asks. This is the agent that lives inside Cursor or Claude Code for most of the day.
The builder is allowed to be a little dumb. We do not want creativity here. We want execution.
3. The Reviewer
Runs after the builder is done. Fresh context. Gets the diff and the original plan. Its job is to find three things: places the code does not match the plan, obvious bugs, and security or data issues.
The reviewer is intentionally adversarial. Its prompt tells it that if it cannot find three issues, it is not looking hard enough. About 70% of the time it catches something real. The other 30% is noise, which is fine.
4. The Documenter
Last step. Updates the README, the CHANGELOG, and any internal docs that referenced the old behavior. This is the agent everyone skips. We skipped it for a year. Then we started running it and onboarding new contractors went from a week to a day.
How They Hand Off
The handoff is the whole game. If you do it wrong, you just have four agents that all need babysitting.
We use files. Not memory. Not tools. Plain markdown files in a .agents/ folder at the project root.
.agents/plan.mdgets written by the planner, read by the builder..agents/diff-summary.mdgets written by the builder, read by the reviewer..agents/review.mdgets written by the reviewer, read by me..agents/changes.mdgets written by the builder, read by the documenter.
Files are durable. They survive context resets. You can read them. You can edit them. You can commit them if you want a history of how a feature was built.
What This Actually Costs
More tokens. Roughly 1.5x to 2x what a single session would burn. That sounds bad until you count the hours you used to spend cleaning up the single-session output. For us it is a clean win.
If you are on Claude Pro or Max plans, the math is even better. You are paying flat. Use them.
That is the pattern. The four agents, the file-based handoffs, and the exact prompts that make each one actually do its job are behind the gate. Inner Circle members get the full setup plus the orchestration script we run internally.
