Multi-Agent Collaboration: Capability Upgrade or Complexity Trap?

Multi-agent collaboration is a capability upgrade only when a task genuinely decomposes and the benefit of that split exceeds the cost of communication, coordination, evaluation and debugging. Renaming one agent as four characters — planner, researcher, executor and reviewer — does not automatically improve quality. If they keep retelling the same material to one another, the system has merely used more calls to do one job.

Here, multi-agent means several agents with independent task contexts or tool permissions, assigned work by orchestration rules, exchanging results toward one objective. It is not the visual effect of several participants in a chat, and it is not the same as ordinary program nodes in a fixed pipeline. If the boundary between one agent and conventional automation is still unclear, start with what an AI agent is.

Review the single-agent baseline before the multi-agent proposal

Suppose the task is to produce a supplier assessment: read internal requirements, collect candidate material, compare capabilities and risks, draft a recommendation and verify the evidence. One agent can do this sequentially. A multi-agent design might run candidate research, internal-requirement analysis and risk review separately, then let a coordinator merge them. The second looks more like a team, but whether it is better must be measured on the same task set — not inferred from one attractive demonstration.

The baseline should at least record task success, amount of human revision, elapsed time, total call cost and recovery effort after failure. If one agent already meets the requirement reliably, the multi-agent version must solve a named bottleneck: excessive waiting, contexts contaminating one another, permissions that cannot be isolated, or a recurring class of missed review. Without a baseline, collaboration benefit is usually an architectural impression rather than evidence.

Decomposition can create net value in four situations

The first is independent work that can run in parallel, such as collecting material on several candidates with almost no dependency between them. The second is natural separation of tools or authority: a role reading finance data should not gain external-send permission, while an external-research role need not see internal sensitive material. The third is context isolation, allowing different specialist material to stay in smaller workspaces instead of crowding one agent. The fourth is deliberately independent review, where a checker tests the evidence without inheriting the producer's entire reasoning path.

All four require subproblems with explicit inputs, outputs and completion criteria. If every role continuously needs the whole history and must repeatedly ask its peers what to do, no real boundary has been formed. Also confirm that the work needs an agent rather than a normal function or parallel job in a deterministic pipeline. The determinism test in choosing between an AI workflow and an AI agent applies inside a multi-agent proposal too.

• Parallel value: subproblems can start together, have a clear merge point and materially reduce waiting.
• Specialist value: roles use different evidence, tools or evaluation rules rather than merely different character prompts.
• Isolation value: data and authority narrow by responsibility, reducing the impact of any one role's failure.
• Review value: the checking role can find errors against an independent standard rather than politely echo the producer.

Communication and coordination reclaim part of the gain

Agents cannot rely on the tacit understanding that experienced colleagues use to fill gaps. When one role hands work to another, it compresses key facts into a message. Compression can lose evidence, applicability conditions and unresolved questions; transferring everything consumes context and money. More roles mean more handoffs and more opportunities for the same term to acquire a different meaning at each boundary.

A handoff therefore needs a contract-like structure: task ID, input versions, completed work, conclusion, evidence references, assumptions, uncertainties and permitted next step. The receiver must be able to reject an incomplete delivery rather than guess and continue. Communication cost is not only message length. It includes reruns for clarification, rework after a distorted summary, and coordinator calls spent reconciling incompatible results.

Coordination handles dependencies, timeouts, retries, cancellation and duplicate effects. If two agents edit the candidate list, whose version wins? If upstream times out, may downstream continue? If the coordinator retries, will an external action happen twice? These are distributed task-management problems; calling the participants agents does not remove them. The design needs one authoritative task state, explicit object ownership and version rules. The five memory and state layers of an AI agent help separate shared task state from durable memory and logs.

Evaluation becomes a set of composition problems

