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

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "Research Assistant: AstraZeneca's Agentic System for R&D".

Jane: The paper was written by Piotr Grabowski, Mohamed Alameen, Jorge Bretones, Sabina Cardell, Miguel Carmona et al. from AstraZeneca.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Title: Tom: Welcome back to the show, everyone. Today we're looking at a paper that's been making the rounds on arXiv, and it's called "Research Assistant: AstraZeneca's Agentic System for R andD." Jane, when I first saw that title, I thought, okay, another chatbot for scientists, right? But this is actually something much bigger.

Jane: Oh, absolutely, Tom. And I love that you said that, because the title really undersells what they've built. This isn't just a chatbot. It's a whole multi-agent system that AstraZeneca deployed internally to help their scientists and clinicians dig through an enormous amount of biomedical data. We're talking literature, knowledge graphs, chemistry data, clinical trials, safety records, gene expression—all of it behind one chat interface.

Tom: And the scale is what gets me. Fifteen thousand internal users within a year. That's not a pilot project, that's a full-on cultural shift inside a pharmaceutical giant. I mean, before this, researchers had to write Cypher queries or use REST APIs to get at their knowledge graph. Now they just ask a question in plain English.

Jane: Exactly. And the authors make this really interesting point in the introduction. They had all this rich data infrastructure already built, but it required software engineering skills to use. So they built Research Assistant to lower that barrier. And the name itself, "Research Assistant," is kind of humble, but the architecture behind it is anything but. It's built on Apache Burr, which is a state machine framework, and it runs two distinct modes depending on the complexity of the question.

Tom: Right, and we're going to dig into those modes in a bit. But first, let's just sit with the implications of the title itself. "Agentic System" is a buzzword these days, but here it's earned. This is a system that doesn't just retrieve documents—it plans, it routes queries to specialized tools, it synthesizes evidence, and it cites its sources. For a company like AstraZeneca, that could mean faster drug discovery, better safety assessments, and fewer dead ends in research.

Jane: And honestly, Tom, the fact that it's from AstraZeneca and not a tech company is significant. It shows that big pharma is now building these systems in-house, tailored to their own data. That's a shift in who gets to build AI for science.

Tom: So, Jane, what's the one thing you'd tell a listener who thinks this is just another chatbot?

Jane: I'd tell them to look at the numbers. Sixteen cents per query. Ten to thirty seconds response time. Fifteen thousand users. Those are production numbers, not demo numbers. And that's the story of this paper—taking agentic AI from a cool demo to a daily workhorse.

Tom: And that's exactly where we're headed next. We're going to look at the summary and the core workflow, because that's where the real engineering decisions show up.

Summary: Jane: So, Tom, we've established that this is a serious system, not a toy. Now let's talk about how it actually works, because the summary in this paper is deceptively simple. The workflow is basically: take a user question, find the right data sources, ground the answer in evidence, and link back to the original sources. But underneath that simplicity, there's a really clever architecture.

Tom: And I want to bring in Lu here, because I think the multi-agent design is something you'd have strong opinions on. Lu, the paper describes this parallel architecture where a single query triggers multiple tool agents simultaneously. That's a big departure from the typical chain-of-thought approach.

Lu: It is, Tom, and I think it's the right call for this domain. The paper is very explicit about this: they run lightweight tool calls in parallel, then a larger LLM does the final synthesis. That's why they get responses in ten to thirty seconds. If they tried to do everything sequentially with one big model, the latency would kill the interactive experience. And the cost—sixteen cents per query—is remarkably low because they're not feeding the whole world into the context window. They're retrieving focused evidence.

Meng: And as an engineer, that's what I find most impressive. They're using Apache Burr, which is a state machine framework, to manage the orchestration. That gives them loops, conditional execution, and telemetry out of the box. They're not bolting this together with ad-hoc scripts. And they're streaming state updates to the frontend using server-sent events, so the user sees progress in real time. That's a polished engineering effort.

Jane: Meng, you mentioned the tool agents. Let's talk about those, because the paper lists twelve of them. There's a Literature Agent that searches over three point eight billion sentences from sixty-seven million documents. There's a Compound Agent that talks to AstraZeneca's chemistry gateway. There's a Knowledge Graph Agent, a Clinical Trial Agent, a Web Search Agent, even an OFF-X Agent for drug safety alerts.

Tom: And my favorite detail is the Tool Agent Picker. That's the router that decides which agents to activate for a given query. The paper says they tried embedding-based nearest neighbor search first, but it was hard to maintain. So they switched to topic modeling on tens of thousands of real user queries. They identified topics like "Biological Relationships" and "Drug Safety," and each topic maps to a set of agents. That's a really pragmatic design choice.

Lu: It is, and it addresses a fundamental problem in agentic systems: how do you decide what tools to use without running everything? The topic modeling approach is transparent and easy to update. And it lets the LLM operate on high-level concepts while the developers control which agents are best suited for each topic. That separation of concerns is smart.

Meng: And the grounding is what makes it trustworthy. Each agent returns an Observation object with an ID, a URL, the actual data, and a citation string. The final LLM response is injected with those IDs, so every statement can be traced back to a source. That's how you reduce hallucinations in a domain where accuracy is literally a matter of life and death.

