The Wet Lab Is the Press Release. The Research Codebase Is the Transformation.

Start with the framing the source piece sets up. It opens on Anthropic's lofty goals for science, including opening a wet lab, and then immediately pivots: meanwhile, a quiet transformation is happening all across AI x Science. The rhetorical move is the argument. One of those things is a bet on future capacity. The other is already changing how Monday morning goes.

Here's the Feynman version, the one you could explain to someone outside the field. An experiment is not one action. It is a loop: you form a hypothesis, you design something to test it, you run the thing, you process the output, you look at the result, and you decide what to do next. Most people outside research assume the expensive step is "run the thing." In a lot of labs it isn't. The expensive steps are design and process the output, because both of them are bottlenecked on a human with rare context and no spare hours.

A wet lab, including a beautifully automated one, makes "run the thing" cheaper and faster. That matters. But if your loop spends three weeks between runs because one person has to rewrite a parsing script and re-derive a statistical model, doubling your throughput at the bench buys you very little. You've widened the road and left the tollbooth.

This is why the codebase framing is not a technical footnote. It's the part of the loop where an agent can do real work today, with reversible consequences, at a cost measured in tokens instead of reagents. And it's why the interesting sentence in the whole source piece is the one about a single person who can describe what an LLM does to both halves.

If you read only the wet-lab headlines, you'd conclude AI-for-science is a 2029 story that requires a building. Read the workflow story and it's a 2026 story that requires a harness and some discipline.

The title of the source piece names two postures: foundries versus navigators, in service of lowering the cost of science. I'd read that split as a strategic distinction rather than a technical one, and it's worth spelling out because it tells you where your own money should go.

A foundry strategy lowers the price of one experiment. You industrialize: automation, standardized assays, more parallel runs, a physical plant that turns capital into data at a predictable unit cost. Wet labs and screening platforms sit here. The bet is that if data gets cheap enough, discovery falls out of volume.

A navigator strategy lowers the number of experiments you need. You get better at choosing. You prune the hypothesis space before spending anything physical, and you make the analysis fast enough that each result actually updates the next decision instead of arriving three weeks late.

These are not opposed, but they have very different capital profiles, and that asymmetry is the practical point. A foundry requires a building and a balance sheet. Navigation requires better software and someone with taste. Guess which one a ten-person biotech can actually execute this quarter.

This is also where the standard agent-industry framing helps. Think of it as a value-chain map: the physical instrument layer is heading toward commodity, slowly and expensively, because it evolves at the speed of hardware and regulation. The decision layer sitting on top of it is nowhere near commodity. It's custom, tacit, and mostly living in one senior scientist's head. Genesis-stage components are where differentiation lives, and right now the decision layer is the genesis-stage component in most research organizations.

So when you see a frontier lab announce a wet lab, the correct read is not "they will win science." It's "they are buying the commoditizing half." Plausibly on purpose: firms routinely try to commoditize the layer adjacent to theirs so their own layer keeps its margin. Cheap, abundant experimental data makes a model-and-harness business more valuable, not less.

For you, the reader running or funding actual research, the takeaway is narrower and more useful. You are almost certainly under-invested in navigation. It's the cheaper term in the equation and it compounds, because every improvement to how fast you close the loop multiplies against every experiment you ever run afterward.

Let's get concrete about what "an LLM in a research codebase" means, because the phrase is doing a lot of quiet work in the source piece and it deserves unpacking.

A research codebase is not a product. It's sediment. Layers of scripts deposited by people who have since graduated, each one written to answer one question once, none of them written to be read again. It typically includes:

• A parser for whatever format the instrument vendor decided on this decade.
• Three versions of the normalization step, two of which are wrong and one of which is the one everyone uses.
• A statistics notebook whose assumptions nobody has re-examined since the person who wrote it left.
• Plotting code that exists only to make one figure for one slide.

That sediment is exactly the kind of work agents are unreasonably good at: bounded, textual, tediously specific, and verifiable if you bother to verify. You point an agent at the vendor's output format and it writes the parser. You describe the experiment and it drafts the analysis. You ask it to restore the dead script from 2023 and it does, including the parts the original author never documented.

And this is where I'm going to be the annoying teacher, because I have watched this go wrong. The failure mode is not that the agent can't do it. The failure mode is that it does it plausibly.