For one agent, teams can begin with whether the final task succeeded and then inspect step quality. A multi-agent system adds three evaluation layers: did each role complete its subtask, did each handoff satisfy its contract, and did the composition achieve the end-to-end goal? Improving one research role does not prove system improvement. If it becomes slower, changes format unpredictably or makes the coordinator redo work, a local gain can reduce overall success.

Measure local competence separately from the full journey

Role tests use fixed inputs to check evidence completeness, format and permission boundaries. Handoff tests deliberately omit fields, introduce conflicting versions or create timeouts, and verify that the system stops in the right state. End-to-end tests use a representative task set and compare success, cost, latency, human interventions and recoverability. Do not test only one cooperative path. The approach in writing checkable acceptance criteria for an AI pilot can be extended with explicit collaboration-failure measures.

Evaluation also faces attribution. If the final report misses one issue, did the planner fail to assign it, the researcher fail to find it, the handoff summary drop it, or the merger delete it? A final-answer score says that the system failed but not which component to improve. Each layer needs its own inputs, outputs and validation results so the global score becomes an actionable diagnosis.

Debugging is chain reconstruction, not one prompt edit

A multi-agent failure appears in the final result, while its cause may sit several steps upstream: a planning error omitted a subtask, stale state looked current, a tool exception went unreported, a handoff summary removed a constraint, and the reviewer checked only style. Editing the final role's prompt may conceal the symptom for one input while leaving the original failure ready to recur.

Without end-to-end records, stable reproduction is impossible

Each run needs one identifier spanning parent and child tasks, with role versions, input references, outputs, tool calls, state transitions, retries, approvals and timing. An investigator can then trace backward from the bad result and replay a handoff in isolation. More logging is not automatically better: capture decisions and side effects needed for diagnosis without copying sensitive content indiscriminately into every role.

Permissions add another combinatorial layer. Each role receives only the tools its subtask needs. A coordinator's right to assign work does not imply authority to perform every business action; a reviewer's right to reject does not imply write access to production. Consequential actions still pass through read, generate, modify, execute and external-send controls described in AI agent permission, approval and human-takeover boundaries. Otherwise one bad plan can amplify through several roles' combined authority.

Do not use multiple agents under these conditions

A short, linear task where each step depends on the full context from the previous one is usually better as one agent or a fixed workflow. When every role reads the same material, uses the same tools and applies the same standard, decomposition repeats work. When the final output needs one coherent voice and holistic judgment while sub-results cannot be accepted independently, merging can cost more than specialisation saves.

Also avoid multi-agent architecture when the single-agent baseline has not been tuned, the team cannot define a handoff schema, no end-to-end task set or failure examples exist, latency or cost limits are tight, the platform lacks full-chain state and logs, or high-risk actions have no owner and approval point. Collaboration that cannot be evaluated or debugged is not a stronger system; it is a system whose correctness is harder to establish.

Split one evidenced bottleneck at a time

Selection starts with a short architecture argument, not a cast list. Run one agent on representative tasks and locate the dominant failures. Ask whether clearer tools, retrieval, workflow design or instructions solve them first. Add a role only when the bottleneck genuinely comes from parallel waiting, specialist-context conflict, permission isolation or independent review, then hold the other conditions constant for comparison.

1. Can both subtasks define completion independently and hand off with little back-and-forth communication?
2. Does the new role have genuinely different evidence, tools, authority or evaluation criteria?
3. Which baseline metric should improve, and what caps apply to added calls, latency and operational cost?
4. Are there deterministic rules for incomplete handoffs, timeouts, conflicting results and duplicate execution?
5. Can the team evaluate role, handoff and end-to-end performance separately and locate a responsible step from the records?
6. If the role is removed, does quality or speed fall materially? If not, the role should not remain.

Maturity is not the number of circles on an architecture diagram. It is the ability to explain the net value of every split and remove a role when that value disappears. Make one agent measurable, controllable and debuggable; then let a second role solve a problem already confirmed by evidence. That is much closer to useful enterprise collaboration than starting with the ambition to simulate an AI team.