Nearly every large sponsor now carries an enterprise AI subscription on the books. Claude Enterprise, ChatGPT Enterprise, Gemini for Workspace — approved, deployed, live. Ask what those tokens actually do all day and the honest answer is drafts, summaries, inbox triage, meeting notes. Useful work. Not the work a five-figure annual contract for frontier-model access was supposed to buy.
The models are not the bottleneck. A frontier model reads faster than anyone on your team and pattern-matches against documented standards better than most specialists.
The bottleneck is that a base model does not know CDISC. It cannot map an adverse-event dataset to conforming SDTM variables with the right controlled terminology, the right cross-domain checks, and a confidence score that tells your DM lead which calls actually need a human. It cannot generate a Pinnacle 21–passing Define-XML package. It has never seen your study's USDM structure, your DMP template, or your SOP reference numbers.
That gap is exactly what Nexus Assistant closes — and the MCP v2 upgrade we shipped last week is what turns it from a demo into something you can put in front of a regulator.
The tokens that would have drafted a meeting summary can close a study build instead.
What Nexus Assistant is
Nexus Assistant is @TrialNexus: our CDISC-native agents, exposed as MCP tools and callable straight from Claude Enterprise, ChatGPT Enterprise, Gemini for Workspace, or any MCP-compatible client. The assistant your DM lead is already typing into gets a set of tools that understand CDISC, hold the study's USDM output in context, and route every result through the same Part 11 Decision Queue as the full TrialNexus Core pipeline. No new login. No new interface. No workflow to migrate to.
One prompt. Three decisions instead of thirty-four.
Your DM lead types what they would type anyway: @TrialNexus map the AE dataset for Study A4471 — flag anything below 85% confidence. What comes back is not a plausible-looking guess. It is a structured result: 34 variables mapped, 31 auto-mapped above threshold, 3 routed to the Decision Queue with the specific ambiguity documented for each. Your DM lead reviews 3 decisions, not 34 — and every one arrives with the evidence needed to make it.
Behind that single message, the audit trail records the invocation, the model version, the agent version, the inputs, the outputs, and the timestamp — immutably, in the same append-only store as every other action in TrialNexus. The DM lead never left their enterprise AI window. The compliance record is already complete.
Why MCP v2 made this real
TrialNexus has run an MCP endpoint in production for a while. What the old SDK could not do was negotiate the protocol introduced in the 2026-07-28 MCP specification — and one capability in that spec is the difference between a neat demo and a tool you would trust with a signature.
That capability is the multi-round tool request (MRTR). In the old model, a tool call was one round trip: inputs in, output out. Fine for a query. Not fine for a tool that records a 21 CFR Part 11 approval on a clinical artifact.
A single round trip gives an agent no structural way to pause and show the artifact to a human before committing the approval — so the agent could sign on its own judgment, and the audit trail would have no way to tell that apart from an approval a human actually directed. That distinction is not a nicety. It is the compliance boundary. Part 11 §11.10(e) requires audit trails of operator entries — and in an AI-assisted pipeline, the operator is the qualified human who directed the action, not the agent that executed it.
The new tnx_approve_artifact_interactive tool uses MRTR to hold that line. When your DM lead's session calls it, the tool pauses mid-execution, returns the artifact's current content with an explicit confirmation prompt, and waits. The DM lead confirms or declines. Only then is the approval recorded. Each entry carries an outcome field — "completed" when a human explicitly confirmed, "paused" when the session ended first. A paused call is never written as a completed approval.
Human-in-the-loop, enforced by the protocol — not by a policy you have to trust everyone to follow.
See @TrialNexus run on your study's actual protocol.
Book a walkthroughThe ROI your finance team was actually looking for
The business case for enterprise AI, in most pharma budget decks, read like this: the team will use it to speed up documents, cut meeting time, improve search. Real value — but diffuse, hard to measure, hard to pin to the line item.
Nexus Assistant changes the accounting. Now there is a tokens-to-outcomes line: @TrialNexus mapped the AE dataset for A4471. @TrialNexus generated the Define-XML package. @TrialNexus ran the data-quality scan on Site 042. Every call logged with the study, the artifact, the agent version, and time saved against the manual baseline. The subscription that was paying for email summaries is now paying down the 68-day study build.
This is what we mean when we say TrialNexus is built to run on the AI infrastructure sponsors already have. We are not asking for a new budget line. We are asking you to point the tools you already pay for at work that is worth doing — SDTM mapping, Define-XML generation, DMP drafting — with the domain knowledge, the compliance architecture, and now the protocol to make the hand-off seamless from wherever your team already works.
The frontier-model subscription your sponsor already approved is the right place to run these agents. We built the MCP v2 layer to make that true — and it is live today.