Coscientific Swarm

Coscientific Swarm is an architecture for parallel research.

• Independent researchers study a hypothesis graph.
• Workers share findings through a Queen-managed nest (the corpus).
• Workers take work from a prioritized frontier.

Inspiration

I started from Andrej Karpathy's autoresearch.

There, one agent edits training code, runs a five-minute experiment, keeps or discards the change, and repeats.

Coscientific Swarm adds improvements around that loop: competing hypotheses, parallel labs, shared knowledge, and global scheduling.

I actually took more inspiration from OpenAI's The Hugging Face incident and the road ahead (26 August 2026).

Agents hacked an unauthorized bulletin board, collected discoveries, exchanged information, divided work, and continued investigations other agents had started.

Shared state

The Queen is the only one who records shared state.

Workers submit results bundled like papers in academia.

The Queen writes the corpus and sets final research-schedule priority.

• The research graph is a graph that records hypotheses, sources, methods, results, evidence, parent links, starting-weight links, and execution history.
• The corpus is the collected scientific findings from the research.
• The frontier is where unclaimed, currently runnable work sits in schedule order.

flowchart TD
    Goal["Swarm objective"] --> O["Queen"]
    O -->|"Commit records"| Graph[("Research graph")]
    Graph -->|"History and evidence"| O
    O -->|"Publish versioned knowledge"| Corpus[("Corpus")]
    Corpus -->|"Relevant findings"| O
    O -->|"Admit and reprioritize"| Frontier[("Frontier")]
    Frontier -->|"Eligible candidates"| Scheduler["Scheduler"]
    O -->|"Run state and resource policy"| Scheduler
    Scheduler -->|"Assign suitable work"| Context["Prior-research compiler"]
    Goal --> Context
    Graph -->|"Relevant records"| Context
    Corpus -->|"Knowledge snapshot"| Context
    Context --> Lab1["Lab 1"]
    Context --> Lab2["Lab 2"]
    Context --> Lab3["Lab 3"]
    Context --> Lab4["Lab 4"]
    Lab1 -->|"Result and 0-3 proposals"| O
    Lab2 -->|"Result and 0-3 proposals"| O
    Lab3 -->|"Result and 0-3 proposals"| O
    Lab4 -->|"Result and 0-3 proposals"| O
    Goal --> Judge["Goal judge"]
    Graph -->|"Evidence and artifacts"| Judge
    Corpus -->|"Consolidated findings"| Judge
    Judge -->|"Continue or confirm completion"| O

Labs submit results to the Queen.

The Queen improves the graph and the corpus, the scheduler finds worthwhile work on the frontier and assigns it to workers, and the prior-research compiler attaches relevant shared knowledge to each assignment.

The Queen reflects the goal judge's conclusions into state.

The Queen is a role, not necessarily one program (there can be several).

Goal

A goal names what to achieve and when it counts as success.

Do not change the goal during research.

Changing it voids the previous labs' scientific findings.

class GoalContract:
    """
    Sketch of a research or engineering goal.
    """
    objective: str
    success_criteria: str
    constraints: str
    evidence_requirements: str
    resource_budget: str
    permitted_tools_and_environments: str
    stopping_policy: str
    version: str

Nodes and attempts

A research node is one bounded question.

It has to be specific enough to run without talking to the proposer.

class ResearchNode:
    """
    Rough sketch of a research node.
    """
    id: str
    goal_version: str
    question: str
    hypothesis: str
    rationale: str
    scope_and_assumptions: str
    predictions: str
    falsification_or_resolution_criteria: str
    origin_references: str
    related_node_ids: str
    evidence_references: str
    status: str
    notes: str
    conclusion: str
    conclusion_confidence: str
    proposed_followups: list  # 0-3
    scoring_history: str
    provenance: str
    starting_model_id: str  # or weight

Execution attempts belong to the node and are recorded separately.

If it fails from an external cause (for example, an environment-setup failure), keep it as an execution failure and leave the hypothesis unverified.

A retry creates another attempt on the same node.

class ResearchAttempt:
    """
    Rough sketch of one execution attempt.
    """
    id: str
    node_id: str
    worker_id: str
    methodology: str
    input_artifacts: str
    environment_version: str
    context_snapshot: str
    lease: str
    status: str
    observations: str
    output_artifacts: str
    resource_usage: str

A conclusion says whether the evidence fits the hypothesis, contradicts it, is still undecided, is narrow in scope, and so on.

Confidence is a quantification or grounding of how much to believe that claim and its evidence.

Follow-ups and admission

When finished, a worker may propose up to three follow-up hypotheses (or none).

Each proposal records a rationale, why it would be useful, confidence, proposed importance, and estimated cost.

If the hypothesis is wrong, that branch can be closed.

Failed findings should still be searchable (a failure can still inspire something else).

