Appearance
A paper published in Nature on September 16 reports a more ambitious way to make scientific literature machine-usable than simply letting a chatbot read a PDF. Paper2Agent turns a paper, its code, data, and workflows into an executable agent interface that can answer questions, reproduce analyses, and apply the original methods to new inputs.
The core idea is not brand new this week. An earlier Paper2Agent preprint appeared in September 2025. What is new is the peer-reviewed Nature publication and its broader evaluation across computational biology papers, including a large-scale test of how often the approach can actually turn published research software into reliable tools.
That distinction matters. The interesting result is not that a language model can discuss a manuscript. It is that a system can sometimes convert a paper's executable scientific contribution into a structured interface, test that interface against the original implementation, and then expose it to an AI agent through natural language.
From a paper to tools, resources, and workflows
Paper2Agent starts from a manuscript and its associated code repository. A multi-agent pipeline inspects the research artifacts and builds a Model Context Protocol, or MCP, server for the paper.
The generated server separates the paper into three kinds of components. Tools are executable functions that represent operations from the original research code. Resources expose static material such as the manuscript, supplementary files, datasets, and documentation. Prompts encode multi-step procedures that help an agent use those tools in the intended order.
This makes the system materially different from retrieval over a paper's text. A retrieval system can help an agent find the method section that describes an analysis. Paper2Agent tries to give the agent a tested implementation of that analysis.
The framework also includes an execution-and-repair loop. Generated tools are run against examples from the original repository, failures are diagnosed, and the system attempts repairs. Once a tool passes its tests, it is locked rather than continuously regenerated during normal use. The goal is to reduce a particularly dangerous failure mode in scientific agents: producing plausible-looking code that does not actually reproduce the source method.
The authors demonstrate the approach with agents based on AlphaGenome, Scanpy, and TISSUE. These examples span regulatory-variant interpretation, single-cell analysis, and spatial transcriptomics.
The large-scale test is the important part
The strongest evidence in the paper comes from the attempt to apply the pipeline across 100 computational biology papers.
Paper2Agent successfully converted 74 of those papers into working agents. Across those successful conversions, it proposed 599 tools, of which 593 passed the automated validation process.
That result is encouraging, but it also gives the system a useful boundary. Paper2Agent did not convert every computational paper. The failures included missing executable code, unavailable data or model artifacts, broken environments or dependencies, and research scripts that were too specialized to generalize into reusable tools.
In other words, the framework is partly an AI-agent system and partly a stress test of scientific software packaging. If a paper cannot be reproduced from the artifacts its authors released, an agent cannot reliably manufacture the missing pieces.
The authors also evaluated the generated agents on 300 tutorial-derived questions. With Sonnet 4 as the underlying model, Paper2Agent achieved 91.2 ± 1.6% accuracy. In the reported comparison, Claude Code with direct repository access scored 80.3 ± 2.3% using Sonnet 4 and 86.3 ± 1.1% using Sonnet 4.6.
Those are benchmark results from the study, not evidence that Paper2Agent will outperform direct code access on arbitrary scientific work. The benchmark is constructed from papers that the pipeline could successfully agentify, and the system benefits from having converted the source repository into a constrained, purpose-built tool interface.
Still, the comparison supports a useful engineering hypothesis: for scientific software, carefully exposing validated operations may be more effective than giving a general-purpose coding agent an entire repository and asking it to infer the right workflow every time.
Reproducibility becomes part of the agent interface
The paper's most interesting contribution may be architectural rather than conversational.
Scientific reproducibility is usually treated as a property of a publication package: paper, code, environment, and data. Paper2Agent instead tries to make reproducibility operational. The agent's available actions are derived from the paper's implementation, and those actions are tested before they become part of the interface.
That can reduce the distance between reading a method and using it correctly. A researcher could ask an AlphaGenome-derived agent to analyze a variant or a Scanpy-derived agent to process a dataset without manually reconstructing the exact command sequence from documentation and notebooks.
The paper also reports generalization beyond biology. Across 42 execution-based tasks from 10 non-biology computational papers, Paper2Agent achieved 98.1 ± 0.8% accuracy over five runs. That is a small evaluation compared with the computational-biology experiment, but it suggests that the mechanism is not tied to one scientific domain.
The design is particularly relevant to fields such as bioinformatics, where important papers frequently ship with substantial software pipelines. Many of the practical barriers to reusing those methods are not conceptual. They are dependency management, data formatting, command selection, and knowing which part of a repository actually implements the published analysis.
Hypothesis generation is more interesting, and much less settled
The authors also use multiple paper agents together for scientific hypothesis generation.
In one example, agents representing different genomic resources were combined to analyze an ADHD genome-wide association dataset. The system prioritized the variant rs1626703 and proposed a possible mechanism involving altered splicing and expression of MPHOSPH9 in glutamatergic neurons.
The paper presents this as a computationally generated candidate hypothesis. It is not experimental validation that the variant is causal, nor evidence that the proposed mechanism is biologically correct. The authors explicitly state that the hypothesis requires experimental validation.
That boundary is important because the agent architecture can make a chain of computational operations look more authoritative than it is. A validated tool call can establish that the software executed as intended. It cannot establish that the biological interpretation produced downstream is true.
The same distinction applies to collaboration between paper agents. Combining methods from several papers can surface relationships that a human researcher might not have tested, but the result remains a hypothesis until it is evaluated with appropriate scientific evidence.
What remains unresolved
Paper2Agent does not solve the reliability problem for scientific agents. It narrows part of it.
The system is strongest when a paper already has accessible, executable, reasonably generalizable code and data. Its 74-of-100 conversion result shows how often those prerequisites were met in the sampled computational biology literature, but it should not be treated as an expected success rate for science as a whole.
The evaluation also focuses heavily on computational research. Wet-lab protocols contain tacit knowledge, physical constraints, undocumented judgment calls, and experimental failure modes that cannot be captured simply by wrapping a repository in an MCP server. The paper's framework can expose computational components of scientific work much more directly than it can reproduce the full process of experimental science.
There is also a second validation problem after the tool layer. Even when every individual tool is correct, an agent can still choose the wrong tool, combine results incorrectly, or make an unjustified scientific interpretation. Tool reproducibility and scientific reasoning are separate layers of reliability.
A stronger future test would therefore evaluate not only whether paper agents execute the original software correctly, but whether independent researchers using them reach valid conclusions on genuinely new problems. Prospective studies, external replications, and domain-expert review would provide stronger evidence than tutorial-derived benchmarks alone.
Why this matters
The scientific literature increasingly contains methods that are useful only when the associated code can be installed, understood, and applied correctly. Paper2Agent treats that gap as an interface problem.
Its strongest result is not the idea of a paper that can talk. It is the attempt to turn published computational methods into tested, machine-callable research objects while preserving links back to the source implementation.
The Nature study provides credible evidence that this can work across a substantial subset of computational biology papers. It also reveals the limiting factor clearly: the quality and completeness of the research artifacts still matter.
That makes Paper2Agent less a replacement for scientific publishing than a possible new layer on top of it. Better agents will not remove the need for reproducible code, accessible data, explicit methods, and experimental validation. They may make the value of those practices much more immediate.