Building reliable agentic AI systems

A Case Study in building production-ready agentic AI systems

This paper presents the Preclinical Information Center (PRINCE), a cloud-hosted platform

developed by Bayer AG with Thoughtworks to address pharmaceutical industry challenges in drug

development. PRINCE leverages Agentic Retrieval-Augmented Generation

and Text-to-SQL to integrate decades of safety study reports. We describe PRINCE's evolution

from keyword-based search to an intelligent research assistant capable of answering complex

questions and drafting regulatory documents. We reflect on key engineering decisions through

the lens of context engineering—how information was shaped and routed between specialized

agents—and harness engineering—how orchestration, recovery, and observability were built

around the models to maintain control and reliability. The system prioritizes trust through

transparency, explainability, and human-in-the-loop integration. PRINCE demonstrates AI's

transformative potential in pharmaceuticals, significantly improving data accessibility and

research efficiency while ensuring governance and compliance.

Sarang Kulkarni is a Principal Consultant at Thoughtworks, working at the intersection of

software engineering, data platforms, and applied AI. He focuses on building

production-grade GenAI systems, particularly Retrieval-Augmented Generation (RAG) and

multi-agent workflows, and helps teams take these systems from early ideas to real-world

use. Sarang also contributes to Thoughtworks’ Global AI Service Development team and teaches

an O’Reilly

course on building production-ready RAG applications.

Preclinical drug discovery is inherently complex and data-intensive.

Researchers face the significant challenge of efficiently accessing and

analyzing vast volumes of information generated during this critical phase.

Traditional keyword-based search methods, often reliant on rigid Boolean

logic, frequently fall short when confronted with the nuanced and intricate

nature of preclinical research questions.

The advent of Large Language Models (LLMs) has presented a transformative opportunity. By

combining the generative power of LLMs with the precision of information retrieval systems, Retrieval-Augmented Generation (RAG) has emerged as a promising technique.

This approach holds the potential to revolutionize preclinical data access, enabling

researchers to pose complex questions in natural language and receive accurate, context-rich

answers grounded in proprietary data.

Recognizing this potential early, Bayer committed to exploring how these

technologies could address longstanding challenges in preclinical research.

In this post, we share that journey—how Bayer's early investment in generative AI

has resulted in PRINCE, an agentic AI system built on Agentic RAG. This case study

explores the technical architecture, engineering decisions, and lessons

learned in transforming preclinical data retrieval from a challenging maze

into an intuitive conversational experience.

Many of the engineering decisions behind PRINCE can now be understood through the lens of context

engineering and harness engineering, although when the system was first designed we did not use these terms. Context engineering shaped what information each model

received, what it did not receive, and how context moved between specialized steps such as

research, reflection, and writing. Harness engineering shaped the scaffolding around the

models: orchestration, tool boundaries, state persistence, retries, fallbacks, validation,

reflection loops, observability, and human review.

While this post focuses on the technical architecture and engineering challenges, our paper

published in Frontiers in Artificial Intelligence covers the

product evolution and business impact in more detail.

The preclinical research landscape at Bayer, like many large

pharmaceutical organizations, is characterized by a diverse and extensive

array of data. This includes highly structured datasets from various studies, alongside vast

amounts of unstructured

information embedded within text documents such as study reports,

publications, and regulatory submissions. Researchers frequently

encountered significant hurdles in accessing and analyzing this

information effectively:

These inherent challenges highlighted a clear need for a more

efficient, intelligent, and integrated approach to preclinical data

retrieval and analysis.

To address these challenges, Bayer developed the Preclinical

Information Center (PRINCE) platform. PRINCE was conceived as a unified

gateway to preclinical data, initially focusing on consolidating

previously siloed structured study metadata and exposing them in a “Searchable” manner.

This initial phase allowed users to apply advanced filters and retrieve

information primarily from structured study metadata.

However, a significant portion of Bayer's valuable preclinical

knowledge resides within unstructured PDF study reports accumulated over

decades. Due to numerous system migrations over the years, the structured

metadata associated with these reports could be incomplete, missing, or

even contain incorrect annotations. Crucially, the authoritative “gold

