AI Agents in Drug Discovery: How Large Models Embed Into the R&D Workflow

1. From “AI-Assisted” to “AI-Executing”: The Drug Development Workflow Is Being Redefined

Drug development is known for its “ten years, ten billion dollars, and low success rate.” It features long development cycles, heavy cross-disciplinary collaboration, and a large documentation burden—characteristics that happen to complement the capabilities of large models.

• Long cycles: Much time is spent on repetitive work such as literature retrieval, contract routing, data organization, and document writing.
• Cross-disciplinary: Teams in chemistry, biology, clinical medicine, regulatory affairs, and manufacturing quality each have their own terminology and workflows.
• Heavy documentation: From lab records and process specifications to regulatory submissions, nearly every decision requires traceable written evidence.

Case in point. According to public reports, a micro-biotech company focused on research into two rare pediatric muscle-wasting diseases was operated by its founder alone. He used a large-model agent to handle a large volume of work:

• Coordinating contracts, logistics, and experimental arrangements with 11 external laboratories;
• Delegating much of the company’s day-to-day operations to agents;
• Advancing a candidate therapy for one of the indications from concept to the mouse-experiment stage in under 18 months, with early positive results.

The company was subsequently acquired by an AI-driven R&D enterprise, and the founder joined that company to continue the research. The acquirer also disclosed that its life sciences team has established deep research collaborations with six institutions. General-purpose large models have already delivered quantifiable efficiency gains across molecular design, manufacturing document review, regulatory submissions, and clinical trial planning. Its stated plan is to “significantly expand” the scope of work and extend the models’ involvement into the human clinical trial stage.

Three takeaways from this event.

1. The value of a “one-person pharma company” lies not in company size but in the collaboration model. By replacing project management, administrative coordination, and document-processing roles with agents, the founder concentrated his energy on scientific judgment. In essence, this is a re-partitioning of the human-machine division of labor.
2. The role of the large model shifts from “answering” to “executing.” It can call tools, read and write documents, pass data between systems, and track progress—taking on execution responsibility for workflow nodes, not merely offering advice.
3. The source of efficiency is the workflow, not just the model. The steps compressed in this case—contracts, logistics, scheduling, and documentation—are mostly coordination and paperwork. Such tasks have relatively clear rules, verifiable results, and discoverable errors, which makes them the areas where agents most easily produce reliable gains today.

Understanding this shift is a prerequisite for designing such systems. The rest of this article builds on this judgment.

2. Core Capability Breakdown: Which R&D Stages Can Large Models Embed Into

2.1 Early Discovery: From Molecule Generation to Candidate Optimization

Generative models are now widely used in industry for tasks such as structure prediction, target pocket analysis, molecule generation, and property prediction. Typical applications include:

• Generating and screening candidate molecules based on target structures;
• Predicting druggability metrics such as solubility, permeability, metabolic stability, and toxicity (ADMET);
• Sequence design and optimization of biological macromolecules such as peptides, nucleic acids, and antibodies;
• Planning retrosynthetic routes to support process development.

The engineering challenge is not generation but evaluation. High scores from computational models must be validated by wet-lab experiments; otherwise, they risk falling into a “model self-loop.” The practical approach is to have agents batch-generate candidates, filter them with a property-prediction module, and then submit them to automated or manual experimental validation. The validation results feed back as the basis for the next round of training or prompt optimization, forming a “design–synthesize–test–analyze” closed loop.

2.2 Literature Mining and Knowledge Asset Consolidation

A team’s knowledge is scattered across papers, patents, internal reports, and lab records. Agents can:

• Organize literature reviews by research question and output evidence tables with citations;
• Track research progress on similar targets and similar indications;
• Extract experimental results, conditions, and conclusions to build a structured knowledge graph;
• Answer internal questions using retrieval-augmented generation (RAG), with original sources attached.

The core engineering issue here is traceability: every conclusion should be traceable back to a specific document, version, and page number.

2.3 Outsourcing Coordination, Contracts, and Cold-Chain Logistics: Where Solo Teams Benefit First

The most instructive part of the “one-person pharma” case is the delegation of external coordination to agents, specifically:

