One agent or a team? What a real build showed

There has been a lot of interest lately in multi-model agent teams for coding: a lead model plans, cheaper models do the routine work, and an independent reviewer checks the result. To test the idea on a real use case, we built a team in Claude Code on a single Claude subscription and ran it on a real project. Then one Opus agent built the same thing from the same plan.

Short answer: one strong agent was cheaper and built a better first version. The team pulled ahead only because of its independent reviewer. A single fresh review kept finding real bugs through six more changes and a public launch, and the published research points the same way.

The test project

St. John’s is home to the Tely 10 road race, first run in 1922 and one of the oldest road races in Canada. The Newfoundland and Labrador Athletics Association (NLAA) publishes results back to 1978, one page per year in a variety of layouts, along with a list of participants with 14 or more completed Tely 10 races. My test project, runhistory.jeffbarnes.ca, searches that public data and aims to list the Tely 10s a runner has finished, based on same-name results.

It’s small, but it has real research, messy parsing, privacy questions and a measurable answer, which made it a good test. Before launch, we confirmed with NLAA that this use was OK, and the site removes anyone who asks.

Team versus one agent

Role	Agent	Model
Lead: plans, delegates, sorts findings	main session	Opus
Researcher	`team-researcher`	Haiku
Implementer	`team-implementer`	Sonnet, Opus for the hard parser
Reviewer: fresh context, plan and diff only	`team-reviewer`	Opus

A scorecard was written before the single-agent run started. One Opus agent then built the app in a separate copy of the repo, with the same approved plan and acceptance checks and no helpers.

	Agent team	One Opus agent
Agent tokens	~576k (412k of it Opus)	~324k
Wall time	~40 min	~30 min
Plan’s acceptance checks	all passed	all passed
Known defects avoided, first build	1 of 7	5 of 7
Known defects avoided, after review	7 of 7	5 of 7

Team tokens leave out the lead’s coordination and count each resumed agent at its last figure, so they’re a lower bound.

What stood out:

Review was the whole advantage. Two review rounds found nine real problems and no false alarms. Examples: names with a bracketed tag silently dropped out of search, and a few rows had street addresses in the town field.
Parallelism didn’t save time. The critical path was one long job, parsing 43 page layouts, and nothing could finish before it.
The lead made mistakes too. Two of the reviewer’s findings came from the lead’s own change requests.
Cheap research needs checking. The Haiku researcher missed the project’s most useful source, an NLAA page listing official race counts for 466 long-time runners. The single agent found it. Both misread NLAA’s finishers-per-year table.

Can we trust the count?

We use NLAA’s count page as an accuracy check: an outside answer key that no agent controls. The app’s default count matches it, allowing for the four years with no results online, for 78.5% of those runners. That’s up from 74% after middle-initial matching was added. Most of the gap is name changes and races before 1978, since the race itself dates to 1922. The single agent’s build scored higher on this check, 82%, but only by merging near-matches automatically, which gave 22 over-counts against the team’s 4.

What the research says

Each finding here lines up with published work.

One strong agent first.

Vals AI: teams of one model cost 1.8 to 5.1 times as much. Only one of the four team setups did significantly better (GPT 6 Sol at medium effort), and neither Opus team did.
OpenAI’s agent guide: “maximize a single agent’s capabilities first.”
Anthropic’s “Building effective agents”: add complexity “only when it demonstrably improves outcomes.”
Pappu et al. (ICML 2026): LLM teams “consistently fail to match their expert agent’s performance,” losing up to 41.1% on ML benchmarks.

Parallelism pays only when the work really splits.

Anthropic’s multi-agent research system: an Opus lead with Sonnet subagents beat a single Opus agent by 90.2% on broad research, but used about 15 times the tokens of a chat. “Most coding tasks involve fewer truly parallelizable tasks than research.”
Cognition’s “Don’t Build Multi-Agents”: subagents working from partial context make conflicting decisions.

Hand-offs are where teams break.

Cemri et al., “Why Do Multi-Agent LLM Systems Fail?”: 1,600+ annotated traces across 7 frameworks, with failures grouped into system design, inter-agent misalignment and task verification.

Independent checks beat self-review.