Follow-ups from one node do not exceed three.

That is a deliberate constraint, because some nodes dump dozens of hypotheses.

Every proposal is compared with in-progress, completed, deferred, and closed research before it becomes a new node or enters the frontier.

The Queen comprehensively matches datasets, interventions, conditions, results, and so on, and revises the node if two nodes are the same.

• Same: the existing node stays canonical, and the proposal only keeps a reference to it.

  A running node keeps running.

  A finished node links its already-recorded result.

• Partial overlap: keep the distinction that still remains.

  Matching context is merged into the canonical record or continues as a narrower follow-up.

  A merge still goes through evaluation.

• New: score importance, usefulness, and cost.

  Accept, defer, or reject with a rationale.

Intentional replication is a new attempt on the same hypothesis, or a replication task with purpose and cost written down.

This lineage does not cycle.

Same, support, and contradiction links can make the graph denser.

Rewriting an ancestor still leaves parent-child history acyclic.

Corpus and context

The corpus is a maintained record of reusable findings, limits, methods, artifacts, failed approaches, and open disagreements.

A result stays limited to the dataset and conditions that produced it.

class KnowledgeEntry:
    """
    Sketch of a corpus entry.
    """
    id: str
    version: str
    statement: str
    scope_and_conditions: str
    status: str
    confidence_assessment: str
    supporting_evidence: str
    contradicting_evidence: str
    source_node_ids: str
    artifact_references: str
    supersedes: str
    created_at: str
    updated_at: str

Status can be provisional, supported in a limited scope, disputed, superseded, invalidated, and so on.

That label is valid only inside that scope.

The Queen checks a submitted result against its evidence and the existing corpus, then makes a versioned update.

It feels roughly like a git-controlled Wikipedia.

Raw observations and prior versions stay.

A new summary leaves conflicting evidence in place.

Workers submit interpretations.

The Queen publishes a cleaned-up account of the graph.

Later labs verify independently.

When labs exchange findings, it works like this. A submits to the Queen, the finding is registered in the corpus, and B receives an update message.

Before a task starts, the compiler gathers the goal, hypothesis, relevant lineage, related experiments, applicable corpus entries, contradictions, tools, and limits.

It also records which literature version it included, so later you can see whether the worker lacked that finding, ignored it, or used a conclusion that later changed.

That is how you tell whether context was excluded because it was not in the literature yet, or because it was judged irrelevant.

New knowledge is available on later context requests.

A running worker keeps the snapshot it started with, but can always access the latest corpus read-only.

If a finding invalidates an assumption, answers the question, or changes execution, the Queen notifies the affected tasks.

Notices are logged.

A long experiment keeps the method it started with unless the Queen records a cancel or a new attempt.

Priority and scheduling

A worker's attached importance and confidence are valid only for that specific proposal.

The Queen does not take the worker at their word. It evaluates from the result, the follow-up rationale, the graph, and the goal.

• Confidence is how much to believe the claim.
• Importance is what changes if you resolve it.
• Priority is whether doing that work now is the right call.

If some research would essentially change the paradigm, run cheap, low-confidence hypotheses first.

High-confidence work that is not urgent waits.

class ResearchEvaluation:
    """
    Sketch of an admission score.
    """
    proposed_importance: str
    judged_importance: str
    confidence_assessment: str
    goal_relevance: str
    expected_information_value: str
    estimated_cost: str
    downstream_value: str
    redundancy_assessment: str
    scheduling_priority: str
    rationale: str
    evaluated_against_state_version: str

The scheduler can be any heuristic whose rules are visible.

The scheduler can be updated continuously as the research progresses.

A work assignment records the worker, the task, and an expiry time.

Heartbeats distinguish live work from abandoned attempts.

An expired assignment can be retried.

Late results from stale attempts are stored, and the more newly accepted result is current.

Result submission must be idempotent.

That is, leave it as a replayable record (like a durable workflow).

Disagreement

When credible results disagree, that disagreement is recorded explicitly in the corpus until later work resolves it. The Queen defines replications, methods reviews, rigor boundary conditions, and so on. Failed findings must also carry the conditions from that time. Closed branches must still be searchable. Later evidence can retest the same question under different conditions.

Stopping

The goal judge checks evidence against the goal. Corpus summaries can point at relevant results. Completion still requires confirming all required evidence, such as measurements, proofs, and artifacts. A promising result becomes a verification candidate. Completion requires finishing every condition: required replications, holdout evaluation, constraint checks, leftover work.

Research tokens running out, operator cancellation, and frontier exhaustion are different stop reasons.

The frontier counts as empty only after workers, proposal evaluations, and dependency unlocks have all stopped, and no remaining research is worth doing (fully ended, the goal itself completed or verified, or the goal itself refuted).