Emerging Multi‑Agent Trends: From Agent Teams to Swarms for Creative Discovery

Agent Forms and Taxonomies

Two complementary taxonomies are used to describe multi‑agent systems.

LangGraph topology : Network, Supervisor, Sub‑agent‑as‑tool, Hierarchical, Custom. The taxonomy is defined by the direction of message flow and which component decides the next step.

Kimi collaboration style : Single, Network, Supervisor, Sub‑agent‑as‑tool, Hierarchical, Custom. It focuses on the role each participant plays in the workflow.

The essential difference between Network and Hierarchical is who has authority to schedule the next action; Custom mixes static and dynamic authority.

How Agents Coordinate (Context Engineering)

Evomap experiment compared three coordination patterns on the same 563 benchmark questions using Claude Haiku 4.5:

Single‑context (one LLM processes all questions in a single long context): 26.29 % accuracy .

Sub‑Agent mode (a coordinator splits the questions, sub‑agents report in natural language, the coordinator re‑reads the reports): 38.54 % accuracy .

EvoX Swarm (each question is handled by an isolated agent; a script aggregates the answers without any LLM re‑reading): 70.69 %–70.87 % accuracy .

The 32‑point jump from Sub‑Agent to Swarm is attributed to the loss of information when the coordinator re‑interprets the sub‑agent reports – a “lossy compression” step that the swarm avoids by letting a program collect the results directly.

A second Evomap study let agents choose partners based on visible information. Coefficients measured from a statistical model show:

When only social links are visible, agents strongly prefer familiar neighbors (+2.28).

When expertise scores and accuracy are also visible, the preference for neighbors drops to near zero, while agents favor high‑accuracy (+1.88) and complementary expertise (+1.47) partners.

These results demonstrate that the observable data directly shapes the emergent collaboration graph.

Cost Breakdown

Three additional costs are identified when scaling agents:

Handover cost : Re‑packaging information between agents, often via files.

Sharing cost : Every agent must re‑process the shared context, inflating token usage.

Aggregation cost : Merging many partial outputs into a coherent final answer is expensive and error‑prone.

The “Cost of Consensus” study reports that naïve parallelism can increase token consumption by 2.1–3.4× without improving accuracy, especially for “same‑opinion” debates where agents merely echo each other.

Training Agents into the Model (PARL)

Kimi’s PARL (Parallel‑Agent Reinforcement Learning) trains only the orchestrator while freezing a checkpoint‑derived sub‑agent. This avoids credit‑assignment problems and stabilises training. Three reward components guide learning: r_perf: Task performance. r_parallel: Direct reward for spawning sub‑agents, counter‑acting “serial collapse” (the tendency of the orchestrator to fall back to a single‑agent solution). r_finish: Reward for completing spawned sub‑tasks, preventing “spurious parallelism” where the orchestrator creates useless agents just to increase the parallelism metric.

During training the parallelism bonuses are annealed to zero; the model must retain parallel behaviour after the incentives disappear, proving that it learned a genuine efficiency advantage rather than merely chasing a reward.

PARL introduces the metric critical steps , which counts the orchestrator’s decision step plus the longest‑running sub‑agent per round. Optimising critical steps focuses on the critical path rather than raw parallelism.

Benchmark results (compared to the same K2.5 model without PARL) show:

BrowseComp (deep search) accuracy ↑ 60.6 % → 78.4 %.

WideSearch (broad retrieval) Item‑F1 ↑ 72.7 % → 79.0 %.

Custom Swarm Bench ↑ 41.6 % → 58.3 %.

Speed gains are reported as 3–4.5× less time to reach the same quality target, especially on harder tasks where parallelism yields larger savings.

Turning Scale into Intelligence

Claude Code Modalities

Claude Code offers three complementary ways to organise agents:

Subagents : A main session spawns a fixed‑function sub‑agent (e.g., explorer, worker, default). Each subagent runs in its own context; the main session aggregates the final results. Scaling beyond a few dozen subagents quickly exhausts the model’s context window.

