Agent sprawl in life sciences - part 1: how we got here

Why your agents multiplied quietly, and what makes the GxP intersection so tricky

A pattern is showing up across larger life science companies, and it's common enough by now that most people in R&D recognise it the moment you describe it, even if no one's put it on a slide yet.

A computational biology team in early discovery builds an agent to scan PubMed, pull hit compounds from internal assay databases, and map them against known target pathways. It saves hours of manual triage per week. A few months later, the clinical data science team builds something similar to capture safety signals from trial data, but on a different stack, pulling from different systems, because their data sits in a validated environment and they can't wait for IT alignment. Meanwhile, regulatory affairs start using an agent to draft responses to health authority questions, trained on previous submission dossiers. A quality team builds one to flag out-of-trend results in stability studies before they turn into deviations.

None of them know about each other at this stage.

Multiply that across discovery, translational, clinical, regulatory, quality, and supply chain. Add years of decisions made under deadline pressure. Add the reality that some of those systems touch GxP and some don't, and the people building agents often aren't sure which is which.

The question stops being "how do we adopt AI?" and becomes something harder: how do we make sense of what we've already built, so it aligns with what we want to build next?

That's what agent sprawl looks like in practice.

It doesn't look like chaos. That's the problem.

The tricky thing about agent sprawl is that each individual decision is feasible and defensible. The computational biology team chose a cloud-hosted model because it integrated with their existing notebook environment. The clinical team used a platform their vendor already supported. Regulatory picked a tool the compliance team had seen before. Every choice made sense in context.

Zoom out, and the picture is messier:

• No centralised storage, ingestion, or vector search layer: each team builds its own RAG pipeline end to end, chunking and embedding the same documents separately, so the same infrastructure gets rebuilt and paid for multiple times over.

• Multiple teams are calling different external model APIs, each with a separate contract and no visibility into combined spend, and no tiering either: a simple task often runs on the same expensive model as a hard one.

• Two agents pull data from the same clinical database or even the same table, but with different query logic, and occasionally return different numbers for the same question.

• Prompt templates have diverged across teams: what counts as a "complete" summary in regulatory is different from what discovery expects.

• When something goes wrong, there's no shared logging, so debugging turns into a string of meetings, and no audit trail to show a regulator what an agent actually accessed and why.

What you end up with isn't just an architecture. It's a pile of reasonable decisions that nobody has looked at as a whole.

And the places where that pile matters most are exactly the places that are hardest to unpick: where agents touch regulated data, regulated decisions, or regulated outputs.

Where it gets complicated: AI in a GxP world

GxP, the family of "Good x Practice" regulations covering clinical, manufacturing, laboratory, and other regulated activities, was not designed with AI agents in mind. The frameworks are built around systems that are specified, validated, and change-controlled. An agent that calls a model, interprets a response, and writes to a database is, in that sense, a system. That has consequences most teams haven’t fully worked through.

In a typical tech company, updating a model or adjusting a prompt is a minor deployment. In a GxP-regulated context, the same change can require formal risk assessment, documentation, and in some cases even revalidation. The specifics depend on the system's classification, data confidentiality, and what it's used for, but the question needs to be asked, and in sprawl conditions, it often isn't.

Regulators are only just catching up to this themselves: the FDA's first guidance addressing AI directly, lays out a seven-step, risk-based framework for establishing whether an AI model's output can be trusted for a regulatory decision, but it explicitly excludes AI used in drug discovery or for general operational efficiency. That line matters. It means a tool your discovery team built as a research shortcut can drift, unnoticed, into something a regulatory reviewer is actually relying on, and cross straight from "outside guidance scope" into "the FDA has an opinion about this" without anyone re-classifying it.

In practice, most pharma R&D organisations are running across three different zones simultaneously:

• Tier 1: GxP-validated. Systems and tools that feed directly into regulated outputs. Change is formally controlled. Risk tolerance is low.

• Tier 2: GxP-qualified. Systems and tools that inform regulated decisions without directly producing them. There's governance, but there's room for more flexibility.

• Tier 3: Non-GxP. Notebooks, research tools, internal knowledge assistants, literature monitors. Fast to build, easy to iterate, minimal regulatory overhead.

Those tiers only tell you about regulatory risk, and it's a separate question from how sensitive the data itself is. Most life science companies also run a data confidentiality classification, usually something like public, internal, confidential, and highly confidential/restricted, and the two scales don't move together. A Tier 3 tool sitting comfortably outside GxP scope can still be handling confidential data: a competitive intelligence agent, an early discovery tool touching unpublished IP ahead of a patent filing. Meanwhile, a Tier 1 system can end up processing data that's effectively public, once a result has cleared review and disclosure.

The problem with sprawl is that the line between tiers blurs quickly, and people building in tier three sometimes don't realise their tool has drifted into tier two. An agent that was a convenient internal summariser can become the thing a regulatory reviewer is relying on.

Each layer also carries its own tooling requirements, and that's usually where teams get caught out. GxP tier requires things like validated environments, formal change control, and audit logging. Confidentiality tier requires things like encryption, stricter access control, and often a hard no on any vendor that might train on the data. An agent has to satisfy both sets at once.

The tricky thing about agent sprawl is that each individual decision is feasible and defensible.

Five types of data, and why none of them play by the same rules

Governance aside, there's a second structural challenge: pharma data is heterogeneous in ways that most platform thinking doesn't account for.

An agent built to work with omics data operates very differently from one built to parse regulatory dossiers or pull results from an electronic lab notebook. These aren't just different file formats. They require different models, different retrieval strategies, and different validation approaches.

The five data modalities most pharma organisations are navigating:

• Omics data. High-dimensional, statistically complex, and usually processed through specialised pipelines before it's usable. An agent that tries to retrieve raw variant data the same way it retrieves a PDF is going to produce nonsense. This is where a lot of early genomics agents ran into trouble.

• Pre-clinical data. Scattered across LIMS, ELN systems, vendor databases, and the occasional Excel file someone built in 2014. Data engineering does most of the real work here. Agents can help, but only once there's a coherent data layer underneath.

• Clinical data. Structured and standardised but semantically tricky. A query that looks correct can return a misleading answer if the agent doesn't understand protocol amendments, visit windows, or imputation rules. Clinical data scientists spend years learning about these domains. Agents don't inherit that knowledge automatically.

• Document-based data. Regulatory dossiers, technical reports, SOPs, meeting minutes. Structure matters as much as content. An agent that can summarise a document isn't the same as one that understands where in a submission hierarchy that document sits, or what a gap in a section actually means.

• Image data. Histopathology slides, flow cytometry plots, in-vivo imaging, manufacturing inspection photos. Entirely separate infrastructure, often separate teams, and models that need domain-specific fine-tuning to be useful. This is the modality most organisations are least prepared to govern.

Most agents are built within a single data modality, by people who understand it very well. The gap is cross-modality: the ability to connect an omics finding to a clinical observation to a regulatory implication. That's where some of the real scientific value lies, and it's also where the governance complexity increases exponentially.

Where this leaves us

Mapping the sprawl is the easier half of the problem. The harder question is what to do about it, how to bring agents back into a coherent picture without slowing down the teams who are actually delivering value, and without pretending you can standardise this whole mess at once.

That's where we'll go in part two: what consolidation actually looks like when full standardisation isn't realistic, the organisational shifts that make it possible, and a pragmatic near-term target for getting visibility and control without slowing the work down. More on that in the next blog.