Taking Claude Science (beta) for a test drive

Claude Science is not a new model. It is a public beta scientific workbench built around Anthropic’s existing Claude models, with the important difference that it is packaged for real scientific workflows rather than general conversation. In Anthropic’s own description, the app brings together the tools researchers already bounce between—literature search, notebooks, code, domain databases, figures, manuscripts, and compute—inside one environment. The main selling points are that it can run multi-step analyses, use specialist tools and databases, manage compute on your own infrastructure, and attach an auditable trail to each result so you can inspect how an output was produced. Anthropic announced the beta on June 30, 2026, and the product page says it is available for macOS and Linux on Pro, Max, Team, and Enterprise plans. 

The easiest way to explain the difference from a normal chat app is this: a general assistant can talk about biology, but Claude Science is intended to actually do pieces of the work. Anthropic says that general assistants can discuss biology, but cannot reliably run pipelines, navigate scientific databases, orchestrate cluster jobs, or preserve session-level provenance in the way Claude Science is designed to do. Compared with Claude Code, which is focused on software engineering tasks like reading a codebase, editing files, and running development commands, Claude Science is a science-specific application layer: it is geared toward genomics, single-cell, proteomics, structural biology, cheminformatics, scientific rendering, and lab compute workflows at present with the possibility to extend to other domains. In that sense, Claude Science is best understood as “Claude plus scientific tooling, connectors, compute, and provenance,” not as “a biology super-model.” 

Later in the post, I’ll go through my own test drive, where I used Claude Science to independently recreate a DESeq2 RNA-seq analysis pipeline and compare it against a pipeline I had already built using an agentic, test-driven development process in Claude Code for a client. I'll describe my process of agentic coding in a future post, but what I want to do now is test how Claude Science compares to this process. That comparison matters because my original pipeline was already built in thin slices, validated with unit tests, checked end-to-end on synthetic data where the expected answer was known, and documented with walkthroughs—so the Claude Science run acts less like a first draft and more like an independent audit of the whole pipeline.  The ability to generate re-usable, auditable code is something that I argue Claude Science will eventually have to address. 

The official entry point is the Claude Science product page, and the documentation for getting started and using Claude Science is here. Claude Science is extensible by adding additional connectors and skills that you create or choose from a library of premade connectors and skills based on the MCP connectors and SKILLS technology that I describe further below.  Anthropic says the app can be installed wherever your data already lives—on a laptop, Linux box, HPC login node, or cloud VM—with browser access on top, and jobs can run through local kernels, Slurm over SSH, or Modal. 

One practical advantage of working with an agentic AI application is that, when installation or configuration goes sideways, you can often ask it to inspect the environment and help debug the problem instead of switching into a fully manual troubleshooting mode.
During my installation, every one of Claude Science's database connectors failed to install on my Intel Mac — a wall of red error text ending, cryptically, at the word "Rust." This was not my first "Python dependency hell" rodeo but instead of trying to solve it myself, I just asked Claude Science to fix it for me. Which it did.
It worked out that a security library the app needed had just dropped support for Intel Macs, so my machine was being forced to compile it from scratch — a build that then tried to download an entire compiler toolchain from a site the app was blocked from reaching. Every obvious fix we threw at it was a dead end, and each one cost a full app restart to disprove; at one point Claude Science read the source code of the offending installer to prove that a fix I'd tried could never have worked, saving me hours of chasing it.

The actual cure was almost anticlimactic: pre-install the slightly older version of that library — the last one that still ships a ready-made Intel package — into the exact hidden folder the app uses, so it never attempts the doomed build. Claude Science couldn't reach that protected folder itself, so it had me run one read-only command in my Terminal, read what I pasted back, and handed me a single line to run. It worked on the first try. What struck me most is that I never had to understand any of the underlying machinery — I supplied symptoms, screenshots, and the occasional Terminal paste, and it did the reasoning. For a wet-lab biologist who just wants the software to work, that's the whole point.

Anthropic’s language around Claude Science makes most sense if you think of it as a coordinating agent that can spin up specialist side-conversations. In plain English, “multiagent” here means the main assistant does not have to do every subtask in one giant monologue. Instead, it can delegate specific work—literature synthesis, tool use, data exploration, or a specialist computation—to separate workers that run in their own context windows and then return only the useful summary or artefact. Anthropic’s broader agent documentation explains why this matters: separate subagents help prevent the main conversation from being flooded with logs, search results, or intermediate files, and multi-agent systems can add capacity for parallel reasoning when a task is too large or too fragmented for a single context window. That is the technological problem being solved: context-window control and parallelization of work. 

