53.1 Automated Research Loops

1. The Six Phases of Automated Research

Imagine a system that, at 2 a.m. on a Tuesday, proposes a hypothesis no human suggested, writes the code to test it, trains a model, discovers the hypothesis fails, revises its own idea, and by sunrise has a publishable result on its fourth attempt, all without a single human keystroke. That is the automated research loop in action, and every AI scientist system, regardless of domain or architecture, implements some version of the same six-phase cycle that makes it possible.

Without an automated loop, a researcher's Tuesday hypothesis waits until Wednesday's implementation, Thursday's execution, and Friday's evaluation; by then, the original context has faded and the feedback arrives too late to steer the next idea. That lag between question and answer is the single largest bottleneck in empirical science.

An automated research loop is a software system that cycles through hypothesis generation, experimentation, and evaluation without waiting for human intervention between steps. It compresses days of sequential decision-making into hours of continuous compute, letting the system explore far more ideas per unit time.

The mechanism is straightforward: each phase produces a structured output (a hypothesis document, a code artifact, a results table, a review verdict) that feeds into the next phase. A controller routes failures back to earlier phases for revision. Use an automated loop rather than manual orchestration when experiments are cheap enough to tolerate discarded runs (under ~\$100 each) and when you can express the evaluation criteria programmatically. For expensive or subjective domains, the supervised variant (Level 2 in Section 4) is more appropriate. In short: close the loop so the machine never waits for a human to carry a result from one phase to the next.

The six phases are:

1. Propose. Generate a research hypothesis or idea. The input is a research domain, a set of existing results, and (optionally) a gap analysis from a knowledge graph. The output is a concrete, testable claim. In Chapter 39, we built hypothesis generators using structural hole detection (where structural holes are gaps in a knowledge graph where no edge connects two otherwise related clusters of concepts) and analogical transfer; those become the "propose" module here.
2. Implement. Write the code needed to test the hypothesis. This includes data loading, model definition, training loops, evaluation metrics, and visualization. The coding agent from Section 40.1 handles this phase.
3. Run. Execute the experiment. In machine learning (ML) research, this means training a model and recording metrics. In chemistry, it means sending instructions to lab hardware (Chapter 55). In mathematics, it means running a search algorithm over candidate solutions. The critical requirement is determinism: the same code and data must produce the same result.
4. Evaluate. Analyze the experimental results. Compute statistical tests, compare against baselines, check for confounds. The analysis agent from Section 40.1 handles this, augmented with the causal reasoning tools from Chapter 31.
5. Critique. Review the methodology and results for errors, biases, and weaknesses. This is the internal peer review step. The reviewer agent from Section 40.1 performs this, often implemented as a separate large language model (LLM) call with a critic prompt that incentivizes finding flaws rather than confirming success.
6. Report. Write up the findings as a structured document (paper, technical report, or notebook). This phase also decides whether the result is worth reporting at all, or whether the loop should continue with a revised hypothesis.

Figure 53.1 shows the six-phase loop with its feedback edges.

2. Formalizing the Research Loop

We can express the research loop as a state machine. Let $S = \{s_{\text{propose}}, s_{\text{implement}}, s_{\text{run}}, s_{\text{evaluate}}, s_{\text{critique}}, s_{\text{report}}\}$ be the set of states, and let $T: S \times \{0, 1\} \to S$ be the transition function, where the binary input indicates success (1) or failure (0) at each phase. The key transitions on failure are:

On success, the transition is always to the next phase in sequence, with \(T(s_{\text{report}}, 1) = s_{\text{propose}}\) closing the loop for the next research idea. Each state is associated with a maximum retry count \(r_i\) that prevents infinite cycling. When the retry count is exhausted, the system either escalates to a human supervisor or abandons the current idea and moves to \(s_{\text{propose}}\).

3. Novelty Detection Through Embedding Distance

The state machine above tells the loop when to keep iterating, but it says nothing about what is worth iterating on; without a filter, the system could cycle endlessly through ideas that duplicate published work.

An AI scientist that rediscovers known results wastes compute and, worse, could present existing knowledge as novel findings. Novelty detection is therefore a critical filter applied at the propose phase. The core idea is simple: embed the generated hypothesis in the same space as the existing literature, and reject hypotheses that are too close to published work.

Formalizing the Novelty Score

Let \(h\) be the text of a generated hypothesis, and let \(\mathcal{P} = \{p_1, p_2, \ldots, p_n\}\) be the set of existing papers in the relevant domain. We compute embeddings using a scientific text encoder \(\phi\) (such as SPECTER2, a transformer model trained on citation graphs to produce embeddings that capture scientific similarity, or a fine-tuned Sentence-BERT, a siamese network architecture that maps sentences to fixed-length vectors optimized for semantic comparison):

where \(d\) is cosine distance. A hypothesis is accepted only if \(\text{novelty}(h) > \tau\), where \(\tau\) is a threshold calibrated on a held-out set of known-novel vs. known-derivative paper pairs. In practice, \(\tau \approx 0.3\) on cosine distance typically works well for ML research papers when using SPECTER2 embeddings, though the optimal value varies by subfield and corpus size. Figure 53.2 traces the decision flow from a candidate hypothesis through the novelty filter.

