Ask an experienced healthcare actuary "What was our inpatient PMPM last year?" and they won't start typing SQL. First they'll settle a few things. Should PMPM cover all member months or only attributed members, and should it use paid or allowed amounts? Does inpatient include associated professional claims costs? They'll also check whether that period has enough claims runout to trust. Only then do they write a query, and before sharing the result they double-check that the results make sense and the numbers are accurate.
Most "chat with your data" tools skip all of that and often build a wrapper where they put the table schemas and a few expert written example queries into a prompt, send the question to a large language model, and return whatever SQL comes back. In value-based care, that approach gives you a number that looks precise but is often wrong. The right number always exists, but getting to it takes a sequence of actuarial decisions that no single prompt reliably makes.
The market is filled with tools that point a general-purpose model at a data platform and call it healthcare AI. That makes for a good demo, but not for a number a CFO can take into a contract negotiation. Putting Arbital AI in front of real clients and real actuarial questions showed us exactly where simple AI models fall short. Over the past year we've built new capabilities one step at a time, and each step was added because of a specific need that we identified through rigorous testing.
What we learned is that the models are the easy part.
The right model for the right job
Arbital AI doesn't run on a single Large Language Model (LLM). It uses a combination of LLMs across OpenAI, Anthropic, and Google, and each is assigned the work it is the best at.
This matters because reasoning through a value-based care question and writing correct SQL are different skills, and today's models aren't equally strong at both. Because each response goes through multiple processing steps, we can put the most capable reasoning model where judgment is required and a fast, efficient one where the job is mechanical translation. We select models for each task based on their proven performance in our actuarial benchmarks, rather than relying on public reputation. Whichever model handles a given step, the same controls apply.
The hard part, and where Arbital's intelligence actually lives, is everything around the models. What makes an answer right is the actuarial thinking and engineering around them.
Context is what separates a system that knows healthcare finance from a general agent that is reading about it for the first time when the user sends a question. We equip Arbital AI with precise definitions our actuaries use: how PMPM (cost per member per month) should be calculated, how contract terms translate into a surplus or deficit, and the value-based care concepts a question depends on before it can be answered correctly. Getting that right is a Goldilocks problem. Too little context produces weak answers, and too much buries what matters. So the system draws on the exact context a specific question and each processing step needs, when it needs it.
Reasoning is defined, not assumed. Our actuaries define how the system approaches each type of question. This is where a generic approach falls short. Pointing a general model at claims data doesn't show it how an actuary thinks, and it doesn't tie the answer to the financial terms of a real risk contract. The model is the execution engine. The product brings actuarial judgment, data science, and engineering together: actuaries define the answer, data scientists validate it, and engineers make it run every time.
Retrieval-augmented text-to-SQL handles "how many members do we have in Texas?" well. Value-based care questions are harder because each one contains judgment calls. If a model doesn't make those calls deliberately, it makes them by accident, and not the same way every time.
Bad judgment calls by the model don't produce an error. The outcome is worse: the query runs and the number looks plausible, which is what makes them dangerous. Adding more context doesn't help either: a bigger prompt just gives the model more wrong things to latch onto.
It gets harder still, because many of these choices have no universal answer. Two actuaries can correctly arrive at different PMPMs from the same data if their contracts, attribution methods, or runout assumptions differ. An AI can't learn one right answer. It has to know which conventions apply to this customer and state which ones it used.
The best way to show that is to walk through what actually happens when someone asks Arbital AI a question.
What happens when you ask a question
A question doesn't go to a language model and come straight back as an answer. It enters an agentic system that works out precisely what's being asked, decides which tools it needs, uses them in sequence, checks what came back, and keeps going until it has a response that delivers value to the user.
Say a finance lead asks: "Find my biggest cost problem, the members driving it, and what to do about it." A single model call can't answer that well. It takes several distinct pieces of work: identifying the market and service category with the most excess cost, tracing that cost to the members and providers behind it, and sizing the opportunity against the terms of the actual contract. Arbital AI agents lay out that plan before it runs, so the user can see how it intends to approach the problem, and every result can be traced back to the underlying data.
Actuarial task decomposition
Instead of asking one model to solve a complex problem in a single pass, Arbital AI splits it into actuarial tasks. An orchestrator agent plans those tasks, runs them in the right sequence, and keeps track of what each one has surfaced. Each task does one piece of the analysis, sees only the context it needs, and produces output we can check. Whenever possible, small independent subtasks run in parallel, so the analysis is fast. And because results arrive after each step of the plan, the user can follow the work as it happens instead of waiting for a single answer at the end.
Our team of AI engineers, actuaries and data scientists are constantly refining and adding new tasks to the Arbital AI repository. At a high level, a standard actuarial question goes through the typical flow below:
- Refine. A refinement step tightens the question until any two analysts would read it the same way, and states its assumptions for the user to see.
- Resolve codes. Drug and condition names become NDC, POS, HCC, CCSR, ICD-10, CPT, DRG codes, etc., filtered to the ones in this customer's claims and relevant to the question.
- Ground. The question is matched to actuary-built enrichments and written metric definitions in our governed analytics lakehouse.
- Select data sources. A specialized model picks only the data sources the question needs, including data that the user provides to the chat session to be dynamically plugged in.
- Run safely. The query is validated and runs safely under the customer's access permissions.
- Explain. The response closes with a plain-language summary that leads with the finding.
Our actuaries manage our knowledge base the way engineers manage code. It includes hundreds of business rules and metric definitions and example queries and thousands of standard values such as CCSR categories, drug categories, and each customer's own market names and terminology. Every entry is versioned and has a recorded source, and every example query is tested against the live schema.
The engineering payoff
We took the process of a single query and went to the whiteboard to determine how we can allow Arbital AI to produce even better, more accurate results. One of the answers we kept coming back to was simple in principle, though complex in practice: observability. We ended up breaking up the work of a single query into tasks to make answers more accurate. It also made the system easier to audit, evaluate, and change.
In fact, our unique design is built around rapid iteration and our testing framework is so robust that we can evaluate and switch models in a matter of hours. Dealing separately with each type of task, and each separate step in the reasoning graph made it easy to understand how we can perfect each one without affecting the others. Furthermore, having context control and tuning directly in the hands of scientists and actuaries, and testing in the hands of the product team, allows us to validate and deploy new versions quickly and confidently.
- Answers in minutes, not days. Questions like "where are we losing money, and who is driving it?" usually take analysts several days of pulling data, reconciling it, and checking it against contract terms. Arbital AI does the same reasoning in minutes, partly because it does the legwork itself. It looks up the codes, pulls the benchmarks, and runs the forecasts, fetching each one only when the analysis needs it, since every actuarial toolkit is just a tool call away.
- Tracing and measuring: Each check, the refinement, retrieval, table selection, and every SQL attempt is recorded in our MLflow traces. We measure performance with CADRE, the eval framework we published for evaluating actuarial AI analytics in real use. We also use CADRE to evaluate new models that hit the market.
- Fast iteration. Each step can be tested on its own against a library of expected behaviors, without starting the full system. New behavior first runs in shadow mode, where it is measured but doesn't affect answers, until we know it delivers the value we expected. This is how we turned observability into velocity and accuracy.
How we know it's right
An AI system is only as trustworthy as the way it's tested. Ours is tested with evals: a library of questions paired with answers we already know to be correct, so we can score how close the system comes on its own.
The part worth emphasizing is who writes them. Plenty of teams test their AI against generic benchmarks. Our evals are written by Arbital's credentialed actuaries, who author each question and work out the right answer the way they would for a client. Every meaningful change, including a model swap, has to clear the full set at the same quality threshold before it reaches clients. That's what makes switching models a controlled decision instead of a gamble, and it's why we can make a specific claim about accuracy rather than a general one.
What this means for your team
At one provider organization with about 200,000+ lives, people from operations, clinical, and finance used Arbital AI’s agents to build four cost analyses. They covered leakage in the clinically integrated network, cost of care in a home-based program, skilled nursing facility strategy, and which independent practices to target.
None of this replaces the actuaries and analysts who make the final judgment calls. It takes the manual assembly, reconciliation, and first-pass analysis off their plate so they can spend their time on interpretation, risk, and decisions, while more of the organization gets answers with actuarial thinking behind them.
Built by actuaries, a year in production
Plenty of companies can announce AI. What's harder to show is a system that has been live with clients for a year, built and checked by the actuaries who do this work every day, and designed to get better as the technology under it does. That's what's under the hood of Arbital AI: the financial infrastructure for healthcare contracting, showing how each contract is performing and what to do next.
The Arbital platform and Arbital AI follow industry-standard security practices and are HIPAA-compliant, SOC 2 audited, and HITRUST i1 certified. This includes all models underpinning Arbital AI and all services performed under the Arbital platform.
