Anthropic’s three-agent setup is a way to split AI work into roles: one agent plans, one writes or changes code, and one checks the result over long runs...
Anthropic’s Three-Agent Harness Explained: What It Means for Long-Running Full-Stack AI Development
Anthropic’s three-agent setup is a way to split AI work into roles: one agent plans, one writes or changes code, and one checks the result over long runs. That sounds simple. It is not. For full-stack work, the real trick is keeping the system steady when the task goes on for hours, not minutes. I’m Ernie Castro, and after years of watching code break in clever ways, I can tell you this kind of design matters because software work is not just speed; it is stewardship.
Key Takeaways- A three-agent setup divides labor into planner, builder, and reviewer roles.
- Long-running tasks need memory, checkpoints, and error recovery.
- Full-stack work gets messy fast, so role separation helps.
- Strong prompts and clear limits reduce drift.
- Human review still matters, because dignity and responsibility do not vanish when a model writes code.
What is Anthropic’s three-agent harness?
Anthropic’s three-agent harness is a workflow pattern for AI-assisted software work. One agent thinks ahead, one agent does the coding, and one agent checks the output. The point is not magic. The point is control. Long tasks fail when one model tries to do everything at once, especially when the work spans frontend, backend, tests, deployment steps, and bug fixes across many files.
I have seen this problem before in real teams. At Google, Microsoft, Amazon, and later at Zulily, the messy part was never the first draft. It was the second and third pass, when details went stale, tests drifted, and a tiny change in one layer broke another. AI behaves the same way. Give it a broad task and no guardrails, and it starts inventing shortcuts. That is how you get broken builds and fake confidence.
Anthropic’s own research on agentic coding, including its Claude Code work and broader model safety writing such as Anthropic Research, points toward tools that can reason, act, and verify in cycles. A three-agent harness is one practical way to do that. It is close to how a careful engineer works: plan, build, inspect. Repeat.
The setup matters most for long-running full-stack AI development. That means tasks like building a login page, wiring an API, adding database changes, writing tests, fixing lint errors, and maybe updating deployment settings. Lots of moving parts. Lots of chances to go sideways. Frankly, a single-agent approach often gets tired. It forgets earlier choices, repeats work, or takes a bad turn and keeps digging.
A good harness gives each agent a job. That sounds boring. Good. Boring systems are usually the ones you can trust.
Core Benefits and why this matters
Here’s the kicker: this setup is less about fancy AI and more about good habits.
- Better focus. A planner can think about the whole task without also wrestling with code edits. That reduces confusion.
- Cleaner code changes. The builder can stay on one lane, making smaller edits with less noise.
- Stronger quality checks. The reviewer can spot contradictions, missing tests, or risky changes before they ship.
- Less drift over time. Long tasks often go off course. Separate roles help keep the work anchored.
- Easier debugging. When something fails, you know which agent likely caused the mess.
I’ve tested AI coding tools enough to know that most demos are cherry-picked. They show a neat little app and skip the ugly part where the system gets lost in state management or forgets a file it already touched. In one internal prototype years back, a tool generated a backend change that looked fine until the frontend expected a different response shape. The machine did not care. The pager did. A three-agent flow would have caught that mismatch earlier.
The benefit is not just speed. It is judgment. A decent system can move fast, but a wise one checks its work. That lines up with a simple moral idea: talents are meant to be used well, not wasted. In software, that means not throwing a half-baked change into production because the model sounded confident.
This setup also helps with bigger codebases. When a repo has many services, shared libraries, and deployment scripts, one model can get lost. A planner can keep the map. A builder can edit the roads. A reviewer can make sure the bridges still stand. That is the useful part.
How to implement a three-agent harness
You do not need a cathedral of tooling. You need structure.
- Define each agent’s job. The planner should read the request and break it into steps. The builder should only write or modify code. The reviewer should compare the result against the plan, tests, and repo rules. No freelancing.
- Give each agent the same core context. They need the task, repo summary, file tree, and constraints. But do not drown them in junk. Too much context is another way to lose control.
- Add checkpoints. After each major step, save state. If the builder fails, restart from the last known good point. Long-running tasks need receipts.
- Use tests as a gate. If the code does not pass unit tests, integration tests, or lint checks, the reviewer should reject it. No excuses. I’ve worked with enough production systems to say this bluntly: if you skip tests, you are borrowing trouble.
- Limit scope per turn. Ask the builder to change one thing at a time. Ask the reviewer to check one thing at a time. Small steps win. Big leaps break ankles.
- Track assumptions. If an agent assumes a library behavior, document it. If it assumes an API field exists, verify it. Do not trust a guess just because it is neatly phrased.
- Keep a human in the loop. That is not a weakness. It is responsibility. Human review protects users, code quality, and the team’s time. In plain terms, someone has to own the consequences.
If you want a broader view of modern AI tooling, see my earlier piece on AI model updates and product news and practical engineering advice in this OpenAI model overview. The tool names change. The need for discipline does not.
When I worked on large systems, the best wins came from reducing surprise. That is what a harness does. It cuts surprise down to size.
Comparison table: three-agent harness vs. single-agent approach
| Aspect | Three-Agent Harness | Single-Agent Approach |
|---|
| Planning | Separate planner builds task map | One model plans while coding |
| Coding | Builder focuses on edits | Same agent juggles all roles |
| Review | Dedicated reviewer checks output | Review is often weak or skipped |
| Long tasks | Better for hours-long work | More likely to drift or forget |
| Debugging | Easier to isolate failure point | Harder to know where it went wrong |
| Safety | More checkpoints and oversight | More chance of silent errors |
| Best use case | Full-stack, multi-step work | Small, simple tasks |
Most guides tell you AI coding is just about prompt quality. That is only half true. The other half is system design. I have seen excellent prompts fail inside weak workflows. I have also seen plain prompts work well inside tight systems. The system wins more often than the clever wording.
Common Mistakes to Avoid.
People make the same errors over and over. That is normal. It is also avoidable.
- Mixing roles. If the planner also edits code and reviews it, the whole thing becomes mush. Separate the jobs.
- Skipping verification. A reviewer that only reads the final message is not a reviewer. It is a cheerleader.
- Feeding too much context. More text is not always better. It can bury the useful facts.
- Ignoring repo rules. Code style, lint rules, and branch rules exist for a reason. Fight them at your peril.
- Expecting perfect memory. Long-running AI work still needs logs, summaries, and checkpoints.
- Trusting confidence over proof. AI can sound sure while being wrong. That is not rare.
Let’s be real, the biggest mistake is treating the system like a person who “just gets it.” It does not. It predicts. It guesses. It can be very useful, but it is not a conscience. That is why human judgment still matters. In Catholic terms, work should serve the good of others, not just the thrill of automation. If a tool makes mistakes that users pay for, then your process was sloppy.
I once watched a team spend two days cleaning up an automated code change that looked clean on the surface. The tests passed in one environment and failed in another. The model had followed the prompt, but it had not understood the deployment shape. That is the part many articles skip. Real systems have edges.
So yes, the three-agent harness is useful. But only if you respect limits. Add constraints. Add checks. Add ownership. That is how you keep the machine useful and the work honest.
Frequently Asked Questions
What is the main purpose of a three-agent harness?
It splits AI work into planning, building, and reviewing so long tasks stay controlled and easier to fix.
Is a three-agent harness only for coding?
No. It can help with research, documentation, testing, and other multi-step work, but it is most helpful in software tasks.
Does this replace developers?
No. It supports developers. People still need to define goals, judge tradeoffs, and approve changes.
Why is it better for long-running tasks?
Because long work tends to drift. Separate roles, checkpoints, and reviews help keep the task on track.
Final Thought
The real value of Anthropic’s three-agent harness is not that it sounds clever. It is that it respects how work actually goes. Plans change. Code breaks. Reviews catch what speed misses. If you treat software as a human craft, not just a race, you will build better systems and waste less time. That is the plain truth. And if there is any lesson I keep relearning, it is this: good tools should make us more careful, not merely faster. Ermenildo V Castro would call that a decent day’s work.