Research Assistant: AstraZeneca's Agentic System for R&D

Summary

This paper describes Research Assistant, an internal LLM-based system developed at AstraZeneca to help scientists and clinicians explore biomedical questions across a broad range of data sources. The system provides a chat-style interface that brings together evidence from scientific literature, knowledge graphs, chemistry, clinical trials, safety resources, expression data, and internal experimental systems. It supports both a fast mode for direct question answering and a multi-step mode for more complex research tasks. Responses are grounded in retrieved evidence and linked back to the original sources, allowing users to review and further explore the underlying data. The paper outlines the system architecture, the main design choices behind the product, and lessons learned from deploying it at scale to support day-to-day R&D workflows across AstraZeneca.

The motivation for the system is that prior to ChatGPT, the team at AstraZeneca built and maintained an array of data services for consuming their Knowledge Graph and NLP pipeline, but these resources required software engineering experience to use, such as writing queries for REST APIs or querying the graph using Cypher. Research Assistant was developed to make internal biomedical data resources more accessible to domain experts. It grew from a small pilot to 15,000 unique internal users within one year.

The workflow of Research Assistant is: (1) Given a user question, find the most appropriate data sources and facts; (2) Ground the answer in retrieved evidence; (3) Link users to the original sources for manual evaluation and further exploration.

The backend was written in Python with heavy use of the asyncio package, the API layer was developed in FastAPI, and the framework at the heart of the application was Apache Burr, a light-weight state machine framework which allows building complete assistant-style applications involving loops and conditional execution. The frontend was written in TypeScript and React. During state machine execution, the backend streams messages with state updates using server-sent events asynchronously to the frontend. The system uses a parallel architecture in which a user query triggers multiple lightweight tool calls simultaneously, with a final synthesis step performed by a larger LLM. The average cost of a Research Assistant query is only 16 cents (including all input and output tokens, using Gemini 3 Flash and Gemini 3.1 Pro models). Responses are typically generated within 10 to 30 seconds.

Two modes are available to users: Scientific Mode and Deep Research Mode. The Scientific Mode balances complexity and depth with speed by performing a single feed-forward pass mapping the user query to relevant tool agents. The Deep Research Mode offers a multi-step planning and execution workflow built around the concept of a research plan modeled as a directed acyclic graph (DAG) of questions, simulating how a real human would approach a more complex problem. The application initially creates and revises the plan until a judge agent accepts it. The accepted DAG of questions is topologically sorted so independent questions are answered first, and dependent questions are rewritten using information obtained in earlier steps. Users can even ask questions about repeating analysis on multiple different entities, and the planner translates this into an iterative research plan. Users can also provide a very specific research plan to override automatic plan generation.

The Tool Agents are central to the system's ability to answer diverse questions. A Tool Agent is composed of the tool API and the prompt. The tool API translates keywords, accession numbers, IDs, and filter settings into function calls accessing internal AstraZeneca resources or external APIs. The prompt explains to the LLM how to map the free-text user query into a structured tool API query. The glue between the Tool Agent LLM calls and the tool APIs is the Instructor package, which facilitates creation and validation of structured Pydantic models. Each agent returns data packaged into the same Pydantic class instance (Observation) containing: ID of the observation, URL for the source of the data, a flexible container with grounding data, and a citation string.

The Tool Agents include: the Literature Agent, which connects to an internal NLP pipeline that ingests over 3.8 billion sentences from over 67 million documents covering sources such as PubMed, EuropePMC, Embase, bioRxiv, medRxiv, Wiley, Springer Nature, Dailymed, Insightmeme and AstraZeneca's internal Electronic Lab Notebook systems. The pipeline consists of deep-learning based biomedical named entity recognition using the KAZU pipeline, deep-learning based grammatical and syntactic structure extraction, and rule-based relation extraction. The processed sentences are indexed for fast retrieval using Elasticsearch. The system uses lemmatized versions of words and automatic translation of keywords into Named Entities to increase recall. For publication searches, hits are enriched with information from OpenAlex, including citation normalized percentile score and percentile-transformed journal-level h-index, which are summed with Elasticsearch scores to create a final relevance score.