Claude Science’s reviewer agent is the other half of the architecture. Anthropic says that as a pipeline runs, a reviewer works in the background to inspect outputs, flag incorrect citations, catch untraceable numbers, identify figures that do not match their code, and correct problems before results fully surface to the user. The public FAQ goes even further and says a background reviewer flags claims it cannot trace to evidence. So, yes: the available public description makes this sound largely automatic, not something the user has to remember to invoke manually each time. The concern this addresses is not just “hallucination” in the abstract. It is the much more concrete scientific problem of citation drift, calculation errors, and outputs that look polished but are not actually anchored to recoverable evidence or reproducible code. That is a very sensible design choice for a research-facing product. However, in my own experience, the reviewer agent did not run automatically and when I asked if it had, I was prompted to request a review of my workflow. So this is something to be aware of; don't trust that processes you think should have run have actually run.  Ask.  

This is where Claude Science is most interesting scientifically. Anthropic says every artefact includes the exact code that generated it, the environment it ran in, a plain-language description of what was done, and the conversation that led there (see the docs here). That is a stronger provenance story than a normal chat transcript and much closer to what computational biologists actually need when they revisit an analysis months later. Anthropic also says the app runs on your own infrastructure, with raw datasets and compute staying local, and only the context needed for each step being sent to Claude. For a biology audience, the key point is that Claude Science is trying to turn “AI output” into something more like a reconstructable computational notebook plus environment record plus rationale trail. 

On the narrower question of where scripts and steps are stored, I just asked in my session:

And received the following detailed answer:

So, yeah; provenance is taken seriously.

Would that, by itself, meet the requirements of scientific journals? Partly—but not fully. Claude Science’s provenance model maps well onto reproducibility expectations, but journals usually want more than an internal audit trail. For example, Bioinformatics author guidelines require software papers to provide a self-contained implementation, appropriate test data, detailed install/run documentation, stable public URLs for source code (e.g. github/bitbucket), and archived versions of software and test data. They also require information on how to reproduce results and encourage platforms like Code Ocean. So Claude Science helps with the generation and capture of reproducible artefacts, but journal compliance usually still requires conversion into public, versioned, reviewer-accessible research outputs. 

That leads directly to authorship and accountability. There is already broad editorial consensus that AI cannot be an author because authorship requires responsibility for accuracy, integrity, and final approval. The ICMJE recommendations state this clearly, and Springer Nature and Elsevier say essentially the same thing in different language. That means a bioinformatician, statistician, or domain scientist still has to review the work and stand behind it. Claude Science can improve the evidence trail, but it cannot absorb scientific accountability away from the human authors. 

For that reason, I think you can make a strong case that Claude Science outputs should be converted into deterministic scripts and committed to a normal public repository before submission. That argument is supported both by long-standing reproducibility advice—such as the classic “Ten Simple Rules for Reproducible Computational Research”, which emphasizes tracking exactly how every result was produced—and by software-review venues such as JOSS (Journal of Open Source Software), which look for tests, CI, documentation, public history, and open development. In other words: Claude Science may be a productive authoring environment, but GitHub, archived releases, CI, and deterministic reruns are still the right lingua franca for review, maintenance, and peer scrutiny. 

People are talking about best practices for AI-generated or AI-assisted research software, even if the field has not yet stabilized around one universal checklist. Useful examples include the FAIR checklist for research software, the PHA4GE proposed standards for public-health bioinformatics software, continuous integration guidance for research software, and venue-specific expectations from journals like JOSS and Bioinformatics. Across these sources, the recurring themes are familiar: public repositories, version control, changelogs, documentation, tests, archived releases, validation data, and reproducible environments such as containers. 

One common recommendation is to include test or validation datasets that let other people verify that the code behaves correctly - it strikes me that there are many commonly used bioinformatics packages that must have been developed using multiple test data sets that are lost in the current modality of providing "just code".  Bioinformatics explicitly asks for appropriate test data, and PHA4GE specifically recommends benchmark or validation datasets so researchers can evaluate and compare tools consistently. And literature supports the idea that automated testing remains underused in scientific software, including bioinformatics, and that this underuse hurts sustainability and reproducibility. So I would argue that published, reusable validation datasets would materially improve reproducibility, and many conventional projects would benefit from them. And the advent of agentic AI coding makes this goal even more easily available and the failure to provide such programming resources even less defensible.