standard” information was consistently present within the approved PDF

study reports.

The emergence of Generative AI, particularly RAG, provided the key to

unlocking this wealth of unstructured data. By integrating RAG

capabilities, PRINCE began to shift the paradigm from a filter-based

'search' tool to a natural language 'ask' system, enabling researchers to

query the content of these study reports directly.

This evolution reflects PRINCE's progression through three distinct

phases:

This deliberate evolution from Search to Ask to Do represents a strategic

response to the industry's need for greater efficiency and innovation in

preclinical development. By providing researchers with increasingly powerful

tools to access, analyze, and act upon preclinical data, PRINCE aims to enable

faster data-driven decision-making, reduce the need for unnecessary experiments,

and ultimately accelerate the development of safer, more effective

therapies.

The system functions as an interactive conversational UI, powered by a robust backend

infrastructure. Its architecture, designed for handling complex queries and delivering

accurate, context-rich answers, is orchestrated using LangGraph and served via a

FastAPI application.

Figure 1 provides the system context—UI, backend, data

stores, LLM fallbacks, and observability—while Figure 2

zooms into how the system coordinates its specialized agents.

Figure 1: System context and supporting

platforms.

A design principle running through this architecture is context discipline. Larger context

windows did not remove the need to be selective about what each agent sees. In early

iterations, putting too much information into the context made the system harder to steer

and harder to evaluate. PRINCE therefore avoids treating the prompt as one large container

for all available information. Instead, different stages receive different context: planning

context for Think & Plan, retrieval context for the Researcher Agent, evidence context

for the Reflection Agent, and synthesis context for the Writer Agent. This reduces context

pollution and makes the system easier to debug, evaluate, and improve.

These steps ensure that the system can provide reliable and contextually relevant answers

to a wide range of complex queries by leveraging a sophisticated, multi-agent architecture

and a diverse set of powerful tools and data sources.

PRINCE incorporates an agentic RAG system ( Figure 2 ) to handle complex user requests that require multiple

steps, reasoning, and interaction with different tools or data sources. This setup,

implemented using LangGraph, orchestrates the overall workflow and leverages Researcher

Agent, Writer Agent, and Reflection Agent for specific tasks. The system

is designed to be robust and reliable, with multiple fallback mechanisms in place to ensure

that the system can continue to function even if some of the components fail.

The Clarify User Intent step serves as the first line of defense against

ambiguity. As the system scaled to include diverse domains like toxicology and

pharmacology, simple user queries often became ambiguous, making it difficult to

automatically select the right tools. Rather than relying on expensive trial-and-error

across all data sources, the system proactively asks clarifying questions to pinpoint the

specific domain or data type.

This ensures the system enhances the query with the necessary constraints to target the

correct tools. We are also optimizing this by developing domain-level selection in

the UI, which will allow users to pre-filter valid tools upfront. To further reduce

friction, the system also provides AI-assisted source recommendations: when a user has not

selected any data source — or has selected several without a clear focus — the model

analyzes the intent behind the user's query and suggests the most relevant sources. The

user retains full control and can accept, adjust, or override the recommendation, ensuring

domain expertise always has the final say. This “fail-fast” mechanism prevents wasted

execution on vague queries, while careful tuning ensures the system remains unobtrusive

when the intent is already clear.

From a context engineering perspective, this step is the first assembly decision in the

workflow: it constrains which tools, domains, and data sources will be in scope before any

retrieval begins, ensuring subsequent agents receive a focused rather than open-ended

problem.

The Think & Plan step is responsible for devising a strategy to fulfill the

user's request. This critical component gives the system a dedicated space to reason about

the next steps before taking action—a technique inspired by Anthropic's Think tool.

Importantly, this step performs process reflection: evaluating whether the agent is

making the right progress toward its end goal and is on right trajectory, rather than

evaluating the data itself.

In multi-step agentic workflows, particularly those involving many sequential actions,

process reflection is essential. Consider a scenario where the system needs to execute 50

steps to complete a complex task. At each juncture, the system must ask: Am I taking these

steps in the right manner? Am I making the progress I'm supposed to make? Is the current

trajectory leading toward the user's goal? The Think & Plan step provides this

