- The number of agents should follow the structure of the work.
- Each handoff adds a contract, a cost and a failure point to manage.
- Human approval must precede actions that require it.
Put the engineering example in context
In its 24 March 2026 article on long-running applications, Anthropic describes a system separating planning, generation and evaluation. This engineering account illustrates one way of organising agent work in a specific setting. It does not establish that several agents always outperform one.
We start with the business process. We examine what should be deterministic, what needs interpretation and what requires approval. Architecture follows. This sequence avoids complex coordination when a few explicit steps would be enough.
Distinguish three solution types
A workflow follows predefined steps: receive a document, extract fields, check a rule and save a proposal. It fits situations where paths are known and exceptions can be described. One step may use a model without turning the entire process into an autonomous system.
An agent has discretion to choose its next action from approved tools. A multi-agent system distributes work across several roles. Specialisation can help when contexts, tools or responsibilities differ. It also requires defining what is passed between roles and how disagreements are resolved.
Define contracts between agents
Every role needs an input, an expected output, tools and a stopping condition. A research agent may return passages with their sources. A synthesis agent receives that evidence and produces a structured note. A check then verifies required elements without assuming correctness simply because another agent produced the note.
Use stable exchange formats. Specify how missing information, failed retrieval and contradictions are reported. Logs should make a case understandable without unnecessarily exposing data. An unbounded loop or indefinite automatic retry should be replaced by an explicit rule.
Place approval at the right point
Preparing an action and executing it are different steps. An agent may propose a sales response without permission to send it. It may suggest a CRM update without the right to change every record. Permissions should match the assignment and the risk of the process.
The approver needs the information required to decide: proposed content, relevant sources, recipient and the action’s consequence. Approval after sending does not control the send. In a pilot, start by observing proposals before gradually expanding execution capabilities.
Test errors and exceptions
The happy path is only part of evaluation. Add an unavailable source, contradictory data, an unexpected API response and an out-of-scope request. Observe whether the system stops, asks for clarification or presents an incomplete proposal as certain.
Compare architectures using the same cases. Measure output quality, total duration, model calls and review effort. Multiple agents should justify their coordination cost. If separation produces no observable benefit or better control, simplifying the system may be the right decision.
An example: preparing a client meeting
Consider an illustrative scenario: preparing a dossier using approved sales information. One role retrieves material from the CRM and documents. Another organises facts, open questions and an agenda. A check identifies missing sources. The account owner approves the dossier.
By default, this process does not need agents able to send emails, change prices or explore every internal system. Scope expands only when an identified need justifies it. To define your own project, bring an example request, an expected result and the tools the system should be able to consult.
| Option | Prefer when… | Watch for |
|---|---|---|
| Workflow | Steps and exceptions are known | Do not overconstrain genuinely variable work |
| Single agent | One coherent responsibility requires choices | Define tools, limits and stopping conditions |
| Multiple agents | Roles and contexts benefit from separation | Coordination, repetition and output consistency |
Sources & methodology
This insight combines cited publications with editorial analysis. Illustrative examples are not client results. Vendor features and terms may change.