• Contract extraction: Extracting deliverables, milestones, payment nodes, responsibility boundaries, and default terms from contracts, and tracking fulfillment status.
• Sample shipment: Determining suppliers, quantities, concentrations, cold-chain conditions (such as dry ice or liquid nitrogen transport), and delivery time windows based on the requirements of reagents, cell lines, or animal models for the target experiment.
• Schedule orchestration: Integrating the machine time, delivery cycles, and experimental sequence of multiple labs into a single Gantt chart, identifying the critical path, and proposing adjustments when delays occur.
• Meetings and records: Organizing meeting minutes and tracking the completion of action items.

Control points:

• Agents only generate draft proposals; actual ordering, payment, and signing are confirmed by humans;
• Terms involving amounts, delivery commitments, and intellectual property ownership must be reviewed by legal counsel or the project lead;
• Contract text often contains commercially sensitive information, so data classification and redaction should be completed before calling the model.

2.4 Manufacturing Document Review and Quality Systems (GMP/GCP)

In quality management systems for drug manufacturing and clinical research, document review has long consumed a large amount of manpower. Review objects include:

• Batch production records and batch packaging records;
• Deviation reports, change control requests, and corrective and preventive action (CAPA) reports;
• Standard operating procedures (SOPs);
• Clinical protocols and investigator brochures.

Large models excel at three types of tasks:

• Consistency checks: Verifying whether fields are complete, whether signatures and timestamps are complete, and whether records contradict one another;
• Clause comparison: Comparing operation records against SOPs item by item and flagging deviations;
• Initial screening of quality defects: Providing defect-level recommendations based on predefined rules and historical cases.

A boundary that must be made clear: Large models are suited to “initial screening” and “prompting,” but the final release decision still rests with responsible persons such as the Qualified Person, based on regulatory and data-integrity requirements. At the same time, all inputs and outputs must be retained in a complete audit trail, ensuring traceability to a specific model version, prompt template, and timestamp.

2.5 Regulatory Submissions: Document Engineering and Q&A Retrieval

New drug submission materials are organized in the modular Common Technical Document (CTD) format, covering pharmaceutical, non-clinical, and clinical data, and can reach thousands of pages. Large models can provide support in the following areas:

• Generating and proofreading documents by module, unifying format, terminology, and cross-references;
• Checking whether the same data is expressed consistently across summaries, body text, and tables;
• Retrieving submission clauses and prior review concerns based on regulatory guidelines and regulator Q&A documents;
• Assisting in preparing drafts of responses to pre-submission inquiries.

A boundary that needs emphasis: Regulations are time-sensitive, and requirements differ across jurisdictions. Agent output can only serve as a drafting reference; any submitted content must be reviewed line by line by regulatory and regulatory-affairs professionals.

2.6 Clinical Trial Planning: From Protocol Design to Subject Recruitment

In the clinical trial stage, agents can undertake:

• Protocol element design: Assisting in drafting inclusion/exclusion criteria, primary and secondary endpoints, visit schedules, sample size, and randomization strategies;
• Feasibility assessment: Estimating target population size and recruitment timelines by combining historical trial data with epidemiological data;
• Site and investigator selection: Matching based on prior trial experience, specialization, and patient sources;
• Document generation: Drafting informed consent forms, case report form instructions, and statistical analysis plan frameworks.

Where risks concentrate: Protocol elements directly affect subject safety and data quality. Content involving dosing, endpoint definitions, and statistical assumptions must be finalized by clinical and statistical experts and confirmed through ethics review and regulatory communication.

Summary: The closer a stage is to “documentation, coordination, and structured data processing,” the more mature and faster-returning large models are. The closer a stage is to “scientific hypotheses, safety decisions, and regulatory responsibility,” the more it requires human-machine collaboration and strict validation.

3. Reference Architecture: Where Agents Sit in the Drug Development Workflow

To engineer the capabilities above, a layered architecture is recommended, with a unified observability and governance system running throughout.

┌──────────────────────────────────────────────────────────────┐
│ Interaction layer: chat assistant / R&D portal / SSO /        │
│                     role- and project-based authorization      │
├──────────────────────────────────────────────────────────────┤
│ Agent orchestration layer: task planning · multi-agent        │
│   collaboration · tool routing · approval gates ·             │
│   checkpoints and retries                                      │
├──────────────────────────────────────────────────────────────┤
│ Capability layer: LLM inference · retrieval-augmented           │
│   generation · molecular property prediction ·                │
│   structured output and function calling ·                    │
│   document parsing (PDF / spreadsheets / scans)               │
├──────────────────────────────────────────────────────────────┤
│ Data layer: ELN and sample management systems ·               │
│   documents and knowledge base · object storage ·             │
│   message queues · vector retrieval · metadata & versioning   │
├──────────────────────────────────────────────────────────────┤
│ Governance layer: logging · monitoring & alerting ·           │
│   audit trail · access & key management ·                     │
│   data classification & redaction · model & prompt versioning │
└──────────────────────────────────────────────────────────────┘

