Opening

A team builds a market report generator with five agents. A senior researcher, a data analyst, a writer, a reviewer, and an editor in chief. In the demo, the diagram looks impressive.

In production, only the researcher has a tool. The other four receive text, rewrite it, and pass it on. The report takes several minutes, costs several times what it should, and sometimes arrives with a number that differs from the source. Nobody knows in which of the five handoffs it changed. You met this smell in the last lesson. Today you'll collapse it, without losing what was actually useful.

The idea

Merge the agents that have no technical reason to be separate into a single agent, with the right tools, and a prompt that describes the task, not the job titles. And keep separate only what isolates context, restricts tools, or provides an independent review that was measured.

Before and after

Before, five roles in a queue. Four of them rewriting text.

After, the request reaches a single agent. And its prompt describes the task and the output format. Not characters.

The agent researches as many times as it needs, with search and page fetching.

And the review that mattered, every claim has a source, became a check in code.

The report comes out with a fraction of the calls.

A real case

Let's follow one number through the old design's five handoffs. The names and numbers are hypothetical.

The researcher finds, on a page: the contactless payments market moved one point two four billion dollars in twenty twenty-five, according to association X.

The analyst writes: about one point two billion, last year.

The writer: over a billion dollars a year.

The reviewer keeps it, with improved wording.

And the editor: moves billions every year.

No agent got it wrong on purpose. Each one summarized a little, and dropped what looked like a detail. Added up, the handoffs lost the source, the year, and the order of magnitude. And each intermediate agent read the previous text in full, and wrote it again in full. Four reads and four rewrites of the same content, to reach a text the researcher already had the data to write. In the new design, the agent writes the report once, with the sources right there in its own context.

A challenge

Here's one for you. In the old system, the final report said billions every year, where the source said one point two four billion. What's the most likely cause?

Each free text handoff summarized a little, and the precision eroded, step by step. Each agent rewrites without seeing the original source, and small losses add up. It wasn't the editor hallucinating. The editor only received text that already said over a billion. And a sixth agent to check the numbers would just be one more handoff, with the same loss. The check that works lives in code, against the recorded source.

Why it works

For a model, splitting into agents only helps for technical reasons. When agents share everything and only rewrite, each handoff costs a full read, and risks dropping details. When you merge, the model does in one reasoning sequence what it used to do in five calls, without rereading its own work as if it were someone else's. And what used to be review was often a verifiable criterion, which works better in code.

But splitting isn't always wrong. When several subagents research broad questions in parallel, each one reading a lot of material in its own context, and returning only the essentials, it can pay off. Even at a much higher token bill.

And when everyone works on the same material, like the same code, agents that can't see each other's context make decisions that contradict each other. So the rule is simple. Split when there's heavy, independent reading, a sensitive tool, or a measured review. Merge when everyone works on the same material.

Safe mechanics

Now the mechanics. Step zero, measure. Run the eval on the current system. Quality, cost per task, latency. And save each intermediate agent's output.

Compare each agent's input and output. If the output is nearly the same as the input, that agent is a candidate to go.

Try removing one at a time, and run the eval. The ones whose removal doesn't change quality, go.

Write the single agent's prompt, with the task, the format, and any useful rules the removed roles carried.

And turn the verifiable reviews into code. Sources, format, length, banned terms. Then keep separate only what has a reason, give the merged agent a budget, and measure again. Same or better quality, lower cost and latency.

The traps

Now the common mistake. Throwing out the rules along with the roles. The reviewer's prompt sometimes held a rule worth keeping, buried among character lines. Never cite data older than two years.

Say that in the eval, that rule caught problems in six percent of cases. What do you do with it? Not keep the reviewer as a whole agent. A date is verifiable without a model. And not drop it either, hoping the single agent will look for recent data on its own. Turn it into a code check on each source's date, and state the rule in the prompt, so the agent looks for recent sources from the start.

So before you remove each role, copy its concrete instructions into a list. Drop the character ones, like you are a demanding reviewer with twenty years of experience. And move the verifiable ones into the prompt, or into code.

The risks. Context overflow. If one of the agents isolated heavy reading, merging fills the context. Keep that one as a subagent.

Losing a review that mattered. Say you removed the analyst, and the eval didn't change. Then you removed the reviewer, and the score dropped on cases with tables. Don't put both back. The analyst can go. Find out what the reviewer fixed in tables, and pick the cheapest home for it. A rule, a check in code, or a separate evaluator.

Merging into a mega agent. If, while merging, you also give the agent the tools to email customers and publish on the website, you created the opposite smell. Merge only what's decorative. Tools with side effects keep their own scope, and approval.

And pushback from whoever designed it. Five agents with job titles look more sophisticated on a slide. Bring the eval comparison. Same quality, fewer calls, less time.

Practice

Let's practice. Five agents that answer public tenders. Which would you merge, and which would you keep separate?

The reader stays separate. It isolates the reading of forty documents. The summarizer goes. The reader can already return structured requirements.

The writer and the formatter become one. Formatting is part of writing, or the format becomes a template in code. And the compliance reviewer stays separate, if the eval shows it catches problems. It reviews with a rubric, and without the writer's reasoning.

Wrap-up

So here's the idea to take with you. Measure, remove one agent at a time, and keep only what moves the score. Copy the useful rules before deleting any role, and turn the verifiable ones into code. You end up with one agent that does the work, and a few separations you can explain.

In the next lesson, we'll look at the separation that does pay, when it's done right: the evaluator optimizer. See you there.