metacognitive capability, allowing the system to reflect on its own workflow and adjust

its strategy accordingly.

This “thinking space” has proven particularly valuable in scenarios involving multiple

tool calls.

When PRINCE was initially developed, it had only a couple of tools: one for RAG-based

retrieval and

another for Text-to-SQL queries. However, as we integrated more data sources to expand the

system's

capabilities, the number of available tools grew significantly. With this explosion of

tools came an

inherent challenge: overlapping concerns and domain boundaries across different tools.

For example, multiple tools might serve similar but subtly different purposes—querying

structured

metadata versus unstructured reports, or retrieving study summaries versus detailed

experimental data.

When presented with tools that belong to similar domains but handle slightly different

data, the LLM

would sometimes struggle to select the most appropriate tool for a given query. By

introducing a

dedicated thinking step, the system can explicitly reason about which tool best matches

the user's

intent, evaluate the characteristics of each available tool, and make a more informed

decision. This

approach led to a dramatic improvement in the accuracy of tool selection.

Beyond tool selection, the Think & Plan step is essential for orchestrating

multi-step processes. Many complex queries in PRINCE require a series of tool calls where

the output of one tool must be analyzed before determining the next action. For instance,

the system might first query structured metadata to identify relevant studies, then use

those study IDs to retrieve detailed information from unstructured reports, and finally

synthesize the findings. Without a dedicated space for process reflection, the system

would attempt to execute these steps linearly without evaluating whether each step is

bringing it closer to the goal. With the thinking step in place, the system can pause,

assess its progress in the workflow, and intelligently plan the subsequent tool calls

needed to complete the user's request.

The Researcher Agent serves as the system's primary information gatherer. As we

onboard new scientific domains onto PRINCE, we consistently observe that data falls into

two primary categories: structured and unstructured. While specific

implementation techniques may vary across domains — for instance, leveraging Snowflake

Cortex Analyst for pharmacology queries for Text-to-SQL versus other more custom methods

for toxicology—the fundamentals behind these retrieval strategies remain consistent.

As PRINCE expands across multiple preclinical domains, a single Researcher agent with a

flat tool list

becomes increasingly hard to manage. Many tools operate on similar concepts—“studies”,

“findings”, “assays”—but point to different underlying datasets, schemas, and regulatory

interpretations depending on the domain. For example, when a user refers to “the study”,

the relevant context might be a repeat‑dose toxicology study, a cardiovascular safety

pharmacology package, or a particular assay in aggregated mass‑data tables, each with its

own preferred sources of truth.

To avoid one monolithic agent juggling overlapping tools and subtly different data

contracts, we are actively evolving the Researcher capability into a hierarchy of

domain‑specific

sub‑agents. In this proposed architecture, each domain agent will own its own toolset (for

example, toxicology RAG + tox

metadata SQL, or pharmacology RAG + assay‑level SQL) along with tailored prompt

instructions that encode how that domain’s data model works, which tables or indices are

authoritative, and how to interpret key concepts. We anticipate this will keep

responsibilities coherent,

reduce accidental cross‑domain leakage, and make it easier to reason about and test

retrieval behaviour per domain.

To effectively harvest insights from this diverse landscape, the Researcher Agent employs

a hybrid retriever approach focused on two distinct

patterns:

This dual-strategy allows the system to bridge the gap between narrative scientific

reports and quantitative experimental data.

In this updated vision, the top‑level Researcher Agent is designed to act as a

coordinator rather than a

single all‑knowing component. Given the clarified user intent and any explicit domain

selection from the UI, it will route the query to the appropriate domain sub‑agent, which

can then

decide how to combine RAG and Text‑to‑SQL within its own boundary. This pattern aims to

preserve the simplicity of “one researcher” from the user’s perspective, while internally

allowing each domain to evolve its own tools, schemas, and retrieval recipes without

destabilizing the rest of the system.

Given the vast repository of thousands of preclinical study reports and other

unstructured documents, RAG is essential for extracting relevant insights by grounding

LLM responses in this specific knowledge base. The RAG pipeline comprises a

comprehensive ingestion process and a sophisticated

query-time architecture.