The responsibilities of each layer are as follows:

• Interaction layer: Unified entry point and unified permissions. Researchers are authorized by role and project, seeing both task progress and the basis for each step.
• Agent orchestration layer: The core of the system, responsible for task decomposition, tool selection, process control, human confirmation, and state persistence.
• Capability layer: Encapsulates large models, prediction models, retrieval, and parsing capabilities as standard interfaces, making them easy to replace and roll out gradually.
• Data layer: Can be deployed on container platforms for elastic scaling, using object storage for raw files and message queues to decouple long-running tasks.
• Governance layer: Aggregates full-chain records through logging and detects anomalous behavior through monitoring and alerting, including abnormal call volume, abnormal output, and unauthorized access.

4. Key Engineering Practices

4.1 Orchestration Pattern: Plan–Act–Observe–Reflect

A single-turn Q&A cannot complete an end-to-end workflow. A “plan–act–observe–reflect” loop is recommended:

1. Plan: Break the goal into ordered steps, noting the tools, inputs, output formats, and acceptance criteria each step requires.
2. Act: Call controlled tools such as retrieval, database queries, document read/write, and experiment scheduling interfaces.
3. Observe: Verify whether the returned results match the expected format and whether key values fall within reasonable ranges.
4. Reflect: On failure, locate the cause and retry, or adjust the plan; escalate to human confirmation for high-risk operations.

The plan should be persisted as a directed acyclic graph or state machine, with each node recording its input, output, model version, and elapsed time, enabling checkpoint recovery and after-the-fact review.

4.2 Retrieval Augmentation: Giving Conclusions a Source

Drug development documents are highly specialized and have many versions, so relying solely on the model’s parametric memory is unreliable. Recommendations:

• Retain version, effective date, and scope of applicability when documents are ingested;
• Segment by heading hierarchy and semantics, with metadata including source, section, page number, and classification level;
• Answers must include citations; when there is no reliable basis, state clearly that “no supporting evidence was found” rather than guessing;
• Maintain a separate update process for regulatory knowledge bases to ensure timeliness.

4.3 Reliability Design: Don’t Let “Plausible-Looking” Become the Final Conclusion

Four lines of defense are recommended:

1. Structural constraints: Use schema definitions to specify output fields and value ranges; retry if parsing fails.
2. Numerical and computational validation: Content involving calculations—such as sample size estimation, dose conversion, and concentration dilution—should always be handled by deterministic computation modules, with the model only responsible for understanding intent and organizing results.
3. Rule-engine cross-checking: Use code rules to check document completeness, such as whether required fields are empty, whether dates precede the experiment start time, and whether batch numbers conform to encoding standards.
4. Confidence-based tiered handling: For high-risk conclusions (such as safety judgments), require citation of raw data and expert sign-off.

4.4 Data Governance and Compliance

• Data classification: Classify data into public, internal, confidential, and highly sensitive (such as subject personal information) levels, with different redaction and access strategies for each level.
• Privacy protection: De-identify clinical data; for cross-institution collaboration, consider privacy-computing approaches such as federated learning, trusted execution environments, and differential privacy to achieve “usable but invisible” data.
• Audit trail: Record “who, at what time, using which model version, based on which data, produced what result,” meeting the traceability requirements for electronic records and electronic signatures.
• Supply chain security: Use self-hosted model inference or general cloud services that have passed compliance assessment, and perform sensitive-information detection on uploaded data.

4.5 Human-Machine Collaboration and Approval Gates

Divide workflow nodes into three categories:

• Automatic execution: Low-risk, reversible operations, such as read-only queries, draft generation, and format validation.
• Execute after human confirmation: Operations that affect others, such as external communication, contract generation, and schedule changes.
• Human execution only: Operations involving subject safety, regulatory submission, and release decisions.

