AI Engineer World's Fair 2026
Healthcare’s Agent Bytecode: X12 as the Harness for AI Agents
Read the talk
Healthcare’s Agent Bytecode: X12 as the Harness for AI Agents
Healthcare agents need more than good reasoning: they need bounded transactions, preserved evidence and a way to revise what they believe when insurers contradict themselves.
From a talk by Vasant Kearney
What should healthcare automation accomplish?
How can an agent reduce the cost of interacting with insurance while making the experience better for the patient? Those are Vasant Kearney’s starting requirements. A technically interesting workflow still has to serve at least one of them: lower administrative cost or improve the patient’s experience of care.
The capability now available to pursue those goals is an execution layer. Kearney traces the progression from artificial neurons and convolutional networks through large-scale unsupervised learning around 2011–2012, then the Transformer introduced in Attention Is All You Need. Chat interfaces made language models directly accessible; Claude Code, Codex, OpenClaw, Hermes Agent and his team’s internal system add the ability to act. In healthcare, the engineering problem is making those actions safe and reliable.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Recognizing a check is not depositing it
Suppose a model can recognize every handwritten digit from zero through nine. Can it now deposit a check? It still has to read the other characters, match the extracted information against banking infrastructure and verify the destination account. A successful recognition step does not establish that money will reach the right place. Those surrounding requirements are part of the harness. Claims automation has the same shape: many small AI tasks connect eligibility checking to an insurer depositing money into a provider’s account, and each must operate within strict constraints.
Even deciding what information to pass between steps is consequential. An imaging pipeline might extract anatomy, geometries and pathologies, then combine those findings with electronic health record data in a downstream model. That can make sense for cost or model-capability reasons. But the upstream extractor may not know which procedure the downstream task will consider. It can discard something that becomes relevant later.
Preserving multimodal context keeps later reasoning from being limited to an earlier model’s selection of facts. This matters beyond clinical images. On a desktop, a shape or visual arrangement may reveal that an object is a button; a text-only reduction can lose the information an agent needs to interact with it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Actions need boundaries, and model upgrades need validation
An execution layer gives a model actions. It might begin by querying a database, discovering its schema and inspecting the data. With access to source code, it can investigate how that code relates to the records. In a healthcare workflow, its tools can extend to insurance transactions, phone calls, payer portals, electronic health records and practice-management systems. Some of those operations write to external systems. Kearney identifies user logs as a minimum for desktop and practice-management interactions.
Memory also needs an operational boundary. Kearney contrasts the local memory used by coding agents such as Claude Code and Codex with his team’s database-backed memory. The database provides logical separation for their enterprise healthcare system; this is an architectural choice for that system, rather than a universal prohibition on local storage.
Replacing the model changes the behavior inside those boundaries. More parameters or better evaluation scores do not establish that a replacement will behave better in every situation the existing system creates. A model upgrade requires renewed system validation. Evals, tests and validation procedures must establish that the new model can enter the workflow without breaking it. The execution-layer slide brings these concerns together as permissions, tool calls, memory, validators, human gates and audit logs.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A contract that can reject an action
Kearney uses a broad definition of harness: memory, tools, checks, permissions, handoffs and evals surrounding agentic reasoning. For healthcare claims, he adds X12, the standardized transaction structure used to communicate with insurers. His comparison is to constrained languages and formats such as COBOL and TypeScript: limited permissible values give the model a more definite target.
The useful property is that a proposed result can be rejected. Consider Kearney’s illustrative claim-handling or EHR-research workflow with roughly fifty steps. A mistake in an early step can propagate into later decisions. A strict contract creates places where the system can identify an invalid result and stop it from moving downstream.
That same long workflow exposes a tradeoff. Repeated multimodal reasoning costs money, adds waiting time and creates another opportunity for error at every step. Hard-coding the entire process avoids some open-ended reasoning, but can produce an unmanageable body of code and a correspondingly large engineering burden. The design problem is deciding which work should remain flexible and which behavior should be fixed.
Kearney’s team uses memory at three scopes—partner, organization and user—to help find that balance. People in multi-site healthcare organizations often repeat familiar tasks. A few words from one user might usually mean an eligibility check in a particular context; the same words from another user might imply different work. Persistent memory can supply that context without rediscovering it in every conversation.
But persistence across chats and days also introduces bias. If today’s request differs from yesterday’s, the remembered pattern can steer the user back toward the wrong task. Memory should inform interpretation without trapping the user in a previous workflow. Users need a way to break out of the inferred pattern.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Different interfaces, the same business transaction
Insurance work begins before the patient arrives. Scheduling leads into coverage questions; coverage affects which procedures are considered; treatment produces documentation; a submitted claim eventually leads toward payment into the provider’s bank account. Sometimes an X-ray is itself the supporting document. Kearney frames this lifecycle through its corresponding X12 exchanges. That is a mapping of business activity, not a requirement that every clinical or scheduling action be an X12 message or that every claim follow one fixed sequence.
The interface does not determine the business transaction. A phone call identifying a patient and asking about eligibility has the same underlying purpose as a 270 eligibility request. A claim-status question likewise has an X12 counterpart. An agent might gather or communicate information through a desktop, browser or imaging system, then normalize it into the relevant transaction structure. The 275 carries supporting patient information; it is not the imaging system itself. Bank transfers through EFT/ACH are structured too, but are distinct from these X12 exchanges.
The X12 healthcare transaction flow and the talk’s mapping slide give the principal targets:
| Business purpose | Transaction |
|---|---|
| Eligibility request / response | 270 / 271 |
| Prior authorization | 278 |
| Claim submission | 837 |
| Supporting information | 275 |
| Claim-status request / response | 276 / 277 |
| Payment and remittance information | 835 |
| Movement of funds | EFT/ACH |
These identifiers let an agent aim at a bounded business operation regardless of which interface it used to obtain the information.
For example, a TypeScript boundary can represent an eligibility request before anything is sent. Here, a phone-derived request and a portal-derived request retain their channel while sharing the same transaction target:
typescript
type EligibilityRequest = {
kind: "eligibility-request";
patientId: string;
channel: "phone" | "portal";
};
type Proposed270 = {
transactionSet: "270";
patientId: string;
sourceChannel: EligibilityRequest["channel"];
state: "proposed";
};
function propose270(request: EligibilityRequest): Proposed270 {
if (!request.patientId.trim()) {
throw new Error("A patient identifier is required");
}
return {
transactionSet: "270",
patientId: request.patientId,
sourceChannel: request.channel,
state: "proposed",
};
}
const proposal = propose270({
kind: "eligibility-request",
patientId: "patient-42",
channel: "phone",
});
This is an internal proposal, not a serialized X12 message or an executed insurance request. Its purpose is to make the intended transaction explicit before downstream validation and submission.
Using an established standard also reduces schema invention. Whether engineers write the code by hand or use Claude Code and Codex for research, a shared transaction vocabulary gives incoming engineers something recognizable to look up. Kearney describes the transactions as public; more precisely, public summaries are available, while complete specifications and implementation guides are subject to X12 licensing and distribution requirements. A discoverable vocabulary is not the same as an unrestricted implementation specification.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Valid structure does not make payer information true
X12 supplies rules, not a guarantee that an insurer’s response is true. A payer’s portal, phone system, X12 interface and FHIR interface may be built by different teams or even different contracted companies. They can disagree, and agreement does not necessarily establish correctness either.
Kearney illustrates the problem with coverage. The phone representative, browser portal and X12 response all indicate that a patient is covered. The provider treats the patient. Later, the insurer denies the claim on the grounds that the patient was not covered during that period. Three matching answers have still failed to predict the downstream decision.
Experience may reveal payer-specific patterns: one channel can be more reliable than another for a particular insurer. Regardless of where information originates, Kearney proposes reducing it to an internal X12-grounded representation that remains provisional. It is accepted until downstream evidence overturns it. Any insurer response can be wrong or updated later, so normalization must not turn revisable evidence into an immutable fact.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From patient estimates to remittance
For the patient, uncertainty appears as a practical question: how much will I have to pay up front? Answering it affects the experience of going to the doctor. Once treatment begins, the clinical work can also produce the evidence the insurer requests. A cone-beam computed tomography scan, or CBCT, supplies images and slices that may support the claim.
The claim then becomes the provider’s statement of work already delivered: an invoice asserting which treatment occurred. The accompanying workflow slide makes the construction concrete. Practice-management records feed a claim bundle, an 837D builder, validation and a submission ledger before routing through a clearinghouse, SFTP, portal or paper fallback. Submission commits the provider’s assertion and puts the next action with the insurer.
After submission, the workflow has several distinct checkpoints:
- Implementation acknowledgment. A
999reports syntactical and relational validation results. As the X12 transaction reference clarifies, receiving one does not itself establish acceptance, semantic correctness or payment approval. - Receipt and status. The provider follows updates about the claim. If a status update does not arrive, the workflow may include a phone call to verify what happened.
- Remittance information. Kearney describes the EOB/
835as a payment receipt. More precisely, the835communicates remittance and payment information; CMS distinguishes that advice from funds issued by check or EFT. It should not be treated by itself as proof that money settled in the bank.
These checkpoints answer different questions: whether the submission conforms, what happened to the claim and how it was adjudicated or paid.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Enthusiasm still needs cost discipline
Kearney closes by pairing enthusiasm for AI with skepticism about its operation. Large language models, small models and tiny models all deserve conservative introduction into healthcare workflows. Failure is not solely a property of the model: the surrounding system can set it up to fail. Designers therefore have to examine the conditions under which they ask it to act.
That scrutiny includes cost. Consider his illustrative routine task repeated 1,000 times a day. Using an unnecessarily powerful, expensive model for every repetition can defeat the original purpose of automation. The appropriate execution layer must make the work reliable enough to trust and economical enough to reduce the cost of interacting with insurance.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The original paper introducing the Transformer architecture.
Personal assistant software with tools, messaging integrations, setup instructions and security guidance.
Nous Research's agent framework with persistent memory, reusable skills and tool integrations.
Further reading
- X12 healthcare transaction flowDocumentation
Official diagrams connecting eligibility, claims, supporting information, status and payment transactions.
- X12 transaction set referenceDocumentation
Public descriptions of transaction purposes, including the 999 implementation acknowledgment.
- X12 licensing and intellectual property guidanceDocumentation
Explains access, licensing and distribution requirements for X12 standards and implementation guides.
- Understanding electronic remittance adviceDocumentation
CMS explains Medicare's 835 remittance advice, claim adjustments and its relationship to payment.
Kearney discusses agent workflows, payer-specific rules, permissions, auditability and human escalation.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hey, everybody. How's everyone doing today?
- 0:16
Good. So this is a bit about my background, but I think it's always really good to learn what the audience background is, if it's more on the technical side, which I know this conference is, healthcare side.
- 0:32
Let's get a quick show of hands to see who, who here is on the healthcare side?
- 0:38
Ooh, wow. That's a lot of you. That's more than I expected. Wow. Okay. Who here is on the technical, does agentic workflows?
- 0:46
Wow. Okay. Overlap. All right. As should be expected at this conference. Who here has models running right now somewhere doing some work? Wow. [laughs] It's like the whole audience. Okay.
- 0:59
All right. So I know who I'm talking to. Wonderful. This is the right crowd.
- 1:04
So what is the goal of this? Like, if we're working in healthcare and we're doing some agentic workflows, we have to keep in mind the goal, and that goal, at least from my perspective, is to drive the overall cost down.
- 1:23
So in this talk will be about insurance costs, specifically the cost of, of interacting with insurance. Um, but also to improve the patient experience because insurance relates back to the patient and how they experience the whole process.
- 1:41
So let's keep that in mind when we're solving problems. I know that if we're on the technical side, we like to get really experimental with things and get excited about just the s- the technology itself, but has to be grounded in one of these two concepts.
- 1:58
So a little trip down memory lane, just starting from this long journey of AI machine learning and where we are today, and we're obviously going to talk about the last point, this ag- agentic execution layer.
- 2:12
But we can see this evolution from the neuron, convolutional neural networks, large scale unsupervised learning back in two thousand, uh, eleven, two thousand twelve. Then the introduction of Attention Is All You Need, uh, one of my favorite titles for a paper, the tran- introduction of the transpa- the Transformer.
- 2:32
Then we go into this modern chat interface with these large language models and then finally with the Claude Codes, the Codexes, and our system internally and a lot of systems, you have OpenClaw, Hermes Agent, all, all that kind of stuff, which really brings into the, into the picture this execution layer.
- 2:55
So we're going to be talking about how to do this execution layer safely and reliably in healthcare.
- 3:06
So let's think back to some of the earlier examples of like getting really excited about some AI technology and then realizing it has all these little bits and pieces which make it a, a lot more trickier than maybe it is, is obvious at first.
- 3:21
So like you have a check and you want to cash it, you want to deposit it into your bank account. Um, you might say, "Oh, we have solved the handwritten digit problem.
- 3:32
We can recognize digits from zero to nine." Right? Wow. Oh, oh, so now we're ready to, um, deposit this check into this person's account and transfer money. Well, not quite, because as you dig in a little bit deeper, you see that you have to identify all sorts of characters in the check.
- 3:50
You have to make sure it matches up with all these other pieces of the infrastructure. You have to make sure that it is, um, that it is, um, going to the target account that you're interested in.
- 4:04
So parts of this can be thought of as, as the harness. Um, in claims we have a similar challenge that there's a lot of these little AI steps involved in fulfilling that whole patient journey of eligibility to getting the insurance company to deposit money in the provider's bank account.
- 4:28
A whole bunch of little steps, and we have to make sure that we're safely doing this, that we're operating like in these tight co- uh, these strict confinements.
- 4:42
So another thing that comes up, just sort of setting the stage, is that, um, multimodal context and it comes up very frequently with claims. So you might have an image, and it might seem like at, at first, for cost reasons or something else, that you'd want to take that image and reduce it down to the findings like,
- 5:05
"Here's the anatomy in the image," and maybe even extract some geometries from that anatomy. Here's pathologies. And then you would take that and then combine it with some other machine learning, with some other data in a different downstream machine learning model
- 5:20
like, um, EHR. And that might make sense from a cost perspective and also just like model capabilities. Um, but in a lot of situations, it-- you lose context, so it might be that you're extracting all this information and missing something that relates to some downstream procedure that you didn't, that wasn't-- the
- 5:46
upstream model wasn't aware of it. So that introduces this concept of just multimodal processing. So, uh, uh, another place this comes up in healthcare, but not related to anatomy or anything like that, is desktop use.
- 6:01
You can see that sometimes, you know, things are buttons or, or s- or, you know, might have some shapes that are only obvious when you do this multimodal.
- 6:16
All right. What is the agentic execution layer?
- 6:22
So this can, this can take on a lot of different forms. It is the ability of this model to take actions. So it might be you're starting out with, um, database queries, and let's say it's just completely open.
- 6:38
You're querying the database, you're finding your schema, you're figuring out what this-- what the data looks like, and then it might even have access to your code. So then you're querying your code with respect to your data, uh, and you might actually, in our system or other systems, you might be making insurance transactions.
- 6:58
You might be making a phone call. You might be looking at a web portal. You might be interfacing with an EHR. These are all actions you can take. And some of these actions have write implications.
- 7:11
If you're interfacing with different PMSs, you're going to the desktop, you can have at least user logs at the minimum.
- 7:20
Uh, and then the next concept is memory. So Claude Code or Codex, they use local memory they write to your desktop. In enterprise healthcare, we can't really do this, so we do memory in a database just so we have that logical separation.
- 7:40
A important concept here is that when you're introducing new and improved better models, more sophisticated, more parameters, you can't, you can't just replace the model and assume it's going to be better.
- 7:56
It's different, right? It's a, it's a-- on certain evals it's a better model as measured by these different metrics, but it doesn't necessarily mean it's better, right, for all the situations that you want it to be better at because of the way you've designed your system.
- 8:10
So you really have to redo everything from scratch. Um, just make sure your evals, your testing, your validation is all set up so that you can introduce these new models and not break your system.
- 8:31
So this concept of harness. Different groups have different definitions of this. So I'm gonna use a super broad definition here, which is, like, all the different nuts and bolts that, that surround this agentic reasoning.
- 8:48
And that is the con- this concept of memory that we discussed, the different tools, the checks, the permissions, the handoffs, the evals. Um, but also in the context of healthcare and claims, it's X12.
- 9:04
So just like we have these old-school languages or formats like COBOL, um, or other stricter, maybe strict languages, TypeScript, um, LLMs really thrive.
- 9:20
They work well and when they're confined, they have clear, um, limited, uh, values that they can predict. And X12 is exactly this. So it provides this underlying structure, this contract between what you're trying to communicate and the insurance company.
- 9:44
So when you're reasoning in this, in this healthcare, your, your objective is to do something with-- handle a claim or research your EHR with respect to claims. It might be that you have, like, fifty steps or something like that.
- 9:59
There's a lot of different steps. And so you can, um, you-- at, at each of those steps as you make mistakes, those mistakes can propagate down your system. Um, and so it's very good to have something grounded that can be rejected too.
- 10:16
So if you have a really strict gu- guardrails, you can reject something that happens that's incorrect.
- 10:27
So with your reasoning over, let's say, the previous example, fifty steps, that-- and they're multimodal. You're considering images and everything like that. That can get really expensive. It can also take a really long time, and folks might not wanna wait.
- 10:43
You know, it could be too expensive, and people don't wanna wait that long. And each time, each step is an opportunity to introduce an error, and you can have problems.
- 10:53
Uh, but if you hard code your whole system, you say, "We're gonna throw out this whole agentic process," you limit yourself or your code can explode to be just unmanageable.
- 11:04
So now all of a sudden you just have this crazy bloat, and you have to have this giant engineering team which poses its own problems. Um, so what we wanna do is strike this balance between what we should be completely free, like, um, with just pure agentic reasoning and execution, and what is hard-coded.
- 11:28
So we do that internally with introducing memory, just this, uh, partner-level memory, um, organizational-- organized memory and user memory. So we say if a user-- we find people in, in multi-site health, uh, organizations, they tend to do s- the same thing day after day.
- 11:50
And it might be if they mention a few words, oh, they usually do eligibility, and they usually do it within this context. They probably mean this, right? Where another user, they probably mean that.
- 12:05
So we want to be really careful here because as you introduce memory, you also-- persistent memory across chats, across days, you also introduce bias. So maybe that person doesn't want to do the exact same thing that they did yesterday, and now you steered them to do the exact same thing they did yesterday.
- 12:23
That's a problem. So you want to strike a balance somewhere in there, and you want to make sure that the u- any user can break out of this.
- 12:36
So for folks that are unfamiliar with the whole claim life cycle, it's many steps. So each step does have an X12 correspondence with it, starting with the schedule when, let's say, you're showing up to the doctor's office.
- 12:51
Before you even show up, that's-- insurance starts then. Um, when you're getting treated, that also relates to insurance. What you, you know, the different procedures that you're a candidate for depending on your insurance, um, your documents.
- 13:05
Sometimes the X-ray itself is the document, and you would send proof of that in, submitting the claim, and then finally getting the payment in the provider's bank.
- 13:22
So this-- I think this concept is a little bit, uh, I, I found it to be obvious in retrospect, but let me talk you through it. Maybe you find it's, it's, uh, interesting or not.
- 13:36
But if you're calling an insurance company, [chuckles] uh, that i- that boils down to a transaction, an X12 transaction. You'd say, "Hey, this is the patient I'm talking about." Great.
- 13:48
That's a, like, an eligibility request, a two seventy. Uh, oh, I need to do-- you're requesting a claim status or whatever it is you're doing. That has an X12 grounding, um, and that is the whole concept here, this, this X12 harness.
- 14:05
So you call the insurance company, you have an agent interact with the desktop, you have an agent interact with the browser, um, your imaging system, that's a two seventy-five, and, um, and, and your insurance, your bank, your ACH.
- 14:21
So that's not an X12, but still that structured, uh, transaction.
- 14:33
So this is just a reiteration of these different transactions.
- 14:39
And the other beautiful thing about it, it's not, you know, it can-- you ask an agent to do something. Let's say you're agentically programming, or let's say you're just-- you're, you're programming how, you know, maybe half the companies I spoke with here, um, still program today just everything by hand, um, and they use these Claude Code or
- 14:58
Codex for research. If you look up any of these transactions, they're all public. Like, this is not-- The beautiful thing about this is, like, this is not my schema.
- 15:08
If you ask agents to make a schema for you, you're gonna get, like, all sorts of stuff. But now, if we ground it in something standard, you can look up all of these, and you would know just right off the bat my schema.
- 15:20
Let's say you're a new engineer coming in, like, you know.
- 15:30
So X12 is a, is, uh, a system of rules, and it doesn't mean that when an insurance company gives you an X12, it's true. So [chuckles] that concept is, uh, it-- When an insurance company tells you something, it's coming from different teams potentially.
- 15:52
They can have an engineering team that's res- It could be even a different company. A different company that the insurance company contracts out designed their web browser, their phone system, or their X12 layer, um, or their FHIR.
- 16:07
And, uh, we have to understand that there's no ground truth. They also, within all these systems, they can, they can all actually agree on the wrong information as well.
- 16:19
Like, let's say they all say this patient is covered, all three. You, you call them, you look in the browser and the X12, and they all say, "Yes, this patient is covered."
- 16:27
And then you treat the patient. They say claim is denied due to the, the patient wasn't covered during that time.
- 16:33
Um, so they can all disagree, but sometimes you'll learn some idiosyncrasies of these different payers that some of these systems are more reliable than others. But regardless of if it o-originates as an X12 or not, you can boil all those transactions down to your own internal cor-- semi-correct X12.
- 16:52
Correct until downstream evidence proves it otherwise, uh, to be incorrect.
- 17:01
So just a little bit more on that. So an-any of the X12, any of the information coming from the insurance company at any time can be wrong and can be updated later.
- 17:09
So have fun. [chuckles] This is just an example of what it would look like if you're, um, j-- in that patient journey. You're, you're trying to figure out how much you would pay as a patient up front, and it's very important for your experience going to the doctor.
- 17:32
And then the different treatments that you have in that clinic can... Oop.
- 17:40
Yeah. The different treatments that you have in that clinic can be the evidence that you need. Like, you might get a CBCT. Well, that, those images and the slices of those images might be the evidence that they're asking for.
- 18:00
So ultimately, if you're delivering that treatment, you're sending that claim. That claim is like a receipt of what you did. I did this. Like, here's the invoice. Right? Like, you send it to the insurance company as an invoice, and they would pay you back.
- 18:15
So that is your ultimate, like, contract of you're saying you did this work, it's sealed, um, and now the ball is in the insurance company's court.
- 18:29
And just a little bit about this progression of the claim from you're sending it, you're getting some acknowledgement, it has, like, the syntax is right with that 999. The status has been updated.
- 18:42
"Hey, cool, we received it." Um, maybe you call them and you verify if the status didn't come in. Then you have this EOB's 835 receipt of payment.
- 19:00
And then we're getting to the end of this, uh, this talk here. But I think that, you know, LLMs... I'm fully AI pilled, right? But we wanna make sure that we introduce lu- um, large language models, small, tiny models in a very skeptical, conservative way.
- 19:20
So being AI pilled is great, um, but you should also be very AI skeptical. Like, um, these things, they make mistakes, and it's not even... You can't even say they make mistakes.
- 19:31
Like, we make mistakes designing them. We might set them up to fail, so we have to be very skeptical of them, and we have to use them in a way that's also cost-effective.
- 19:41
You can't throw... I mean, you don't, you don't want to use an overpowered, overexpensive model, 'cause then if you're going back to if you're reducing costs or not. Let's say it ends up being super, super expensive to deliver one of these routine things that need to be done 1,000 times a day.
- 20:00
You definitely don't want that. All right. Thank you very much. [clapping] [outro music]