Ingestion Process: Preclinical study reports, mostly PDFs spanning decades and

often including scanned documents with complex tables, are first centralized into an S3

data lake and passed through an extraction pipeline tuned for this corpus. The extracted

text is normalized into structured JSON and then chunked using a strategy that preserves

enough scientific context while keeping chunks efficient for retrieval.

Each chunk is enriched with study‑ and section‑level metadata from Amazon Athena (for

example study ID, compound, species, route, page, and parent section), which later

enables precise metadata filtering in the RAG layer. Finally, these annotated chunks are

embedded and indexed in Amazon OpenSearch Service,

forming the vector store that backs semantic and metadata‑aware retrieval over both the

historical corpus and the daily deltas as new or updated reports arrive.

Query-Time RAG Pipeline: When a user submits a query, the system initiates a

multi-stage retrieval process. This pipeline is engineered to effectively retrieve the

most relevant and trustworthy information from the vector database to ground the LLM's

response.

To illustrate this pipeline, consider the example query: “Were any of the

following clinical findings observed in study T123456-2: piloerection, ataxia,

eyes partially closed, and loose faeces?”. The system processes this query

through the following steps:

While RAG excels at unstructured data, queries requiring precise filtering,

aggregation, or comparison of structured data points are better suited for Text-to-SQL.

Examples include “Give me 50 example studies done on RAT” or retrieving specific

numerical assay results including dosage groups. As shown in the

Researcher Agent can intelligently decide to hand over such queries to the

Text-to-SQL tool.

The process for converting a natural language question into an executable

SQL query and retrieving results involves several key steps:

While the Think & Plan step provides process reflection, the Reflection

Agent performs a complementary but distinct type of reflection: data reflection.

This crucial component evaluates whether the data retrieved from various tools is

sufficient and relevant to answer the user's question—a fundamentally different concern

from whether the workflow itself is progressing correctly.

In multi-step agentic workflows, these two types of reflection serve different but

equally important

purposes. Process reflection (Think & Plan) ensures the agent is taking the right

steps and making

appropriate progress toward the goal. Data reflection (Reflection Agent) ensures that the

information

gathered through those steps is adequate to fulfill the user's request. Both are

essential: an agent

might execute a perfectly valid workflow (good process) but still retrieve insufficient

data to answer

the question, or conversely, might have access to sufficient data but fail to progress

effectively

through the workflow.

As illustrated in the research workflow diagram ( Figure 2 ), after initial information retrieval and 'think

& plan' loops, the Reflection Agent is invoked when Think & Plan step

thinks that the process has progressed well enough and is ready to evaluate the data.

'Reflection Agent' evaluates the sufficiency and relevance of the collected data by

comparing the retrieved context against the user's original query and identifying

potential gaps or missing information. If the gathered information is deemed insufficient

to provide a complete response, the Reflection Agent generates specific follow-up

questions designed to acquire the necessary missing information. These follow-up questions

are then handed back to the Think & Plan step, which initiates further

retrieval steps to obtain more comprehensive results. This iterative process of data

validation and subsequent information retrieval, driven by the Reflection Agent 's

generated questions, demonstrates the system's ability to refine its search strategy based

on the initial results. If the information is sufficient, the workflow proceeds to the

next step.

Once the Researcher Agent has collected the relevant evidence from RAG and Text-to-SQL,

the Writer Agent is responsible for turning that raw material into the final answer

shown to the user. Its job is not to “discover” new information, but to synthesize the

retrieved context, respect user instructions, and enforce PRINCE's quality constraints

during generation.

The Writer Agent operates with a few non-negotiable rules. It must ground every claim in

the supplied context and attach accurate citations back to the underlying chunks and study

IDs, since verifiability is critical in a regulated environment. It is also responsible

for honoring user-level formatting requirements (for example, tables, bullet points, or

specific section structures) and for aligning with domain-specific answer standards used

by the preclinical scientists.

For more complex responses—such as multi-section summaries or partially filled regulatory

templates—the architecture supports extending the Writer Agent with a short internal

review loop. In this pattern, the Writer would first draft an answer, then a reviewing

step would check for missing sections, inconsistent tables, or gaps relative to the

