ArcticSwarm: Multi-Agent Research Architecture

• ArcticSwarm is a multi-agent research architecture that separates evidence gathering from evidence integration through access-controlled communication, task-level isolation, structured review, and delayed commitment, thereby mitigating premature consensus and unproductive information exchange across agents.
• The architecture involves the creation of a Bulletin Board System (BBS) where findings are aggregated, reviewed, and filtered according to specific commitment boundaries, ensuring that answers are chosen from a greater pool of independent evidence while utilising reviewers to challenge and validate the hypotheses.
• Empirical results on the BrowseComp-Plus benchmark show that ArcticSwarm achieves $82.6% accuracy,

ArcticSwarm is a multi-agent research architecture for long-horizon, open-ended tasks in which agents must search, read, compare, and synthesize evidence without access to a reliable solve-time verifier. Introduced in “ArcticSwarm: Deferring Early Consensus in Long-Horizon Multi-Agent Research” (Yoon et al., 1 Sep 2026), it separates evidence gathering from evidence integration through access-controlled communication, task-level isolation, structured review, and delayed commitment. Subagents publish findings to a shared Bulletin Board System (BBS), while selected search tasks cannot read peer findings and therefore retain more independent search trajectories. On the 830-question BrowseComp-Plus benchmark, ArcticSwarm achieved $82.6\%$ with Qwen 3.5-27B, compared with $78.8\%$ without gated isolation, $74.5\%$ when structured review was also disabled, and $70.6\%$ for the aligned MiroFlow comparison (Yoon et al., 1 Sep 2026).

1. Problem formulation and motivation

ArcticSwarm addresses multi-agent research under conditions in which no inexpensive and reliable verifier exists. Coding systems can generate candidate programs and select one using compilation or unit tests. Open-ended research lacks an equivalent answer key: a response may contain entity confusion, satisfy most constraints while failing one, or cite evidence that supports only a partial match. Majority voting and self-consistency therefore function only as proxy-verification mechanisms.

The architecture identifies premature consensus as the principal failure mode. Independent agents may make correlated errors because they use similar retrievers, discover the same salient documents, or follow the same search heuristics. Agreement can consequently reflect shared search bias rather than correctness. In the reported experiments, forty independent single-agent MiroFlow rollouts on BrowseComp-Plus achieved only $63.5\%$ majority-vote accuracy, although an oracle best-of-$N$ union reached $86.5\%$. The oracle result is not operationally realizable because it assumes a perfect answer-time selector.

Unrestricted peer communication introduces a second failure mode. When an early agent posts a plausible candidate, later agents may treat it as a premise, formulate confirmatory queries, cease searching for alternatives, and interpret ambiguous evidence in its favor. In a 120-question live-web comparison, disabling BBS isolation caused agents to perform $21\%$ fewer web searches, $24\%$ fewer page fetches, and $26\%$ fewer PDF reads, while reading the board $78.8\%$0 more often. Accuracy fell from $78.8\%$1 to $78.8\%$2 (Yoon et al., 1 Sep 2026).

Naive parallelism also produces redundant exploration. The mean pairwise document Jaccard overlap among independent single-agent runs was approximately $78.8\%$3. ArcticSwarm uses the overlap-adjusted rollout-count heuristic

$78.8\%$4

where $78.8\%$5 is the nominal number of paths and $78.8\%$6 is a visualization heuristic rather than a formal effective sample size. Under this heuristic, twenty independent runs yielded only about $78.8\%$7 overlap-adjusted paths.

The architecture therefore treats diversity of evidence and timing of information exchange as resources distinct from agent count. Its design objective is not to eliminate collaboration, but to postpone the point at which collaboration can constrain subsequent search.

2. Architectural principles

ArcticSwarm separates two activities:

1. Evidence gathering: agents explore search directions without conditioning on peer hypotheses.
2. Evidence integration: agents inspect findings, compare candidates, identify unsupported constraints, and determine which claims merit propagation.

This separation is implemented through a shared BBS and task-specific access control. An isolated task can publish findings but cannot read peer findings; a collaborative task can both read and write. The implementation enforces the distinction at the tool level rather than through instructions alone.

An isolated task receives an information context represented as

$78.8\%$8

where $78.8\%$9 is the question, $74.5\%$0 is the agent profile, and $74.5\%$1 is the agent’s own search history. A collaborative task receives

