53.3 Coscientist and AI Co-Scientist

1. Coscientist: LLM-Driven Autonomous Chemistry

What happens when you hand a large language model the keys to a chemistry lab, complete with a liquid-handling robot, a shelf of reagents, and no human standing over its shoulder? Coscientist (Boiko et al., 2023) answered that question: the system autonomously planned and executed Suzuki and Sonogashira cross-coupling reactions (where a palladium catalyst joins two molecular fragments by forming a new carbon-carbon bond), two foundational organic chemistry transformations, without human intervention during execution.

Coscientist is a closed-loop autonomous chemistry platform. A large language model serves as the central controller for the entire wet-lab workflow: reading the literature, planning a synthesis protocol, writing robot control code, running the experiment on physical hardware, and interpreting the results. This matters because Coscientist is the first system to replace the iterative human cycle of "design, execute, analyze, redesign" for real chemical reactions, compressing days of manual effort into hours of unattended operation. The core mechanism is tool-augmented prompting. GPT-4 receives the experimental goal as a prompt, then selects from five tools (web search, documentation lookup, code execution, hardware control, and an experiment planner) in a ReAct-style loop until it meets the goal. Use Coscientist-style direct hardware integration when you have a well-characterized reaction class with established safety profiles and robotic equipment. For domains where the experimental space is too broad or the apparatus too varied for a single robot, the hypothesis-generation approach of AI Co-Scientist (Section 2 below) fits better.

1.1 Architecture

Coscientist uses GPT-4 as its central reasoning engine, augmented with five specialized tools. Figure 53.3 illustrates how these tools connect to the central LLM and how experimental results flow back for iterative refinement.

1. Web Search. Searches the internet for chemical procedures, safety data sheets, and reaction conditions. The LLM formulates search queries and interprets results.
2. Documentation Lookup. Queries technical documentation for the specific hardware and reagents available in the lab. This grounds the system in what it can actually do, preventing it from proposing reactions that require unavailable equipment.
3. Code Execution. Runs Python code for calculations (stoichiometry (calculating the exact quantities of each reagent needed based on the balanced chemical equation), dilution factors, timing schedules) and data analysis (spectral interpretation, yield calculation).
4. Hardware Control. Sends commands to the Opentrons OT-2 liquid-handling robot. The system generates Python scripts using the Opentrons API that specify which reagents to pipette, in what quantities, at what temperatures, and in what sequence. (As of 2024, the Opentrons Flex platform offers higher throughput and a larger deck than the OT-2; newer autonomous chemistry projects increasingly adopt Flex, though the OT-2 remains widely deployed.)
5. Experiment Planner. An internal reasoning module that decomposes a high-level goal ("perform a Suzuki coupling of aryl halide X with boronic acid Y") into a step-by-step experimental protocol.

1.2 The Experiment Loop

Coscientist's experiment loop differs from the purely computational loop of Section 53.1 in a critical way: the "run" phase involves physical actions that cannot be undone. If the system dispenses the wrong reagent, there is no "undo" button. This asymmetry between computational and physical experiments drives the entire safety architecture.

The loop proceeds as follows:

1. The user provides a high-level goal: "Optimize the Suzuki coupling of 4-iodoanisole with phenylboronic acid."
2. Coscientist searches the web and documentation for known reaction conditions.
3. The experiment planner generates a protocol with specific reagent quantities, temperatures, and timing.
4. The LLM generates an Opentrons Python script implementing the protocol.
5. The script executes on the robot. The system monitors for errors (failed aspirations, temperature deviations).
6. Results (yield, purity) are measured and fed back to the LLM.
7. The LLM decides whether to modify conditions and repeat, or to report final results.

1.3 Safety Architecture

Coscientist implements three layers of safety:

• Chemical safety database. Before executing any protocol, the system checks all proposed reagents against a safety database (Globally Harmonized System (GHS) classifications, incompatibility tables). Reactions involving highly toxic, explosive, or pyrophoric reagents (substances that ignite spontaneously on contact with air) are blocked automatically.
• Hardware limits. The Opentrons robot has physical constraints (maximum volume, temperature range, compatible labware) that prevent certain dangerous operations mechanically, regardless of software commands.
• Human review gate. Before the first execution of any new protocol, a human chemist reviews the generated script. Subsequent iterations of the same protocol type (parameter tweaks within pre-approved ranges) can proceed autonomously.

