Biomedical agents / Engineering notebook
Biomedical agents for inspectable evidence.
ICI Innolabs’ Hetionet KG-based agent and Monarch KG-based agent are biomedical agents that investigate natural-language questions using independently developed knowledge graphs. The agents retrieve graph evidence and present answers with inspectable citations.
01 / The premise
An answer should have a trail
A biomedical question can cross several kinds of knowledge: a gene, the condition associated with it, a phenotype recorded for that condition, and the sources behind those assertions. A fluent answer can flatten those distinctions. The Hetionet KG-based agent and the Monarch KG-based agent keep the route through the graph visible.
Each evidence desk accepts a natural-language question, finds relevant entities, runs bounded Cypher against its own Neo4j graph, and returns claims linked to the rows retrieved during that investigation. The reader can inspect the exact query, returned values, native nodes and relationships, and available provenance. A saved recording lets anyone examine that experience without a model key or a live graph. Direct graph exploration provides another route: start from an entity and browse its recorded neighborhood without asking a model.
This design makes an answer more inspectable. It does not turn an association into a causal finding, and it does not make the generated interpretation scientifically correct by itself. That distinction matters equally to a researcher testing a hypothesis, a curator checking a source, and an engineer evaluating the system.
02 / Two evidence spaces
What each graph describes
A graph stores entities as nodes and their recorded relationships as edges. The type of each entity and edge matters: binds, treats, participates in, and has phenotype describe different assertions. Both demonstrators expose those distinctions, but they are separate applications over separate datasets.
Biomedical connections across domains
Hetionet brings together genes, diseases, compounds, pathways, anatomy, symptoms, side effects, and other categories. It was originally assembled for drug-repurposing research, but its typed relationships also support questions about pathway participation, disease associations, and recorded treatments. Its identifiers are category-qualified in the explorer: the TP53 gene is Gene:7157.
- Nodes
- 47,031
- Relationships
- 2,250,197
- Types
- 11 nodes · 24 edges
Phenotypes, disease, genes, and species
The Monarch Knowledge Graph integrates biomedical and ontology data around genes, diseases, phenotypes, and model organisms. Its Biolink categories and predicates, compact CURIE identifiers, species labels, sources, qualifiers, and explicit negation make the meaning of an association part of the record. For example, human CFTR is HGNC:1884 and cystic fibrosis is MONDO:0009061.
- Nodes
- 1,668,236
- Relationships
- 16,107,480
- Release
- 02 Sep 2026
These totals describe the dataset versions installed in the demonstrators. The public Monarch Knowledge Graph changes by release; the article does not imply that these are permanent totals or that the two databases have been merged. Hetionet’s overview and the pinned Monarch release provide upstream context.
03 / Shared architecture
One pattern, two deployments
The browser interface is built in Svelte and draws inspected evidence with Cytoscape. It talks to a FastAPI service over HTTP; server-sent events publish progress and run snapshots while a live investigation is underway. The backend owns a bounded tool loop using the OpenAI Responses API. Its tools inspect the installed graph schema, resolve entities, and execute guarded Cypher through Neo4j. The Hetionet KG-based agent and Monarch KG-based agent each run that pattern against their own database and their own curated recordings.
Hetionet KG-based agent
Monarch KG-based agent
Optional OLS name resolution; verify matches back in the Monarch Knowledge Graph
Saved JSON runs → UIReplay without live execution
Graph browsing → FastAPI → Neo4jGraph endpoints bypass the model
The diagram separates retrieval from presentation. The graph is the evidence source for a live answer. The model chooses questions and queries within the permitted tool boundary, then proposes structured claims; the backend checks their references before release. Saved JSON recordings are a different path through the interface: they replay captured execution states and evidence without contacting Neo4j or the model. The Monarch KG-based agent also offers a bounded EMBL-EBI Ontology Lookup Service search to discover candidate ontology identifiers. A candidate must be checked in the installed Monarch Knowledge Graph; lookup alone is not citable evidence of local coverage.
04 / The investigation loop
From question to an inspectable response
A question starts with entity resolution, not with a guessed edge. The agent can search a name or identifier and inspect the live schema to learn which labels and relationship types actually exist. It then submits a read-only Cypher query with explicit parameters and limits. The result is an artifact: query text, parameters, columns, row IDs, returned values, timing, truncation state, and native graph records where the query returned nodes or relationships.
- Question Investigate one question against one graph.
- Discover Find entities and inspect the available schema.
- Query Guard and run bounded, read-only Cypher.
- Retrieve Inspect evidence rows and native graph records; refine within budget.
- Claim Build structured claims from the retrieved evidence.
- Validate Check each citation against its actual evidence row.
- Answer Return supported claims with inspectable evidence.
Bounded loop Iterative retrieval stays within budgets, with at most two citation-repair turns.
Evidence gate Invalid or missing citations and truncated evidence are withheld; the result may be partial or unsupported.
The model may need more than one pass. It can refine a predicate, narrow a traversal, or retrieve complete rows after an oversized result. Finally it proposes claims with citations of the form q2:r1: query artifact q2, row r1 in this run. The backend rejects claims with missing citations, unknown artifacts or rows, or citations to truncated artifacts. It allows at most two citation-repair turns within the run budget, and the result can remain partial or unsupported if usable evidence is insufficient.
In the evidence view, selecting a statement takes the reader back to its cited rows and, when present, the corresponding graph records. A Cypher result that contains only counts or other scalar projections remains a table. The interface does not draw an edge by interpreting a pair of text columns as a relationship; drawn edges come from native Neo4j records. That keeps the visual explanation within what the query actually returned.
05 / Recorded examples
Two questions, two kinds of path
The following details come from the installed recordings, rather than hypothetical outputs. They show what a visitor can inspect in the demonstrators today.
Hetionet KG-based agent · Pathway membership
Which pathways does TP53 participate in?
The recorded question asks for up to five pathways ordered by identifier. The run first inspects the schema and resolves TP53 to the gene identifier 7157. Its evidence query matches the directed PARTICIPATES_GpPW relationship from a Gene to a Pathway. The essential lines of the recorded Cypher are:
MATCH (g:Gene {identifier: $gene_identifier})-[r:PARTICIPATES_GpPW]->(p:Pathway)
...
ORDER BY pathway_identifier ASC
LIMIT 5The five rows include AP-1 transcription factor network (PC7_1123), p53 pathway (PC7_12271), and p53-Dependent G1 DNA Damage Response (PC7_12274). They also retain the relationship source and license: the first two are recorded as PID via Pathway Commons, while the third is Reactome via Pathway Commons. The answer cites q1:r1–r5, so a reader can move from the claim to the five returned gene–pathway relationships. This is a sample of five sorted records, not every pathway connected to TP53 or a measure of pathway activity.
Monarch KG-based agent · Multi-hop connection
How does human CFTR connect to phenotypes?
The recorded question follows human CFTR (HGNC:1884) through cystic fibrosis (MONDO:0009061) to five phenotype records. The first query returns several distinct gene–disease predicates, including biolink:related_to, biolink:gene_associated_with_condition, and biolink:causes. The second query narrows the first step to a directed biolink:causes record and the second to biolink:has_phenotype, while excluding explicitly negated edges and choosing five phenotypes by identifier.
Its cited artifact q2 contains paths to Sinusitis (HP:0000246), Hearing impairment (HP:0000365), Depression, Anxiety, and Kidney stone. The Sinusitis statement points to q2:r1. In those five rows the gene–disease assertion names OMIM as its primary source, and the disease–phenotype associations name Orphanet. Source and qualifier fields are available for inspection; an absent publication field is not filled in by the answer.
Reading the path correctly is as important as finding it. The graph records a CFTR-to-disease assertion followed by a disease-to-phenotype assertion. It does not thereby contain a direct CFTR-to-Sinusitis edge, prove that every person with cystic fibrosis has Sinusitis, or predict an individual outcome. The five rows are selected examples, not a complete phenotype profile.
06 / Boundaries
What the checks do—and where judgment begins
Query scope
Both services restrict model-generated Cypher to a conservative read-only subset. Writes, administrative commands, and unbounded traversals are rejected. A run has a 120-second deadline and at most 12 Cypher attempts; each query has a 10-second timeout, variable traversals stop at four hops, and results stop at 100 rows or 128 KiB. These limits do not make a public service an authenticated research platform.
Citation integrity
Each released claim must point to complete rows from its current run. Unknown or truncated references are withheld. This confirms that the cited rows exist and can be inspected. It cannot judge whether the wording captures the biology, whether an upstream source is correct, or whether a graph path is causal.
Coverage and provenance
A missing edge means the selected graph and query did not return that edge; it is not proof that the relationship is absent in nature. Sources, species, qualifiers, direction, and explicit negation need to travel with the interpretation. The Monarch KG-based agent’s ontology lookup can help find a term, but only a checked graph record can support an answer.
These are research demonstrators. Their outputs can guide exploration and review, but they are not clinical advice, diagnosis, or a substitute for assessing the underlying evidence.
07 / Stakeholders
Different readers, different checks
The same evidence trail supports several kinds of work. Its value depends on the question a reader brings to it—and on recognizing what the graph cannot settle.
| Reader | Useful view | Critical question |
|---|---|---|
| Biomedical researcher | Follow typed multi-hop paths and compare candidate connections. | Which observed edges support this hypothesis, and what experiment would test it? |
| Clinician or translational researcher | Inspect disease and phenotype context without collapsing distinct assertions. | Does the cited record apply to this clinical context, population, and individual? |
| Data curator | Inspect IDs, source properties, species, direction, qualifiers, and negation. | Is an apparent connection a mapping issue, an upstream assertion, or a coverage gap? |
| Engineer or evaluator | Review exact Cypher, parameters, rows, status, and citation repair behavior. | Can this result be reproduced, and did the guardrails hold on this run? |
| Educator or research leader | Use a keyless recording to teach the difference between a fluent answer and inspectable support. | What evidence literacy and independent review would a real deployment require? |
08 / Explore
Start with a record, then ask your own question
Try the saved Pathway membership example in the Hetionet KG-based agent or Multi-hop connection in the Monarch KG-based agent. Their 20 and 10 curated recordings, respectively, replay without a key, provider call, or live Neo4j connection. For an entity-first view, use the graph explorer; it needs the graph service but no OpenAI key.
Custom questions use the visitor’s own OpenAI key and an independent live run. The key stays in page memory and is sent through the application server to OpenAI for that run; a refresh clears the browser’s copy. Live results are transient rather than a shared, persistent history. If a live question is still running, use Stop to cancel it: closing the stream or leaving the page does not cancel accepted work. Open the evidence view after each answer, follow a citation to its row, and read the relationship type and source before carrying any conclusion forward. The Monarch KG-based agent also offers a text answer download and a JSON evidence export with queries, rows, and citations for later review.