The Compound Agent links to AstraZeneca's Chemistry Application Gateway, communicating via templated GraphQL queries to fetch information on activity values from biochemical assays, physicochemical properties, and translating SMILES into compound names. The Knowledge Graph Agent gives access to the Biological Insights Knowledge Graph. The authors found that letting an LLM access the whole graph schema and directly generate Cypher/SPARQL queries leads to issues: behaviour becomes non-deterministic, difficulty taking into account meta-level information, and generated queries can be too complex and lead to timeouts. The Knowledge Graph Agent's workflow involves: grounding entities mentioned in the question using the KAZU NER service and the BIKG mapping service; creating a prototype query based on a projected schema; adjusting the prototype query using deterministic rules; and executing the final query and returning a summary of results.

The Clinical Trial Agent retrieves data from ClinicalTrials.gov via the REST API, using a compositional approach to fetch only specific pieces of trial data relevant to the user's query, such as 'Basic Information', 'Eligibility and Participant Criteria', 'Outcomes and Endpoints', or 'Adverse Events and Publications'. The Web Search Agent uses Google Vertex AI platform to perform Grounding with Google Search with the Gemini 3 Flash model, turning the Gemini response into Observation objects. The authors note that the Web Search Agent can access sources that are not scientifically credible, controlled with a domain exclusion list, and that additional care and verification of sources is required. The Discover Agent supports predictive capabilities using graph machine learning approaches including Graph Convolutional Neural Networks, knowledge graph embedding models (RotatE, ComplEx), path-based methods (Degree-Weighted Path Count, Sörensen Similarity), and PageRank. Rankings are combined using CRank to identify predictions with strongest agreement across models. The Clinical Endpoints Agent is based on a ClickHouse database produced by the NLP Endpoints pipeline, which applies four models based on Google's BERT model to extract entities relating to drug properties and clinical trials read-outs such as RECIST, drug efficacy, drug safety, and pharmacokinetic and pharmacodynamic drug properties. The Mapping Agent extracts entities from user queries and retrieves synonyms from the BIKG node index, allowing the system to recognize that EGFR is also called ERBB or HER1. The Glossary Agent translates various terms used within AstraZeneca, such as acronyms. The Human Protein Atlas Agent obtains expression patterns of genes from the HPA REST API. The In Vivo Agent discovers preclinical data from drug experiments, including toxicity studies, animal models, compound testing, and dosing. The OFF-X Agent retrieves information on drug safety alerts from the Clarivate OFF-X API.

The Tool Agent Picker is a router module responsible for mapping the user query to sets of Tool Agents. The authors experimented with an approach using a handcrafted database of example queries embedded and stored in ChromaDB, but found it hard to maintain and dropped it. They subsequently adopted an approach using automated topic modeling on a database containing tens of thousands of real user interactions, shortlisting topics such as Chemistry Information, Biological Relationships, General Biomedical Knowledge, Drug Safety and Recent Events. At run time, the user query is automatically assigned these predefined topics and the union of the Tool Agents assigned to the selected topics is run in parallel.

For evaluations, the authors used the BioASQ Training 10b question-answer set, specifically a random subset of 100 yes/no questions to calculate balanced accuracy compared to vanilla LLMs like GPT 4. They note that improvements made based on user feedback did not translate to performance improvements on the BioASQ question set, exemplifying the orthogonality of biomedical QA benchmarks and real-life user requirements. They also used the STaRK dataset, mapping entities in PrimeKG to the internal AstraZeneca knowledge graph BIKG, to drive development of the Knowledge Graph tool agent. With the growing internal user base, they developed a simple LLM judge agent which, given a pair of real user question and system response, would assign a score and add comments about that interaction.

An example of programmatic use of Research Assistant is the CRAM Auto Tool, which supports Combination Risk Assessment for Patient Safety Scientists. This process evaluates the safety profile when two or more products are used in combination, especially in clinical trials. A critical step is determining whether modulation of a drug target is linked to a biological mechanism that could plausibly contribute to an adverse event. The CRAM Auto Tool embedded this usage pattern into the product by calling Research Assistant programmatically, retrieving relevant evidence and generating grounded outputs with citations.

The authors conclude that Research Assistant was designed around three practical priorities: data accuracy, response speed, and low operating cost. It occupies a different space from more open-ended autonomous research systems, such as Google CoScientist or Robin, and is aimed at helping scientists and clinicians quickly access grounded biomedical information in day-to-day R&D work. Research Assistant can also serve as a grounded biomedical data endpoint for larger agentic systems through its MCP and REST API endpoints. Important challenges remain, including hallucinations and limited sensitivity to biological nuance, such as distinctions between closely related gene paralogs.

