dooopSoftware · Product · 5 min

When a Product Needs Multiple Agents

Evaluate multiple agents by work boundaries, coordination, and outcome. Compare a simpler alternative before increasing autonomy.

Published on September 6, 2026

CENTRAL THESIS

Naming multiple roles does not demonstrate a need for architecture.

Each agent must assume a verifiable part of the task and justify its coordination.

A product must justify multiple agents by the task and the form of coordination, not by the number of roles it can name. Before dividing the work, describe which parts can progress separately, which decisions require common context, and how the result will be verified. If a simple flow solves the task with the same criteria, the architecture with multiple agents still needs to demonstrate why it deserves to be maintained.

Separate Division of Work and Autonomy

Having different steps does not require each to be an agent. A known sequence can be implemented as a predefined flow. An agent involves dynamic choice of steps and tools during execution.

Anthropic on agent patterns differentiates these arrangements and recommends starting with the simplest solution, adding complexity when necessary. This distinction allows comparing alternatives before distributing the task among multiple autonomous components.

First propose a description without agent names. For example: locate documents, verify their relevance, extract information, and produce a synthesis. Then ask at which points the path needs to be chosen dynamically and where it suffices to apply a known rule or step.

Identify a Work Boundary That Can Be Verified

Division becomes clearer when each part has input, output, and acceptance criteria. If all need to interpret the entire objective and alter the same state, separation may only shift the problem to coordination.

Examine four questions:

Do the parts work on sufficiently distinct data or artifacts?
Can an output be verified before entering the final result?
Is there a rule to resolve contradictory information?
Is it defined who can alter the shared state?

These questions are design criteria, not a universal formula for choosing architecture. A weak answer indicates which dependency needs to be understood before increasing autonomy.

Describe Coordination as Part of the Product

An architecture with multiple agents needs to specify who distributes work, how results are received, when a retry is requested, and under what condition the task ends. "The agents talk to each other" does not define sufficient operational behavior.

Also record how execution reacts to delay, incomplete response, or disagreement. It may be necessary to proceed with partial results, request human review, restrict action, or interrupt. The alternative depends on the task and the effect on the user.

Include coordination in observation. Count attempts, calls, context transfers, and reviews needed to reach the result. Do not compare only the time of an isolated step if the user expects the complete task.

Fictional Example: Preparing a Document Synthesis

Imagine a product that helps a team prepare a synthesis of project documents. One proposal distributes document groups to separate components and gathers the extractions into a final text. Another uses a single flow that processes the groups sequentially.

The evaluation must verify if relevant documents were considered, if contradictions were made visible, and if the synthesis preserved the origin of the information. Division by groups can be a useful hypothesis when parts can be verified separately. It does not prove by itself that autonomous agents will be necessary.

If each part interprets terms differently, coordination must handle this. If the final result hides divergences, the problem was not solved just because all steps finished. The example illustrates what to compare without assuming gains in speed or quality.

Compare with a Simpler Alternative

Use the same task and criteria to examine a predefined flow, a single agent, or the proposed composition. Document which adjustments belong to each alternative and which conditions were maintained.

Microsoft ExP describes experimentation as a way to validate hypotheses, measure impact, and iterate products. Here, the hypothesis may be that division improves a specific behavior without worsening important operational conditions. Define this behavior before comparison.

Observe if coordination helps solve a real need or only creates more handoffs. If the main problem is context quality, multiplying participants does not eliminate the need to correct this information. If it is the success criterion, distribute that criterion clearly before distributing execution.

Define When to Reduce or Abandon the Composition

An architecture decision should include conditions for review. Consider reducing the composition when parts no longer have clear boundaries, coordination requires frequent interventions, or the simpler alternative meets the same criteria with more understandable operation.

It is not necessary to remove all components at once. One step can remain specialized but follow a fixed flow. Another can remain assisted by a person. The change should preserve expected behavior and be evaluated as a whole.

Before adding another agent, write which verifiable part of the task it will assume and which coordination decision it will simplify. If the justification ends only in the role name, return to the task description and compare a smaller design.

If you want to discuss this decision in the context of your company, talk to dooop.

Sources

To Continue This Reading

How to Design Human Approval Within an AI Product

NEXT DECISION

Discussing Application in the Company

Conversation about the software company context

Content by dooop. Registration allows linking this topic to the reader's journey and tracking interest in the subject.