← Back to Blog

Helminthix Perspectives

Can AI Build HelminthixDB? Designing a Multi-Agent Scientific Curator

Structuring the scientific literature at scale needs more than one clever algorithm — it takes a team of agents that extract, verify and challenge each other, with a human curator always having the final word.

Diagram of the multi-agent AI curation architecture for HelminthixDB, showing sources flowing through WPmatico and aaa2zzz into a processing queue, then an Extraction, Normalisation and Critic agent layer referencing NCBI Taxonomy, UniProt, PubChem/ChEBI and MONDO/Orphanet, followed by an evidence and confidence gate, human curator review, a staging layer, and finally HelminthixDB.

There is a practical problem behind HelminthixDB: far more potentially useful information is published than any person can continuously read, interpret, standardise and enter into a structured database. A newspaper article, press release or scientific paper might contain one important piece of information: a new compound being tested against a parasite, a potential drug target, a diagnostic marker, an emerging resistance mechanism, or a newly reported species–disease relationship.

For Helminthix, finding the documents is already partly solved. WPmatico collects articles into WordPress, while my own aaa2zzz plugin filters them for likely relevance. The harder problem comes afterwards:

How do we turn unstructured text written for humans into accurate, standardised and traceable scientific knowledge?

Biomedical databases have faced this problem for decades. Systems such as PubTator automatically identify biomedical concepts in the scientific literature, while Textpresso Central combines text mining with tools for human curation (Wei et al., 2013; Müller et al., 2018). More recently, work on AI-assisted biocuration has increasingly emphasised human-in-the-loop systems, where automation handles repetitive work while expert curators remain responsible for scientific judgement (Wood et al., 2026). For HelminthixDB, I think a multi-agent architecture would work particularly well.

First: what kind of environment are the agents operating in?

Russell and Norvig define an agent as something that perceives its environment through sensors and acts upon it through actuators. More importantly, they argue that the design of an agent should depend on the nature of the environment in which it operates (Russell & Norvig, 2021). The HelminthixDB curation environment is difficult: it is partially observable, because one article rarely contains the complete scientific picture; it is dynamic, because new information is continuously published; it is sequential, because an error made during extraction can affect later normalisation and interpretation; and it is also uncertain, because later studies may contradict an earlier result.

That makes a single instruction such as “read this article and update the database” a poor design. Instead, I would divide the problem between three agents.

Agent 1: the Extraction Agent

The Extraction Agent asks:

What does this article actually claim?

It identifies relevant entities such as parasite species, diseases, drugs, compounds, genes, proteins, targets, pathways, diagnostic methods, resistance mechanisms and clinical trials. But simply recognising names is not enough: what HelminthixDB needs is the relationship between them. For example, finding the words praziquantel, Schistosoma mansoni and TRPM_PZQ is less useful than extracting the claim that praziquantel acts through a particular target in S. mansoni. The agent should also retain the exact supporting text, source and publication date.

For this agent, the performance measure should favour sensitivity: missing an important relationship is more costly than sending an occasional irrelevant candidate to the next stage. This resembles the approach behind PubTator, which uses automated concept recognition to reduce the amount of literature that human curators must process manually (Wei et al., 2019).

Agent 2: the Normalisation Agent

The Normalisation Agent has a different problem:

What exactly does this entity refer to?

This may actually be the harder task. Scientific names are notoriously inconsistent: Schistosoma mansoni may appear as S. mansoni; compounds can have generic names, development codes, chemical names and brand names; and genes and proteins accumulate aliases and historical names, sometimes differing between species.

The Normalisation Agent therefore needs to map extracted concepts onto canonical records using resources such as NCBI Taxonomy, UniProt, PubChem, ChEBI, MONDO and Orphanet. Here the performance measure should favour precision: creating a duplicate entry is inconvenient, but incorrectly merging two different genes, proteins or compounds could damage the integrity of the database.

Keeping extraction and normalisation as separate agents also makes errors easier to understand, since we can ask separately whether the first agent understood the article and whether the second agent identified the correct biological entity. This follows an important principle from AIMA: a rational agent can only perform well if its performance measure reflects what we actually want, since optimising the wrong objective can produce perfectly efficient but completely undesirable behaviour (Russell & Norvig, 2021).