The following code shows how a safety check layer can be implemented for a lab automation system.

from dataclasses import dataclass
from enum import Enum


class HazardLevel(Enum):
    NONE = 0
    LOW = 1       # standard lab precautions
    MODERATE = 2  # fume hood required
    HIGH = 3      # specialized training required
    BLOCKED = 4   # not permitted for autonomous use


@dataclass
class Reagent:
    name: str
    cas_number: str
    hazard_level: HazardLevel
    ghs_codes: list[str]
    max_volume_ml: float  # maximum per single operation
    incompatible_with: list[str]  # CAS numbers


class SafetyChecker:
    """Pre-execution safety validation for lab protocols."""

    def __init__(self, reagent_db: dict[str, Reagent]):
        self.reagent_db = reagent_db  # keyed by CAS number

    def check_protocol(
        self, steps: list[dict]
    ) -> dict:
        """Validate a protocol before execution.

        Each step dict has 'reagent_cas', 'volume_ml',
        'temperature_c', and 'action' keys.

        Returns dict with 'approved', 'warnings', and
        'blockers'.
        """
        warnings = []
        blockers = []

        all_reagents_used = set()

        for i, step in enumerate(steps):
            cas = step["reagent_cas"]
            reagent = self.reagent_db.get(cas)

            if reagent is None:
                blockers.append(
                    f"Step {i+1}: Unknown reagent CAS {cas}. "
                    "Cannot verify safety."
                )
                continue

            # Check hazard level
            if reagent.hazard_level == HazardLevel.BLOCKED:
                blockers.append(
                    f"Step {i+1}: {reagent.name} is blocked "
                    "for autonomous operation."
                )

            elif reagent.hazard_level == HazardLevel.HIGH:
                warnings.append(
                    f"Step {i+1}: {reagent.name} requires "
                    "specialized handling. Human review needed."
                )

            # Check volume limits
            if step["volume_ml"] > reagent.max_volume_ml:
                blockers.append(
                    f"Step {i+1}: {step['volume_ml']} mL of "
                    f"{reagent.name} exceeds limit "
                    f"({reagent.max_volume_ml} mL)."
                )

            # Check incompatibilities
            for other_cas in all_reagents_used:
                if other_cas in reagent.incompatible_with:
                    other = self.reagent_db[other_cas]
                    blockers.append(
                        f"Step {i+1}: {reagent.name} is "
                        f"incompatible with {other.name}."
                    )

            # Check temperature limits
            temp = step.get("temperature_c", 25)
            if temp > 200:
                blockers.append(
                    f"Step {i+1}: Temperature {temp} C "
                    "exceeds equipment limit."
                )
            elif temp > 100:
                warnings.append(
                    f"Step {i+1}: High temperature ({temp} C). "
                    "Verify labware compatibility."
                )

            all_reagents_used.add(cas)

        return {
            "approved": len(blockers) == 0,
            "warnings": warnings,
            "blockers": blockers,
        }

2. Google AI Co-Scientist: Hypothesis Generation at Scale

Coscientist proves that an LLM can close the loop between planning and physical execution, but its scope is deliberately narrow: one reaction class, one robot, one lab. What if the goal is not to optimize a known reaction but to propose entirely new scientific hypotheses across broad domains where no single robot can run the experiments?

Google's AI Co-Scientist (Gottweis et al., 2025) takes a fundamentally different approach. Rather than executing experiments, it generates and refines hypotheses through a multi-agent system inspired by evolutionary computation. The system then hands promising hypotheses to human domain experts for experimental validation. In short: one system closes the loop with a robot arm; the other closes it with a tournament of ideas, and both still need the physical world to say yes or no.

2.1 Agent Architecture

AI Co-Scientist uses five specialized agent types, each implemented as a prompted Gemini model with different instructions and tools:

1. Generation Agent. Produces initial hypotheses given a research goal and background context. Uses literature retrieval (similar to PaperQA2) to ground hypotheses in existing knowledge. Each hypothesis is a structured object with a claim, supporting evidence, proposed experiments, and predicted outcomes.
2. Reflection Agent. Critically examines each hypothesis for logical consistency, feasibility, and alignment with known science. Functions as an internal reviewer, similar to the critique phase in Section 53.1's research loop. The reflection agent can request revisions from the generation agent.
3. Ranking Agent. Scores hypotheses on multiple dimensions (novelty, testability, potential impact, feasibility) and produces a ranked list. Uses pairwise comparison via Elo rating, where each hypothesis carries a numerical score (initialized at 1500) that rises or falls after head-to-head comparisons, rather than absolute scoring, to reduce calibration bias.
4. Evolution Agent. Takes the top-ranked hypotheses and produces variations: combinations of two hypotheses, extensions with additional variables, specializations to specific sub-problems. This is analogous to crossover and mutation in genetic algorithms. The evolved hypotheses re-enter the pool for reflection and ranking.
5. Proximity Agent. Searches for related work that supports or contradicts each hypothesis. Unlike the generation agent's initial literature search, the proximity agent performs targeted searches after the hypothesis has been refined through multiple rounds of debate. It identifies both supporting evidence and potential falsifiers. Figure 53.3.1 illustrates AI Co-Scientist multi-agent tournament selection cycle.

Figure 53.4 shows how these five agents interact in a cyclic tournament. The generation agent seeds the pool; the reflection agent critiques each entry; the ranking agent scores survivors via pairwise Elo comparison; the evolution agent breeds new candidates from the top scorers; and the proximity agent injects external evidence at each generation.

2.2 Tournament Selection

Without a mechanism to cull weak candidates, a system that generates twenty hypotheses per round would leave scientists buried in undifferentiated proposals, unable to separate genuine insight from plausible-sounding noise. Tournament selection solves this by forcing every hypothesis to prove itself head-to-head before it can survive to the next generation.

AI Co-Scientist borrows tournament selection from evolutionary computation to manage its hypothesis pool. The process works as follows:

1. The generation agent produces \(N\) initial hypotheses (typically \(N = 20\)).
2. The reflection agent reviews each hypothesis, producing a refined version.
3. The ranking agent scores all \(N\) hypotheses using pairwise Elo comparison.
4. The top \(k\) hypotheses (typically \(k = 5\)) survive to the next round.
5. The evolution agent produces \(N - k\) new hypotheses by combining and mutating the survivors.
6. Steps 2 through 5 repeat for \(T\) generations (typically \(T = 10\)).

The Elo rating for each hypothesis \(h_i\) is updated after each pairwise comparison:

where \(E_i\) is the current Elo rating of hypothesis \(h_i\), \(S_{ij} \in \{0, 0.5, 1\}\) is the actual outcome of comparing \(h_i\) to \(h_j\) (as judged by the ranking agent), \(P_{ij} = 1 / (1 + 10^{(E_j - E_i)/400})\) is the expected outcome, and \(K\) is the update constant (typically \(K = 32\)).

The following code implements the tournament selection loop.

import random
from dataclasses import dataclass, field


@dataclass
class Hypothesis:
    """A scientific hypothesis with metadata."""
    claim: str
    evidence: list[str]
    proposed_experiments: list[str]
    elo_rating: float = 1500.0
    generation: int = 0
    parent_ids: list[str] = field(default_factory=list)
    id: str = ""

    def __post_init__(self):
        if not self.id:
            self.id = f"hyp_{random.randint(10000, 99999)}"