This is a large and evolving topic: Claude Science makes provenance much easier, but the path from “auditable AI workflow” to “journal-grade computational supplement” still runs through human review, deterministic scripts, public repositories, frozen environments, and validation datasets. If people are interested, I would be happy to consider a deeper follow-up essay. For additional reading on this point, the starting points are Bioinformatics author guidelines, ICMJE on AI use by authors, Elsevier’s generative AI policy for journals, JOSS submission criteria, PHA4GE standards, Sandve et al. on reproducible computational research and popular accounts of how AI is altering the AI landscape.

The cleanest explanatory frame for Claude Science involves connectors (which may be MCP servers), and skills (which are reusable instructions for how to use tools encoded by connectors correctly). Anthropic’s MCP connector docs describe MCP as a way of connecting Claude to remote tool servers without building one-off custom integrations for every pairing. Anthropic’s Skills docs describe skills as modular packages of instructions, metadata, and optional resources like scripts and templates that Claude can load automatically when relevant. Put simply, MCP gives the ai agent real handles on external systems, while Skills give the agent reusable know-how for using those systems well. 

Why does that matter technically? Because both mechanisms are answers to the same two failures that often make AI systems brittle in science: context bloat and hallucination. If every workflow rule, database schema, and tool instruction has to be pasted into the prompt every time, context fills up fast and the model is forced to reason over a noisy mess. MCP reduces that by letting Claude call tools only when needed; Anthropic’s documentation explicitly notes that Claude calls MCP tools when the user’s request maps to the tool’s capability. Skills reduce repetition by packaging workflows so that the agent does not need the same long instructions repeated over and over, and the benefit of Skills is that they only load when needed and can be combined compositionally. In other words, both are ways of turning “remember all this” into “use the right capability when needed.” 

A concrete connector example from the public Claude ecosystem is the 10x Genomics Cloud connector, which appears in Anthropic’s connector directory under life sciences and healthcare. A concrete skill example in Claude Science is the integration with NVIDIA’s BioNeMo Agent Toolkit, whose published skill set covers things like protein folding, molecular docking, generative chemistry, genomics analysis, protein design, and biomarker discovery. Anthropic says Claude Science uses BioNeMo Agent Toolkit skills to connect to life-sciences models and libraries in BioNeMo, including Evo 2, Boltz-2, and OpenFold3. So, for readers, one useful shorthand is: connectors link Claude to systems; skills define how Claude should use those systems. 

The point of this architecture  is that it is reusable, composable, and extensible. Anthropic’s docs emphasize that labs can add custom skills, and the connectors directory is designed to grow. This suggests that in the near future, it would be very natural to see labs add connectors to ELNs, LIMSs, internal assay APIs, institutional data catalogs, microscopy stores, or bespoke Slurm wrappers, and add skills for recurring analysis patterns such as scRNA-seq QC, DESeq2 differential-expression report generation, ATAC-seq peak annotation, or standard figure polishing against a lab style guide. You can search for  live lists of connectors (such as the public connectors directory) for MCP-style resources but you can also make your own.  Additionally, the Skills docs and BioNeMo Agent Toolkit repository are starting points for making or incorporating new skills. 

I wanted to use Claude Science to create a reusable bulk RNA-seq analysis — not a one-off script against one dataset, but a pipeline I could hand the same three file types (sample metadata, a gene-count matrix, a GTF) and get a complete, timestamped, reportable analysis back. And I wanted it built in a way that a second person — a bioinformatician extending it, or a reviewer auditing it — could take over without me in the room.  This meant committing it to Github.

The interesting part of the experience wasn't that the agent wrote R. It's how it got from a paragraph of intent to a determinative, version-controlled artefact with a complete provenance trail. That's what this section is about.

I didn't drip-feed requirements. I wrote one structured prompt describing the inputs, the outputs, and — critically — the method of work I wanted, then asked it to plan before doing anything:

Yes, it's a very high-level, low-detail prompt.  But it works.  This speaks to the capability of LLM's and their associated AI's to replicate work on tasks that have been described and discussed thousands of times online.  As it should be. 