Huang et al. (ICLR 2024): LLMs “struggle to self-correct their responses without external feedback.”
Panickssery et al.: LLM evaluators can recognize and tend to favor their own outputs, which is an argument for a reviewer running on a different model.

The shape that stuck

Every change since the comparison has had one fresh Opus review, and five of them used this lighter shape:

A plan, approved by a human first. It’s the cheapest place to catch a wrong direction.
One implementer working from the plan.
One fresh Opus review per change.
Objective checks with limits the agents can’t loosen, such as tests and the NLAA answer key.
Research verified at the source before it shapes a decision.

Five feature changes cost about 95k to 205k agent tokens each, review included. Every review found something worth fixing that the tests hadn’t caught. The most useful finds came close to launch:

a publish script that half-deleted its own output on OneDrive’s read-only folders
a removal list that wasn’t checked against the data actually published
an opt-out email that missed name variants, which mattered for one of NLAA’s conditions

The researcher and parallel builders are still in the kit for broad work. They’re just no longer the default.

Build your own

Claude Code has what you need built in. A subagent is a Markdown file in ~/.claude/agents/: a description the lead reads to decide when to use it, a model, a tool list, and plain instructions. The one piece to keep if you keep only one is the reviewer:

---
name: team-reviewer
description: Independent Opus reviewer. Checks the current diff against .team/plan.md for bugs, security issues and plan drift, with no knowledge of how the code was written.
tools: Read, Grep, Glob, Bash
model: opus
---
Read the plan, then git status and git diff. Assume the change is wrong and find where.
Return PASS or FIX, then findings with file:line and a concrete failure scenario. No style nits.

The starter kit, multi-agent-starter-kit.zip, has three team agents plus an optional Gemini reviewer, a CLAUDE.md section that defaults to the lighter shape, a plan template and a metrics log. To set it up:

Copy the agents into ~/.claude/agents/.
Paste the section into your project’s CLAUDE.md, copy the two templates into .claude/, merge the settings, and add .team/ to .gitignore.
Open the project once to accept the folder-trust prompt, then start a new session and ask, for example, “Build X. Use the agent team.”

The kit is free to use under the MIT License. It’s provided as is, without warranty of any kind, and you use it at your own risk. The full terms are in the LICENSE file inside the zip.

Three things worth knowing:

A subagent’s tools list can’t limit shell commands, so “never edit or push” is an instruction, not a hard limit.
A deny rule in settings applies to your own session too.
Token figures for a resumed agent include its earlier rounds, so count only the last figure per agent.

The Gemini reviewer runs on the free tier, which means Flash only. Google may use what you send to improve its products, and people may review it, so keep it to public work.

After deploying: what else to consider

Shipping isn’t the end of the loop, especially for a site that lists people’s names:

Keep the review loop for every change. The reviews just before launch were among the most valuable.
Make the answer key a regression test. Re-run it on every data refresh, with thresholds no agent may relax.
Plan for removal requests before the first one arrives. Document the steps, promise a turnaround (here, 7 days), and have the build enforce a removal list. Keep that list out of the published site, and keep the repo private.
Collect as little as possible. No analytics or request logs on a page of names. Block self-identifying AI crawlers. Remember that a static site’s whole dataset is downloadable, so minimize what goes into it.
Give the pipeline only the access it needs. Narrow the build token that the platform creates automatically, turn off default preview and dev addresses, and re-check both at each yearly update.
Know how to roll back, and write the runbook while you deploy, not afterwards.
Keep the data source’s conditions visible, such as the no-endorsement disclaimer and the opt-out link, and re-ask if the use changes.
Keep measuring. Logging tokens per change is what showed the lighter shape holding at 95k to 205k.

The takeaway

Three things earned their keep: the independent reviewer, a plan approved before work started, and a check against data no agent controlled. That held for the lead’s own decisions too.

One project is an anecdote, not a benchmark. If your work splits cleanly into parallel parts, like broad research, a team may well pay for itself. For building software from a clear plan, start with one good agent and spend the savings on a reviewer.

If you came for the Tely 10 rather than the agents, and want to know when you might be eligible for a commemorative pin, visit NLAA’s Tely 10 site. Questions and opt-out requests are welcome at [email protected]. Thanks for reading.

Sources