Agent Teams : A preview feature where multiple “teammates” share a common task list, can claim tasks, and communicate directly via a mailbox (JSON files under ~/.claude/teams/{team‑name}/inboxes/). The lead session can request a plan from each teammate and approve or reject it. The system is limited to 3–5 teammates (the documentation recommends “three focused teammates often beat five scattered ones”).

Dynamic Workflows : Users write a JavaScript‑style workflow that calls agent() or pipeline(). The workflow script performs the orchestration; intermediate results stay in script variables, not in Claude’s context. The runtime enforces a hard limit of 16 concurrent agents (configurable to 5 or 50) and a soft limit of 1 000 agents per run. A “large workflow” warning appears when token usage exceeds ~1.5 M, but execution continues.

Cursor Architecture for Large‑Scale Code Editing

Cursor experimented with four successive architectures to let thousands of agents edit a real repository:

All agents read/write a shared coordination file protected by a lock. The model does not understand locks, causing severe contention and most agents idling.

Introduce explicit roles – planner, executor, worker, judge – with a central executor that schedules workers and a judge that validates results. The executor became a bottleneck because the slowest worker blocked the whole round.

Remove the separate planner; let the executor also plan. The executor exhibited pathological behaviours (random sleeping, dropping tasks, premature termination) because it was overloaded with responsibilities.

Final version – recursive planner : A root planner owns the full scope, spawns sub‑planners on demand, and each leaf worker operates on an isolated clone of the repository. Workers never communicate with each other; they write a handoff file that is later merged into Git. A neutral arbitration agent resolves merge conflicts.

Conflict statistics improved dramatically: an early run generated >70 000 merge conflicts in two hours; after the final architecture the same workload produced <1 000 conflicts in four hours, and the hottest file’s conflict count dropped from 7 771 to 47.

Apodex Verification Pipeline (Heavy‑Duty Mode)

Apodex (formerly MiroMind) builds a three‑stage pipeline:

Orchestrator splits the problem into sub‑tasks.

Sub‑agents (specialised workers) execute the sub‑tasks on isolated clones.

Global verifier receives the assembled evidence graph, checks consistency, and can reject the answer if the evidence is insufficient.

In heavy‑duty mode up to 150 agents can run 15 000 steps. The global verifier is a separate component that can say “no” and forces the system to redo or augment the evidence. This design yields large quality jumps (e.g., BrowseComp from 75.5 % to 90.3 %; FrontierScience‑Research from 28.3 % to 46.7 %).

DeepMind AlphaProof Nexus

AlphaProof Nexus combines three orthogonal techniques:

Parallel proof generation by a pool of Gemini 3.1 Pro agents.

External reinforcement‑learned prover “AlphaProof” that fills missing proof steps.

Elo‑based ranking of proof sketches, where a pairwise tournament selects the most promising sketches for further refinement.

Four configurations were tested (A‑D). Only the most powerful configuration (D = parallel agents + AlphaProof + Elo ranking) solved nine long‑standing mathematical conjectures, including two Erdős problems unsolved for 56 years. The compute cost per problem was a few hundred dollars.

MiniMax Agent Team Engine

MiniMax structures a long‑running task as a pipeline:

Leader creates a plan (a “Plan” object) and sends it to a deterministic Team Engine .

The engine batches sub‑tasks, dispatches them to Workers , and attaches a Verifier to each worker (a built‑in adversarial component analogous to QA).

Workers retry failed sub‑tasks until the verifier returns PASS, then the engine aggregates the results into a CycleReport for the leader.

The engine enforces max_concurrency (max parallel workers per batch) and max_cycles (max retry rounds). The leader can intervene on any cycle, override decisions, or manually retry high‑risk tasks.

Key Takeaways

The hardest problem in large‑scale multi‑agent systems is merging the outputs reliably, not merely spawning many agents.

Deterministic scheduling, batch orchestration, and conflict resolution should be performed outside the LLM (state machines, scripts, or dedicated arbitration agents).

Non‑LLM verifiers (compilers, Lean provers, external adjudicators) at the end of the pipeline are essential to prevent error amplification as agent counts grow.

When the verification step is external and authoritative, scaling agents yields genuine quality gains (e.g., Evomap’s 44 % gain, Cursor’s conflict reduction, Apodex’s heavy‑duty accuracy jumps).