Multi-Agent and Role-Based Work: When One Agent Isn’t Enough

Previous chapters built a single agent that works reliably: describe work, plan, verify, load memory, use deterministic mechanisms, and connect to external tools.

But there’s a point where a single agent may no longer be the right model. The work might be too large, require multiple perspectives, or have parts that should be independently verified.

This is where multi-agent work enters.

Multi-Agent as Scaling Strategy

The key is to view multi-agent not as a “better” default, but as a scaling strategy with costs. Every agent added means new context, new compute costs, and new coordination. Without a clear reason, adding agents means adding a system that needs supervision.

The pattern language calls this approach role-based development and subagents: splitting work into roles with their own context and boundaries—such as explorer, implementer, and reviewer. The important principle isn’t the number of agents, but isolation and structured handoff.

Roles, Not Assignments

The term “multi-agent” creates an image of multiple agents working simultaneously on the same problem. But the more useful model is clear role assignment.

Three basic roles:

• Explorer — explores the codebase, maps dependencies, identifies assumptions, and reports findings
• Implementer — makes code changes according to specification or approved plan
• Reviewer — verifies results against requirements, acceptance criteria, and diff using independent context

This division is useful because each role needs different information. An explorer needs breadth; an implementer needs enough context to make changes; a reviewer needs artifacts to check rather than the reasoning that produced them.

This leads to two properties that make role-based work practical:

Isolation means each role has its own context window and toolset. An explorer can read large repository sections without filling the implementer’s context, and a reviewer can start from a diff without carrying all of the implementer’s reasoning.

Structured handoff means passing only the information the next role needs—not entire transcripts. A reviewer needs the diff, requirements, and verification results. They don’t need to read every step the implementer took to think through the problem.

The goal of role division isn’t to increase agent count, but to control context boundaries.

Adversarial Review

Among all roles, the reviewer typically provides the highest leverage, because it fills the gap that executable checks can’t detect.

The longer an agent works without human oversight, the more important independent verification becomes before counting work as complete.

The effective approach is to have the reviewer work in a fresh context with the information needed for verification:

• Specification or acceptance criteria
• Diff
• Test results
• Relevant constraints

Don’t send the implementer’s reasoning along unless necessary.

The key reason: reasoning can become assumptions. When an implementer has made certain decisions, a reviewer who sees the original reasoning may accept those assumptions without questioning them. Fresh context cuts this inheritance, so the reviewer evaluates artifacts based on actual evidence.

The reviewer’s job isn’t to ask “do I like this code?” but rather:

What in the requirements remains unproven?

And:

What in the diff could cause correctness, security, or stated requirements to fail?

The scope of findings matters too. Pre-define that the reviewer should flag only issues affecting correctness or stated requirements. Opening the door for the reviewer to report everything that “could be improved” turns review into a work-generating machine.

Adversarial review doesn’t mean finding fault every time. It means creating an independent opportunity to find fault.

From Pipeline to Tree Search

Multi-agent architecture isn’t one pattern—it’s a spectrum.

On one end is the fixed pipeline:

Explore → Implement → Review

Sequence is predetermined. No complex path selection. Suitable for work with fairly predictable workflow.

In the middle are plan-execute loops where the agent can adjust its plan when discovering new information, including retry budgets and composing multiple primitives.

On the other end is tree search with multiple candidate paths to explore, using LLMs or policies to choose which branch to continue or backtrack from dead ends.

All three can be multi-agent or agentic composition, but costs and capabilities differ significantly.

For most repository work, you don’t need to start with tree search. Much work falls in an easier zone:

One Agent
    ↓
One Agent + Reviewer
    ↓
Explorer + Implementer + Reviewer
    ↓
Parallel Agents
    ↓
Search / Dynamic Multi-Agent System

The further right you go, the more coordination overhead the system has.

Don’t choose architecture based on how interesting the technology is. Choose based on the nature of the work.

If the work is linear with clear verification, a pipeline may suffice. If the work requires broad exploration or has multiple options, adding roles may be worthwhile. And if the work has a genuine search space, tree-based approaches start to make sense.

Selection Rule: Use as Few Agents as Possible

Every agent added has at least three types of cost:

1. Context cost — each agent must create and maintain its own context
2. Compute cost — each agent uses tokens and tool calls
3. Coordination cost — handoff, synchronization, and failure handling must be designed

So the default rule should be conservative:

Start with one agent, and add roles when observed failure says you should.

Examples:

• Explorer is added when the agent repeatedly misses dependencies or related files
• Reviewer is added when tests pass but regressions or requirement gaps slip through
• Parallel agents are added when work items are truly independent and results can be safely merged

The reason must come from failure, not from a feeling that “more agents would be better.”

This is the same principle we use with memory files and hooks: don’t add machinery before the problem appears.

Good multi-agent architecture doesn’t maximize agent count—it maximizes useful isolation per coordination cost.

Handoff Is Interface

When multiple roles work together, handoff becomes the interface between agents.

A good handoff should immediately answer these questions for the next role:

• What is the work?
• What was discovered?
• What has been verified?
• What remains assumption?
• Where are the artifacts?
• What is the next step?
• What needs to be checked?

An example handoff from explorer to implementer might look like:

Goal:
Add Google OAuth

Relevant files:
src/auth/session.ts
src/auth/providers.ts
src/config/oauth.ts

Current flow:
Login → Provider → Callback → Session

Findings:
Session is created in callback handler
OAuth config reads from environment variables

Risk:
Existing session IDs are used by API middleware

Next:
Implement provider and callback
Preserve existing session contract
Run auth tests

Notice this handoff has no transcript, no chain-of-thought, and no details the implementer doesn’t need.

It’s an interface, not a diary.

This is why structured handoff is critical for multi-agent systems: if the handoff is ambiguous, isolation won’t help, because ambiguity gets passed to the next role.

Supervisor Remains Human

Multi-agent doesn’t remove the supervisor role—it moves it up a level.

With a single agent, you supervise execution:

Prompt → Plan → Implement → Verify

With multiple roles, you supervise architecture:

Goal
  ↓
Role Assignment
  ↓
Handoff
  ↓
Execution
  ↓
Independent Review
  ↓
Decision

Humans still decide:

• Whether work should be split
• Which role should be responsible for which part
• What context should be passed along
• Which checks serve as gates
• Which findings must be fixed
• And when work is considered complete

This is why multi-agent work is supervised delegation, not handing responsibility to a swarm.

A well-designed agent team increases leverage for the supervisor.

A poorly-designed agent team increases blind spots and makes verification harder.

---

This article is adapted from Chapter 15 of the Agentic Coding book.