Two things in that prompt did most of the work. First, "assume these will be the standard input for a generic pipeline that can be re-used" — that one sentence is what turned a script into a config-driven tool. Second, "plan your work using the elephant carpaccio method, create tests for each slice" — I was dictating an engineering discipline, not just an output.  This is the same pattern I use during agentic coding with Claude Code.

The agent came back with a plan before touching code: ten thin vertical slices (Slice 0 environment + skeleton, Slice 1 IO + gene-name map + config, … through Slice 8 Rmd assembly + real-data run, Slice 9 package + document), each ending in a saved artefact and each with its own test. I approved it, and only then did work start.

The elephant-carpaccio structure meant every slice was a complete, testable increment rather than a horizontal layer. By the end there were eight R modules under scripts/deseq2_bulk/R/ — io.R, describe.R, deseq.R, de.R, enrich.R, viral.R, plots.R, config.R — plus run_pipeline.R, two R Markdown report templates, and a config.yml capturing every analysis decision. Nothing was hard-coded: paths, contrasts, FDR thresholds, gene-set collections all live in the config.

All unit tests passed during development followed by a full end-to-end test on synthetic data at the end. 

On the real data, the pipeline produced results that not only made biological sense but matched exactly with the code-base output that I had previously generated using agentic coding. So, in all, this counted as an independent validation of the code that I had written or an independent validation of Claude Science (depending on the point of view you wish to take).

From here, it's easy to imagine how this applies to a reviewer or a new bioinformatician looking at this codebase for the first time.  Not only is a codebase present but a test data set used for its development as well as unit tests and end-to-end tests.

The repo creation and push were driven by prompts, not by me dropping to a terminal:

Note the guardrails embedded in the prompt: don't commit results (they're regenerable — the repo ships code, not data), and run a session-close discipline that reconciles the documentation (a description of features of the software, progress made towards developing those features, and a code-walkthrough document) before pushing. The generated outputs stay gitignored and out of version control by design; the code, tests, config, and docs go up. The final state is a single clean commit on main — working tree clean, nothing uncommitted — pushed to the private repo claude-science-test-drive.

Put together, the person who clones this repo cold gets:

Runnable code with no hidden dependencies — a config-driven pipeline whose only inputs are the three documented file types, plus a test runner that passes on a fresh clone with zero access to the original data.

A synthetic end-to-end path — they can run the whole pipeline start to finish on generated data and see it work before pointing it at anything real.

Reports and a code walkthrough — HTML reports show the shape of the output; the walkthrough document explains the module structure and the non-obvious design decisions (replicate collapsing, the msigdbr API pins, how figures are embedded in the Rmd).

A README that tells a newcomer exactly what to do — add your own metadata, or run the e2e test with the provided mock metadata.

Provenance they can interrogate — every result traces back through the dependency graph to code, environment, and inputs.

Specify the method, not just the output. "Elephant carpaccio, tests per slice, synthetic e2e" bought me a test suite that later proved the code was pickup-ready. Asking only for "a DESeq2 analysis" would not have.

Say "reusable" out loud. The single instruction to treat the inputs as a standard interface is what produced a config-driven tool instead of a script welded to one dataset.

The headline, for me: the conversation didn't just generate code, it generated code plus the evidence that the code does what it claims — tests that pass on a clean clone, a synthetic dataset anyone can run, and a provenance record that ties every output back to the exact command and environment that produced it. That's the difference between an AI that writes code and one that hands off a project.

For launch coverage and product documentation, the most useful links are the Anthropic launch announcement, the Claude Science product page, the Reuters launch coverage, the connectors directory, the MCP connector docs, and the Agent Skills overview. For background on why Anthropic leans so hard on multi-agent design, the best technical explainer is How we built our multi-agent research system. 

For work by people or groups involved in early adoption or adjacent beta-style use, see examples Anthropic itself highlights: the Garvan Institute customer story, the launch-post examples involving Manifold Bio, the Allen Institute, and UCSF, the Xaira Therapeutics early-access post, and Anthropic’s AI for Science Discourse community. For the BioNeMo method layer underneath Claude Science, the most relevant external reading is NVIDIA’s BioNeMo Agent Toolkit repository and its launch coverage from NVIDIA Newsroom. 

If you're working at the intersection of bioinformatics, data science and agentic ai coding, check out the recursivehuman.com website where you can book a free introductory phone call or write to me at [email protected]