This preserves efficiency gains while clarifying responsibility boundaries.

5. Sample Code: An Auditable Agent Workflow Skeleton

The following example demonstrates the orchestration skeleton using generic interfaces. In engineering implementation, you can choose the appropriate framework and model service for your tech stack.

import json, time, uuid
from dataclasses import dataclass, field
from datetime import datetime, timezone
from typing import Any, Callable
# ---------- 1. Tool registration: capability list, risk level, and human approval policy ----------
@dataclass
class ToolSpec:
    name: str
    handler: Callable[..., Any]
    risk: str = "low"          # low | medium | high
    need_approval: bool = False
TOOLS: dict[str, ToolSpec] = {}
def tool(name: str, risk: str = "low", need_approval: bool = False):
    def deco(fn: Callable[..., Any]):
        TOOLS[name] = ToolSpec(name=name, handler=fn, risk=risk, need_approval=need_approval)
        return fn
    return deco
@tool("search_literature")                       # read-only retrieval
def search_literature(query: str, top_k: int = 10) -> list[dict]:
    # Connect to the literature database / vector retrieval service; return entries with sources
    return [{"source": "literature_db", "title": f"related:{query}", "score": 0.9}]
@tool("predict_admet")                           # computation tool, no large model involved
def predict_admet(smiles: str) -> dict:
    return {"solubility": "medium", "permeability": "high", "hERG_risk": "low"}
@tool("update_schedule", risk="medium", need_approval=True)   # affects external schedule, requires human confirmation
def update_schedule(plan_id: str, new_order: list[str]) -> dict:
    return {"plan_id": plan_id, "status": "submitted_for_approval"}
# ---------- 2. Execution records and audit ----------
def audit(node: str, payload: dict) -> None:
    rec = {"ts": datetime.now(timezone.utc).isoformat(), "node": node, "model_version": "v1", **payload}
    print(json.dumps(rec, ensure_ascii=False))   # in production this should write to a centralized logging service
class ApprovalRequired(Exception):
    pass
def guard(tool: ToolSpec, args: dict, ctx: dict) -> None:
    if tool.risk == "high" and not ctx.get("expert_signoff"):
        raise ApprovalRequired(f"high-risk operation {tool.name} requires expert confirmation")
    if tool.need_approval and not ctx.get("approved_by"):
        raise ApprovalRequired(f"operation {tool.name} requires owner approval")
# ---------- 3. Orchestration loop: plan -> act -> observe -> retry ----------
def run_workflow(plan: list[dict], ctx: dict, max_retry: int = 2) -> dict:
    results, checkpoint = [], {"plan_id": ctx["plan_id"], "done": []}
    for idx, step in enumerate(plan):
        if idx in checkpoint["done"]:
            continue
        spec = TOOLS[step["tool"]]
        guard(spec, step.get("args", {}), ctx)               # approval and risk interception
        for attempt in range(1, max_retry + 1):
            try:
                out = spec.handler(**step.get("args", {}))
                assert step.get("validator", lambda x: True)(out), "output validation failed"
                results.append({"step": idx, "tool": spec.name, "output": out})
                checkpoint["done"].append(idx)
                audit("node_done", {"step": idx, "tool": spec.name, "attempt": attempt})
                break
            except ApprovalRequired:
                raise
            except Exception as exc:
                audit("node_retry", {"step": idx, "attempt": attempt, "error": str(exc)})
                time.sleep(2 ** attempt)                      # exponential backoff
        else:
            results.append({"step": idx, "tool": spec.name, "status": "failed"})
    return {"status": "completed", "results": results, "checkpoint": checkpoint}
# ---------- 4. Example: have the large model produce a structured plan, then hand it to the orchestrator ----------
def make_plan(goal: str) -> list[dict]:
    """Call the large model, requiring it to return only JSON in the structure below (illustrative)."""
    prompt = (
        "You are a drug development workflow assistant. Break the goal into executable steps and "
        "output only a JSON array, where each element contains tool (must be one of "
        "search_literature / predict_admet / update_schedule), args (object), and validator type. "
        f"Goal: {goal}"
    )
    raw = llm_client.complete(prompt, response_format="json")   # generic inference interface
    return json.loads(raw)