original question, and may send targeted instructions back to the Writer to revise

specific parts. This design enables a lightweight form of reflection focused on answer

completeness and

presentation, complementing the Reflection Agent's focus on data sufficiency

earlier in the workflow. Importantly, all outputs from these regulatory drafting workflows

are intended for expert review; final submissions are authored and approved by qualified

personnel.

This gives PRINCE three complementary reflection loops. Process reflection checks whether

the workflow is on the right path and helps catch bad trajectory, wrong tool choice, or

poor sequencing. Data reflection checks whether the gathered evidence is sufficient and

helps catch thin evidence, missing context, or gaps in coverage. Draft reflection checks

whether the generated output is complete and helps catch missing sections, incomplete

tables, or synthesis gaps.

Together, these agents form a practical context engineering pattern. The system does not

simply keep adding more information to the prompt. It routes the right context to the right

capability at the right time: planning context for Think & Plan, retrieval context for

the Researcher, evidence context for the Reflection Agent, and synthesis context for the

Writer. This plays out in concrete decisions throughout the system: the Text-to-SQL step

injects only the schema components relevant to the current query rather than the full

database schema; the Reflection Agent receives the original question alongside collected

evidence to assess gaps, not the full workflow history; and the Writer Agent receives curated

chunks with citation constraints, not raw retrieval output. Moving from a monolithic agent

to this structured workflow meant each agent could be evaluated, debugged, and improved in

isolation.

Building and maintaining user trust is paramount for the successful

adoption of any AI system, particularly in a critical environment like

preclinical drug discovery where decisions have significant implications. For

a production LLM application, trust is not just about accuracy; it's also

about reliability, transparency, and the ability for users to verify the

information provided. Several mechanisms are integrated into PRINCE

to achieve this:

Ensuring transparency and explainability is a critical aspect of PRINCE's

design, fostering user trust and enabling verification of the

generated responses. The system incorporates several mechanisms to achieve

this:

Rigorous evaluation is fundamental to building and maintaining a reliable

LLM application. PRINCE's performance and reliability are assessed

through a combination of two types of evaluations: Dataset Evaluations and

Live Traffic Evaluations.

Continuous monitoring of the system's performance and outputs is essential

for proactive identification and resolution of issues in a production

environment. Using platforms like Langfuse, we continuously monitor

PRINCE to identify potential biases, errors, or areas for improvement,

ensuring the reliability and safety of the system's responses.

Given the complexity of the multi-step workflow inherent in PRINCE,

robust error handling and recovery mechanisms are critical to ensure

the system's reliability and provide a seamless user experience. The system is

engineered to recover gracefully from failures at various stages without

requiring a complete restart of the entire workflow.

Key aspects of our error handling and recovery approach include:

This comprehensive approach to error handling and recovery minimizes the

impact of transient failures, reduces the need for users to restart complex

queries from scratch, and contributes to cost and latency savings by avoiding

redundant execution of successful steps and LLM calls, all of which are

essential for a production-ready system.

These mechanisms are harness engineering in practice. The LangGraph workflow acts as

the control layer around the agents: it defines which component can act, which tools it can

use, where the workflow can pause, how failures are retried, how state is persisted, and

when the system should move from research to reflection to writing. This harness makes the

system less opaque and more reliable than an unconstrained autonomous agent. It gives the

application clear control points for recovery, inspection, evaluation, and human

intervention.

The accuracy and completeness of the structured metadata in Amazon Athena

are critical for the performance of the Text-to-SQL component and overall data

discoverability within PRINCE. Due to historical data migrations and varied

annotation practices across different laboratories and systems over Bayer's

extensive operational history, the metadata can sometimes be incomplete,

missing, or incorrect.

To address this challenge and continuously enhance the quality of the

structured metadata, we have developed a utility system that employs Named

Entity Recognition (NER) to extract and create accurate annotations directly

from the study PDFs. This system is designed to read the textual content of

the preclinical reports and identify key entities and associated information

that should be represented in the structured metadata.

We are actively working on integrating this utility system into our data

pipelines to automatically correct and enrich the data within the Amazon

Athena database. The system's performance in generating accurate annotations