$74.5\%$2

where $74.5\%$3 is the current BBS state. The architecture consequently restricts selected trajectories from conditioning on the shared board while allowing their results to be published afterward.

The BBS is the only inter-agent communication channel. Each post contains:

• a candidate or hypothesis;
• an evidence summary;
• a confidence value;
• sources.

The board is used to track competing candidates, evidential support, missing constraints, and follow-up requirements. Publication and consumption are deliberately decoupled: an isolated investigator may write a finding without reading peer findings, while a collaborative reviewer can inspect and challenge the shared state.

The architecture is distinct from systems that rely on a fixed hierarchy or unrestricted message passing. MiroFlow uses hierarchical delegation and ensembles, whereas ArcticSwarm uses a dynamic swarm, a shared BBS, runtime task-level peer-read policies, and review of intermediate hypotheses rather than only completed answers (Yoon et al., 1 Sep 2026).

3. Orchestration, agents, and task diversity

The orchestrator receives a research question, decomposes it into subtasks, creates tasks with search or reasoning profiles, assigns isolation or collaboration modes, and tracks ownership and status. It dynamically spawns agents, reads BBS findings, extracts candidate hypotheses, launches follow-up searches, and eventually calls prepare_report.

Its workflow is:

1. initialize an empty BBS and task board;
2. create isolation-mode tasks with different search angles;
3. spawn investigators and at least one dedicated reviewer;
4. collect structured findings;
5. create verification tasks when multiple candidates or a strong candidate appear;
6. create additional isolation tasks when evidence is weak or incomplete;
7. enforce the reporting gate;
8. submit only after review and alternative-search conditions are met, except under deadline fallback.

Subagents use two broad profiles. Browsing agents search, fetch pages, read PDFs, and gather evidence. Reasoning and review agents analyze candidates, constraints, and sources, and issue structured verdicts. Agents maintain persistent trajectories: completing a task does not erase their prior queries, sources, candidates, or unresolved gaps. A completed investigator can subsequently review the BBS while retaining its original search context.

Task diversity is created by assigning different constraint groups to separate isolated tasks. Example search directions include geographic and institutional affiliations, creative works and publications, and biographical timelines. These profiles are not claimed to establish formally distinct statistical priors; they create different information-access conditions and search directions.

Isolation is assigned per task rather than globally by phase. Isolation and collaboration can coexist throughout a run. In the GPT-5 full live-web BrowseComp experiment, $74.5\%$4 of cases launched multiple isolation waves; the median number of waves was $74.5\%$5, the mean was $74.5\%$6, the median last-isolation spawn occurred at $74.5\%$7 of case progress, and the median first-collaboration spawn occurred at $74.5\%$8. Thus, the architecture does not impose a strictly sequential “isolation first, collaboration later” schedule.

The controlled information policy is summarized below.

Property	Isolation mode	Collaboration mode
read_bbs tool	Removed	Available
BBS prompt context	Empty	Last 30 messages
post_to_bbs	Available	Available
Automatic polling	Disabled	Enabled

The empirical evidence indicates that isolation broadens the evidence pool. On BrowseComp-Plus, one ArcticSwarm subagent retrieved $74.5\%$9 distinct passages compared with $70.6\%$0 for one independent run. At $70.6\%$1, ArcticSwarm retrieved approximately $70.6\%$2 distinct passages, compared with approximately $70.6\%$3 in an independent pool and approximately $70.6\%$4 in the unrestricted-BBS variant. Within ArcticSwarm, pairwise overlap declined from approximately $70.6\%$5 at $70.6\%$6 to $70.6\%$7 at $70.6\%$8 (Yoon et al., 1 Sep 2026).

4. Commitment boundaries and evidence propagation

ArcticSwarm controls not only access to shared evidence but also the conditions under which a hypothesis may be propagated as a committed answer. Review occurs at three commitment boundaries.

Local finding

Before completing a browsing task, each agent performs a self-check. It compares its candidate against the question’s constraints and searches for additional evidence for constraints that remain unverified. The self-check is trajectory-aware: it examines what the agent itself has found and identifies missing support rather than asking only whether the answer appears plausible.

Shared hypothesis

The BBS audit is performed by a dedicated reviewer who has not previously investigated the question and by finished investigators, called builder reviewers, who carry their original search trajectories into review. Reviewers issue per-constraint verdicts:

• Challenge: a constraint failed or the source is weak;
• Alternative: another candidate should be considered;
• Verified: a constraint is supported by specific evidence.

Constraint-level verdicts allow the orchestrator to request targeted retrieval rather than treating a hypothesis as simply accepted or rejected. A reviewer can reopen retrieval, create a new search task, or force comparison with another candidate.

Final answer

When the orchestrator calls prepare_report, the report remains locked unless:

1. the leading hypothesis has a Verified verdict from a builder reviewer;
2. it has a Verified verdict from a dedicated reviewer;
3. at least one alternative or contrarian search task has run.

If a requirement is missing, the gate creates the required review or search task. The normal remediation budget allows up to two rounds. At the soft deadline, requirements become advisory so that the system can terminate rather than hang.

The resulting information flow is:

$70.6\%$9

A candidate is therefore not considered consensus merely because several agents mention it. It must survive local constraint checking, board-level review, alternative-candidate search, and final multi-source verification.

The controlled ablation results distinguish the contributions of exploration diversity and review. With gated isolation retained, progressively removing the review gates produced the following accuracies:

Configuration	Accuracy
All review gates enabled	$63.5\%$0
Commit gate removed	$63.5\%$1
Commit gate and board audit removed	$63.5\%$2
Commit gate, board audit, and self-check removed	$63.5\%$3

Removing all review gates cost $63.5\%$4 percentage points, whereas removing gated isolation alone cost $63.5\%$5 percentage points. This supports the interpretation that isolation broadens the evidence pool while review determines whether the evidence is sufficiently complete and whether further search is required.

Earlier discretionary-gate runs found that cases receiving verified verdicts from both a builder and a dedicated reviewer achieved $63.5\%$6 on BrowseComp and $63.5\%$7 on BrowseComp-Plus. Cases with no reviewer achieved $63.5\%$8 and $63.5\%$9, respectively. These associations are observational rather than randomized causal estimates. Similarly, BrowseComp-Plus accuracy was $N$0 when no alternative task was opened and $N$1 when at least one alternative task was opened. The current system enforces at least one alternative task.

5. Evaluation and quantitative performance

The primary controlled evaluation uses BrowseComp-Plus, which contains 830 questions over an approximately 100,000-document curated corpus. Qwen 3.5-27B is used for all generation roles, Arctic Embed L v2.0 for retrieval, common tools and judges, and three runs for reported uncertainty values. GPT-4.1 serves as the judge using the official prompt.

The main results are:

Configuration	Accuracy	Relative tokens per case
ArcticSwarm	$N$2	$N$3
Without gated isolation	$N$4	$N$5
Without isolation and all review gates	$N$6	$N$7
Matched MiroFlow rerun	$N$8	Not reported as comparable
Single agent, ArcticSwarm harness	$N$9	$86.5\%$0
Single agent plus majority vote, $86.5\%$1	$86.5\%$2	$86.5\%$3
MiroFlow, single agent plus majority vote, $86.5\%$4	$86.5\%$5	$86.5\%$6

The live-web BrowseComp evaluation contains 1,266 questions. ArcticSwarm achieved $86.5\%$7 with GPT-5, compared with $86.5\%$8 for the reported provider system and $86.5\%$9 for MiroFlow. With Sonnet 4.5, ArcticSwarm achieved $21\%$0. On BrowseComp-Plus, ArcticSwarm achieved $21\%$1 with GPT-5, $21\%$2 with Sonnet 4.5, and $21\%$3 with Qwen 3.5-27B. These live-web comparisons are extensions rather than perfectly compute-matched controlled experiments because provider budgets and infrastructure differ.

On BrowseComp-Plus, the complete controlled configuration used approximately $21\%$4 million end-to-end tokens per case and a median runtime of $21\%$5 minutes. Removing isolation reduced the median runtime to $21\%$6 minutes and tokens per case to $21\%$7 million, but lowered accuracy to $21\%$8. A two-agent configuration achieved $21\%$9 at $24\%$0 million tokens per case and a median runtime of $24\%$1 minutes. Direct messaging achieved $24\%$2 at $24\%$3 million tokens per case and a median runtime of $24\%$4 minutes.

The default controlled setup allowed up to 16 dynamically spawned subagents, a maximum concurrency of 6, 1,200 orchestrator turns, 200 subagent turns, 16,384 maximum output tokens per call, a 9,000-second timeout, pre-shutdown at $24\%$5, a soft deadline at $24\%$6, force-report at $24\%$7 seconds, and hard termination at $24\%$8 seconds.