The following implementation shows a novelty filter using SPECTER2 embeddings and a FAISS (Facebook AI Similarity Search) index for efficient nearest-neighbor search over a large corpus.

import numpy as np
import faiss
from transformers import AutoTokenizer, AutoModel
import torch


class NoveltyFilter:
    """Filter hypotheses by embedding distance to existing literature."""

    def __init__(
        self,
        model_name: str = "allenai/specter2",
        threshold: float = 0.3,
    ):
        self.tokenizer = AutoTokenizer.from_pretrained(model_name)
        self.model = AutoModel.from_pretrained(model_name)
        self.threshold = threshold
        self.index = None
        self.paper_ids: list[str] = []

    def _embed(self, texts: list[str]) -> np.ndarray:
        """Compute normalized embeddings for a batch of texts."""
        inputs = self.tokenizer(
            texts,
            padding=True,
            truncation=True,
            max_length=512,
            return_tensors="pt",
        )
        with torch.no_grad():
            outputs = self.model(**inputs)
        # Use CLS token embedding
        embeddings = outputs.last_hidden_state[:, 0, :]
        # L2-normalize for cosine similarity via inner product
        norms = torch.norm(embeddings, dim=1, keepdim=True)
        return (embeddings / norms).numpy()

    def build_index(
        self, papers: list[dict[str, str]]
    ) -> None:
        """Build FAISS index from existing papers.

        Each paper dict has 'id', 'title', and 'abstract' keys.
        """
        texts = [
            f"{p['title']}. {p['abstract']}" for p in papers
        ]
        embeddings = self._embed(texts)
        dim = embeddings.shape[1]
        self.index = faiss.IndexFlatIP(dim)  # inner product = cosine on normalized vecs
        self.index.add(embeddings)
        self.paper_ids = [p["id"] for p in papers]

    def check_novelty(
        self, hypothesis: str
    ) -> dict:
        """Check if a hypothesis is sufficiently novel.

        Returns dict with 'is_novel', 'distance', and
        'nearest_paper_id'.
        """
        embedding = self._embed([hypothesis])
        similarities, indices = self.index.search(embedding, k=1)
        # cosine distance = 1 - cosine similarity
        cosine_distance = 1.0 - similarities[0][0]
        nearest_id = self.paper_ids[indices[0][0]]
        return {
            "is_novel": cosine_distance > self.threshold,
            "distance": float(cosine_distance),
            "nearest_paper_id": nearest_id,
        }


# Usage
filter = NoveltyFilter(threshold=0.3)
filter.build_index(existing_papers)  # list of paper dicts

result = filter.check_novelty(
    "Applying spectral normalization to the attention weights "
    "of Vision Transformers reduces overfitting on small datasets "
    "by constraining the Lipschitz constant of each layer."
)
print(f"Novel: {result['is_novel']}, "
      f"Distance: {result['distance']:.3f}, "
      f"Nearest: {result['nearest_paper_id']}")

4. The Autonomy Spectrum

AI scientist systems differ dramatically in how much autonomy they grant the AI. We can arrange them on a five-level spectrum (Table 53.1), analogous to the Society of Automotive Engineers (SAE) levels for autonomous driving. Figure 53.1.1 illustrates the autonomy spectrum for AI scientist systems.

Most current systems operate at Level 2 or 3. The barrier to Level 4 is largely institutional rather than purely technical: trust, safety, and accountability remain unsolved. A fully autonomous system risks burning compute on dead ends or, worse, generating plausible but wrong results that mislead downstream work. Level 2 balances throughput with human oversight.

5. Why Current AI Scientists Are Domain-Limited

A striking pattern across all existing AI scientist systems is their confinement to domains where experiments are cheap, fast, and deterministic. AI Scientist v1 and v2 work on ML research, where an experiment costs a few dollars and completes in minutes. FunSearch works on discrete mathematics, where "experiments" are program evaluations that complete in milliseconds. Even Coscientist, which operates in the physical world, targets well-characterized reactions with predictable outcomes.

This limitation has three causes:

1. Cost per experiment. An ML training run costs \$1 to \$100. A biology experiment costs \$1,000 to \$1,000,000. That is a cost gap of up to 10,000x, which is precisely why every current AI scientist system clusters in the cheap-experiment corner of the research landscape. An AI scientist that proposes and discards hundreds of ideas before finding one that works can only operate in low-cost domains.
2. Feedback latency. ML experiments return results in minutes to hours. Wet-lab biology experiments take days to months. The research loop's iteration speed is bounded by the slowest phase, which is almost always the experiment execution.
3. Determinism. Given the same code and data, an ML experiment produces the same result (modulo random seeds, which can be fixed). Biological experiments have intrinsic variability that makes automated evaluation harder. When the system cannot reliably distinguish "my hypothesis is wrong" from "the experiment had noise," the critique phase breaks down.

Key Insight: The Simulation Bridge

