Workflow of Paper2Agent. Before you read: I use LLMs to help me proofread and edit my writing. What follows reflects my own thoughts and experiences — read on if you feel it’s worth your time. More on AI usage. On Tuesday this week, I presented an interesting new Nature paper at our journal club: “Reimagining research papers as interactive and reliable AI agents” by Miao and colleagues. But instead of only presenting the paper, I also wanted to show what the idea looks like in practice. Before the journal club, I used Paper2Agent to create working AI agents for HDStIM and Seurat. During the presentation, I showed how I created those agents and demonstrated their output on test datasets. What made the experience especially interesting was that I did this without writing the analysis code myself, manually installing the packages, or configuring their software environments. I interacted with the methods mostly through natural language. That, in simple terms, is the idea behind Paper2Agent. The problem: papers describe methods, but using them is still hard Scientific papers are how we communicate new discoveries and methods. But papers themselves are passive. Suppose you find a paper describing a useful computational method and want to apply it to your own data. You may still have to: find the GitHub repository, understand the documentation, install the correct packages, resolve dependency problems, identify which scripts or notebooks to run, understand input and output formats, reproduce an example, and finally adapt the code to your own data. The Paper2Agent authors describe this gap between reading about a method and actually using it as an important barrier to research reuse. Even when code is publicly available, getting it to work can require substantial technical effort. In computational biology, this problem is very familiar. Often, the difficult part is not understanding the biological question. It is getting all the software pieces to work together. What if the paper could use its own method? Paper2Agent asks a different question: What if we could turn a research paper into an AI agent that can actually perform the method described in the paper? This goes beyond asking ChatGPT or another language model to summarize a PDF. Paper2Agent combines information from the manuscript, code repository, tutorials, supplementary files, datasets and workflows, and converts them into something an AI agent can use. The paper describes the resulting agent almost like a virtual corresponding author: something that can answer questions about the method, but also help apply it. Instead of asking: Which function should I run? you can increasingly ask: Apply this method to my dataset. That is a major change in how we interact with scientific software. The key idea: tools, resources and workflows Paper2Agent uses the Model Context Protocol, or MCP. You do not need to understand MCP in detail. A simple way to think about it is: MCP gives an AI agent a standard way to access tools and information. Paper2Agent creates three important components. Tools are functions the agent can execute, such as quality control, normalization, clustering, prediction or visualization. Resources include the paper, source code, datasets, supplementary materials, tables and other information the agent may need. Prompts describe multi-step workflows, including the correct order in which tools should be used. For example, a single-cell RNA-seq workflow may involve quality control, normalization, feature selection, dimensionality reduction, clustering and annotation. Instead of expecting the language model to invent that workflow every time, the workflow itself can become part of the agent. Why testing matters One obvious concern is reliability. What happens if an AI misunderstands a package and creates code that looks reasonable but produces the wrong scientific result? Paper2Agent does not simply generate functions and assume they work. Its workflow includes finding the associated codebase, creating an isolated environment, identifying tutorials, running those tutorials, extracting reusable tools and testing them against reference outputs. Functions that repeatedly fail validation are excluded from the final MCP server. This is an important distinction. There is a difference between: asking an AI to generate new analysis code every time and allowing an AI to call a reusable tool that has already been tested against the original implementation. The second approach has the potential to be much more reproducible. The Scanpy example The paper demonstrates this idea using Scanpy, a popular Python package for single-cell analysis. Paper2Agent created tools for common analysis steps and also generated a workflow describing how those tools should be used. The authors could then give the Scanpy agent a dataset and ask it to perform a standard preprocessing and clustering pipeline. The agent inspected the data, executed the workflow and produced results comparable to analyses performed by human researchers following the standard tutorials. This example was especially relevant to me because it is close to the type of computational biology work many of us perform regularly. My experiment: HDStIM and Seurat agents I wanted to see whether the idea would work beyond the examples presented in the paper. My setup was slightly different from the authors’ setup. I was working in Positron and using Codex as the coding agent. I installed Paper2Agent as a skill in Codex. Then I asked the Paper2Agent skill to agentify two methods: HDStIM and Seurat. I did not manually write the implementation for either agent. I also did not first install and configure the packages myself or build their analysis environments by hand. Paper2Agent handled the process of inspecting the available software and examples, setting up what was needed, and turning useful functionality into tools the agent could call. I then tested both agents on example data. Both worked as intended. During our journal club, I presented the Nature paper together with this practical demonstration: how the agents were created and what they produced when given test data. For me, this made the paper much more interesting than presenting the concept alone. Agentifying a method is different from simply generating code A general coding agent can already inspect a GitHub repository, write some code and try to answer a scientific question. That is useful. But Paper2Agent is trying to create something more reusable. A simple way to think about the difference is: General coding agent Paper → repository → understand code → write code → run analysis Paper2Agent Paper + repository → extract methods → test them → create reusable tools → let an agent use those tools The expensive work of understanding and validating the research software can therefore happen during agent creation rather than being repeated from scratch for every scientific question. Not every paper can become an agent The approach is not perfect. The authors tested Paper2Agent on 100 computational biology papers. Seventy-four were successfully agentified, producing 599 proposed tools, of which 593 passed automated validation. Failures were often caused by missing code, unavailable data, dependency problems or scripts that could not easily be generalized. This result is interesting for another reason. Perhaps how easily a paper can be agentified is itself a test of reproducibility. If an automated system cannot determine how to install the software, run the examples and reproduce the results, future human researchers may struggle as well. The authors even suggest that one day papers might contain an “agent availability” section, similar to today’s data availability and code availability sections. After trying the approach myself, that idea no longer feels very far away. From “read my paper” to “use my paper” Scientific publishing has slowly become more executable. We moved from papers alone to papers with code repositories, notebooks, containers and reproducible environments. Paper2Agent suggests a possible next step: publish an agent that knows how to use the research. A future paper might effectively provide four layers: Paper: understand what was discovered. Code: inspect how it was implemented. Data: reproduce the analysis. Agent: ask the method to work on your data. That could greatly reduce the distance between discovering a useful method and actually trying it. And agents could work together The paper goes one step further. If different papers become agents, those agents can potentially work together. A method agent could interact with a dataset agent. Another agent could provide experimental evidence. An AI co-scientist could combine their tools and resources to investigate a new question. The authors demonstrate this by combining multiple agents to study a psoriasis-associated genetic locus. Today, papers are connected mainly through citations. In the future, they may also be connected through executable agents. The scientist is still responsible for the science Paper2Agent does not remove the need for researchers. The authors emphasize that scientists must still select research directions, judge evidence and evaluate scientific interpretations. That is also how I see the value of this approach. A surprising amount of research time goes into installing software, fixing environments, understanding APIs and translating tutorials into working code. If AI agents can reliably handle more of that layer, researchers can spend more time on the questions that matter: What should we test? What does the result mean? Does it make biological sense? What should we do next? Large language models have already started changing how scientists write code. Paper2Agent points toward something slightly different. The future may not only be AI writing scientific code for us. It may also be scientific methods becoming validated tools that AI can directly operate. After creating working HDStIM and Seurat agents and demonstrating them alongside the paper, that possibility felt much less theoretical. The paper may remain the record of the science. The agent may become one of the ways we actually use it. Follow this blog via RSS What Is RSS and Why It Still Matters To comment on this blog post, use the comment box below or any of the following methods: Email rohit@rohitfarmer.com; XMPP/Jabber rohitfarmer@yax.im; Matrix @rohitfarmer:matrix.org.