Users Could Find Any Record on a Pharma Data Platform. They Couldn't Get an Answer Out of It.

The Problem

The company's platform serves market access teams at global pharmaceutical companies. It holds regulatory decisions, health technology assessments, and reimbursement outcomes across national and regional jurisdictions, down to the evidence behind each decision and the documents where the reasoning lives.

A team preparing a launch needs precedent from it: what each HTA body decided for comparable drugs, on which evidence, with which restrictions, and why. That precedent shapes the reimbursement strategy and the launch sequence. Misreading one market can cost a resubmission cycle.

What users could do

Find records. Not answer questions. A filter takes one condition per field. A landscape question carries many at once and often needs a computation across the results. "What share of decisions in this indication carried restrictions, by country, and is it trending?" No filter computes that. And from any result there was no way to go deeper: which trials this decision was assessed against, which approval preceded it, which reimbursement conditions followed, why it went negative. Each was a new search.

So every real question became filter, export, deduplicate, cross-tabulate, read the documents. Precedent dropped out at each step. The most-asked questions had already been turned into templates. That was the signal: users needed templates because they could not compose the questions themselves.

When users could not get there, they asked the company's in-house experts, who asked data engineers, who wrote queries that came back for validation. Days per question, occupying the two groups the company could least spare.

The first attempt

So the company invested in an SQL agent. An external vendor built it over several months, with ongoing support from the internal team. It arrived as a narrow first version: a single view with 10 columns, basic SQL only. It had no structured outputs, no guardrails, and no separation between domain logic and agent logic, so it could not grow into the questions users were asking.

It had also shaped the platform around itself. API contracts, frontend components, and services were all written against its limits. Replacing it meant weeks of extra engineering to remove it from every system it touched.

What Prosperaize Delivered

Prosperaize replaced the first agent with an intelligence layer the company owns, one that handles the full complexity of market access data across every jurisdiction in the dataset. It rests on four capabilities.

Metadata Foundation

A structured knowledge layer: column descriptions, business-context annotations, country-specific constraints, value-range definitions. It made the database understandable to an AI agent. This was the least visible work in the engagement and everything else depended on it. We kept refining it after the first version, as edge cases surfaced.

Domain-Organized Data Architecture

Twelve purpose-built database views spanning 300+ columns, pre-encoding the critical JOINs, country-specific business logic, and semantic groupings. Instead of asking the agent to work out the database, we reorganized the database so the agent could use it.

Production SQL Agent

A LangGraph-based agent with query validation, deterministic SQL, complexity classification, multi-turn conversation handling, and strict output guardrails. Every query component is validated before execution. The same question produces the same SQL every time. The guardrails also cover what the data cannot say.

Cross-Platform Intelligence

Document summarization with parallel extraction and majority voting, and an API that makes the agent available to other teams and other agents. Both sit on a composable architecture designed for expansion from the start.

How the Engagement Ran

The client knew what they needed. Not an AI strategy, a diagnosis. They had an agent in production that was not working, and the first question was whether it could be saved. So the engagement started where a failing system enters the AI Asset Development Lifecycle: at diagnosis. Each step below names the lifecycle stage it maps to.

Step 1. Diagnosing the agent they already had

AI Reliability & Optimization, entry point

Engineering leadership brought us in to find out whether the existing agent could be fixed. Over two weeks we ran workshops with them and the internal team who had been supporting the agent, and we inspected the codebase.

The business bottleneck was obvious. The data foundation was the finding. The data had never been described for a machine reader. Jurisdiction-specific constraints lived with the domain experts, not in anything an agent could read. No agent could have worked against the data in that state, whoever built it.

The codebase confirmed the rest. Its structure could not carry the questions users needed answered, so improving it was not an option. It had to be replaced. Engineering leadership accepted that verdict, and the cost of it, on the evidence.

Step 2. Fixing the data before touching the agent

AI Opportunity & Readiness Assessment, data readiness only

A rebuild normally loops back to the first stage for strategy: which use case, what return, in what order. The company skipped that part by agreement. The use case was already proven by demand, and they wanted an implementation, not a plan. What could not be skipped was the data. We spent two weeks building the first metadata layer with their domain experts: column descriptions, business-context annotations, jurisdiction-specific constraints, value ranges. Every later capability depended on it.

Step 3. Testing the architecture and the economics before funding the build

Feasibility & ROI Validation

