Biomni: A Biomedical Agent That Plans With a Data Lake and Executes Python
Biomni: a general-purpose biomedical AI agent
At a glance
- What is it?
- Biomni is a Stanford-published Python agent that turns natural-language research requests into code execution against a bundled biomedical data lake. The interesting part is the retrieval-augmented planning step; the painful part is the 11GB download and the environment build.
- Who is it for?
- Adopt Biomni if your group already runs conda environments, has roughly 11GB of disk and bandwidth to spare, and wants an agent that writes and runs Python against a curated biomedical data lake rather than answering from model weights.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Biomni is trying to close between an LLM and a lab notebook
A general chat model asked to plan a CRISPR screen will produce fluent prose and no executable artifact. Biomni's stated goal is narrower and more useful: autonomously execute research tasks across biomedical subfields by combining LLM reasoning with retrieval-augmented planning and code-based execution. The README frames the payoff as generating testable hypotheses, not publishing results. That framing matters, because it tells you the intended user is a researcher who wants a first draft of an analysis pipeline, not a validated finding. The examples in the README are concrete about the shape of a request: plan a CRISPR screen to identify genes regulating T cell exhaustion and generate 32 genes that maximize the perturbation effect; perform scRNA-seq annotation at a given path and generate a hypothesis; predict ADMET properties for a SMILES string. Each of those needs different tooling, which is why the project ships a data lake rather than a single model.
Retrieval-augmented planning plus a code interpreter, not a fine-tuned model
The README describes the architecture in one sentence: LLM reasoning, retrieval-augmented planning, and code-based execution. Read that as three stages. The agent receives a natural-language task, retrieves relevant context from its data lake, plans a sequence of steps, and then executes those steps as code. The data lake is the part that distinguishes Biomni from a thin wrapper around an API. It is downloaded automatically on first run and the README puts it at roughly 11GB. The A1 constructor takes a path argument that points at where that data lives, plus an llm argument naming the model. So the agent object is the unit of state: it owns a data directory, a model choice, and a timeout, and its go() method is the entry point for a task. What the README does not specify is how the retrieval step is implemented, what the lake contains, or how the planner decides which tools to invoke. Those are the questions a serious evaluation would need answered, and the repository's docs directory is the place to look rather than the README.
Installing Biomni means building an environment first, then a pip package
The install path is deliberately two-stage. First you follow biomni_env/README.md, which the project describes as setting up a massive software environment through a single setup.sh script. Then you activate the environment and install the package:
conda activate biomni_e1 pip install biomni --upgrade
For the newest code the README offers a source install: pip install git+https://github.com/snap-stanford/Biomni.git@main. Configuration comes next, and the recommended route is a .env file copied from .env.example. ANTHROPIC_API_KEY is listed as required; OPENAI_API_KEY, OPENAI_ENDPOINT, GEMINI_API_KEY, GROQ_API_KEY, AWS_BEARER_TOKEN_BEDROCK and AWS_REGION are optional and depend on which provider you use. LLM_SOURCE accepts values such as OpenAI, AzureOpenAI, Anthropic, Ollama, Gemini, Bedrock, Groq, or Custom. Two defaults are worth noting because they affect cost and disk: BIOMNI_DATA_PATH defaults to ./data, and BIOMNI_TIMEOUT_SECONDS defaults to 600. One provider quirk is documented: if you plan to use Azure, prefix the model name with azure-, as in llm='azure-gpt-4o'.
Skipping the 11GB data lake is the first thing to learn
By default, constructing an agent triggers the datalake download. The README gives an escape hatch: pass expected_data_lake_files = [] to the A1 constructor, which skips automatic download and makes initialization faster. The documented use cases are faster testing and development, environments with limited storage or bandwidth, and situations where you only need tools that do not require datalake files. That last clause is doing a lot of work and the README does not enumerate which tools fall on which side of the line. If you are evaluating Biomni rather than using it, this is the flag that makes evaluation cheap. Note also that the path argument and BIOMNI_DATA_PATH both point at the same concept, so teams running multiple agents on one machine should decide early whether they share a data directory or each carry their own 11GB.
Known package conflicts and a Gradio version ceiling
Two constraints in the README are the kind that cost an afternoon if you miss them. First, some Python packages are not installed by default because of dependency conflicts. The README states that if you need those features you must install the packages manually and may need to uncomment relevant code in the codebase, and it points at docs/known_conflicts.md for the current list. Uncommenting library code to enable a dependency is a maintenance signal: upgrades can move those lines, and a pinned environment is the safer posture. Second, the Gradio interface requires Gradio 5.x and the README notes that API changes in 6.0 break it, so an environment with Gradio 6.x needs a downgrade. The demo itself is launched with agent.launch_gradio_demo() and defaults to binding 0.0.0.0 on port 7860. If you expose it, the documented option require_verification=True gates access behind an access code whose default is "Biomni2025", which is a default you should change before putting the port anywhere reachable.
Where Biomni is the wrong tool
The 600-second default timeout is a real boundary. A task that legitimately needs longer, such as a large scRNA-seq run, will hit it unless you raise BIOMNI_TIMEOUT_SECONDS or set default_config.timeout_seconds, as the configuration section shows with a value of 1200. That is a config change, not a design flaw, but it means the out-of-the-box experience is tuned for interactive tasks rather than batch jobs. The bigger limitation is one the README implies rather than states: an agent that plans and executes code against a curated data lake is only as good as that lake and the retrieval step over it. Nothing in the material describes how retrieval quality is measured or how a user would audit which lake entries informed a plan. For a lab that needs reproducible pipelines with provenance, an agent that generates code per request is a starting point, not an audit trail. And if your work is a single well-defined task with a known tool, the setup cost of a two-stage conda environment plus an 11GB download is not repaid.
How Biomni differs from a general coding agent
The obvious comparison is a general-purpose coding agent such as Claude Code or an equivalent, pointed at a bioinformatics repository. Those tools are strong at editing existing code and running shell commands, and they assume you already know which packages and reference data you need. Biomni inverts that assumption: it bundles the reference data and a retrieval step over it, so the agent can supply domain context the coding agent would have to be told. The trade is control. A coding agent works inside your existing environment and your existing data layout; Biomni wants its own conda environment, its own data path, and its own model configuration through LLM_SOURCE. If your lab already has a validated Snakemake or Nextflow pipeline, a general coding agent that edits that pipeline is the lower-risk choice. Biomni is aimed at the earlier moment, when the pipeline does not exist yet and the question is what to try.
Licence, release cadence and what versioning implies
Biomni is Apache-2.0, which permits commercial and academic use and modification, and includes an explicit patent grant and a requirement to state changes. That is a permissive licence, and it does not by itself resolve the terms of the LLM provider you point LLM_SOURCE at, nor the licences of the data lake contents, which the README does not enumerate. Those are separate questions and worth checking against docs/known_conflicts.md and the data documentation rather than assuming Apache-2.0 covers everything the agent touches. On cadence, the project is at v0.0.8 with v0.0.7 roughly a month earlier and v0.0.6 about five weeks before that. A 0.0.x series moving that fast means APIs can shift between releases; pinning a version in your environment file is the practical response, and the README's own upgrade command (pip install biomni --upgrade) is the opposite of pinning. This is not legal advice; read the licence text and your provider's terms yourself.
Editorial conclusion
Adopt Biomni if your group already runs conda environments, has roughly 11GB of disk and bandwidth to spare, and wants an agent that writes and runs Python against a curated biomedical data lake rather than answering from model weights. Do not adopt it as a lightweight library: the README describes a massive software environment built by a single setup.sh, known package conflicts that require manual installation and uncommenting code, and a Gradio interface pinned below version 6.0. Before committing, verify three things in your own checkout: that biomni_env/README.md builds cleanly on your platform, that docs/known_conflicts.md does not list a package your pipeline depends on, and that your chosen LLM_SOURCE has a working key in .env.
Community notes