Harnessing a Swarm, Through One Tool

UniSwarm follows a centralized orchestration design. One main agent plans and coordinates the workflow; a swarm of sub-agents carries out the delegated work. The two roles are cleanly separated.

This centralization is deliberate, not merely for simplicity, but for error control. Every sub-agent result flows back through the main agent, which serves as a single validation bottleneck: it verifies, reconciles, and filters findings before they can influence the final synthesis. No sub-agent output reaches the answer unchecked. Recent work on scaling agent systems points the same way, architectures without centralized verification propagate errors more readily than those with centralized coordination (Kim et al., 2025).

The main agent's job is decision, not execution: how to decompose the problem, which sub-agents to assign, what each should do, and how their results should be interpreted and integrated, with increasing precision across rounds. The sub-agents provide the capability. Each has web search (search), page visits (visit), Google Scholar (google_scholar), and a stateless Python interpreter (python_interpreter). Depending on its assignment, a sub-agent may investigate a topic, gather evidence, verify a claim, reproduce a calculation, critique an earlier result, or synthesize a line of reasoning, then return.

Methodology

Every design decision serves one of two goals, and usually both: keep the main agent's job small, and give each sub-agent enough context to act well. The main agent should not spend capacity picking tools or restating context it already holds. The sub-agent should never have to guess what it is part of or what its answer should rest on.

The orchestration model

A run starts from the user's question. At each step the main agent does one of two things: dispatch a batch of sub-agents, or emit a final answer and stop. Work proceeds in rounds, and each round is a single swarm_run call. A round carries an optional shared context and a list of sub-agent specifications; a specification is a unique id, the task, an optional role override, and an optional list of dependencies.

A single tool for every mode of work

A controller with many tools spends real capacity deciding which one to use, overhead that does not advance the problem. The main agent therefore has exactly one tool. Independent work, dependent work, verification, and integration all run through it. There is no separate tool and no mode flag: intent is expressed through how many sub-agents are spawned, what each is asked to do, and which ones are wired together.

// common case: a sub-agent is an id + a task
swarm_run({
  shared_context: "…",     // shared batch background
  agents: [
    { agent_id: "…",       // unique across the run
      task: "…",           // what this agent does
      system_prompt: "…",  // optional role override
      depends_on: ["…"] }  // the only behavioral switch
  ]
})

One optional field, depends_on, is the entire difference between independent and dependent work. With it, the sub-agent builds on prior results; without it, it runs on its own. The tool itself does not change.

Passing context by reference

The context model follows from one observation about model behavior. Take a common situation: a sub-agent returns a long report, often more than 8k tokens, and a later sub-agent needs it, say to verify it. Passing that report by value fails in two ways.

This layout is how each sub-agent's user prompt is assembled, in a fixed order, with each part present only when set. The system prompt is a separate, independent part that carries the sub-agent's role and tool-use rules:

Reference resolution is strict: ["*"] inherits every completed, successful sub-agent, the natural form for a final integrator. A reference to an unknown agent is rejected; a reference to a failed agent is rejected too, since downstream work should not build on a failure. The same ids that make context cheap to move also lay down an explicit propagation chain between sub-agents, giving the orchestration a more structured form.

Shared context, stated once

shared_context complements depends_on and follows the same principle: the main agent should not write the same context twice. Background common to the batch, established facts, constraints, the scenario, is stated once and injected into every sub-agent. It is not limited to fixed setup: as the run advances, the main agent can place into it what has already been established and the stage the work has reached, so each new batch starts from the current state instead of from scratch.

Cooperation, competition, and their hybrid

Neither cooperation nor competition is a separate mode; both are patterns of how sub-agents are dispatched and wired.

None of this is a fixed recipe. The main agent composes these patterns freely, over as many rounds as the problem needs, and revises the plan as results come in. The verification patterns are just dispatch patterns too, evidence → draft → review → revision; deriving a quantity two ways and reconciling them; a red-team sub-agent tasked only with breaking a conclusion, followed by a referee; a shallow pass to map the terrain, then deeper sub-agents aimed at the weak spots. Only the wiring changes.

Failure semantics

Sub-agents fail independently. A malformed specification produces an error result on its own, and the rest of the batch runs to completion. A sub-agent that crashes or exhausts its turn budget is marked failed rather than allowed to abort the round. A single bad sub-agent never brings down the call.

Swarm Training

