Robin, a multi-agent system for automating parts of scientific discovery

What the system actually does

Robin is described as a multi-agent system for automating scientific discovery, from Future House, with a blog post and an arXiv preprint linked for the detail.

The architecture is a pipeline of agents, and the README's own description of the input tells you how it is meant to be used. To run Robin as it was used in the manuscript, you only input the name of a disease, with no other text. The hypothesis generation and the experiment design are then driven from that.

That is an important framing. This is not an assistant you chat with, it is a batch pipeline whose input is a research question and whose output is a set of candidate hypotheses and the experiments to test them.

The two Edison platform agents are named in the prerequisites: Crow, and Falcon, which is now called Literature. The name change is the kind of detail that matters when you are following documentation written at different times, since searching for Falcon in a paper from last year will not match the current API name.

The data analysis portion of the repository requires access to the Edison platform, and the README is explicit that without it, all the hypothesis and experiment generation code can still be run. That is a sensible split for a research artefact, because the generation half is the part you want to read and modify, and the analysis half is the part that needs the platform.

The project is Apache-2.0 licensed, written in Python, on the main branch, with the last push on 2026-04-21.

Prerequisites and the two API keys

The prerequisites are short, and both of them are things you pay for or sign up for.

Python 3.12 or higher is required. Then there is the Edison platform key, EDISON_API_KEY, obtained from the Edison profile page, and the README spells out the sequence: create an Edison profile, purchase credits, then create an API key under Account, Profile, API Tokens. The credit purchase is not incidental, because the platform agents are what cost money to run.

The second key is for your chosen language model provider, with OPENAI_API_KEY given as the example. The README explains that Robin uses LiteLLM, so it can support various providers. That is the detail worth noting: the model is not hard-wired to one vendor, and LiteLLM handles the abstraction, so switching providers is a matter of changing which key and model you configure.

The cost picture is therefore two-part. The platform credits pay for the literature and analysis agents, and the model key pays for the language model calls that generate hypotheses and design experiments. A team running this at scale is making two kinds of API spend.

The Docker alternative is the recommended setup, and the README's reasoning is that it avoids the most common installation issues, which for a project with a large dependency tree and a notebook workflow is a real class of problem rather than a hypothetical one.

The first step is building the image:

docker build -t robin .

then the keys, and here there is a warning that will save you an afternoon:

cp .env.example .env
# Edit .env and fill in your EDISON_API_KEY and OPENAI_API_KEY

The README is emphatic that you must not wrap the values in quotes, giving OPENAI_API_KEY=sk-abc123 rather than OPENAI_API_KEY="sk-abc123", because Docker reads the file differently from Python and will include the quotes as part of the key. That is a genuinely obscure failure, since the key looks correct in the file and fails only at the API call.

The run step then starts Jupyter on a published port:

docker run -p 8888:8888 --env-file .env robin

The README explains the output: Jupyter prints three URLs and you should use only the one that starts with http://127.0.0.1:8888/, since the other two are internal container addresses and will not work from your browser.

Running from a checkout and where to change the behaviour

The manual setup path is the usual one. Clone the repository, create and activate a virtual environment, and install the package with its development extras, which include Jupyter:

uv venv .venv
source .venv/bin/activate

uv pip install -e '.[dev]'

A plain python3 -m venv is given as the alternative, and pip install -e '.[dev]' as the alternative to uv. The project uses pyproject.toml for dependency management.

The keys are then set by copying .env.example to .env and editing it. The README says Robin loads that file automatically at startup, and that you can alternatively export the variables in your shell or pass them directly when creating the RobinConfiguration object. Having all three routes is a small quality-of-life thing that avoids the usual friction of a tool that only supports one.

The run step is a notebook, and the README's guidance on how to use it is worth reading closely. Navigate to the robin directory with the environment activated and start Jupyter:

jupyter notebook
# OR
jupyter lab

The advice on tuning is specific and unusual. If you wish to optimize how Robin searches for experimental models and therapeutic candidates, the suggestion is to change the internal prompts of Robin through prompts.py, not the initial input to the pipeline. The initial input is a disease name, and the prompts are where the search behaviour lives.

That is a meaningful architectural point. The pipeline is parameterised by prompts rather than by its entry points, which is what makes the system a research instrument rather than a fixed program. The consequence is that the file to read when you want to understand or change what the system does is prompts.py, and the README says so before you run anything.

It also explains why the system is published as sample code with a paper behind it. The contribution is the structure of the loop and the prompts that drive it, and the README treats the prompts as the thing to modify.

How this fits against the alternatives

The comparison to make is with the other way of doing this, which is a person reading papers.

The case for a system like this is throughput. A named disease has a literature, and reading it well is a multi-day activity for one researcher. If a system can produce a ranked set of hypotheses with the experiments that would test them, that changes how much ground a team can cover, and the hypotheses are the useful artefact even when the experiment design needs a human to be right.

The case against is the one the project itself is careful about. The output is a model-generated hypothesis, and a hypothesis that sounds plausible and is wrong is more dangerous than no hypothesis, because it consumes a graduate student's month. The README's framing, that the results are for cross-verification rather than accusation, is the same idea applied to science: the output is a starting point for a human, not a result.

The second alternative is a general agent framework with a literature plugin. Several exist, and they would let you assemble the same loop yourself. The difference is that Robin is a specific arrangement of specific agents with specific prompts, published alongside a paper describing what it did. If you are writing your own, the prompts are the thing to take.

The third alternative is doing the literature search with a commercial tool and the design by hand. For a one-off question this is faster and safer, and the setup cost of Robin, which is an API key, credits and a notebook, only pays off if you intend to run it many times.

Two practical warnings for anyone evaluating it. The first is the cost, which is double and not bounded in advance, since a discovery loop that runs more literature searches and more model calls is exactly what a better result costs. The second is the environment, where the Docker path avoids the installation problems but hides what is actually installed, and you will want to change prompts.py at some point.

For a research group that wants to explore the design rather than use the result, this is a well-documented artefact with a paper attached, and that combination is rare in this area.

Editorial conclusion

Adopt Robin if you are a research team that wants to see an automated discovery loop end to end, and you are willing to pay for Edison platform credits. Skip it if you only want a literature search agent, since that is a much smaller problem. Verify first by running the hypothesis and experiment generation path without Edison access, confirming the prompts in prompts.py do what you expect, and only then connecting the platform and the model key.

Frequently asked questions

Official sources

1. Future-House/robin on GitHub
2. Issues
3. License: Apache-2.0
4. README