Enterprise text-to-SQL against data of this complexity was unsolved at the time. So the company funded a ten-week validation phase before committing to a build, longer than a standard feasibility sprint because the problem had no known solution, and on the understanding that the first architecture might not pass.

We built the first approach against the normalized schema and asked the agent to learn the JOINs across ten-plus tables. Through several iterations the same constraint held: even simple questions needed multi-table JOINs, latency was unacceptable, and outputs were not deterministic. We gave one documented no-go, with the evidence behind it. The company accepted it without pushback, because the phase had been designed to produce exactly that kind of answer.

The pivot followed from the evidence. The agent should not need to understand the database's internal structure. We created domain-organized views that pre-encoded the hard parts, and the agent's job changed from "work out the database" to "query the right view with the right filters." That architecture worked in testing against the real data, not only in a demo.

Alongside the architecture, we ran a short economic analysis of what each agent invocation would cost at expected query volumes. The result was a cost per query that made the agent a sensible business model for the platform, not only a working feature. With both answers in hand, the company funded the build.

Step 4. Building it to production standard

AI Build & Integration

With a validated architecture, we moved to production engineering in LangGraph with standards set from the start: query validation, deterministic SQL, complexity classification, conversation tracking, document intelligence, domain logic stored as data rather than code, strict output guardrails, and a composable service architecture.

Removing the old agent's integrations added weeks of our engineering time to work around architectural debt that should never have existed.

Step 5. Back where they started, with a system that compounds

AI Reliability & Optimization, ongoing

After launch, regular use among platform users grew from 10% to 55%. Nothing was mandated. The growth came from capabilities we added: multi-turn conversation, document summarization, and an API, which we exposed in a single week because the architecture was composable.

The company entered the lifecycle at this stage with an agent that was failing. They are at this stage again with one that keeps gaining value, which is what the stage is for.

Results

• Market access users get an answer in under 60 seconds to questions that took days, including queries the old agent could not produce at any speed: shares and trends computed across jurisdictions, questions with many conditions answered in one pass, and follow-ups that go from a decision into its trials, its regulatory approval, its reimbursement conditions, and its rationale. The agent reliably generates 100+ line SQL with multiple CTEs and subqueries.
• Data coverage grew from 10 columns on one view to 300+ columns across twelve domain-organized views: the full regulatory, HTA, and reimbursement dataset, with the evidence behind each decision.
• Regular use among platform users rose from 10% to 55%, without a mandate.
• In-house experts stopped coordinating multi-day data engineering cycles and moved to client-facing work. End clients get grounded answers during the conversation.
• Data engineers reclaimed sprint capacity for platform development instead of ad-hoc query requests.
• We exposed the agent's API in one week, making the same capability available to other teams and other agents in the organization.

What They Learned

• A data product's users need to ask questions, not compose filters. The company's own query templates were the evidence: users needed pre-built questions because they could not assemble them. The agent generalized a handful of templates into any question.
• Test the architecture on the real schema before funding the build. The first agent skipped that step and cost a full budget plus the integration debt. The rebuild spent ten weeks on validation and produced one no-go and one architecture that held in production.
• Domain rules belong in data, not code. The metadata layer and views the company now owns encode country-specific outcome fields, rating conventions, and naming variants. When a rule changes, the knowledge layer changes, and the agent follows.
• Composable architecture pays in post-launch speed. The API took one week because expansion was a design constraint from the first day rather than a retrofit.

If This Sounds Like Your Company

Your data product finds records but does not answer questions

If your users export to spreadsheets or rely on templates for the questions that matter, the data is there and the access layer is the gap. A metadata foundation and domain-organized views make it answerable without simplifying it.

You already paid for an AI agent that underperforms

The sunk cost is the agent plus the architecture that grew around it. A structured assessment determines whether to fix, replace, or remove it before the integration debt grows further.

Your experts spend their time on retrieval instead of judgment

When analysts, consultants, or domain specialists spend days assembling data before they can start their real work, a production-grade query layer returns that time to the work that needs them.

You want AI that compounds instead of stalling after launch

Most AI features ship and stagnate. Composable architecture and domain logic stored as data let each capability build on the last, at falling cost and rising value.

Where to Start

If you already run an AI agent that is not delivering, an AI Reliability & Optimization engagement diagnoses whether the problem is the architecture, the data, or both, and sets the path to fix or replace it. If you run a data product and have not built an agent yet, an AI Opportunity & Readiness Assessment shows whether your data can support one and what has to be built first.