Adding another agent is useful when it creates a clear boundary in the work: a separate evidence search, a specialized context or a task that can proceed independently. It is less useful when several agents merely repeat the same reasoning and pass longer summaries between themselves.
The business question is therefore not how many agents a product should contain. It is which part of the work becomes more reliable, faster or easier to maintain when separated, and whether that improvement outweighs coordination. A single agent can already use multiple tools and complete multiple steps.
First ask whether the work needs an agent at all
An invoice arriving, being checked for required fields and entering an approval queue may follow a known path. A conventional workflow can control that sequence and call a model only where interpretation is needed. The model does not have to choose the entire process.
Anthropic's Building effective agents distinguishes predetermined workflows from systems where models direct their next steps. Its architectural guidance favors simple designs until added complexity has a demonstrated purpose. That distinction is more useful than naming every model call an agent.
For a business product, sketch the decisions that are uncertain. If the next step is always defined by an explicit status or rule, ordinary application logic is a strong candidate. If the system must explore evidence and adapt its search, an agent may be justified for that bounded part.
Use a supplier assessment to make the choice concrete
Consider an illustrative procurement assessment. The team wants a brief combining supplier capability, quoted commercial terms and relevant product documentation. These evidence streams can be investigated separately, provided they refer to the same supplier, product and enquiry.
One design uses a single agent with well-described tools. It retrieves the quote, checks the product material and prepares a brief. Another design assigns bounded research tasks to separate workers and gives a coordinating component responsibility for reconciling their findings. Neither design should place an order merely because the brief is complete.
Start with the single-agent version as a measurable baseline. Check whether it loses relevant context, chooses the wrong tools or spends time serially exploring independent material. If the observed problem is a missing supplier identifier, adding workers will probably reproduce that mistake in several places.
LangChain's multi-agent documentation describes motivations including specialized context, independent development and parallel work, while noting that one agent with suitable tools can often be sufficient. Those are useful reasons to test separation; the presence of several departments in an organization is not enough by itself.
Choose a boundary, then define the handoff
| Observed need | Candidate structure | Evidence needed before keeping it |
|---|---|---|
| One bounded task with a small tool set | One agent | Correct completion and manageable context |
| Independent evidence investigations | Coordinator with research workers | Better coverage or lower elapsed time after reconciliation |
| Fixed sequence with an interpretation step | Workflow with selected model calls | Predictable state changes and recoverable failures |
| Specialized knowledge used occasionally | Load relevant context or capabilities when needed | Fewer wrong tool choices without unnecessary delegation |
| Separate services owned by different teams | Explicit service contracts, with agents where justified | Clear ownership, compatible results and failure handling |
These structures can coexist. “Multi-agent” describes how responsibilities are divided; it does not specify where state is stored, which component may commit an action or how access is enforced.
A handoff needs more than “look into the supplier.” Include the business objective, exact entity, permitted sources, expected result structure, scope exclusions and stopping condition. Ask workers to return source references, unresolved conflicts and work they could not complete. Otherwise, a tidy summary can conceal missing evidence.
Keep one place responsible for shared business state
Research workers can produce candidate findings, but allowing them all to edit the same final record creates a different problem. One may overwrite another's conclusion, attach evidence to the wrong version or interpret a partial result as completion.
For the supplier assessment, store each worker's result separately with a task identifier and source version. Let a designated aggregation step merge findings into the draft brief. Resolve conflicting supplier names or units before producing a recommendation. Preserve uncertainty rather than averaging incompatible answers.
Enforce permissions in the application and tools. A worker named “researcher” is not automatically read-only, and a separate prompt is not a security boundary. Give each component only the operations it needs and make the purchasing system enforce its own authorization. The component preparing a recommendation should not acquire purchase authority through another worker.
A reviewer agent can share the same blind spot
An extra review pass can catch omissions, but agreement between models is not proof. If every worker receives the same outdated policy or incorrectly extracted table, several confident answers can repeat one mistake.
Give the reviewer an explicit rubric and access to the underlying evidence. Use deterministic checks for identifiers, required fields and calculations where possible. For an unfamiliar commercial exception, retain a human decision point. The reviewer should report what it verified and which evidence remained unavailable.
Anthropic's account of its multi-agent research system describes gains from parallel exploration alongside coordination and resource challenges. It is evidence about a particular research design, not a guarantee of the same benefit in an order-processing application. Your trial should compare the workload you actually intend to run.
Test coordination failures, not just successful answers
The test set should include a worker that times out, two findings that conflict, a late result arriving after cancellation and a repeated task message. Decide whether the product waits, produces a clearly partial brief or stops for review. A missing worker must not silently disappear from the completion criteria.
Set bounds on delegation depth, concurrent work and retries. Record parent and child task IDs so an operator can understand why a request is still running. Cancellation should propagate to work that is no longer needed, while any already-committed external action still needs reconciliation.
Compare accepted task completion, evidence coverage, operator intervention, elapsed time and total resource use against the simpler baseline. Also inspect maintainability: can the team change one worker without breaking the shared result contract? A faster demonstration is not enough if every prompt update requires debugging the entire network.
For the supplier use case, keep multi-agent research only when it improves the brief under the same review standard. Keep order creation as a separately controlled workflow. See AI-assisted supplier comparisons for the business side and agent permissions and approvals for action boundaries.
Talvyn Labs can assess a single-agent baseline and build the coordination your product actually needs. Bring one workflow with its evidence sources and failure cases. We can test the architecture, define ownership and deliver an AI product whose extra components have a measurable reason to exist.
Build the agent architecture your workflow can justify
Let Talvyn Labs test a single-agent baseline, compare useful task separation and develop a product with explicit state ownership and review boundaries.
Plan and build your agent system