Agent 3: the Critic

The third agent has an intentionally different role: its job is to find what the other agents got wrong. The Critic receives the original source together with the proposed claim and normalised entities, and asks whether the evidence really supports the interpretation.

Was the target experimentally demonstrated or merely predicted? Was the experiment in vitro, in an animal model or in humans? Has an association accidentally become a causal claim? Did the Normalisation Agent select the correct species or protein?

This is surprisingly close to the critic in Russell and Norvig’s learning-agent architecture: a component that evaluates performance against an external standard rather than allowing the acting component to judge its own success (Russell & Norvig, 2021). In other words, the Extraction Agent should not be allowed to mark its own homework.

Store evidence, not just conclusions

Another important principle is that HelminthixDB should distinguish between entities, claims and evidence. A newspaper article reporting that a compound kills a parasite should not automatically become a statement of scientific truth. Instead, HelminthixDB should record that a particular source made a particular claim, since a later scientific paper, clinical trial or regulatory decision may strengthen, qualify or contradict it.

This idea already appears in established biological knowledgebases. CIViC, for example, separates individual evidence records from higher-level clinical assertions and requires expert moderation (Danos et al., 2019). The Gene Ontology Causal Activity Modeling (GO-CAM) framework similarly represents biological knowledge as interconnected activities and relationships rather than isolated annotations, an approach Chris Mungall and colleagues were instrumental in developing (Thomas et al., 2019). That kind of provenance is exactly what HelminthixDB will need.

Humans remain the final decision-makers

Initially, new entities and uncertain claims should enter a staging area rather than the production database, where a human curator can see the source, proposed relationship, normalised entities and the Critic’s assessment, and decide whether to approve, edit or reject the proposal.

Those decisions also become useful feedback: over time, they can be used to improve all three agents. The goal is therefore not to eliminate human curation but to concentrate human effort on the decisions where expertise actually matters.

A relatively simple technical stack

The implementation does not need to depend on expensive commercial AI APIs. WPmatico and aaa2zzz can continue handling collection and relevance filtering, while a Python application running on the existing Unix server manages the processing queue, queries reference databases, validates outputs and communicates with HelminthixDB.

For routine language-model work, I would start with a small open-weight model running locally through llama.cpp; most identifier matching, duplicate detection and validation should use conventional software rather than generative AI. If an unusually difficult document requires more memory or processing power than the web server can provide, that individual task could be sent temporarily to AWS, processed there, and returned, so cloud compute remains the exception rather than the default.

The overall workflow is simple: articles are collected and filtered, one agent extracts scientific claims, another resolves the entities, a third challenges the interpretation, and a human curator makes the final decision before anything enters HelminthixDB.

The aim is not to create an autonomous artificial scientist. It is something rather more practical:

A team of artificial scientific curators that can read continuously, extract systematically, standardise carefully and challenge each other’s conclusions, while keeping the evidence visible and leaving final scientific judgement with humans.

Implementation recipe

None of this needs to be exotic. Here is the stack I would actually reach for, agent by agent.

Core stack

Runtime: Python 3.11/3.12

Packages: sqlalchemy, pymysql, pydantic, requests, httpx, python-dotenv, tenacity, orjson, loguru, typer, pandas

Use for: database access, schemas, HTTP calls, configuration, retries, JSON, logging, CLI jobs, occasional curation/export work

Local LLM layer

Packages: llama-cpp-python

Use for: Extraction Agent, Normalisation Agent reasoning, Critic Agent, local inference with quantised GGUF models

Biomedical NLP

Packages: spacy, scispacy

Models: en_core_sci_sm, optionally en_ner_bionlp13cg_md, en_ner_bc5cdr_md

Use for: entity spotting, candidate genes/proteins, chemicals, diseases, species, reducing LLM workload

Entity normalisation

Packages: rapidfuzz, diskcache

Use for: synonym matching, fuzzy entity resolution, cached lookups, matching extracted terms to HelminthixDB and reference vocabularies

External reference resources