if __name__ == "__main__":
    llm_client = ...   # inject the specific inference service client
    ctx = {"plan_id": str(uuid.uuid4()), "approved_by": None, "expert_signoff": False}
    plan = make_plan("Retrieve supporting data for candidate molecule M001, evaluate druggability, and submit a mouse-experiment schedule adjustment")
    print(json.dumps(run_workflow(plan, ctx), ensure_ascii=False, indent=2))

This code embodies four engineering design principles:

• The tool registry clearly marks risk levels and approval strategies, blocking unauthorized operations at the entry point;
• Computational results are produced by deterministic tools, without relying on the model’s numerical “estimation”;
• Every step is written to the audit record, along with the model version used;
• Failures are automatically retried, output must be validated, and any step that fails to meet acceptance criteria is explicitly exposed.

6. Effectiveness Evaluation: Building a Quantifiable Metrics System

The company in the case claimed to have achieved “quantifiable” efficiency gains across multiple stages, which suggests that technical teams should define metrics in advance rather than estimate them after the fact.

Dimension	Recommended Metric	Collection Method
Efficiency	End-to-end task time, number of manual interventions, rework rate	Automatic statistics from orchestration logs
Quality	First-pass rate of drafts, factual error rate, proportion of traceable citations	Expert spot checks + rule validation
Scientific output	Number of candidate molecules entering validation, reduction in cycle time	ELN records
Compliance	Audit record coverage, number of unauthorized calls, redaction hit rate	Logging service and monitoring/alerting
Cost	Per-task inference cost, cache hit rate	Inference service usage statistics

The baseline should be established before launch, and an “same task, human baseline vs. agent-assisted” comparison approach is recommended for evaluation. Only this way can you distinguish between gains from model capability and gains from workflow reorganization.

7. Phased Implementation Roadmap

Phase	Goal	Typical Tasks	Key Control Points
Phase 1: Single-point pilot	Validate feasibility	Literature reviews, meeting minutes, contract key-point extraction, document format proofreading	Read-only primarily; human review of all outputs
Phase 2: Workflow integration	Connect end-to-end	Outsourcing coordination and experiment scheduling, batch record initial screening, submission document drafts	Set approval gates, audit trail, failure fallback
Phase 3: Multi-agent and wet-lab closed loop	Form an iteration loop	Molecule generation — property prediction — experimental validation — data feedback	Expert sign-off, data version management
Phase 4: Scaling and deeper compliance	Platform-based operation	Multi-project, multi-institution collaboration; gray release of model and prompt versions	Model evaluation system, cost governance, continuous monitoring

Every phase should adhere to one principle: first let agents create value in reversible, verifiable stages, then gradually extend into higher-risk stages. The company in the original case planning to extend the model into the human clinical trial stage corresponds precisely to the path of transitioning from phase two to phases three and four.

8. Risks and Governance Boundaries

1. Hallucination and overconfidence: Large models generate plausible but unfounded conclusions. These must be constrained through citations, validation rules, and expert review, especially in judgments involving safety and efficacy.
2. Non-transferable responsibility: Whether in manufacturing document review or clinical protocols, final responsibility always rests with natural persons and their organizations. The agent’s role is an “efficiency-boosting assistant” and cannot replace the responsible person’s signature.
3. Data and privacy: Contracts, patents, and clinical data may all constitute sensitive information. Data classification, redaction, and access control should be completed to avoid using data for model training or transmitting it externally without authorization.
4. Biosafety: When it comes to sequence design and pathogen research, sequences that are generated or uploaded should undergo synthesis screening and be incorporated into ethics and biosafety review.
5. Model change risk: Updates to the model or prompts may cause output drift. Regression testing should be performed before changes, rollback versions retained, and the impact of versions on results recorded.

9. Conclusion

The acquisition of a “one-person pharma” company by an AI-driven R&D enterprise looks, on the surface, like an M&A deal; in substance, it reflects a change in the way R&D collaboration is conducted. Large-model agents are taking over a large amount of the coordination and paperwork in drug development, enabling even extremely small teams to mobilize external resources and accomplish what once required a large organization.

For teams preparing to implement this, it is advisable to start from three questions:

1. Which stages have clear rules and verifiable results?
2. Which conclusions must be signed by a human?
3. How can efficiency gains be proven with data?

Designing the architecture around these three questions, setting up approval gates, and building a metrics system will allow large models to truly become a reliable, auditable, and continuously improvable part of the R&D workflow.