The methodology defines an interface. A model still has to learn to use it well: when to decompose, how many competitors to run, which results to trust, when to stop. We teach this with agentic supervised fine-tuning on trajectories the swarm produces when driven by a strong model.

Collecting agent trajectories, the swarm as a data amplifier

We run the full swarm with a strong reasoning model (DeepSeek-V4-Pro) driving both roles, on 4,000 hard research questions drawn from UniScientist (UniPat AI, 2026), sampled uniformly across physics, chemistry, biology, and mathematics. Each run produces two kinds of trajectory:

This makes the swarm an unusually data-efficient source of supervision. A single question expands into one orchestration trajectory plus many research trajectories, each a distinct subproblem. A modest pool of questions produces a large and diverse training set, and the multiplier is highest on hard, decomposable problems, exactly the ones where good trajectories are otherwise scarce.

Rejection sampling

The collected trajectories are not all worth learning from. We filter on two axes before training.

What survives is a pool of clean, correct trajectories, main and sub together.

Mixing roles: multi-task agentic SFT

At inference the same base model plays both roles; the role is selected by the system prompt. Because one model serves both, we train it on both distributions at once, main and sub trajectories pooled and fine-tuned together, as a single multi-task objective.

The two roles pair naturally. Orchestration and research share a substrate, decompose, delegate, gather evidence, verify, integrate. Training them together lets that substrate reinforce from both directions, while the system prompt keeps the tool interfaces distinct. The result is one model that can both orchestrate the swarm and serve as its sub-agents.

Results

We evaluate UniSwarm on four benchmark suites: FrontierScience (Olympiad and Research tracks; Wang et al., 2026), DeepResearch Bench II (Li et al., 2026), ResearchRubrics (Sharma et al., 2025), and Humanity's Last Exam (Phan et al., 2025). Only FrontierScience-Research is in-distribution; the others are out-of-distribution and measure how well the learned orchestration transfers. On FrontierScience, every baseline uses the same four-tool deep-research design as UniSwarm and runs at maximum thinking effort. "Aggr@4" combines four independent runs into one answer (UniPat AI, 2026), a parallel-thinking form of test-time scaling applied on top of the swarm. On Humanity's Last Exam, all models run with tools; DeepSeek-V4-Pro and UniSwarm-35B-A3B are evaluated on the text subset while the others use the full set, and Claude-Fable-5 additionally runs with fallback.

Case Studies

Two case studies, both live and fully expandable. Each collapses to a compact card; open it for the round-by-round orchestration flow, zoomable, with every node drilling down into the agent's real reasoning, tool calls, and outputs, alongside the problem and its rubric-based score.

Swarm as a Test-Time-Scaling Axis

Test-time scaling has become one of the most important levers for improving model performance, and the swarm is another efficient axis along which to apply it. It is best understood alongside parallel thinking, the more familiar form.

Parallel thinking scales at the global level of a task: the model produces several independent attempts at the whole problem and selects or aggregates among them. The swarm scales at the local level: within a single attempt, the hard subproblems are dispatched to many sub-agents that investigate, compute, and cross-check in parallel, and the main agent integrates what they return.

The two are complementary rather than competing. Global parallel thinking widens the search over whole-task strategies; local swarm scaling deepens the work on the difficult parts of each strategy. Because they act at different levels, their effects compose, running a swarm within each parallel-thinking branch stacks the two, and can push the scaling curve further than either axis alone. UniSwarm's Aggr@4 result is exactly this stacking in action.

Aggregation in action: four swarms, one better report

Here the two axes stack. The same problem is handed to four independent swarms; each produces a full report and is scored on its own rubric. The individual scores split around 0.7, two runs above and two below, yet a single synthesis pass merges all four into one report that scores higher than any run alone. Open any node to drill into that swarm's trajectory; the graph scrolls sideways for the full set.

A Broader Principle: Simple Interface, Broad Function

The single tool is one instance of a wider principle: keep the tool interface narrow, and let it map onto broad function. Narrow is not the same as limited, it means the surface the model calls through is small, while the function reachable behind it stays wide.

In practice the better question is not which tool to add, but how to abstract broader function behind the tools already present, without growing the count, and sometimes by shrinking it. That is how reach is balanced against the difficulty of use.

Acknowledgement

@misc{unipat2026uniswarm,
 title  = {UniSwarm: Unified Agent Swarming for Harnessing Collective Intelligence},
 author = {UniPat AI},
 year  = {2026},
 url   = {https://unipat.ai/blog/UniSwarm}
}