class TournamentSelector:
    """Evolutionary tournament selection for hypotheses."""

    def __init__(
        self,
        pool_size: int = 20,
        survivors: int = 5,
        generations: int = 10,
        k_factor: float = 32.0,
    ):
        self.pool_size = pool_size
        self.survivors = survivors
        self.generations = generations
        self.k_factor = k_factor

    def pairwise_compare(
        self,
        h1: Hypothesis,
        h2: Hypothesis,
        rank_fn,
    ) -> tuple[float, float]:
        """Compare two hypotheses and update Elo ratings.

        rank_fn(h1, h2) returns the winner: 1.0 for h1,
        0.0 for h2, 0.5 for tie.
        """
        expected_h1 = 1.0 / (
            1.0 + 10 ** ((h2.elo_rating - h1.elo_rating) / 400)
        )
        actual = rank_fn(h1, h2)

        h1.elo_rating += self.k_factor * (actual - expected_h1)
        h2.elo_rating += self.k_factor * (
            (1.0 - actual) - (1.0 - expected_h1)
        )
        return h1.elo_rating, h2.elo_rating

    def run_tournament(
        self,
        pool: list[Hypothesis],
        rank_fn,
        evolve_fn,
        reflect_fn,
    ) -> list[Hypothesis]:
        """Run the full tournament selection loop.

        rank_fn(h1, h2) -> float: pairwise comparison
        evolve_fn(parents) -> Hypothesis: create offspring
        reflect_fn(h) -> Hypothesis: critique and refine
        """
        for gen in range(self.generations):
            # Reflection pass
            pool = [reflect_fn(h) for h in pool]

            # Pairwise ranking (sample pairs for efficiency)
            n_comparisons = len(pool) * 3
            for _ in range(n_comparisons):
                i, j = random.sample(range(len(pool)), 2)
                self.pairwise_compare(
                    pool[i], pool[j], rank_fn
                )

            # Selection: keep top survivors
            pool.sort(
                key=lambda h: h.elo_rating, reverse=True
            )
            survivors = pool[: self.survivors]

            # Evolution: generate offspring
            offspring = []
            while len(offspring) < self.pool_size - self.survivors:
                parents = random.sample(
                    survivors, min(2, len(survivors))
                )
                child = evolve_fn(parents)
                child.generation = gen + 1
                child.parent_ids = [p.id for p in parents]
                offspring.append(child)

            pool = survivors + offspring

        # Final ranking
        pool.sort(key=lambda h: h.elo_rating, reverse=True)
        return pool

Library Shortcut: OpenAI Agents SDK for Multi-Agent Debate

The tournament selection above manages the hypothesis pool, but each agent (generation, reflection, ranking, evolution, proximity) is a separate LLM-backed function. The OpenAI Agents SDK provides typed handoffs between agents with built-in tracing, reducing the orchestration code from ~200 lines to ~60. Define each agent with its own system prompt and tools, then use Runner.run() with handoff triggers to route hypotheses between agents. The SDK's built-in tracing records every agent call, which is essential for debugging why a promising hypothesis was rejected or a weak one survived.

2.3 Validation Results

AI Co-Scientist was validated across three biomedical domains:

• Drug repurposing for acute myeloid leukemia (AML). The system identified existing drugs that could be repurposed for AML treatment. Domain experts reported that several predictions aligned with unpublished experimental findings, suggesting the system can rediscover results independently.
• Novel antimicrobial targets. The system proposed mechanisms for antibiotic resistance in bacteria. Some predictions were validated through wet-lab experiments, demonstrating the system's ability to generate testable, experimentally confirmed hypotheses.
• Rare disease mechanisms. For rare genetic diseases with limited literature, the system proposed pathogenic mechanisms that experts found plausible and worth investigating.

3. Comparing Coscientist and AI Co-Scientist

These two systems represent opposite ends of the physical integration spectrum, as Table 53.3 summarizes:

4. Safety Architectures for Physical-World AI Scientists

The comparison above highlights a shared dependency: regardless of whether a robot or a human runs the experiment, both systems must ensure that proposed protocols do not cause harm. For Coscientist, that concern is immediate and physical; for AI Co-Scientist, it surfaces when human teams act on generated hypotheses.

When an AI scientist controls physical equipment, safety requirements escalate dramatically. A bug in an ML experiment wastes GPU hours; a bug in a chemistry experiment can cause fires, toxic releases, or equipment destruction. We organize the safety architecture into four layers, each catching failures that slip through the layer above.