Sources: NCBI Taxonomy, UniProt, PubChem, ChEBI, MONDO, Orphanet

Use for: canonical names, stable identifiers, aliases, species resolution, drugs/compounds, genes/proteins, diseases

Web/source handling

Packages: feedparser, beautifulsoup4, lxml

Use for: article metadata, source-page parsing, supporting-paper lookup, feeds if needed beyond WordPress

Structured agent outputs

Packages: pydantic

Schemas: ArticleInput, ExtractedEntity, ExtractedClaim, NormalisedEntity, CriticVerdict, CuratorDecision

Use for: strict JSON validation, rejecting malformed agent output, stable handoff between agents

Database

Backend: MariaDB/MySQL via sqlalchemy + pymysql

Tables: articles, processing_queue, entity_candidates, claim_candidates, normalised_entities, critic_reviews, staging_entities, staging_claims, curator_actions, later entities, claims, evidence

Use for: processing state, provenance, staging, curator decisions, final HelminthixDB records

Extraction Agent

Packages: llama-cpp-python, scispacy, pydantic

Use for: identify entities, extract scientific claims, capture supporting sentences, return structured JSON

Normalisation Agent

Packages: rapidfuzz, requests, diskcache, optionally llama-cpp-python

Use for: canonicalise names, resolve aliases, map to NCBI/UniProt/PubChem/ChEBI/MONDO IDs, detect new vs existing entities

Critic Agent

Packages: llama-cpp-python, pydantic

Use for: verify claims against source text, detect association-vs-causation errors, predicted-vs-demonstrated claims, species/context mistakes, assign supported/uncertain/contradicted status

Orchestration

Packages: sqlalchemy, tenacity, loguru, typer

Use for: queue management, agent sequencing, retries, error handling, job logging, cron entry points

Human review UI

Packages: fastapi, uvicorn, jinja2, optionally sqladmin

Use for: approve/edit/reject interface, inspect evidence, review critic verdicts, move approved records into staging/final HelminthixDB

Server/scheduling

Infrastructure: Unix host, cron, Python virtual environment

Use for: scheduled processing, queue polling, local inference, routine database work

Heavy-job fallback

Infrastructure: AWS EC2 or similar temporary compute

Use for: larger models, unusually difficult documents, occasional batch processing, jobs exceeding local RAM/CPU

References

Danos, A.M., Krysiak, K., Barnell, E.K., et al. (2019). Standard operating procedure for curation and clinical interpretation of variants in cancer. Genome Medicine, 11, 76. doi:10.1186/s13073-019-0687-x.

Müller, H.-M., Van Auken, K.M., Li, Y. & Sternberg, P.W. (2018). Textpresso Central: a customizable platform for searching, text mining, viewing, and curating biomedical literature. BMC Bioinformatics, 19, 94. doi:10.1186/s12859-018-2103-8.

Russell, S.J. & Norvig, P. (2021). Artificial Intelligence: A Modern Approach, 4th ed. Pearson.

Thomas, P.D., Hill, D.P., Mi, H., Osumi-Sutherland, D., Van Auken, K., Carbon, S., Balhoff, J.P., Albou, L.-P., Good, B., Gaudet, P., Lewis, S.E. & Mungall, C.J. (2019). Gene Ontology Causal Activity Modeling (GO-CAM) moves beyond GO annotations to structured descriptions of biological functions and systems. Nature Genetics, 51, 1429–1433. doi:10.1038/s41588-019-0500-1.

Wei, C.-H., Kao, H.-Y. & Lu, Z. (2013). PubTator: a web-based text mining tool for assisting biocuration. Nucleic Acids Research, 41(W1), W518–W522. doi:10.1093/nar/gkt441.

Wei, C.-H., Allot, A., Leaman, R. & Lu, Z. (2019). PubTator Central: automated concept annotation for biomedical full text articles. Nucleic Acids Research, 47(W1), W587–W593. doi:10.1093/nar/gkz389.

Wood, V., et al. (2026). Empowering biological knowledgebases: advances in human-in-the-loop AI-driven literature curation. Bioinformatics Advances, 6(1), vbag028. doi:10.1093/bioadv/vbag028.