The model is not the problem. In life sciences, the data an agent needs lives across a dozen systems and thousands of documents, and all of it is bound by regulation. The agent has to decide which of those sources matters for the question in front of it. Nothing in the data tells it how.
We call this the domain understanding problem.
Storing data is not understanding it
Most tools that give agents access to data do two things: they store it and they retrieve it. That works for a customer support chatbot. It does not work when the question is “which products are affected by this change?” and the answer depends on what a product, a batch, a dossier or an identifier means in this industry.
A generic retrieval tool does not know that an IDMP identifier points to a specific medicinal product. It does not know that two records with different names can describe the same thing. It finds text that looks similar to your question, and it hands that text to the model. If the right context is not in what it found, the model fills the gap. That is where wrong answers that sound right come from.
This is not a model problem. It is a knowledge problem.
Four pains we keep seeing
Teams that try to put agents into real operations tend to hit the same four walls.
1. Fragmented master data
The same product has a different name in every system. The ERP calls it one thing, the quality system another, the regulatory system a third.
Illustrative example: a product appears as a short internal code in manufacturing, a trade name in commercial data and a full regulatory description in submissions. A person who knows the business reconciles them by hand. An agent sees three unrelated items.
Until those names are connected, every question that spans two systems is a guess.
2. Regulatory context without structure
Dossiers, SOPs and regulations are searchable. They are not connected. You can find the paragraph, but you cannot easily follow the thread from a regulation to the procedure that implements it to the product it applies to.
Illustrative example: a change to a procedure should trigger a look at the related dossier sections. If the documents are only indexed as text, nothing links them, and the agent has no reason to look.
Finding documents is not the same as reasoning across them.
3. Decisions without an audit trail
When someone asks where a number came from, the answer is a manual hunt: which system, which export, which version of which file.
An agent that gives you an answer without showing where it came from adds to that problem instead of removing it. In a regulated process, an answer you cannot trace is an answer you cannot use.
Illustrative example: an agent reports that a supplier’s documentation is complete. The reviewer asks which documents it checked and which version of each. If the agent cannot name them, the reviewer has to repeat the check by hand, and the agent saved no time.
4. Not ready for AI yet
This is the one that surprises people. Fragmented data does not just slow AI down. It makes it confidently wrong. A weak answer that sounds weak is easy to catch. A weak answer that sounds certain gets acted on.
Many pilots stall at this point. The demo worked on a clean sample. The real data did not behave.
Illustrative example: a pilot answers every question correctly on a curated set of twenty documents. Connected to the real systems, the same question returns an answer built from an outdated record, because two systems disagree and nothing tells the agent which one to trust.
A worked example: “Which products are affected by this change?”
This scenario is illustrative. It is not a customer case.
A quality manager asks an agent: “We are changing the cleaning procedure on a production line. Which products are affected, and which regulatory documents do we need to review?”
Here is what the agent has to do to answer well:
Identify the line and the products made on it. That information sits in the manufacturing system, where products have internal codes.
Match those codes to the products in the regulatory system. There they are described by name, strength and form, and identified by the standards the authorities use.
Find the dossier sections and procedures that refer to those products or to that cleaning step. These are documents, written in different formats at different times.
Check which versions are current. Two documents may describe the same step differently, and only one is in force.
Return an answer the manager can verify. Each product and each document in the list should point back to where it came from.
Now look at what a store-and-retrieve tool does. It searches for text similar to the question. It may find the procedure and a few dossier paragraphs. It has no way to make step 2, because nothing says that code A-1043 and a product in a submission are the same thing. It has no way to make step 4, because nothing says which version wins. So it returns a plausible list, missing some products, with no trail back to the sources.
Nothing in that answer looks wrong. The list is well formatted and reads with confidence. The manager finds the gap later, in an inspection or a deviation report, which is the worst place to find it.
With a knowledge layer, the same question follows a path. The line connects to its products. The products connect to their regulatory identities. The identities connect to the documents that mention them. Because every record can be traced to its source, the manager can check each hop.
The question did not change. The model did not change. What changed is that the data underneath it already knew what things are and how they relate.
Why a better model doesn’t fix it
The natural reaction is to wait for the next model. A larger model reads more, writes better and reasons further. It still reasons over whatever it is given.
If your product has three names in three systems and no record that links them, a better model has three unrelated items to work with. The missing piece is not intelligence. It is knowledge about the domain, held in the data layer where the agent can use it.
What good looks like
You don’t need a product to describe it. A data layer that agents can rely on has three properties:
A shared vocabulary. The domain’s own concepts are defined once, ideally from the reference standards the industry already uses, such as IDMP and RxNorm, rather than invented per project.
Links between systems and documents. The same product, procedure or batch is recognized as the same thing wherever it appears, so a question can follow it across sources.
Traceability by default. Every record can be traced back to its source, and so can the answer built from it.
None of this is exotic. It is the work that people in operations and regulatory teams do by hand today. The point is to build it into the layer underneath the agents, so they start from the same understanding your experts have.
Where Newton fits
Newton is the agentic knowledge platform for life sciences. It builds that knowledge layer: domain data models based on reference ontologies and standards such as IDMP and RxNorm, used to structure the data you ingest, with every record traceable to its source.
In 2025, a pilot at a multinational pharma company connected data across ERP (SAP), commercial data (IQVIA) and a regulatory information system (RIMS).
Newton Cloud, our commercial platform, is in beta. Newton Core, the scinr SDK, is open source.
Want more posts like this? Subscribe to get one practical piece on agents, knowledge and regulated data every two weeks.