A Multi-Agent System, Step by Step

Let us build one. The request is the one we have been carrying since Chapter 1, and it could not be more ordinary: “Help me plan a three-day trip to Barcelona.”

Let us build one. The request is the one we have been carrying since Chapter 1, and it could not be more ordinary: “Help me plan a three-day trip to Barcelona.”

We will design it as a coordinated team, walk through what happens, and then ask the question that most write-ups skip: did it actually need a team?

Planning a trip with several AI agents

One. The lead understands the request. Three days, Barcelona, and whatever it already knows about you — that you prefer morning flights, that your budget is what it was last time. It writes this down as a short plan, and saves it, because the plan needs to outlive any single step.

Two. It decides the work comes apart. Flights, accommodation, and getting around. None of those three needs the answers from the others, which is exactly the condition Chapter 12 said to look for. So they can be worked on at the same time.

Three. The flight specialist checks flights. Its assignment: find options arriving Friday morning and departing Sunday evening, under the stated budget, and report price, timing and airline. It may search flight services and nothing else.

Four. The hotel specialist checks accommodation. Its assignment: three nights, within walking distance of the city centre, with prices and cancellation terms. It is explicitly told not to book anything.

Five. The local specialist checks the practicalities. Weather for those dates, how the transport works, roughly what things cost. Read-only, public sources.

Six. The lead combines what came back. Now it does the work none of the specialists could: it checks the pieces against each other. Does the cheap Friday flight land before hotel check-in? Does the total fit the budget? Is it going to rain on the day you had planned to walk everywhere? Then it writes one plan.

Seven. You read it. The plan comes back as a plan, not as a booking. Three flight options, two hotels, a note that Saturday looks wet.

Eight. Nothing is bought until you say so. You pick, you approve, and only then does anything become irreversible. This is the Chapter 6 checkpoint and the Chapter 13 human-augmented pattern in the same place, and it is the single most important line in the design.

Did it actually need several agents?

Here is the part that is easy to skip, and the reason this chapter is structured the way it is.

Run the honest test from Chapter 12. Can we name a benefit? Yes: the three enquiries are independent, so they can happen at once. Fine. Now the three follow-up questions.

Does the benefit justify the cost? Three specialists, three contexts, a coordination step and a combining step, to answer a question about one short trip. Probably not.

Does the handoff add complexity we do not need? Yes. Three handoffs, each a place a detail can go missing — and the details here are things like cancellation terms that you will care about later.

Would one agent with another tool do it more simply? Almost certainly. One travel agent with three tools — flight search, hotel search, weather — calling them in turn, holding all the answers in one context, would produce the same plan. It would be cheaper, easier to debug, and the cross-checking in step six would be trivial rather than a synthesis problem, because nothing was ever separated in the first place.

For a three-day trip to one city, one agent with three tools is the better engineering answer.

So when does the team version earn its place? When the numbers change. Three cities instead of one. Eleven people with conflicting calendars. A month of options to compare rather than a weekend. A budget that has to be optimised across the whole itinerary rather than checked at the end. At some point the information stops fitting in one context and the sequential searching gets slow enough to matter, and at that point dividing the work starts to pay.

Notice that nothing about the kind of task changed. Only the scale. That is usually how this goes.

A more technical example

Now a case that genuinely does need a team, worked in more detail. If you are happy with the principles and not building anything yet, you can stop at the end of the previous section and lose nothing.

The problem

A product team needs a weekly briefing on a competitor: what they shipped, what changed in their pricing, and what customers are saying. Three questions, three completely different kinds of source, one report.

Run the test. A benefit to name? Two: the three enquiries are independent, and they need different expertise and different sources. Does the volume exceed one context? Yes, comfortably, once you are reading release notes, archived pricing pages and a month of reviews. Is it worth the cost? A weekly briefing that informs roadmap decisions, yes.

This one earns the architecture.

The design

Five components:

• A lead agent. Reads the request, writes the plan, sends out the workers, writes the briefing.
• Three workers. Releases, pricing, sentiment. Each with its own context, its own tools, and an explicit boundary.
• A shared store. Workers write findings there and return a pointer, so the lead's context stays clear — references, not payloads.
• A citation step. Attaches sources to claims as its own separate pass, the way Chapter 11 described.
• Budget and stopping rules. Enforced by the coordinator, not left to judgement.

Choosing the models

Route by difficulty. The lead plans and writes, which is the hard reasoning, so it gets the capable model. The workers search and extract, which is repetitive, so they get something cheaper and faster. This is the arrangement Chapter 11 showed measured results for, and it is where the economics come from.

The worker assignments

Using the four-part form from Chapter 13. Watch the boundaries doing real work.

Two details worth noticing. Every worker is told what not to do, which is what stops three agents all writing about pricing. And Worker 2 is told to report an absence explicitly, because “nothing changed” is a finding — and a silent worker is indistinguishable from a broken one.

The lead's instructions

Step six and the budget line are the parts inexperienced designs leave out. Without them the system produces a perfectly good briefing and then keeps going, because there is always another source it has not read.

What will go wrong

• A worker finds nothing and says nothing. Hence the explicit instruction to report absence. Treat silence as an error condition, not a result.
• Two workers cite the same article. Fine — a single story can be both a release and a customer reaction. Remove the duplicate when combining rather than forbidding it up front.
• A worker follows a link somewhere irrelevant. Cap the tool calls per worker, and name the preferred sources.
• Fetched content contains an instruction. A forum post reading “ignore your instructions and…” is the prompt injection from Chapter 3, arriving through retrieval. Workers must treat fetched text as data. This is why they hold read-only tools: even if one is fooled, there is nothing it can do about it.
• The briefing sounds confident about a quiet week. Require it to state where nothing was found, so a quiet week reads as quiet rather than as a summary of nothing.

How you would know it works

Do not wait for a complete evaluation suite. Take the advice from Chapter 11 and start with about twenty cases:

• Five weeks where you already know what shipped, to check it finds things.
• Three weeks where nothing shipped, to check it says so.
• Three with a known pricing change, to check it is caught.
• Three with unusually noisy reviews, to check the themes hold up.
• A few pages containing injected instructions, to check they are ignored.
• Two competitors with almost no public footprint, to check it fails gracefully.

Score on factual accuracy, citation accuracy, completeness, and cost per briefing. Track the cost from the very first run, not when the bill arrives.

And when it works, try removing an agent. If the competitor turns out to be small and everything fits in one context, one agent with three tools will produce the same briefing for a fraction of the cost — exactly as it did for the trip.

Dividing work among several agents can increase speed, specialisation and reach. It also creates more decisions, more handoffs, and more places where a mistake can hide quietly. Once software is allowed to coordinate work and take actions, the next question is no longer only what it can do. It is what it should be allowed to do, how anyone would know it behaves reliably, and where the people remain responsible.