Do You Need Five AI Agents, or One Clear Workflow?

Five agents join the meeting

Imagine a platform team comparing observability vendors. Someone builds a research workflow with a specialist for each vendor, a critic, and a final writer. The system runs in parallel and produces a substantial report before lunch.

At the review meeting, the first question is about retention. One vendor's price assumes a short retention window. Another includes a longer one. The recommendation treats them as comparable. A third source describes a feature available only on a different plan.

The report is not empty. In fact, it contains a lot of accurate information. The problem is that the information answers slightly different questions.

This is an illustrative architecture story, not a claim about a particular procurement process. I like the example because it shows how multiple agents can increase the amount of work completed while also increasing the amount of reconciliation a human must do.

The team's first reaction might be to add another agent to check the comparison. I would first look at the brief every worker received. Did they share the same requirements, billing assumptions, and definition of an acceptable source? Did they know what to return when pricing was unavailable?

If those contracts are missing, another conversation will not necessarily fix the ambiguity. The workflow needs a common question before it needs more participants.

First identify independent questions

Checking each vendor's retention policy can happen independently. Writing the final recommendation cannot happen independently of the team's requirements and evidence.

Parallel workers are useful when they can explore separate sources without editing the same shared conclusion. Give each a precise question, an output format, and a stopping condition. “Research vendor A” is weaker than “Find its retention options, source URLs, and any plan restrictions.”

Anthropic's multi-agent research write-up describes benefits for tasks involving parallel exploration and information spread across sources. That is a reason to test parallelism for this scenario, not a promise that every workflow improves when split into agents.

Make a single-agent baseline

Before adding orchestration, run the task through one agent with a checklist and a structured evidence record. Measure elapsed time, source coverage, contradictions, and review effort.

If it finishes accurately within your budget, a multi-agent system may not be worth maintaining. You can often improve a vague task definition more cheaply than building a supervisor loop around it.

A baseline also makes comparisons honest. Without one, “the team of agents worked” can mean only that it produced something after several expensive attempts.

The independent work that was not quite independent

In the revised task, each vendor researcher receives the same usage assumptions and a small evidence schema. They return retention options, pricing units, relevant plan restrictions, source links, and unresolved questions. They do not write the recommendation.

That separation makes the useful parallelism visible. Searching vendor A's documentation does not depend on searching vendor B's. Comparing them does depend on both, so one synthesis step owns the final analysis.

Then the team changes a requirement halfway through: audit logs must be retained for a year. Some research remains useful, but the previous cost interpretation may no longer apply. If workers communicate only through free-form chat, it is easy for one to continue using the old requirement while another adopts the new one.

I would attach a requirement version to the evidence task. When the brief changes, the synthesis step can identify which assumptions need refreshing. It does not have to discard every source, and it must not blindly reuse every conclusion.

The same discipline helps with failure. If one source is unavailable, the worker returns a bounded result with the gap marked. The supervisor should not launch an endless series of agents hoping someone will find a public price that the vendor does not publish.

At this point, the architecture looks less like a simulated organization and more like a set of parallel jobs with explicit inputs and outputs. That is a good sign. The boundaries exist because the work needs them, not because a diagram looks more sophisticated with five named roles.

Give workers evidence, not authority

A research worker should return claims with sources and retrieval dates. It should distinguish directly stated facts from interpretation, and note when pricing requires contacting sales.

The worker's conclusion is not automatically true because another model wrote it. The synthesis step needs to reconcile incompatible terms, differing units, and information from different product versions.

For example, daily ingestion and retained storage are not interchangeable billing units. Two agents can extract accurate numbers and still create a meaningless comparison if the final writer puts them in one column without normalization.

Prevent the shared-state mess

Do not let every worker edit the same recommendation simultaneously. Use separate evidence artifacts or records, then give one step ownership of synthesis.

Define how updates invalidate conclusions. If a requirement changes from thirty-day retention to a year, the previous cost comparison is stale even if the vendor research is still useful. Track that dependency rather than rerunning everything blindly or reusing everything optimistically.

Budget the entire workflow. Five workers with generous retry limits can spend much more than five simple requests. Put limits on research breadth, repeated searches, and supervisor iterations.

Test the handoffs, not just the workers

Give one worker an unavailable source. Give another a pricing page with ambiguous units. Provide two sources that disagree. Ask whether the final recommendation admits uncertainty or smooths it into a confident sentence.

Compare the multi-agent result with the single-agent baseline on the same task set. Include total cost and human correction time. Faster research is not an improvement if the reviewer spends longer untangling the answer.

My default is to start with a clear workflow, then parallelize the parts whose independence is real. Roles should correspond to useful boundaries in the work. If removing an agent does not remove a distinct responsibility, it may just be another conversation to maintain.

The shorter report that wins the meeting

The next report is smaller. It states the team's requirements, compares like-for-like terms where possible, and leaves one pricing question open. The recommendation includes what would change it: a retention requirement, a missing quote, or a feature limitation.

That is easier for a technical lead to use than a longer answer that conceals its uncertainty. The parallel workers helped gather evidence, but the shared contract made the evidence comparable.

Would I keep the multi-agent architecture? Only after comparing it with the single-agent baseline. If the task is small and the sources are limited, one agent with the same evidence schema may be simpler and just as useful. If independent research dominates the time, bounded parallel workers may earn their place.

I would also compare maintenance cost. Every additional agent introduces prompts, handoffs, failure states, and observability needs. A workflow that is faster once can still be harder to operate every week.

The practical test is whether each boundary removes a real bottleneck or isolates a distinct responsibility. “Research these three sources independently” is a concrete reason. “Agents work better in teams” is not enough.

The team in our story does not need to admire the architecture. It needs to make a defensible decision. Choose the smallest workflow that produces the evidence they need, then add parallelism where measurement shows it helps.

Sources & further reading

Worked scenarios are illustrative. Technical references were checked on September 10, 2026.

• Anthropic: Multi-agent research system ↗

Working through a similar problem?

Tell me what you are building and where it gets stuck.

Let’s talk ↗