Single-Agent or Multi-Agent: Choose the Architecture from the Business Route
A multi-agent system is not inherently more capable than one well-designed agent. It divides context, tools and responsibility across additional components, which creates new handoffs and failure paths. The added architecture is justified only when a specific separation of expertise, authority or execution improves a business outcome enough to outweigh the cost of coordination.
Define the responsibility before counting agents
Architecture should follow the business route. The team must first identify the completed outcome, the decisions required to reach it and the person accountable when a case stalls or causes harm. These facts show whether one component can retain responsibility or whether the route contains genuinely separate areas of ownership.
Agent names do not establish that separation. Calling components a researcher, planner and reviewer may make a diagram appear orderly, but all three may use the same evidence and permissions to reach one decision. In that case, additional agents can duplicate context and obscure who owns the final result without adding a distinct capability.
Establish what one agent can do
A single agent can use several tools, consult different knowledge sources and complete multiple steps while retaining one case context. This design reduces transfers and makes the route easier to trace. It is often the strongest starting point when one operating owner controls the outcome and one permission boundary covers the required actions.
The team should test that baseline before adding specialists. If the agent fails, the trace must show why. A missing tool, poor retrieval, an unclear instruction or an unreliable source requires a direct repair. Creating another agent would move the same defect behind an additional interface.
Separate specialists when their boundaries are real
Some routes contain responsibilities that should remain separate. A specialist may need distinct instructions, evidence, credentials or evaluation because it performs a different professional or operational role. The separation can prevent one broad agent from receiving permissions that only part of the route requires.
However, the design must state what the specialist contributes that the main agent cannot provide safely or reliably. It should name the input the specialist receives, the output it returns, the action it may take and the component that checks its work. Without that contract, specialisation becomes a label rather than an operating control.
Keep one manager when the outcome has one owner
A manager pattern allows one agent to retain the case and call specialists as bounded tools. This design suits a route in which different analyses support one final decision. The manager decides which specialist to call, checks whether the returned evidence answers the request and combines the findings into the completed result.
The manager does not make weak specialist output reliable merely by summarising it. Each specialist still needs an explicit contract and suitable tests. The workflow also needs a rule for disagreement, missing evidence and repeated calls; otherwise, the manager can conceal uncertainty or create an expensive loop.
Use a handoff only when ownership should transfer
A handoff gives the next agent control of the active case or conversation. That pattern is appropriate when a specialist must apply different policy, use a different authority or communicate directly within its own service boundary. The transfer should state why it occurred, which evidence follows the case and what condition completes or returns it.
Ambiguous handoffs create practical failures. Two agents may refer the case to each other, a specialist may receive incomplete history or both may assume that the other agent will complete the final action. A handoff design therefore needs one accountable owner at every stage and a recovery route when the intended recipient cannot proceed.
Use parallel execution only for independent tasks
Parallel agents can shorten elapsed time when separate investigations do not depend on each other's intermediate findings. They can also produce independent assessments when management wants to compare perspectives. The benefit disappears when agents repeatedly wait for, revise or overwrite each other's work.
Before introducing parallel execution, the team should define a common input, a completion condition and a merge rule. It must also decide how to resolve contradictory results and prevent simultaneous writes to the same business record. These controls turn faster component execution into a reliable completed outcome.
Preserve deterministic control where the rule is fixed
Mandatory sequences, financial limits, approval requirements, retries and transaction writes should remain in code or a workflow engine when the rule is known. An agent can interpret variable evidence or choose among approved routes without controlling every transition. This division limits the decisions that depend on model judgement.
As a result, the relevant comparison is broader than one agent versus several agents. A dependable architecture may combine deterministic orchestration, one agent, specialist model calls and human approval. Each component should receive only the discretion needed for its part of the route.
Treat context and state as a transfer contract
Every additional agent creates a boundary across which evidence and state must pass. Sending the complete history can expose unnecessary information and overwhelm the receiving specialist. Sending too little can remove the assumptions, approvals or earlier findings needed to act correctly.
The transfer contract should identify the case, task, relevant evidence, source references, permissions, prior decisions, unresolved questions and expected return. The workflow should preserve this state independently of any one model conversation. That record allows the organisation to reconstruct a decision when an agent fails or a case resumes later.
Compare architectures on the same cases
The team should run representative cases through the simplest viable architectures. It should compare verified completion, material errors, human correction, elapsed time, model and tool cost, traceability and recovery. For a multi-agent design, the evaluation must also detect incorrect routing, lost context, inconsistent conclusions, loops and duplicated actions.
An additional agent earns its place only when it corrects a named limitation and improves the completed route under realistic conditions. A small gain in answer quality may not justify higher latency, fragmented accountability or more difficult incident reconstruction. The decision should use the operating result rather than the apparent sophistication of the design.
Apply the choice to an equipment-maintenance case
Consider a manufacturer that wants an agentic workflow to prepare maintenance action for a reported equipment fault. One agent may be sufficient if it can retrieve the asset identity, alarm history, maintenance record and approved troubleshooting procedure, then prepare a recommendation for an engineer. The route has one owner, and the engineer retains isolation and repair authority.
Suppose some faults require an independent safety assessment before the maintenance plan can proceed. A safety specialist with separate evidence, instructions and permissions may then be justified. The main agent can retain the case, call the specialist and prevent further action until the safety result meets a defined condition. A handoff would be appropriate only if the safety function must take control of the case under the organisation's operating rules.
Parallel agents could inspect unrelated evidence, such as vibration history and spare-part availability, if neither changes the other's analysis. A deterministic workflow should still enforce isolation approval, work-order status and transaction writes. Evaluation can then compare one-agent and multi-agent designs on correct fault routing, evidence completeness, unsafe recommendations, elapsed time, cost and recovery from unavailable systems.
Record why every agent exists
The architecture decision should identify the owner of the completed outcome and the reason for each agent. For every specialist, it should record the distinct boundary, input, output, tools, permissions, validation rule, failure route and expected benefit. This record allows reviewers to challenge complexity before it becomes an operating burden.
Marketways helps clients decompose the business route, establish the single-agent baseline and test whether additional specialists improve the outcome. The result is an architecture in which every agent has a defensible purpose and every transfer preserves ownership, evidence and control.