A translational team wants to know whether a study is feasible. How many patients with this cancer subtype, this biomarker status, treated in this region, have matched slides and outcome data? Today that question goes to a data manager and comes back a week later, usually revealing that it was the wrong question, because the number tells you your filters were too narrow. So you ask again, and wait again.
PaiX Navigator is built to collapse that loop. You ask in ordinary language and arrive at a real, licensable, AI-ready cohort the same afternoon.
The first time we watched it do that end to end, in front of people whose week it would have saved, it was genuinely satisfying. It was also the easy part.
What follows is that same question put under four kinds of pressure a demo never applies: the first time, a bad day, a thousand times a day, and an auditor two years later. Nearly everything we have learned building this product lives in those four answers.
The same question, the first time
The moment a question arrives, a second and smaller model reads it, watching for prompt injection, abuse, and things outside what the platform is for. It runs alongside the main request rather than in front of it, so in the normal case nobody waits for it, and every decision it makes is logged with the reasoning behind it. Screening every message rather than sampling is the difference between a control you can describe to an auditor and one you cannot.
Then a specialist picks the question up. Navigator is not one assistant with a database behind it. It is several agents, each with its own instructions and its own fixed set of tools: one shapes a data request, one answers availability questions, one explores a dataset. An agent working on a request has no route to another workflow’s tools, which keeps the blast radius small and, less obviously, makes each agent testable in a way a general assistant never is.
The agent writes a query. That query does not go to a database. It goes to application code that checks it first: read-only, no schema or data changes, nothing stacked onto the end of a statement, only tables on an explicit list. Against the governed datalake, a question like this one comes back as a count rather than records. In the exploration workspace, results are capped and stripped of file-location fields before anything renders.
That is the part worth dwelling on. The checks are not instructions to the model; they are code sitting between the model and the data. A model can be argued with. A code path cannot. No amount of clever phrasing in a chat window widens the list of tables an agent may read.
So the team gets a number in a minute instead of a week, sees that their filters were too narrow, and asks again. That is the loop working.
The same question on a bad day
Now run it again on a Tuesday when nothing is behaving.
These systems fail differently from ordinary software. Providers rate-limit. Requests time out. A generated query is occasionally invalid. Every so often the model is confidently wrong. In a demo, any one of those is embarrassing. In production it is just the weather.
So the failure paths get designed rather than discovered. The agent loop runs in a background worker and streams results as they arrive, so a slow model never holds a web request open and one stalled conversation never blocks anybody else’s. Provider errors are translated into a handful of meanings a user can act on, and stored with the message rather than vanishing into a log file. A narrow class of transient failures is retried automatically; everything else surfaces as something a person can respond to instead of a spinner that never resolves. When a query comes back invalid, the error goes back to the agent, which gets a fixed number of attempts to correct it: enough to recover from a mistake, not enough to loop.
One decision only shows up on a bad day. The screening model can itself fail. Somebody has to choose in advance whether it fails open or closed, and write that choice down. We chose, and we documented why. In a regulated setting, an undocumented default is a finding waiting to happen.
I suspect this is where most AI pilots quietly end. In our experience the model is rarely the problem. What is missing is everything around it: the failure paths nobody designed, the defaults nobody decided, the Tuesday nobody planned for.
The same question, a thousand times a day
Nobody meters a demo. A product has a cost per conversation, and that number quietly decides whether a pilot becomes something a team opens every morning. Which makes cost an engineering constraint with a commercial consequence, not a finance footnote.
Every message records its own token usage, priced against a model rate table, so spend is visible per message, per conversation and per user instead of arriving as a monthly surprise. The stable part of each agent’s instructions is cached at the provider, so a long conversation does not re-pay for the same context every turn. History is windowed and older tool output trimmed. Queries are cost-estimated before they run, with a band that warns and a band that refuses, because one careless question against a very large table is otherwise an expensive lesson.
A prototype that costs a fortune per answer has not become a product yet, whatever the demo looked like.
The same question, two years later
Eventually somebody asks why the system said what it said. Usually long after the conversation, usually when something is riding on it, and by then nobody remembers.
This is where systems like ours meet an awkward fact about the rules they operate under. MDR and IVDR were written for software that is fixed, versioned and inspectable. Systems built on today’s models are none of those things by default: the model behind an answer is updated by someone else on their schedule, the same question can take a different route to the same conclusion, and the reasoning is not sitting in a file anyone can open. That is not a reason to avoid building them. It is a reason to decide early what you will be able to show.
Our response was not more documentation. It was to make behaviour reconstructable. Every message, every tool call and what it returned, every screening decision and every administrative action is persisted. Users can flag an answer as wrong, so disagreement becomes data rather than an anecdote someone repeats in a meeting.
The other half of the response is keeping the consequential steps human. Submitting a data request, and releasing data against it, are ordinary application actions that require a person; they are not tools the model can call. The model proposes, a person commits, and nothing leaves the platform because a model decided it should. To be straight about that gate: it is enforced in the application layer rather than in the tool contract. That is sufficient today, when every route to it runs through our own interface. It would have to become intrinsic before we exposed any of this over an API.
What we still cannot do
Maturity is not claiming to be finished. It is knowing the order the remaining pieces have to arrive in.
Everything above is running today. Next, roughly in this order. A single trace per agent run, so the story of one execution does not have to be reassembled from several places. An evaluation suite built from realistic questions with known-good outcomes, so a change to an agent’s instructions can be shown to be an improvement rather than merely a difference. Classification of what the system sends out, not only what comes in; today we redact patterned identifiers and file locations on the way out, which is not the same as judging the output. Versioning of instructions, so an answer from three months ago can be reproduced instead of excavated. And retrieval, so agents look things up rather than relying on what the model happens to know.
That order is not arbitrary. Traces and user feedback have to exist before evaluation is possible, and evaluation has to exist before it is safe to move quickly.
Publishing the list is deliberate. A vendor who cannot tell you what their AI system does not yet do is telling you something either way.
Products are promises
Prototypes are cheap because they are reversible. If a proof of concept turns out to be wrong, very little happens. Products are not reversible in the same way, because people plan around them. A study gets designed. A submission gets assembled. A programme gets funded.
Which is why the question worth putting to any AI vendor in this industry is no longer “can it do this?” Almost everyone can stage a convincing demonstration that it can. The better question is what happens when it is wrong, and whether they can show you.
Answering that calmly, with evidence, is the harder half of the work. It is also the half worth writing about.
PaiX Navigator is in beta. If you have a cohort question that currently takes a week to come back, that is the one worth bringing; the question above is the one to put to us. You can see what it does or request access.
