Healthcare agents should be built around the cost of insurance interactions and the patient experience.
2
X12 gives agentic systems a strict, public contract for handling claims and related payer transactions.
3
Payer data can be wrong, so systems should keep an internal representation that remains provisional until later evidence changes it.
Summary
Vasant Kearney argues that healthcare agents need a constrained execution layer because claims involve many dependent actions. A model may query a database, inspect an EHR, use a browser, make a phone call, or submit an insurance transaction. Each step can introduce an error, and errors can spread through a long workflow. Kearney proposes using X12 as part of the harness around the model. X12 defines structured transactions across the claim lifecycle, from eligibility requests and syntax acknowledgements to payment records. Its public schemas give agents a contract they can look up instead of inventing. The structure does not make payer information true. Phone systems, portals, and X12 feeds can come from separate teams or contractors, and they can agree on incorrect coverage. Kearney recommends normalizing all these sources into an internal representation that is treated as correct only until later evidence disproves it. He also argues for database-backed memory, careful model replacement, and a balance between free reasoning and hardcoded workflows.
Healthcare automation has to reduce insurance cost and improve the patient experience
Kearney sets the purpose of the system before discussing models. In healthcare, he says the work should drive down the cost of interacting with insurance and improve how patients experience the process. Technical experimentation has to stay tied to those goals. The claim journey includes many small actions between eligibility and payment into a provider's bank account, so the system needs to complete them safely rather than merely demonstrate that a model can perform an isolated task.
A narrow AI capability does not complete a healthcare workflow
Kearney compares claims automation with depositing a cheque. Recognizing handwritten digits from zero to nine does not mean a system can safely deposit the cheque. It also has to identify the other characters, match the information to the surrounding infrastructure, and send the money to the intended account. Claims have the same shape. Eligibility, documentation, submission, payment, and other steps all have to work together inside strict constraints.
Multimodal records lose information when they are reduced too early
A medical image might be converted into anatomy, geometry, or pathology findings and then passed to another model along with EHR data. Kearney says that can make sense for cost or model-capability reasons, but the first model may miss information needed for a later procedure. Desktop interaction creates a related problem because the meaning of a button or visual arrangement may only be clear from the screen as a whole. The execution layer therefore needs to handle more than flattened text or extracted findings.
Enterprise agents need database memory and controlled model changes
An agentic execution layer can query databases and code, make insurance transactions, call a payer, use a web portal, or interact with an EHR. These actions have access and audit implications, especially when the agent uses a practice-management system or a desktop. Kearney says enterprise healthcare memory should live in a database rather than on local disk, which provides logical separation. A newer model also cannot be swapped in casually. Its benchmark scores do not show that it will behave better inside an existing system, so evaluations, tests, and validation need to be redone.
A harness gives models structure through tools, permissions, checks, and X12
Kearney uses a broad definition of harness for the parts around agent reasoning: memory, tools, checks, permissions, handoffs, and evaluations. In healthcare claims, X12 belongs in that set because it supplies a contract between the provider's communication and the insurance company. He compares this to strict languages, which give models clear and limited values to predict. The point is to give an agent somewhere structured to return when its reasoning spans many actions.
Pure reasoning is expensive across long claim workflows
A claims task can involve around 50 steps, and mistakes at one step can propagate through the rest of the system. Multimodal reasoning across those steps can cost a lot and take too long for users. Hardcoding every path creates a different problem: the code can become unmanageable and require a very large engineering team. Kearney describes a balance between free agentic reasoning and fixed code. Guardrails should allow incorrect actions to be rejected without turning the whole workflow into hardcoded logic.
Persistent memory can help users while also biasing their next action
Kearney describes partner-level, organizational, and user memory. People at multi-site health organizations often repeat the same work, so a few words may suggest the eligibility task and context they usually mean. Persistent memory across chats and days can also steer someone toward yesterday's action when their intent has changed. The system needs a balance, and users must be able to break out of the pattern that memory suggests.
X12 maps the claim lifecycle and provides public schemas for agents
Kearney says each stage of the claim lifecycle has an X12 correspondence. Eligibility begins before the visit, treatment and supporting documents contribute to the claim, and payment eventually reaches the provider's bank. A phone request about eligibility is a 270, while an imaging document is associated with a 275. A 999 acknowledges that submitted syntax is correct, and an 835 records payment. Because the transaction definitions are public, a new engineer or an agent can look them up instead of inventing a schema.
X12 is structured evidence, but payer responses are not ground truth
X12 is a system of rules, not a guarantee that the payer's information is true. A payer's web portal, phone system, and X12 layer may have been built by different teams or contractors. They can disagree, and they can also agree on the wrong coverage status. A patient may appear covered through all three surfaces and still have a claim denied because coverage was absent at the time of treatment. Kearney recommends normalizing these sources into an internal, semi-correct X12 representation that stays correct only until downstream evidence proves otherwise.
"X12 is a system of rules and it doesn't mean that when an insurance company gives you an X12, it's true."15:30
Who should watch
You are building agents that must move through payer systems, EHRs, portals, or practice-management software rather than answer questions in a chat window.
Your claims workflow has many dependent steps and you need a way to limit error propagation without hardcoding every path.
You are deciding how to store agent memory or replace a model in an enterprise healthcare system.
