AI Chemistry Agents Need an Evidence Trail

An AI agent can return a persuasive research plan long before anyone knows whether the proposed experiment is worth doing. In chemistry, that gap matters: a promising prediction can send a laboratory toward weeks of work, while a small mistake in the underlying record can quietly change the question being asked. The useful measure of an agent is therefore what a scientist can check, reproduce and act on after the conversation ends.

Google DeepMind's November 3 walkthrough of Cheminformatics Skills for Antigravity offers a timely example. Google reports a roughly hour-long workflow that gathers compounds, analyzes molecular changes, builds predictive models and proposes new designs. It uses a familiar drug-development problem rather than claiming a finished medicine. The interesting prospect is a more accessible scientific workbench, with a substantial qualification: faster analysis becomes valuable when its evidence survives inspection.

A workbench is more useful than a clever answer

The attraction of an agent is easy to understand. Research tasks cross boundaries between documents, datasets, software and judgment. A scientist may know precisely what comparison would be useful while still spending a morning getting the relevant information into a form that a program can handle. A conversational interface could make that work easier to request and revise.

Google's Science Skills repository describes packages of instructions, scripts and supporting resources for specialized scientific tasks. It places them inside Antigravity's Science plugin and covers areas including cheminformatics, genomics and structural biology. This is a workflow layer around an agent, rather than a claim that one language model has absorbed every scientific method.

That distinction gives prospective users something concrete to evaluate. A package can be inspected. A script can be rerun. Instructions can be versioned, compared and corrected. None of those properties guarantees a good scientific result, but they create opportunities for checking that are harder to find in an unsupported conversational answer.

The strongest application would let a researcher change one assumption and see exactly which outputs must be regenerated. If a measurement is excluded because its experimental conditions do not match the rest, the agent should update the analysis and preserve the reason for exclusion. Google already describes source documentation in its demonstration. The broader question is how much of the full workflow another researcher can reconstruct. A beautiful final report is less helpful if the steps that produced it disappear into chat history.

Separate the coordinator from the calculator

In Google's example, the language model organizes work, navigates databases and, Google says, contributes scientific reasoning, while chemistry tools perform calculations. RDKit, ChEMBL and PubChem supply established tooling or data resources. That division is sensible, but the interface between these components deserves as much attention as the individual components themselves.

The RDKit documentation illustrates a useful boundary. It can read molecular representations into structured objects and report failures for certain invalid inputs. Such checks can catch errors that ordinary prose would conceal. They do not establish that a valid-looking molecular record is the correct record for the experiment under discussion.

Consider a hypothetical agent that extracts a structure correctly but associates it with a measurement from a neighboring table row. Every later calculation might execute successfully. The plot could look plausible. The central error would be an incorrect relationship between two pieces of evidence, not an arithmetic failure.

This suggests a practical design rule: preserve the connections, not just the values. A result should lead back to the source document, the relevant record, the extraction step and any subsequent transformation. The scientist should be able to challenge that chain without asking the model to invent a retrospective explanation. An agent that exposes an unresolved ambiguity is doing more useful work than one that silently chooses a convenient interpretation.

A potency column needs its experimental context

A spreadsheet encourages the impression that every number in a column measures the same thing. Scientific records often require a more careful reading. The ChEMBL documentation on assays and activities distinguishes binding, functional, toxicity, physicochemical and other assay types. It also explains that its confidence scores concern assay-to-target assignments. A score in a database is not a universal guarantee of every downstream conclusion.

For an agent, the first challenge is deciding which records belong together. Unit conversion alone cannot answer that question. An observation about binding to a target and an observation about a biological effect may both be valuable, but treating them as interchangeable would require a justification. The useful output is a documented comparison, with exclusions and uncertainty visible.

Imagine asking an agent whether a family of compounds has improved over time. Before accepting its trend line, a researcher would want to know whether later experiments used a different assay, whether duplicate reports were counted twice, and whether a missing value was treated as evidence of poor performance. These are proposed review questions, not findings about Google's demonstration.

A good workbench would make these questions easy to answer. It could show the original and standardized values together, distinguish observations from predictions, and keep separate analyses where pooling would be questionable. Automation should reduce the cost of careful curation rather than make a larger table look inherently more authoritative.

The laboratory still gets a vote

A computational proposal is a reason to consider an experiment. The practical next step should depend on the evidence supporting that proposal, the uncertainty that remains and the cost of finding out whether it is wrong.

