Start with the work you need done.
A monthly report follows the same steps each time: collect figures, check them, and place them in a template. An unfamiliar software failure needs investigation before you know the next step. A study of several regions may allow separate searches to run together. These tasks need different amounts of flexibility.
A workflow follows a route set by the developer. An agent can choose its next action using the results of earlier steps. Several agents can divide up the work, but someone or something must coordinate their results. Guides from Anthropic and OpenAI recommend starting simply and adding complexity when the task needs it.[1][2]
Write down what an extra agent should improve: faster searching, better coverage of separate sources, or a more useful independent review. Then decide how you will check that improvement. If ordinary code or a checklist handles the requirement, use it. Giving every step an agent name does not establish a benefit.
Choose the setup around the work, then measure what it improves.
Use a workflow when you know the steps.
For the monthly report, you can specify the order: retrieve the records, extract the required fields, check the totals, draft the commentary, and review the output. Code can enforce that sequence and stop when a required field is missing. It also makes the point of human approval clear.
A workflow can still ask a model to make a judgment. It might classify a document, draft a paragraph, or check whether a passage supports a claim. It can even repeat a step when a check fails. The difference is that the developer defines the available routes and when repetition ends.
This works well when the inputs and completion criteria are understood. Use ordinary code for calculations, access checks, and duplicate detection; use a model where interpretation is needed. If unusual cases keep requiring a new route, identify that part of the process. A limited agent can handle the uncertain step without replacing the entire workflow.
Use one agent when each step depends on what just happened.
An agent investigating a failure may need to inspect a log, form an explanation, try a check, and change direction. You cannot usefully list every possible path in advance. Letting the system choose a tool and examine its result gives it room to adapt.
Keeping the investigation with one agent also keeps the relevant context together: the goal, evidence, failed attempts, and unresolved questions. If every step needs the previous step’s detail, splitting the work can create repeated explanations and incomplete handovers.
Give that agent a clear objective, permitted tools, a progress record, and conditions for finishing or asking for help. Set a time or cost limit appropriate to the task. Start with the access it needs to investigate, and separately authorize actions such as publication or deletion. Choosing its next step does not require giving it unlimited authority.
Keep dependent steps together when they need the same context.
Add agents when the work can be divided.
For a study covering several regions, each agent might investigate one region using the same question and reporting format. They can work at the same time because one region’s search does not need every intermediate result from another. A lead agent then checks coverage and combines the findings.
Anthropic reported a 90.2% improvement over its single-agent comparison on an internal research evaluation using a lead agent and subagents. It also reported that its multi-agent systems used about fifteen times as many tokens—the units used to process model input and output—as chat interactions, and that token use explained much of the variation in performance.[3] These are results for the systems and tasks studied. They do not show that adding agents alone caused the improvement or that every task benefits.
Before splitting the work, try writing each assignment. Can it start from a short brief, finish without constant updates from the others, and return a result you can check? Can you combine the results without losing important detail? If not, keep the dependent steps together. Work divided into separate messages is not necessarily work that can run independently.
Decide how the results will be checked and combined.
Agents can work separately and return their results, report to a lead agent that adjusts assignments, or exchange information directly. Each arrangement changes who can catch an error. A coordinator is useful only if it actually checks the work rather than passing every answer through.
The original 2025 version of a study on scaling agent systems tested 180 configurations across four benchmarks. It found benefits from centralized coordination on a divisible financial task, but a 39–70% performance decline for the tested multi-agent variants on sequential planning. Systems without a central check also spread errors more readily.[4] The size of these effects belongs to that study’s models and conditions; the practical issue is whether your coordination catches errors or adds them.
Use separate workers when their outputs stand alone and can be checked directly. Add a lead when you need to reassign tasks, track missing coverage, or compare conflicting evidence. Allow direct exchanges when one discovery materially changes another task. If agents spend most of their effort updating one another, reconsider the split.
A coordinator helps when it catches errors before they reach the final answer.
These are starting points to test. Add coordination only when it solves a recurring problem in the work.
Make a handover specific enough to verify.
“Research this topic” is a weak assignment, and “done” is a weak return. Name the question, allowed sources and tools, exclusions, required output, and available budget. Ask for supporting evidence, unresolved questions, and any changes made. The recipient should check these against the assignment before accepting the result.
Microsoft’s Magentic-One separates a record of facts, assumptions, and the plan from a record of current assignments and progress. Repeated stalls cause the coordinator to reconsider the plan.[6] The useful idea is straightforward: preserve enough state to tell whether the work advanced, instead of treating another message as progress.
The MAST research introduced more than 1,600 traces from seven multi-agent frameworks and identified fourteen failure types, including problems with design, coordination, and completion checks.[5] In your system, check the delivered files or source passages, not just the worker’s summary. Give shared records clear identifiers and an owner, avoid duplicate updates, and confirm that a requested change actually took effect.
Count the cost of the whole task.
Running searches at the same time may reduce waiting while increasing total computation. Count model use, tool charges, retries, repeated searches, coordination, and human review. Include the work needed to correct mistakes. Several cheaper models may cost more in total if they repeatedly exchange the same context.
AI Agents That Matter shows why evaluating accuracy alone can favor complex, costly systems and hide cheaper ways to achieve similar results.[7] Compare quality, elapsed time, and total cost on the same tasks. Look at difficult cases separately: an acceptable average can hide expensive runs that get stuck in repeated repairs.
Set limits for workers and the overall task so repeated delegation cannot quietly exhaust the budget. Give each worker only the access needed for its assignment. If several workers could edit the same record, use one responsible writer or a reliable conflict check. Added speed is useful when the finished result is worth the extra coordination and review.
Change the setup when the evidence gives you a reason.
Try the simplest credible approach on representative tasks first. Compare it with one agent, then with multiple agents only where a clear division of work could help. Keep tools, budgets, and scoring comparable where possible, and explain differences that could affect the result.
AgentBench evaluates agents across different interactive environments and finds weaknesses in sustained reasoning, decisions, and instruction following.[8] Examine your own failed runs to find the first important error. Did the system misunderstand the task, lose context, choose the wrong tool, or stop before verification? Fix the recurring problem you observe rather than adding roles in response to a disappointing overall score.
Simplify when successful runs settle into a predictable sequence: those steps may belong in a workflow. Keep one agent when workers repeatedly need the same information. Add a worker when an independent task is consistently delaying completion, or a coordinator when results need closer review. Recheck the benefit after each change, including whether a layer can now be removed.
A useful system can become simpler as you learn how the work behaves.