Wrong answers in research code do not throw errors. A unit conversion silently off by a thousand produces a beautiful figure. A statistical test applied to data that violates its assumptions produces a p-value, not a complaint. An agent that "fixes" a normalization step by changing the denominator has just rewritten your historical results, and nothing in your workflow will tell you.

So before you hand a research pipeline to an agent, you'll want three things in place, in this order:

1. A golden dataset with known answers. Any pipeline change gets rerun against it. If the numbers move and you didn't intend them to, stop.
2. Pipeline code under version control, with the analysis and the result stored together. If you cannot say which version of the code produced which figure, you have not accelerated science. You've accelerated the production of unreproducible claims.
3. A written boundary around what the agent may edit. Parsing and plotting: yes. The normalization and statistics that all historical results depend on: change only with a human review.

Do those and agents in a research codebase are the highest-return thing on your list. Skip them and you have built a very fast machine for generating confident nonsense.

Here's the part the model-release coverage keeps missing. The reason a scientist can now put an agent in the middle of a real workflow is not that the model got smarter this month. It's that the plumbing around the model got auditable. The value in AI isn't in the model; it's in the harness that connects the model to the world, and the harness is where the last year of actual progress lives.

Look at what shipped in a single ordinary day of agent tooling releases, translated out of engineering dialect:

• The Pydantic AI team's v2.50.0 release lets you ask a decision model which route to take by name, with one label per route. In plain terms: when your agent picks a path, the choice now shows up in your logs as a word you recognize instead of an opaque internal decision.
• Langfuse's v4.45.2 added batch inference telemetry per project and retry handling for transient failures. Meaning: you can attribute what an agent cost, and to which project, and a temporary failure no longer disappears without a trace.
• Vercel's ai 7.0.114 patch filters tracing context against telemetry allowlists. Meaning: you get to decide what leaves your system in a trace.

None of that is exciting. All of it is load-bearing for science.

Think about why. A scientific result is only worth anything if you can say how you got it. An agent that produces an answer with no record of which route it took, what it cost, and what data it saw is not a collaborator. It is a rumor. Provenance is not a compliance feature in research. It is the product. Named routing labels, per-project cost attribution, and explicit control over what gets recorded are precisely the three things that turn an agent run into something you can put in a methods section.

The allowlist item deserves a second look if you work anywhere near proprietary biology. Your prompts contain unpublished results. Your traces contain your prompts. Every observability tool you add is another place your pre-publication data comes to rest, often outside your own perimeter. That is the trust boundary, and it is the one nobody draws on the whiteboard. If you are thinking about AI agent security in 2026 for a research org, start there: enumerate every system that stores a trace, then decide what is allowed into it.

This is also the honest answer to "which agent orchestration setup should we use." Mostly it doesn't matter. What matters is whether the one you pick can tell you, six months later, exactly what happened.

There's a second cost curve running underneath all of this, and it moves faster than any lab can retool. In the same week, Latent Space's roundup of the news cycle logged a new Chinese open-weight frontier lab claiming the throne for the first time, plus new state-of-the-art models and price cuts from both Anthropic and OpenAI, alongside a $10B fundraise for TypeSafe AI.

Price cuts are the part to underline. Not because of the direct savings, which for most research teams are rounding error, but because of what they do to your judgment about what's worth asking.

Every researcher runs an internal filter: is this question worth the effort of finding out? When the effort was "two days of writing analysis code," the filter was aggressive, and it had to be. Most curiosity got discarded before it was ever articulated. When the effort drops to "twenty minutes and some tokens," the filter recalibrates, and you start asking the questions you previously talked yourself out of. That is not a productivity improvement. It's a change in which hypotheses ever get looked at.

The same roundup offers a nice demand signal for where attention is going: two of their episodes, on genomic language models and on AI scientists, ranked above general-interest heavyweights in Apple Podcasts and helped push the channel past 200K on YouTube. A niche technical conversation about applying models to biology outperforming mainstream tech shows is not a fluke of the algorithm. It's an audience telling you where it thinks the next several years are.

