August 4, 2026 · Engineering retrospective · ~ 17 min read

Building a Multi-Agent System for Drug Discovery:
Six Months of Lessons

Notes from prototyping a multi-agent system that integrates literature search, biological reasoning, molecular design, analysis and planning — over six months of iteration against real lab workflows.

Headline lessons

  • Specialized agents beat a single mega-prompt on every workflow I tried. But only by ~10–15% time-to-result, not the 80% the marketing suggests.
  • The orchestrator is most of the engineering work. Routing is cheap; deciding when to disagree with an agent is expensive.
  • Human-in-the-loop checkpoints are not optional. Multi-agent autonomy in the lab is a worse idea than it sounds.
  • The models you'll actually use are not the headline ones. The orchestrator runs on a 70B-class local LLM; only the literature RAG and the molecular design run on larger APIs.

Why I built it this way

Drug discovery is not a single prediction task. It is a workflow that loops between identifying a target, reasoning about its biology, designing molecules, evaluating them in silico, deciding what to test next, running the wet-lab experiments, and feeding the results back in. Most "AI for drug discovery" demos isolate one or two steps of that workflow and pretend the rest doesn't exist.

The hypothesis I wanted to test, going into this build, was that if you could wire together specialized agents for each step — and route information between them coherently — the system as a whole could actually support a working lab. Not replace it; support it.

Multi-Agent Drug Discovery Architecture Each agent has specialized tools, memory and a domain critic Orchestrator routes messages Literature PubMed · Patents RAG over corpora Biology Pathways · Targets KG reasoning Design SMILES · 3D Pocket docking Analysis Code · Stats Omics pipelines Planner Cost · Value Experiment queue Human PI approves pivots wet-lab gate Vector store papers · patents · assays Knowledge graph proteins · pathways · targets Scientific models ESM · RFdiffusion · Boltz Wet-lab interface protocols · samples

The current architecture. Each agent has specialized tools, a domain critic and access to shared resources. The Human PI is treated as a first-class node, not a UX layer.

What each agent actually does

Five agents, each scoped to one decision class. I'll be brief about the implementation because it's mostly plumbing.

📚 Literature Agent

Retrieve-augmented generation over a curated corpus of PubMed abstracts, granted patents, and a small set of clinical trial write-ups (the latter mostly for failure modes). The corpus is chunked at sentence-level, embedded with a biomedical sentence-transformer, indexed in FAISS.

The agent that consumes the retrieval rarely wants the most similar chunk. It wants the most recent relevant chunk. Recency is one of the easier signals to add and the easiest to leave out, but it makes a big difference to clinical literature where the literature is moving fast.

🧬 Biology Agent

A KG-grounded reasoner that maintains a working knowledge graph of proteins, pathways and disease associations. We use Reactome and UniProt as the backbone. The agent is forbidden from asserting novel biological claims unless it has at least two KG edges to support them.

💊 Design Agent

The only agent that runs a forward-deployed model (RFdiffusion for peptide design, plus an internal conditional-MolGPT variant for small-molecule design). Outputs ranked molecule batches with predicted properties attached.

📊 Analysis Agent

A code-execution agent that lives in a sandboxed Python subprocess. Reads OMICS files, runs RDKit calculations, makes plots, and writes a short summary for the orchestrator. Critically: it doesn't make decisions; it produces numbers. The orchestrator decides what the numbers mean.

🧪 Planner Agent

The only non-LLM-heavy agent. A simple expected-value-of-information optimizer that takes proposed experiments and ranks them against a budget. It deliberately does not attempt to understand the experiments; it just turns a budget into a queue.

What worked

Specialization helps, but only modestly

Replacing one mega-prompt with five specialists gave a 10–15% time-to-result improvement on three drug-discovery tasks I benchmarked. That's real but not huge. The bigger gain came from giving each agent specific tools — a literature agent without FAISS retrieval is just a chat bot; with it, it's actually useful.

Confidence-scoring messages

The single best engineering decision I made was forcing each agent to attach a numeric confidence to every message it routed back. The orchestrator learns to discount low-confidence messages, and the dry-lab user starts to trust the system because the system is honest about its uncertainty.

# Message format shared across all agents
from pydantic import BaseModel

class AgentMessage(BaseModel):
    sender: str
    intent: str            # e.g. "hypothesis", "evidence", "plan"
    content: Any
    confidence: float     # 0..1
    citations: list[str] = []
    needs_human: bool = False

Shared notes beat shared memory

I started with the canonical "shared memory" pattern from the babyAGI / AutoGPT literature. It fell apart within a week. What worked better was a per-task note: when an agent completes a step, it appends to a structured note that the orchestrator summarizes and passes back into the prompt. Notes expire at the end of the task, so older reasoning doesn't contaminate new sessions.

What didn't work

Autonomous iteration

Letting the system autonomously run Design → Analysis → Design loops overnight produced hundreds of molecules none of which the biology agent endorsed. The system converged on internally-consistent but biologically-nonsense outputs. Recommendation: always require a human checkpoint between Design loops. This is what the dashed line in the diagram means; the Human PI node.

Tool registries with more than ~10 tools

Once the orchestrator could call more than a dozen tools, the tool-selection accuracy collapsed. We re-aggregated into a small agent-mediated tool API (i.e. the agent is the tool, the orchestrator doesn't see the internals). Latency went up; reliability went up more.

Local LLM as the orchestrator

I started with a 70B-class local model as the orchestrator to avoid leaking prompts to third parties. This works for routine routing. It fails on adversarial prompts where the orchestrator has to weigh contradictory evidence. I've since routed the high-stakes arbitration through a frontier API behind a "human authorized this call" gate.

The video: a real session, slightly scrubbed

Here's a six-minute capture of one full session. What I want you to notice is not the speed of the agents, but the places where the orchestrator pauses and asks for human input, and where the Planner refuses to schedule an experiment the Biology agent hasn't endorsed.

Live session captured on May 14, 2026. Audio was omitted because too many other researchers were co-located. Many of the Python-notebook scrolls are internal tool calls.

Where this leaves me

Two things I believe about multi-agent systems for science, after six months of trying:

  1. They are not autonomous scientists yet. They are excellent collaborators for the parts of a workflow where the human bottleneck is cognitive load, not judgment. Know which one you're trying to accelerate.
  2. The orchestrator is the product. Every other piece is replaceable. The routing, the arbitration, the human-checkpoint policy — these are what makes the system trustworthy or not. Treat it accordingly.

If you're starting your own multi-agent system for science, I'd strongly recommend scoping to one workflow and one team first. The systems break in workflow-specific ways; you need domain feedback fast.

References and notes

  1. Ramajo-Fernández, G. BioResearch-AI — Project page. link
  2. Watson, J. L. et al. Nature 2023 — RFdiffusion. link
  3. Edwards, C. N. et al. NeurIPS 2022 — Text2Mol. link
  4. Schmidt, C. Nature 2024 — Surveys on autonomous science. link
  5. Kirkpatrick, J. arXiv 2024 — On agentic reliability. link