has been evaluated against curated datasets, demonstrating promising results.

To manage the integration of these annotations into the production database,

we are developing an evaluation system that provides a confidence score for

each extracted field. Fields with a high confidence score will be

automatically used to update the corresponding entries in Amazon Athena.

Fields with lower confidence scores will be quarantined and flagged for human

review and intervention, ensuring data accuracy while leveraging automation.

This approach aims to continuously improve the quality of the structured

metadata, making it a more reliable source of information for PRINCE

and other downstream applications.

PRINCE has been available to end-users since early 2024, with the agentic

integration introduced later that year.

This has been crucial for gathering real-world feedback

and driving iterative development. A key principle guiding our development

has been the understanding that building a production-ready LLM application is

an iterative process; we don't wait for features to be absolutely perfect

before seeking user feedback. Instead, we prioritize delivering value

early and continuously refining the system based on real-world usage.

In the initial stages, our focus was squarely on achieving the desired

accuracy and performance for core functionalities, even if it meant incurring

higher costs. We recognized that optimizing for cost prematurely could

compromise the system's effectiveness and hinder user adoption. Only after

achieving the desired level of accuracy and performance did we begin to focus

on cost optimization, ensuring that efficiency gains did not negatively impact

the user experience or the quality of the results.

The development of PRINCE follows a continuous, iterative

process. User feedback, ongoing monitoring data, and insights from expert

scientists are continuously fed back into the development cycle, leading to

refinements in the architecture, retrieval techniques, agent behaviors, and

user interface to enhance performance, usability, and ultimately, scientific

impact.

Building a production-ready LLM application in a complex enterprise

environment like preclinical drug discovery is a journey marked by significant

technical and engineering challenges. The PRINCE case study

demonstrates that by combining robust data infrastructure, sophisticated

information retrieval techniques like RAG and Text-to-SQL, and an intelligent

multi-agent orchestration system, it is possible to unlock valuable insights

from vast, previously inaccessible data repositories.

Our experience highlights the critical importance of focusing on

engineering for reliability, including robust error handling, state

persistence, and LLM fallbacks. Furthermore, building user trust is paramount,

achieved through transparency in the workflow, clear explainability via

granular citations, and continuous evaluation and monitoring of the system's

performance.

PRINCE has already shown promising results in enhancing data

accessibility and research efficiency at Bayer, transforming how scientists

interact with preclinical information. This is not the end of the journey, but

rather a significant step towards creating truly intelligent research

assistants.

The broader lesson from PRINCE is that production-ready agentic AI is not only about better

models or better prompts. Reliability comes from engineering both the context the model sees

and the harness within which the model acts. Context engineering helped ensure that each

model had the right information, and only the right information, at the right stage of the

workflow. Harness engineering helped ensure that the workflow remained bounded, observable,

recoverable, and suitable for a regulated research environment.

As model capabilities improve, some parts of today's harness may become thinner or move

into native model capabilities. But in enterprise research systems, especially where trust,

traceability, and reviewability matter, explicit control over context, workflow state,

recovery, reflection, and verification remains essential.

We hope this overview provides valuable insights into the practical

considerations and technical depth required to build and productionise LLM

applications in a regulated and data-rich domain.

The author gratefully acknowledges the invaluable contributions of Adam Zalewski, Annika

Kreuchwig, Carlos Henrique Vieira-Vieira, Jobst Löffler, and Jonas Münch from the Bayer

team.

The author also thanks Bala Hari, Balu Saravanan, Bernice Mercy Sharon M, Deril X, Jigar

Jani, Manibalan Baskaran, Nafis Aslam, Priyalakshmi R, Rohit Bansal, Sai Prabhanj Turaga,

Saksham Srivastava, Shivam Sehgal, Sowmya Adimoulame, and

Subhashini Rajamani from the Thoughtworks team for their contributions to this work.

The author used AI assistance during the writing of this article. AI tools were used for

brainstorming ideas, creating outlines, and reviewing drafts to polish language and

improve clarity.

All activities described conform to Bayer's information classification, data governance,

and external communication policies, and do not constitute claims regarding regulatory

decision‑making or product performance.