You already know the agent formula from Class 28 — model plus instructions plus tools plus state plus a loop — and you know how to bound that loop with budgets, timeouts, and approval gates from Class 30. The temptation now is to multiply it. If one agent can research, why not five: a searcher, a reader, a summarizer, a checker, and a publisher, all chatting away?

Resist that temptation. A single agent that you can inspect will teach you more, fail less expensively, and ship sooner than a crowd of vague agents that mostly talk to each other.

Why one agent wins first

A single agent has one instruction set, one tool list, one state record, and one log. When it goes wrong, you open one place and see: what was the goal, which tool did it call, what did the tool return, what did it save, and where did it stop. Debugging is a straight line.

Every additional agent multiplies those surfaces. Two agents means two instruction sets that can drift apart, two context windows that can disagree, a handoff format between them, and a question nobody answered: who is responsible when the final output is wrong? Three or more, and you are debugging conversations between programs instead of debugging work.

Think of it like hiring. Your first hire for a new job should be one capable generalist with a clear job description, not a five-person committee. You learn what the job requires by watching one person do it. Then do you know which parts deserve a specialist.

The specialization test

Splitting roles earns its keep only when the roles genuinely differ on at least one of these four axes:

1. Different tools. One worker needs a search API; another needs write access to a database; a third needs permission to open a review pull request. If every proposed agent would hold the same API keys and the same file permissions, they are not specialists. They are duplicates with different names.

2. Different context. One worker needs five approved sources and nothing else; another needs the full draft and brand rules. Forcing both into one giant context wastes money and invites confusion. Splitting lets each worker see only what its job requires. If both workers need the same twenty pages of background, splitting buys you nothing.

3. Different outputs. One worker produces structured evidence records; another produces prose. Different output shapes mean different validation rules, and that is a legitimate reason to separate them. If every worker produces "a helpful summary," you have not defined outputs at all.

4. Different review criteria. One worker's output is checked for factual accuracy against sources; another's is checked for tone and formatting. When the pass/fail test differs, the role differs. When the same human would check both outputs the same way, keep them together.

If a proposed split fails all four tests — same tools, same context, same output shape, same review — it is one job wearing costumes. Keep it as one agent.

The most common failure: the vague-agent crowd

Here is the design beginners sketch most often:

None of those verbs is a contract. What sources may the researcher touch? What schema does the summarizer return? What does "checks" mean — spelling, facts, or policy? What stops the writer from inventing a detail the researcher never found? Each agent passes a chatty paragraph to the next, and every paragraph loses a little precision. By the end, nobody can point to which claim came from which source.

Compare that with one good agent doing the same workflow end to end: it gathers evidence from three named sources, stores each finding with its URL and retrieval date, drafts a 300-word brief that cites only stored findings, and stops with the draft plus a missing-information note. One log, one state file, one human check. If the brief is wrong, you see exactly which step failed.

Reduce to one agent plus one queue

Before you add a second agent, prove you need it. Use this reduction exercise on any multi-agent proposal:

1. Write the single-agent version. One goal, one approved tool set, one output schema, one stop condition, one owner. Give it the full job. 2. Put a queue in front of it. Incoming work — URLs to check, tickets to triage, sources to review — waits in a visible queue (a database table, a job list, even a folder of Markdown files). The agent takes one item, processes it, writes the result, and takes the next. You now have order, retries, and an audit trail without a second brain. 3. Run it until it hurts in a specific place. The pain that justifies a split sounds like this: "the research step needs the search API but the drafting step needs the brand guide, and stuffing both into every run doubled our cost." Vague pain — "it feels like a lot for one agent" — does not justify a split. Specific pain does.

Only when one step has different tools, context, outputs, or review criteria — and the queue shows that step is the bottleneck — do you carve that step out into a second role. Class 33.2 shows how to write that separation as a real contract.

A concrete single-agent shape

Take the daily source watcher from Class 28: every morning it checks five approved sources, saves anything new, and produces one review packet.

Single-agent design:

Queue: [source-1 … source-5] each with URL, last-checked timestamp
Agent loop (one item at a time):
  fetch URL → compare against stored state → if new, save finding
    {claim, source URL, retrieved_at} → append to today's packet
Stop: all five checked, or 20 tool calls, or 15 minutes — then request review
Owner: you. Reviewer: you. Log: one run record.

That system is boring, cheap, and debuggable. A five-agent version of the same job — finder, fetcher, comparer, saver, packager — would pass the same five URLs through four handoffs, pay for five context windows, and still need the same final human review. The queue already gave you the ordering and retry behavior the extra agents pretended to provide.

Practical exercise

Take a multi-agent idea you have sketched or been pitched — or invent one: "a team of agents that monitors competitors and writes reports."

1. List every proposed agent and its job in one sentence each. 2. Apply the four-axis test (tools, context, outputs, review). Mark which axes actually differ. 3. Rewrite the system as one agent plus one queue: write the AGENT-CARD.md (goal, input, tools, output schema, stop condition, owner) and describe the queue (what waits in it, what a completed item looks like). 4. Write down the specific, measurable pain that would force you to split — e.g., "research calls exceed 40 per run" or "draft review needs different criteria than fact review."

Finish line: a one-page AGENT-CARD.md plus a queue description that handles the whole job with a single agent.

Verify: hand the card to a friend (or a fresh AI session) and ask: could you tell what this agent may touch, what it must produce, and when it must stop? If any answer is "it depends," tighten the card.

Common failure mode: keeping ghost roles — "the coordinator oversees everything" with no tools and no output of its own. If a role produces no artifact you would independently review, delete it.

Check your understanding

1. Why is a single agent easier to debug than three agents passing messages? 2. Name the four axes that justify splitting one agent into specialized roles. 3. What does a queue give you that extra agents do not?

Transition: when roles earn their keep

Starting with one agent is discipline, not dogma. Some workflows genuinely need separation — different permissions, different evidence standards, different review gates. The next lesson shows the one pipeline where roles earn their separation, and how to write each handoff as a structured contract instead of a vague summary.