But I want to flag the trap in the cheap-question story, because it's the one that will bite hardest. Lowering the cost of asking raises the cost of sorting. If you ten-x the number of analyses your team produces and keep the same review capacity, you have not accelerated discovery. You have flooded it. The lab that wins here is not the one that generates the most candidate findings; it's the one that built a filter fast enough to keep up with its own generator.

That filter is human for now, and it should be. Which means the practical constraint on agent-accelerated research is not model quality or token price. It's how many results your senior scientists can meaningfully scrutinize per week, and whether your pipeline surfaces the three that deserve attention instead of all three hundred.

The single most useful distinction for deciding where to let agents run autonomously comes, oddly, from an argument about text generation. The Sequence describes ordinary autoregressive generation as writing with a keyboard that only lets you append: you can think before typing, but once a token lands, the next one has to live with it. The model can issue a correction later; it cannot silently rewrite what it already emitted.

That is a perfect description of a wet lab.

Reagents get consumed. Cells die. A plate that ran overnight with the wrong concentration is not "reverted," it's repeated, at full cost, a week later. Physical experiments are append-only, and every mistake stays in the record as an expense.

Software is the other regime. You can revise. Branch, diff, roll back, rerun against the golden dataset, throw the whole attempt away at no cost beyond compute. Agent deployments live on a spectrum from copilot to full autonomy, and most failures come from deploying at the wrong point on it. The reversibility of the layer tells you where that point is.

So the rule writes itself:

• Reversible layers, high autonomy. Parsing, refactoring, exploratory analysis, figure generation, literature triage, drafting experimental designs. Let the agent run. The worst case is wasted compute and a discarded branch.
• Append-only layers, copilot only. Anything that consumes material, occupies an instrument, moves a robot, or commits to a protocol. The agent proposes; a human approves; the approval is recorded next to the result.

The temptation you'll feel, especially once the reversible half is working well, is to collapse that boundary. The agent has been right about analysis for three months, so why not let it queue the next plate? Because the failure distribution is completely different on the other side of the line. In code, a bad agent decision costs you an afternoon. On the bench, it costs you a week of consumables and, worse, contaminates a dataset that later results will be compared against.

Automation does shrink the gap. A sufficiently instrumented lab makes some physical steps cheap enough to retry casually, which moves them toward the reversible column. That is the actual argument for foundry-style investment: not that robots run experiments faster, but that they make experiments cheap enough to be wrong about. Until your lab is there, treat the physical world as unforgiving, because it is.

None of this requires a wet lab or a frontier-lab partnership. It requires you to treat your research pipeline like production software and your agents like new hires with excellent recall and no judgment.

Here's the order I'd do it in.

1. Make one loop measurable. Pick a single recurring analysis and time it end to end, from raw instrument output to a number someone trusts. You cannot claim an agent lowered your cost of science if you never knew what a cycle cost. Most teams are shocked by the answer, and the shock itself is the argument for the rest of the work.

2. Build the golden dataset before the agent touches anything. Inputs with known correct outputs. Every pipeline change reruns against it automatically. This is the single control that separates "agents accelerated our research" from "agents quietly broke our normalization in March."

3. Store code version, agent run, and result in one record. If a figure exists, you should be able to recover which pipeline version and which agent run produced it. This is where the boring harness features earn their keep: a named route in your logs, per-project cost attribution, a retry that left a trace. Cheap to set up now, impossible to reconstruct later.

4. Draw the trust boundary and write it down. List every place a prompt or trace containing unpublished data comes to rest, including tools your team adopted without telling anyone. Then narrow what's allowed to leave. The allowlist pattern showing up in agent tooling exists because this boundary is genuinely easy to cross by accident.

5. Put the human gate on the append-only side, not the whole system. One approval step in front of anything that consumes material. Full autonomy behind it. Teams that gate everything get no speedup; teams that gate nothing eventually lose a month.

6. Budget review capacity, not just compute. Decide now how many agent-generated findings a senior scientist will actually examine per week, and make your pipeline rank its own output against that number.

The headline version of AI-for-science is a building full of robots, and that will matter eventually. The version available to you this quarter is smaller, duller, and already working: the loop between question and answer gets short enough that curiosity stops being expensive. The labs that get there first will not be the ones with the biggest foundry. They'll be the ones that made their own workflow legible enough to trust an agent inside it.