1. Semantic validation. Before generating any protocol, verify that the proposed experiment is chemically (or physically) sensible. Does the reaction have literature precedent? Are the proposed conditions (temperature, pressure, concentration) within known safe ranges? This layer is implemented as a prompted LLM call with access to a safety database.
2. Computational simulation. Before physical execution, simulate the experiment computationally. For chemistry, this means reaction energy calculations (density functional theory (DFT), where quantum mechanical equations approximate the electronic structure of molecules to predict reaction energies, or semi-empirical methods) to check for exothermic runaway (an uncontrolled temperature spike from heat-releasing reactions). For robotics, this means kinematic simulation to check for collisions. See Chapter 43 for simulation methods.
3. Hardware interlocks. Physical safety systems that cannot be overridden by software: temperature cutoffs, pressure relief valves, emergency stops. These provide a hard floor below which no software failure can cause harm.
4. Human oversight. For novel protocol types (not previously approved), a human expert reviews the protocol before first execution. For approved protocol types with parameter variations within pre-approved ranges, autonomous execution is permitted.

from enum import Enum
from dataclasses import dataclass


class ApprovalStatus(Enum):
    AUTO_APPROVED = "auto_approved"
    NEEDS_REVIEW = "needs_review"
    BLOCKED = "blocked"


@dataclass
class SafetyGateResult:
    status: ApprovalStatus
    layer: str
    message: str


class FourLayerSafetyGate:
    """Four-layer safety gate for physical experiments."""

    def __init__(
        self,
        safety_db,
        simulator,
        approved_protocol_types: set[str],
    ):
        self.safety_db = safety_db
        self.simulator = simulator
        self.approved_types = approved_protocol_types

    def evaluate(
        self, protocol: dict
    ) -> list[SafetyGateResult]:
        """Run all four safety layers on a protocol.

        Returns a list of results; execution proceeds only
        if no result has status BLOCKED and at most one has
        NEEDS_REVIEW.
        """
        results = []

        # Layer 1: Semantic validation
        for reagent in protocol.get("reagents", []):
            hazards = self.safety_db.lookup(reagent["cas"])
            if hazards.is_blocked:
                results.append(SafetyGateResult(
                    status=ApprovalStatus.BLOCKED,
                    layer="semantic",
                    message=(
                        f"{reagent['name']} is prohibited "
                        "for autonomous use."
                    ),
                ))
            elif hazards.requires_review:
                results.append(SafetyGateResult(
                    status=ApprovalStatus.NEEDS_REVIEW,
                    layer="semantic",
                    message=(
                        f"{reagent['name']} requires human "
                        "safety review."
                    ),
                ))

        # Layer 2: Computational simulation
        sim_result = self.simulator.check_exotherm(protocol)
        if sim_result.max_temp_c > 300:
            results.append(SafetyGateResult(
                status=ApprovalStatus.BLOCKED,
                layer="simulation",
                message=(
                    f"Predicted exotherm: {sim_result.max_temp_c} C "
                    "exceeds equipment rating."
                ),
            ))
        elif sim_result.max_temp_c > 150:
            results.append(SafetyGateResult(
                status=ApprovalStatus.NEEDS_REVIEW,
                layer="simulation",
                message=(
                    f"Predicted temperature {sim_result.max_temp_c} C "
                    "warrants human review."
                ),
            ))

        # Layer 3: Hardware interlocks (informational)
        results.append(SafetyGateResult(
            status=ApprovalStatus.AUTO_APPROVED,
            layer="hardware",
            message="Hardware interlocks active (independent).",
        ))

        # Layer 4: Protocol type approval
        ptype = protocol.get("protocol_type", "unknown")
        if ptype not in self.approved_types:
            results.append(SafetyGateResult(
                status=ApprovalStatus.NEEDS_REVIEW,
                layer="oversight",
                message=(
                    f"Protocol type '{ptype}' not pre-approved. "
                    "Human review required."
                ),
            ))
        else:
            results.append(SafetyGateResult(
                status=ApprovalStatus.AUTO_APPROVED,
                layer="oversight",
                message=f"Protocol type '{ptype}' pre-approved.",
            ))

        return results

    def can_proceed(
        self, results: list[SafetyGateResult]
    ) -> bool:
        """Check if a protocol can proceed to execution."""
        return all(
            r.status != ApprovalStatus.BLOCKED
            for r in results
        )