Do not start with roles

When people design multi-agent systems, the first instinct is often role assignment: planning Agent, retrieval Agent, writing Agent, review Agent, execution Agent. It looks like a complete team, but in practice more roles often create more disorder.

The real problem is usually not weak model capability. It is that the architecture cuts apart context that needs continuous understanding. Each Agent receives only local information, makes locally reasonable judgments, and the merged result loses the main thread.

The design unit of a multi-agent system should not be the role. It should be the context. Roles are surface labels; what matters is how information flows, how state is shared, and how conclusions are merged.

Why splitting often breaks the system

Complex tasks are not naturally divisible. Some tasks contain many steps but depend on one continuous thread, such as opinion writing, system architecture, complex bug analysis, and product planning.

Splitting too early creates three problems: the main thread is cut, information is lost in transfer, and collaboration creates noise. A sub-Agent may complete a local task without understanding the overall intent; after context is summarized twice, key constraints may already be gone.

Agent splitting is not a free upgrade. It reduces context pressure inside one Agent, but increases communication, synchronization, merging, and consistency costs.

The real test is context dependency

The key question is not whether the task is complex. It is whether the subtasks need shared context.

Low-context-dependency tasks are good candidates for splitting: summarizing separate articles, checking separate files, retrieving evidence from different sources, or producing independent judgments. They can run in isolation and return compressed conclusions.

High-context-dependency tasks cannot be split casually. System design, long-form writing, refactoring decisions, and multi-step diagnosis require continuous goals, constraints, and judgment criteria. If they are split, they need shared state, not simple dispatch and collection.

Single Agent, Sub-Agent, and Agent Team

A Single Agent fits tasks with a strong main thread and continuous context. If it can complete the task reliably, splitting only to look advanced is a mistake.

A Sub-Agent fits tasks that are isolated, parallelizable, and only need to return conclusions. The main Agent owns the goal and thread; the sub-Agent handles a bounded local job.

An Agent Team fits tasks that require shared state and ongoing collaboration. It is not just a group discussion. It is a more complex shared-context system with state synchronization, conflict handling, and final arbitration.

The real cost of multi-agent systems

The hard part of multi-agent architecture is not making multiple Agents work at once. It is controlling the side effects between them.

Context transfer is not lossless. The main Agent cannot send everything to every sub-Agent, and a sub-Agent cannot return its entire reasoning process. The system must know what can be compressed and what must be preserved.

Collaboration can also create noise. If boundaries are vague, Agents repeat the same discussion, contradict one another, and produce many similar ideas. State inconsistency is worse: one Agent uses old constraints, another uses new constraints, and the system splits apart.

Final Thoughts

The real problem in multi-agent architecture is not role division. It is context-boundary design.

Weak multi-agent design starts with roles: who plans, who writes, who reviews. Strong multi-agent design starts with context: what must remain continuous, what can be isolated, what state must be shared, and what result only needs summarizing.

The final question is not “how many Agents does this task need?” It is “how should this task context be shared, isolated, compressed, transferred, and merged?” That is the line between a toy multi-agent demo and an engineering system.