Based on the paper, here are specific improvements I can implement in AI systems, along with the resulting capabilities:

• Replace single-pass LLM generation with a parallel tool-agent system where multiple specialized agents (literature, knowledge graph, clinical trials, chemistry) execute concurrently

• Implement a two-stage pipeline: (a) retrieve structured evidence from domain-specific APIs, (b) synthesize answers using a larger LLM only at the final step

• Add a mandatory citation/observation layer that tags every generated statement with source URLs and metadata

• Replace free-form LLM tool selection with a two-tier approach: (a) classify user query into predefined topics (e.g., biological relationships, drug safety, chemistry information) using lightweight topic modeling, (b) map topics to fixed sets of tool agents via a deterministic lookup table

• This reduces hallucination risk and improves consistency compared to letting the LLM decide which tools to call

• For knowledge graph access, implement a three-step process: (a) entity grounding using NER to resolve mentions to canonical IDs, (b) prototype query generation against a projected schema (not the full graph), (c) deterministic rule-based adjustment for source filtering and attribute selection

• This prevents non-deterministic graph queries and timeouts

• For large external records (e.g., clinical trials), fetch only the specific data blocks requested by the user (e.g., eligibility criteria, endpoints, adverse events) rather than full records

• This reduces token consumption and latency

• Combine semantic search scores with publication impact metrics (citation-normalized percentile, journal h-index) using a weighted sum for literature retrieval

• This prevents low-quality but keyword-matching sources from dominating results

• Implement a deep research mode that: (a) generates a directed acyclic graph of sub-questions, (b) validates it with a judge agent (with revision limits), (c) topologically sorts and executes sub-questions using the fast mode, (d) rewrites dependent questions using context from prior answers

• This enables complex, multi-hop queries while maintaining bounded runtime and token budget

• Integrate multiple graph ML models (GCN, RotatE, ComplEx, path-based methods) and combine their ranked predictions using CRank to identify high-confidence novel gene-disease-compound associations

• Use this only in deep research mode, followed by evidence retrieval to support or refute predictions

• Answers questions like What causes Sturge-Weber Syndrome? with citation-linked evidence from literature, knowledge graphs, and clinical trials in 10–30 seconds

• Distinguishes between direct gene-disease associations and inferred pathways (e.g., via intermediate pathways or drugs in trial)

• Resolves synonyms automatically (e.g., EGFR = ERBB = HER1) before searching

• Handles multi-step queries like What classes of compounds affect genes expressed in the liver? by planning sub-questions, executing them sequentially, and synthesizing a coherent answer

• Supports iterative analyses across multiple entities (e.g., Repeat this analysis for genes A, B, C) with automatic plan generation

• Can generate novel hypotheses (e.g., Gene X is likely associated with Disease Y) and then retrieve supporting/contradicting evidence

• Provides drug safety alerts from OFF-X, adverse event data, and target safety profiles with source citations

• Supports combination risk assessment by answering questions like Does EGFR inhibition have a role in nausea? with grounded evidence

• Exposes REST API and MCP endpoints, allowing other agentic systems to query biomedical data with grounded, citation-linked responses

• Maintains low per-query cost (0.16) and predictable latency, making it suitable for batch processing and integration into larger workflows

• Automatically filters out non-credible sources (e.g., forums, blogs) via domain exclusion lists

• Uses a judge LLM to score real user interactions, enabling rapid identification of system weaknesses and targeted improvements

We describe Research Assistant, an internal LLM-based system developed at AstraZeneca to help scientists and clinicians explore biomedical questions across a broad range of data sources. The system provides a chat-style interface that brings together evidence from scientific literature, knowledge graphs, chemistry, clinical trials, safety resources, expression data, and internal experimental systems. It supports both a fast mode for direct question answering and a multi-step mode for more complex research tasks. Responses are grounded in retrieved evidence and linked back to the original sources, allowing users to review and further explore the underlying data. In this technical note, we outline the system architecture, the main design choices behind the product, and lessons learned from deploying it at scale to support day-to-day R&D workflows across AstraZeneca.