The live-web GPT-5 run spawned 10,147 subagents and dispatched 9,016 tasks. Of the tasks, $24\%$9 completed normally, $26\%$0 failed, and $26\%$1 remained running at finalization; $26\%$2 did not return before the answer. Web-search cache hits accounted for $26\%$3 of calls, approximately $26\%$4 of web-fetch calls were cache hits, and page compaction reduced delivered content by approximately $26\%$5. Infrastructure failures accounted for $26\%$6 of failed tasks, including gateway authentication, HTTP 5xx responses, rate limits, and network resets.

The document scorer primarily reduced cost rather than increasing accuracy. On the first 100 BrowseComp-Plus questions, scorer-enabled runs achieved $26\%$7 at normalized cost $26\%$8, whereas scorer-disabled runs achieved $26\%$9 at cost $78.8\%$00. Varying the concurrent-subagent cap from 8 to 48 produced accuracies between $78.8\%$01 and $78.8\%$02 on the first 100 questions; a cap of 8 was $78.8\%$03 as costly as the default 16-agent configuration.

6. Failure modes, limitations, and significance

In the GPT-5 BrowseComp analysis, 335 incorrect cases were classified as follows:

Failure type	Share of wrong cases	Reference present in trajectory
Confident-wrong	$78.8\%$04	$78.8\%$05 strict
No-commit	$78.8\%$06	$78.8\%$07 strict
Near-miss	$78.8\%$08	$78.8\%$09
Safety refusal	$78.8\%$10	$78.8\%$11
All failures	$78.8\%$12	$78.8\%$13 strict; $78.8\%$14 including weak matches

Under the strict matching rule, the reference answer was already present in the trajectory in $78.8\%$15 of failures. In a sample of confident-wrong cases, the wrong answer was also repeatedly present. These findings support the interpretation that residual errors often concern candidate adjudication rather than retrieval alone.

Review can itself fail when it audits only a leading candidate. In one example, reviewers verified five of seven constraints for an incorrect candidate, but no search was opened for a missing Cameroon-related alternative. The alternative-task gate addresses this risk but does not eliminate it.

A further negative result concerns pre-decomposing candidate identities. On a 120-question Sonnet 4.6 subset, baseline accuracy was $78.8\%$16, while pre-decomposition accuracy was $78.8\%$17 and cost increased by $78.8\%$18. In the 17 cases where at least two interpretations were generated, accuracy fell from $78.8\%$19 to $78.8\%$20. The reported interpretation is that naming candidate identities before evidence gathering can create anchoring. Decomposing constraints and search directions can broaden exploration, whereas precommitting to candidate identities can narrow it prematurely.

ArcticSwarm has several limitations. Isolation does not guarantee decorrelation if isolated tasks receive similar instructions or generate similar queries. The paper does not provide a dedicated ablation separating task diversity from read restriction. Review remains expensive, with the full controlled system using approximately $78.8\%$21 million tokens per case. The principal controlled evidence comes from BrowseComp-Plus and Qwen 3.5-27B, while live-web comparisons use closed models, provider-specific tools, fallbacks, and less controlled budgets. Reviewer-coverage and alternative-task analyses are partly observational.

The system also depends on the orchestrator’s ability to create genuinely different search directions. It may retain candidate fixation after review, especially when reviewers verify a partial match without initiating contrarian retrieval. Its soft-deadline fallback means that the final reporting requirements become advisory under time pressure. In addition, large-scale deployment is exposed to infrastructure failures, cache behavior, rate limits, and model-specific differences.

ArcticSwarm’s principal significance lies in reframing multi-agent scaling for open-ended research. The relevant resource is not simply the number of agents or trajectories, but the diversity of evidence and the timing of information exchange. Its central design principle can be summarized as

$78.8\%$22

Isolation preserves independent evidence gathering by preventing selected tasks from consuming peer hypotheses. Structured review reconnects the agents through constraint-level challenges, alternatives, and verified findings. The resulting architecture does not treat consensus as a vote over fixed answers; it treats review as a trigger for additional evidence gathering. Under the reported benchmark conditions, this combination outperformed unrestricted collaboration and verifier-free majority voting (Yoon et al., 1 Sep 2026).