When people first hear "AI for your lab," the mental model that forms is usually a chat interface: you type a question about your data, something responds. That mental model is not wrong, but it is insufficient. A scientist does not primarily need a better search engine over their own files. They need a system that can act — that can write the analysis code when they describe what they need, run it against the right dataset, and give them a traceable result. The gap between "chat with your data" and that kind of agency is where most lab AI products currently sit, and it is not a small gap.
This piece is about how we think about the right unit of intelligence for scientific workflows — what it means for an AI agent to be genuinely useful in an R&D context, and what that requires in terms of system design.
The Tool-Writing Problem
Experimental biology generates a long tail of analysis needs. Some are common enough that someone has built a package: differential expression analysis, dose-response curve fitting, flow cytometry gating. But a large fraction of what a working scientist actually needs on a given day is slightly-but-meaningfully different from any pre-built tool: a fold-change calculation that accounts for a specific normalization your lab uses, a plotting function that layers two assay conditions in the exact format your PI wants, a parser for a new instrument file format your vendor introduced in the latest firmware version.
These are not hard problems computationally. Most of them are twenty lines of Python. But they are friction: you have to write the code, or find someone who will, or find a workaround. In practice, a postdoc with a strong experimental background but moderate scripting skills will spend a meaningful fraction of their analytical time either working around these gaps or waiting for the team's designated "Python person" to free up.
An AI agent that can receive a description of the task — "take the dose-response data from this plate, normalize to the vehicle control in column 1, and fit a four-parameter logistic curve to each condition" — and return working, runnable code is a qualitatively different thing from a chat interface. It does not replace the scientist's judgment about what to ask; it removes the friction between asking and having a tool that does the work.
Why Static Tool Libraries Are Not the Answer
One response to the long-tail analysis problem is to build a large library of pre-built analysis modules: pick a workflow, configure parameters, run it. This is how most laboratory informatics platforms have approached the problem, and it works well for the workflows the platform anticipated. The difficulty is that the long tail of scientific need is not stable. It shifts with every new assay type, every new instrument, every new experimental design a PI wants to try.
Maintaining a curated tool library at the pace of scientific evolution is expensive and always slightly behind. The scientific user ends up doing the same workarounds: exporting to a spreadsheet, writing a one-off script, or doing the analysis manually because the platform's module does not quite fit. The library approach is better than nothing, but it does not close the gap — it just moves it.
A tool-writing agent addresses this differently: instead of maintaining a library of static tools, the system maintains the capability to generate appropriate tools on demand. The library is the agent's knowledge of the domain; the output is code tailored to the exact specification the scientist described. This does not mean every generated tool is novel — many requests will produce essentially the same code — but the generation is parameterized to the actual request rather than constrained to what was anticipated when the library was built.
The Scaffolding a Lab OS Needs to Provide
For a tool-writing agent to be scientifically useful rather than just technically interesting, the surrounding system has to provide things the agent cannot produce itself.
First, data context. A general-purpose code-generation model has no knowledge of your experimental structure: which columns in your plate reader export correspond to which conditions, what the sample IDs in your LIMS mean, how your lab normalizes viability data. Without that context, the agent can generate plausible code but not correct code for your specific situation. The lab OS layer needs to supply experiment-specific context at the point of agent invocation — effectively giving the agent a schema of what is known about the current experiment before it starts writing.
Second, a sandboxed execution environment. A tool-writing agent that generates code but cannot run it requires the scientist to copy-paste into a local environment, install dependencies, and interpret output themselves — which reintroduces much of the friction it was meant to eliminate. The agent needs an execution layer: generate code, run it against the connected data, return the result. The execution environment also needs to be sandboxed and audited, so that what ran, when, and against what inputs is recorded and reproducible.
Third, a team-level tool library. When an agent generates a useful analysis tool for one researcher, the same tool should be available to others on the team without requiring them to re-describe the problem. This is different from a static pre-built library — it is an accumulating, team-specific library of agent-generated tools that grows from actual use. Over time, the team's analytical vocabulary becomes an asset rather than a collection of one-off scripts in personal folders.
Where the Agent Boundary Should Be
We are not saying that an AI agent should be making scientific decisions. Deciding what experiments to run, interpreting whether a result is biologically meaningful, judging whether an outlier is real or artifactual — these require domain expertise and scientific judgment that an agent should support, not replace. The boundary we think about is: the agent handles the mechanical gap between scientific intent and executable tool. The scientist handles everything that requires scientific judgment.
That boundary matters for trust. If a scientist runs an agent-generated analysis and the result influences a decision, they need to be able to inspect what the code did, verify that the normalization was correct, and satisfy themselves that the output is trustworthy. This is why audit trails on generated code are not optional — they are what separates a useful research tool from a black box that happens to produce numbers.
A Practical Illustration
Consider a researcher running a CRISPR screen at a growing biotech in the Cambridge area — standard two-condition design, paired-end sequencing, custom deconvolution needed because the library was synthesized with a non-standard spacer length. The standard analysis packages expect a specific input format; the custom spacer means the raw reads need a preprocessing step that no off-the-shelf tool handles cleanly.
Historically, this means either writing the preprocessing script from scratch, finding a colleague who did something similar, or spending a day adapting an existing package. With a tool-writing agent that understands the experiment context — the library design, the expected file structure, the normalization approach — the researcher describes the preprocessing need in plain language and gets a runnable Python function that handles the custom spacer, validates the output, and hands off to a standard downstream analysis. The scientist reviews the code, confirms the logic is correct, runs it. What might have taken a day of debugging takes an hour, most of which is the review.
This is the unit of value we are building toward: not a general-purpose assistant, but a domain-aware agent that understands enough of the experimental context to write tools that are correct for the specific situation, not just plausible in the abstract.
What This Changes for Lab Software Design
The traditional assumption in laboratory informatics has been that the software vendor knows, in advance, what analysis capabilities the user will need. This assumption is false at the edges — and the edges are where science actually happens. A lab OS designed around a tool-writing agent inverts this: the platform provides the context layer, the execution environment, and the memory, while the agent's capability to generate appropriate tools handles the long tail of scientific need that no pre-built library can fully anticipate.
This is not yet a solved problem. There are real challenges in context injection at sufficient fidelity, in code correctness verification, in the handoff between agent output and reproducible execution records. These are the engineering problems Cypher AI was founded in 2025 to work on — not from a general-purpose AI angle, but from the specific requirements of scientific R&D workflows where correctness and auditability are not optional properties.