The path to AI scientists in expensive, slow, or noisy domains runs through simulation. Rather than executing a wet-lab experiment, the AI scientist runs a computational model of the experiment (see Chapter 43 and Chapter 44). Promising results from simulation are then forwarded to human experimentalists for physical validation. Google's AI Co-Scientist (Section 53.3) takes exactly this approach: it generates hypotheses computationally, then hands them to human scientists for wet-lab testing. The AI runs the cheap inner loop; humans run the expensive outer loop.

6. Measuring the Quality of Automated Research

Domain limitations constrain where AI scientists can operate today, but even within those domains we need a way to tell whether the research they produce is actually good.

How do you evaluate an AI scientist's output? The standard metrics from ML (accuracy, loss) do not apply. Instead, we need metrics specific to research quality. The following four dimensions, drawn from the evaluation framework of Huang et al. (2024), cover the space:

1. Novelty. Is the finding genuinely new? Measured by embedding distance (Section 3 above) and expert assessment. Novelty without correctness is noise.
2. Correctness. Are the experimental results valid? Measured by reproducibility: can an independent system re-run the experiment and obtain the same results? AI Scientist v1 reported ~70% reproducibility on its own generated experiments.
3. Significance. Does the finding matter? Measured by effect size, statistical power, and expert assessment of impact. An AI scientist that discovers tiny improvements on saturated benchmarks produces correct but insignificant work.
4. Clarity. Is the report well-written, well-structured, and easy to follow? Measured by automated readability metrics and (ideally) by human reviewers. AI Scientist v1's automated peer review scores its own papers on a 1-10 scale across multiple criteria.

We can combine these into a composite score with domain-specific weights:

where \(r\) is a research output and \(w_n + w_c + w_s + w_l = 1\). In ML research, typical weights are \(w_c = 0.4\) (correctness dominates), \(w_n = 0.3\), \(w_s = 0.2\), \(w_l = 0.1\). The following code implements this evaluation framework.

from dataclasses import dataclass


@dataclass
class ResearchQuality:
    """Composite quality score for automated research output."""
    novelty: float       # 0-1: embedding distance score
    correctness: float   # 0-1: reproducibility fraction
    significance: float  # 0-1: effect size / expert rating
    clarity: float       # 0-1: readability + structure score

    def composite(
        self,
        weights: dict[str, float] | None = None,
    ) -> float:
        """Weighted composite score.

        Default weights emphasize correctness for ML research.
        """
        w = weights or {
            "novelty": 0.3,
            "correctness": 0.4,
            "significance": 0.2,
            "clarity": 0.1,
        }
        return (
            w["novelty"] * self.novelty
            + w["correctness"] * self.correctness
            + w["significance"] * self.significance
            + w["clarity"] * self.clarity
        )


def evaluate_reproducibility(
    experiment_fn,
    n_replications: int = 5,
    tolerance: float = 0.02,
) -> float:
    """Run an experiment multiple times and measure consistency.

    Returns fraction of replications within tolerance of the
    median result.
    """
    results = [experiment_fn(seed=i) for i in range(n_replications)]
    median_result = sorted(results)[n_replications // 2]
    within_tolerance = sum(
        1
        for r in results
        if abs(r - median_result) <= tolerance
    )
    return within_tolerance / n_replications


# Example usage
quality = ResearchQuality(
    novelty=0.72,       # moderately novel
    correctness=0.95,   # highly reproducible
    significance=0.45,  # modest improvement
    clarity=0.80,       # well-written
)
print(f"Composite quality: {quality.composite():.3f}")
# Output: Composite quality: 0.676

7. From Research Agents to AI Scientists: What Changed?

The research agents of Chapter 40 and the AI scientists of this chapter use the same underlying components: LLMs, tool access, memory systems, and multi-agent coordination. What distinguishes an AI scientist from a collection of research agents is loop closure (the ability of the system to feed each phase's output into the next phase and to route failures back to earlier phases, all without human intermediation). A research agent team requires a human to decide what to investigate next and to connect each agent's output to the next agent's input. A human also judges when the work is complete. An AI scientist internalizes all of these decisions.

The three capabilities that enable loop closure are:

1. Self-directed exploration. The system generates its own research questions, rather than receiving them from a human. This requires a model of what is interesting (the novelty filter) and what is tractable (feasibility estimation, a rough prediction of whether the idea can be tested within the system's compute and time budget).
2. Automated self-critique. The system evaluates its own work against quality standards, rather than relying on human review. This requires a separate critic model or prompt that is incentivized to find flaws (see the reviewer agent patterns from Section 40.1).
3. Iteration management. The system decides when to iterate (retry with modifications), when to pivot (abandon the current hypothesis), and when to stop (declare the result publishable). This requires a meta-controller (a supervisory component that sits above the six-phase loop and makes decisions about the loop itself) that tracks progress across iterations and enforces budgets on compute and time.

The rest of this chapter examines how specific systems implement these three capabilities. Section 53.2 covers AI Scientist v1/v2 and FunSearch; Section 53.3 covers Coscientist and AI Co-Scientist; Section 53.4 builds our own supervised AI scientist that implements all three with explicit human gates.