The FDA's overview of preclinical research makes clear how much work sits beyond a candidate description. Before testing a drug in people, researchers investigate its potential for harm, including through laboratory and other preclinical studies. A convincing computational story does not establish safety or justify treating a proposed compound as a medicine.

For teams evaluating an agent, a useful pilot would therefore stop short of celebrating the number of designs generated. It would ask whether the system helps experts select better next experiments. A smaller set with clear reasons, documented uncertainties and feasible follow-up may be more valuable than a long ranked list whose apparent precision cannot be defended.

The agent should also be allowed to recommend gathering better evidence instead of producing another candidate. If two explanations fit the current observations, identifying an experiment that distinguishes them could be the most productive result. A system rewarded only for producing designs will have little incentive to make that recommendation.

This changes how speed should be discussed. Saving time on preparation is useful even when experimental work remains slow. But a shorter computer session is only one part of the research cycle. Review, correction and follow-up need to be included before anyone can claim an improvement in the time required to reach a dependable decision.

A model needs a test it has not helped design

Google's walkthrough describes held-out evaluation and discusses chronological or scaffold-based splits. It also explicitly acknowledges limits from sparse data and assay noise. Those qualifications matter because a prediction deserves a different level of confidence depending on how it was tested.

The broader problem predates today's agents. The MoleculeNet benchmark paper was motivated by the difficulty of comparing molecular learning methods evaluated on different datasets. Its authors found benefits from learned representations while also identifying difficulties with scarce data and highly imbalanced classification tasks. A capable agent does not make these evaluation choices disappear; it makes more choices possible in less time.

That can create a subtle temptation. If an agent tries many models and repeatedly examines the same supposedly final test results, it may select a configuration that looks especially good on that particular test. The test has become part of the search process. The scikit-learn guidance on common pitfalls warns that information leakage can produce overly optimistic estimates and recommends separating training and test data before preprocessing.

For a scientific workbench, a defensible evaluation plan should be established before the search expands. The team should record what the system may inspect, which comparisons count as exploratory, and what remains untouched until the final check. It should also preserve failed runs. Reporting only the strongest outcome hides the amount of searching required to obtain it.

The important question is whether performance survives the change the user actually cares about: a later collection of compounds, a different structural family or a different experimental setting. Those are distinct questions. One favorable score should not be allowed to answer all of them.

The evidence package should travel with the result

The next useful unit of output is an evidence package: the data used, the transformations performed, the software versions, the evaluation plan and the unresolved questions. This is an editorial proposal for how to judge scientific agents, not a claim that Antigravity currently produces every element automatically.

Such a package would let a second researcher revisit the work without repeating the entire conversation. It would distinguish source measurements from calculated descriptors and model predictions. It would record where a human changed an assumption, where a tool failed, and which decisions depended on information the system could not verify.

Reproducibility also requires a realistic account of the environment. A script alone may be insufficient if its dependencies, database snapshot or configuration have changed. Preserving those details creates some overhead, but that overhead is easier to justify when the work may influence costly experiments. It also makes errors easier to diagnose: a team can identify the step that changed instead of debating two conflicting summaries.

The same concern appears in Coding Agents Need a Workplace, Not Just a Model. An agent's usefulness depends on the environment in which its work can be run and checked. Scientific workflows add another responsibility: the environment must preserve the relationship between a computational result and the physical observation it is supposed to explain.

What would make the progress convincing

A strong next demonstration would give independent researchers enough material to rerun the workflow and examine its weak points. It would distinguish time saved in data preparation from time spent reviewing mistakes. It would compare the final decisions with a reasonable baseline, rather than measuring success only by the fluency of the report or the quantity of generated candidates.

For a laboratory considering adoption, a bounded trial is a sensible starting point. Choose a well-understood retrospective task, define the acceptance criteria and keep an expert responsible for the consequential decisions. Measure how often the agent preserves source context, flags uncertainty and produces work that another person can reproduce. A failure that is clearly surfaced may be less costly than a subtle error inside an apparently complete answer.

Google's new chemistry workflow is interesting because it points toward a practical role for agents inside scientific work. The durable value would come from making careful analysis easier to request, inspect and repeat. More hypotheses are welcome. A trustworthy account of why one deserves the next experiment would be better still.

11/05/2026

• Coding Agents Need a Workplace, Not Just a Model
• AI Agents Need Boundaries They Cannot Rewrite