When a Single Agent Becomes a Team: Roles, Handoffs, and Shared Work
For JiuwenSwarm, Agent Team answers a specific coordination problem: what should happen when a goal contains several kinds of work that one agent would have to perform in sequence or from conflicting perspectives? This chapter focuses on the change from one governed execution loop to a Leader coordinating specialized teammates. The practical result is not simply more model calls; it is a way to decide whether specialization, parallelism, and explicit handoffs justify the extra coordination they require.
A team is a change in topology, not a larger agent
A single agent is a reasonable fit for a direct question, a one-step action, or a task with no meaningful division of labor. Agent Team is intended for work with several phases, distinct roles, parallelizable parts, or multiple rounds of refinement. The difference is structural. One agent owns the whole trajectory. A team distributes responsibility and then has to bring the pieces back together.
Consider a request to research an industry and produce a report. One agent could gather information, analyze competitors, identify technology trends, write the report, and proofread it. That may be adequate for a small assignment. For a substantial report, however, those activities have different success conditions. Research needs coverage and source judgment. Analysis needs comparison and interpretation. Writing needs structure and readable synthesis. Review needs distance from the draft. Asking one agent to play every role can make the work serial and can cause each perspective to converge on the same initial assumptions.
JiuwenSwarm's documentation frames Agent Team as coordination engineering: the important design question is how work is divided, how results move, and how the team keeps advancing. That framing also limits the claim. A team does not automatically improve quality because it contains more agents. If subtasks are tightly coupled, if their results cannot be integrated, or if the coordination overhead exceeds the work itself, a single loop may be the better design.
A useful test is to ask four questions. Does the task have multiple phases? Do those phases require genuinely different expertise or viewpoints? Can at least some work proceed independently? Does the result need iteration or cross-checking? The more clearly the answer is yes, the stronger the case for a team. A simple request with no role boundary is unlikely to benefit from one.
The Leader owns the shape of the work
Agent Team divides responsibility between a Leader and teammates. The Leader receives the user's goal, interprets its core need, maps the phases, estimates which roles are required, forms the team, assigns tasks, monitors progress, makes important decisions, and consolidates the result. Teammates claim work that matches their role, execute within the assigned scope, escalate when blocked, submit intermediate artifacts, and report outcomes back.
This is not the same as a user manually invoking several agents one by one. The user states the goal; the team runtime coordinates the workflow. The Leader is not merely a front-end label for the first agent in the chain. The Leader owns the relationships among tasks and is accountable for deciding when the combined output is complete enough to deliver.
That ownership makes handoffs explicit. A teammate's result is not valuable only because it is correct in isolation. It must also be legible to the next participant: what question was answered, what evidence supports it, what remains uncertain, and what the downstream task should do with it. The Leader's consolidation work is therefore a form of interface management. It turns specialized outputs into a deliverable whose parts still fit together.
The distinction between coordination and execution matters when a task fails. If a teammate cannot complete an assigned task, the failure may require an escalation or a new assignment. If two teammates reach incompatible conclusions, the Leader must identify the disagreement rather than silently average it away. If the Leader decomposes the goal poorly, excellent teammate work can still produce an incomplete result. The team structure makes these failure surfaces visible, but it does not eliminate them.
Dependencies determine whether parallelism is real
Agent Team supports prerequisite, dependent, and parallel relationships among tasks. These terms describe timing and information flow, not just labels on a task list.
A prerequisite must finish before a dependent task can start. In a research-to-report workflow, initial evidence gathering may precede analysis because the analyst needs the collected material. A dependent task waits for the output of another stage. Parallel tasks have no blocking dependency and can proceed at the same time, such as two analysts examining different aspects of a topic from the same starting materials.
The distinction is important because “multi-agent” does not mean “everything happens concurrently.” Parallelism is useful only where the inputs are sufficiently independent and the integration point is clear. If two tasks edit the same artifact without a conflict strategy, concurrency can create more work than it saves. If a writing stage depends on a conclusion that has not been settled, starting it early may produce a draft that must be discarded. A team runtime can unlock downstream work when task status changes, but the underlying dependency still determines whether the next stage has enough information to be meaningful.
The intended flow is therefore closer to a directed process than to a crowd of independent chat windows:
The diagram shows the logical handoff. It does not claim that every task has three teammates or that all three branches are parallel in every run. The dependency decision belongs to the particular goal. What matters is that the Leader can express which outputs are prerequisites, which work can proceed independently, and where the final integration occurs.
A dependency is more than a scheduling instruction. It defines what the downstream participant is entitled to assume. If an analyst receives a completed research packet, the packet should make clear which questions were investigated and which evidence remains missing. If a reviewer receives a draft, the reviewer needs to know whether they are checking factual coverage, logical consistency, presentation, or all three. Without that contract, the runtime may start the right role at the right time and still produce a weak handoff.
This is why the Leader's consolidation role cannot be reduced to joining files. The Leader must compare outputs against the original goal, notice when a prerequisite is technically marked complete but substantively inadequate, and decide whether to request more work. A task status can unlock the next stage, but the meaning of the result still depends on the quality gate attached to that stage. Event-driven progress is useful only when the events carry enough information for the next decision.
The same reasoning explains why visibility boundaries matter. When a task calls for independent checking, keeping evaluations separate until the Leader can compare the reports may preserve that independence; whether it improves the result still depends on the task and the quality of integration. Conversely, isolating every teammate can be wasteful when the task requires tight joint editing. The appropriate visibility boundary follows the task's error pattern, not a universal rule about collaboration.
Shared work does not erase private work
The team needs a place where intermediate results can accumulate. JiuwenSwarm describes a shared team workspace for research outputs, analysis data, drafts, documents, and task status. Each member also has a private workspace for configuration, memory, todos, and other agent-specific state. Messages and task records connect these spaces by communicating assignments, progress, and results.
This separation serves two purposes. First, it reduces duplication: a later stage can use a prior artifact instead of asking another teammate to reproduce it. Second, it preserves ownership boundaries. A member's private state is not automatically the same thing as a team artifact, and a message reporting a result is not identical to exposing every intermediate thought or local file.
Users can observe the team through task progress, member status, intermediate artifacts, and consolidated results. That visibility changes the relationship between automation and oversight. A user does not need to direct every subtask, but they can inspect whether work is moving, whether a member is blocked, and whether the final result reflects the intermediate evidence. In a long-running workflow, this traceability is part of the product value, not merely a debugging convenience.
The lifecycle of the team also affects background work. A paused session can pause associated SwarmFlow workflows while preserving resumable progress. Switching sessions can clean up running resources while keeping the progress record available for later resumption. Closing a browser tab does not necessarily stop the team. These behaviors reinforce the idea that a Team is a runtime object with state, not a temporary collection of prompts visible only while a page is open.
There is a corresponding boundary: the documentation's logical shared workspace should not be mistaken for a guarantee that all machines see the same physical directory. Local and distributed deployments have different storage semantics, and that distinction becomes central when teammates run in separate processes or hosts. A shared artifact must be shared through a mechanism that the deployment actually makes visible, or it must be returned through messages, database state, or another explicit transfer path.
A research report as a concrete pattern
The repository uses deep research and report writing as a representative Agent Team task. The Leader breaks the request into phases such as industry overview, competitive landscape, technology trends, market outlook, and writing. It assigns specialized roles, lets teammates execute their portions, and then merges the outputs into a final report with status checks and figures or charts where available.
The example is valuable because it shows why the roles exist. An industry analyst and a technology analyst may need different search questions. A market analyst can work independently on outlook while other members investigate vendors or technical trends. A writing lead can integrate the results after the evidence has been organized. The collaboration is not useful because the word “team” sounds sophisticated; it is useful because the work has separable questions and a non-trivial integration step.
The same example also exposes the limits of the evidence. It demonstrates the intended decomposition pattern, not a controlled comparison with a single agent. The repository does not provide independent measurements of report accuracy, throughput, cost, or user satisfaction for the example. A team can parallelize research and still miss a source, misinterpret evidence, or integrate incompatible assumptions. The right conclusion is that Agent Team offers a structure for handling those risks, not that the structure guarantees their absence.
This distinction is especially important in high-stakes domains. The repository also presents a medical-consultation Swarm Skill as an example of parallel specialist opinions and coordinator integration. That illustrates how disagreement can be surfaced and organized, but it is not independent clinical validation. A reader should transfer the collaboration pattern—specialize, compare, record disagreement, integrate with boundaries—not treat an illustrative report as professional advice.
The cost of adding roles
Agent Team creates value when the task's structure can absorb coordination. It also creates costs that a single-agent run may avoid. The Leader must spend effort interpreting the goal and managing tasks. Teammates need enough shared context to work effectively but not so much that every prompt becomes bloated. Intermediate artifacts need schemas or conventions that make them usable downstream. The final integrator must resolve omissions and disagreements rather than simply concatenate text.
Parallelism can introduce synchronization points. More roles can mean more waiting at the integration boundary. A persistent team can accumulate useful experience, but it also needs rules for memory ownership and cleanup. A visible workflow can improve oversight, but it can expose confusing intermediate states if the user does not know which result is authoritative. These are system-level trade-offs, not reasons to reject teams; they are the conditions under which a team succeeds.
The most reliable mental model is therefore not “many agents are better than one.” It is “a team is justified when the coordination interface is clearer than the work would be inside one undifferentiated loop.” Once that interface exists, the next question is what the team should remember, who may write shared lessons, and how continuity can survive a round without erasing member boundaries.