Jane: Exactly. And the paper makes a point that the quality of the underlying data services is the primary contributor to system performance. The LLM is kept on a short leash—it's instructed to rely only on the retrieved evidence. That's a philosophy that runs through the whole design: the model is a synthesizer, not a knowledge base.

Tom: And that philosophy extends to the Deep Research Mode, which is what we're going to talk about next. Because that's where the system really shows off its planning capabilities.

Improvements: Jane: So we've covered the fast mode, which they call Scientific Mode. But the paper also describes a Deep Research Mode, and this is where I think the system really shines. Tom, this is the part where the system doesn't just answer a question—it plans a whole research project.

Tom: Right, and the way they describe it is fascinating. The system creates a research plan modeled as a directed acyclic graph of questions. It's like a flowchart of sub-questions that need to be answered in a certain order. And there's a judge agent that reviews the plan and either accepts it or sends it back for revision. Once accepted, the questions are topologically sorted, so independent questions get answered first, and dependent questions wait for the results.

Meng: And that's a really practical design, because it keeps the execution bounded. The plan is fixed at the start, so you know how many steps it'll take and roughly how much it'll cost. That's crucial for production systems. You can't have a research run that spirals out of control.

Lu: And there's a beautiful detail here. When the system executes the plan, later questions are rewritten using information from earlier answers. So if the first question identifies a synonym for a drug, the second question can use that synonym. That's how you get coherent multi-step reasoning instead of isolated lookups.

Tom: And the paper gives a concrete example: "What genes are associated with idiopathic pulmonary fibrosis?" The system generates a plan with multiple sub-questions, answers them in sequence, and synthesizes the results. But it can also handle iterative tasks, like "repeat this analysis for multiple genes." The planner translates that into a loop.

Jane: And there's another improvement I want to highlight, because it's about the Discover Agent. That's the one that does link prediction on the knowledge graph. It uses graph neural networks, knowledge graph embeddings like RotatE and ComplEx, and path-based methods. Then it combines the rankings using CRank to find predictions with the strongest agreement across models. That's the system making predictions, not just retrieving facts.

Meng: And that's where it gets interesting for practical use. The paper mentions that in Deep Research Mode, the system can first generate a prediction using Discover, then retrieve evidence that supports or contradicts that prediction. That's a hypothesis-generation loop, which is exactly what scientists do manually.

Lu: And I think that's the most significant improvement this paper suggests: moving from retrieval to reasoning. The system doesn't just find what's known; it helps researchers explore what might be true. That's a qualitative leap.

Tom: And the paper also describes how they evaluate the system. They used BioASQ for sanity checks, but they found that improvements based on real user feedback didn't always improve BioASQ scores. That's a really honest admission. Benchmarks are useful, but they don't capture what real users need.

Jane: And they built an LLM judge agent to score real interactions. That's a clever way to scale quality monitoring. Instead of manually reviewing thousands of queries, they have an automated judge that flags problems and helps them prioritize improvements.

Meng: And I have to say, the programmatic usage example at the end is a great proof point. They integrated Research Assistant into a safety assessment tool called CRAM Auto. It automatically answers questions like "What pathways are implicated in nausea?" and "Does the EGFR gene have a role in nausea?" That's the system being embedded into a regulatory workflow.

Lu: And that's the future. These systems won't just be chat interfaces. They'll be components in larger pipelines, providing grounded evidence to other AI systems. The paper mentions MCP and REST API endpoints, which makes Research Assistant a data service for other agents.

Tom: And that's the perfect segue to our conclusion, because we need to talk about what this all means for the world.

Conclusion: Jane: So, Tom, we've spent this whole episode on "Research Assistant: AstraZeneca's Agentic System for R andD," and I think the takeaway is clear. This is a system that works. It's deployed, it's used daily by fifteen thousand people, and it's changing how drug discovery happens at one of the biggest pharma companies in the world.

Tom: And the numbers are still stunning to me. Sixteen cents per query. Ten to thirty seconds response time. Those are the numbers that make agentic AI viable in an enterprise setting. And the paper is honest about the challenges—hallucinations, sensitivity to biological nuance like distinguishing between gene paralogs. But they're not treating those as unsolvable problems.

Lu: And I think the biggest implication is that this sets a template for other organizations. You don't need to be a tech giant to build this. AstraZeneca built it in-house, on top of their existing data infrastructure. The architecture is described in enough detail that other pharma companies, or even academic institutions, could replicate it.

Meng: And from an engineering standpoint, the use of Apache Burr and the topic-based agent routing are patterns that could be applied far beyond biomedicine. Any organization with large, fragmented data sources could benefit from this approach.

Jane: And the paper even acknowledges that it occupies a different space from more open-ended research systems like Google's CoScientist. Research Assistant is designed for day-to-day work, not autonomous discovery. But the CRAM Auto integration shows how it can be a building block for larger systems.

Tom: And that's what I'll remember about this paper. It's not flashy, but it's real. It's a working system that's making a difference in the real world, and it's documented in a way that others can learn from.

Jane: So with that, we're going to say goodbye to "Research Assistant: AstraZeneca's Agentic System for R andD." It's been a pleasure, and we're looking forward to seeing what AstraZeneca does next with it.

Tom: And we've got another paper coming up on the show, so stay tuned. Thanks for listening, everyone.

Jane: Take care, and we'll see you next time.