Healthcare’s Agent Bytecode: X12 as the Harness for AI Agents

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.

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.

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.

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.

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:

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:

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.

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.

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:

1. Implementation acknowledgment. A 999 reports syntactical and relational validation results. As the X12 transaction reference clarifies, receiving one does not itself establish acceptance, semantic correctness or payment approval.
2. 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.
3. Remittance information. Kearney describes the EOB/835 as a payment receipt. More precisely, the 835 communicates 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.

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.