technical overview

how a run becomes an artifact

from question to a planned run, a grounded result, and the artifact and record behind it. anthropic direct or through openrouter, across the model families your plan includes — or bring your own key once you sign in.

try .bloom*where the run executes

the pipeline

five steps between a question and a result.

the orchestrator is the central routing layer — it classifies intent, selects models and tools, manages multi-turn context, and enforces quality guardrails before results reach the user.

query
natural language query
describe what you need in plain english — a target, a compound, or a research question.
intent
intent detection
the runtime interprets the request and routes it toward the capabilities that can answer it.
model
provider selection
the language layer uses the configured model path, with the model choice kept separate from the biomedical work.
tools
tool execution
the selected tools execute through the runtime and pass their outputs into the next required step.
quality
quality evaluation
results are checked, grounded, and returned as interactive cards with their source context.

model choice

pick the language model that plans the run.

Ivy plans the run with the language model you pick; the scientific models compute it. signed-in plans choose among their model families; guest runs use one fixed model.

model
Choose among the model families your plan includes; that is what you get. Going beyond them with your own provider key is planned. Anthropic is called directly when configured; the other families go through OpenRouter. A self-hosted deploy can run on your own hardware.

four ways in

one run, four ways in.

the same run starts from the browser, a curl request, an MCP client or the cli. the tabs say which doors need an account.

one runtime, four ways in — start free here or bring it to your agent.chat + curl need no account; cli + mcp add saved sessions, higher quota and the full catalog.

ask in the browser. guest chat starts a bounded run without an account.

open a guest chat

no account needed · start with up to $1 in guest computesame request, same .bloom* registry — an agent pastes what a person would.just the compute? submit one tool job directly

500+ scientific tools

each tool is typed, normalized and rendered.

tools are organized by domain and executed in parallel on serverless gpu. each tool has a typed schema, normalizer, and canvas card renderer.

structure prediction
protein folding (esmfold, openfold), binding site detection, homology modeling, and structure alignment.
molecular generation
de novo design (genmol), fragment growing, scaffold decoration, and safe fragment ingestion.
property prediction
admet profiling, toxicity screening, drug-likeness filters, solubility prediction, and medchem alerts.
synthesis planning
retrosynthetic routes, reaction feasibility, vendor sourcing (zinc, molport), and cost estimation.
literature & databases
pubchem, uniprot, chembl, wikidata, clinical trials, patent search, and citation extraction.
target assessment
druggability scoring, binding pocket analysis, selectivity prediction, and cancer genomics (tmb/msi).
genomics & multi-omics
bulk/single-cell rna-seq, deseq2, variant calling, epigenomics, and hi-c 3d genome analysis.
molecular docking
diffdock, gnina, colabdock, mm-gbsa rescoring, and pose visualization with mol*.

canvas & passports

every result renders as a card you can work with.

3d molecular viewers, docking pose visualizations, volcano plots, and more. the card registry dispatches to the right renderer automatically.

typed result cards
the result registry maps tool outputs to an appropriate interactive view, with a generic fallback when no bespoke view exists.
domain sub-renderers
domain-specific renderers handle structures, docking poses, plots, and other scientific result shapes.

results from multiple tools are aggregated into a single compound passport — a unified view of everything known about a molecule. a passport is what a chain of tools produces together; it is an output of the platform, not the thing the platform is.

admet →
docking →
synthesis →
vendors →
literature →
compound passport

one record, every client

signed in, every client writes to the same record.

the web app, curl, the terminal and the MCP server all reach the same runtime. signed-in runs from the web app, the terminal, curl or MCP leave a tamper-evident record you can check, and so does a guest chat, from the browser tab it is open in, while the guest session lasts. edit a row and the chain breaks at the verifier. it detects modification; it does not prevent it, and it is not access control.

the runtime under .bloom* is pleach — a fair-source agent runtime whose typed audit row gives you per-run provenance, deterministic replay, and time-travel checkpoints.

ready to try it?

describe a target, a compound, or a question.

.bloom* handles the rest.

try .bloom*read the docs