Why your healthcare AI agent can’t actually do anything yet.

Healthcare AI agents are everywhere right now. Scheduling bots that answer the phone. Billing assistants that explain a statement. Intake automation that registers a patient before they walk in. Clinical triage that decides what happens next. There are hundreds of millions in venture funding chasing this, and the demos are genuinely impressive.

But most of these agents share the same dirty secret. They can talk. They can’t do.

Ask a scheduling agent to book an appointment and it will have a lovely conversation about it. Whether the appointment actually lands on the provider’s calendar is a different question, and usually the answer is no. The agent is a beautiful front end bolted onto a system it can’t reach.

The AI is the easy part

This is the part nobody says out loud. The model is not the hard problem anymore. Understanding what a patient wants, holding a natural conversation, deciding on the next action, these are close to solved. You can stand up a convincing agent in a weekend.

The hard part is the last mile: getting real-time data in and out of the systems where patient records, schedules, and billing actually live. That is where the work is. That is where every project stalls.

Take eClinicalWorks. It serves more than 180,000 providers. It is one of the most common EHRs in outpatient care. And it has essentially no public API for the operational workflows an agent needs. There is a certified FHIR endpoint, but it exists to satisfy a federal rule, and it is scoped to a government-defined list of clinical data. It has no concept of booking an appointment, running eligibility, taking a payment, or uploading a document. The things your agent was built to do are the exact things the API won’t let it do.

Your agent can hold a perfect conversation about booking an appointment. It just can’t book the appointment.

So the conversation happens, and then it dead-ends. The agent hands off to a human, or writes a note into a queue, or quietly does nothing. The intelligence was never the bottleneck. The plumbing was.

What it takes to build it yourself

You do not have to take my word for how hard the last mile is. Look at who has actually pulled it off.

When R1, a company that processes billions in healthcare revenue, built an AI agent for patient interactions, they described what it took to make it functional. They invested heavily in the data infrastructure, connecting multiple EMRs, scheduling platforms, and account databases, before the agent could reliably do anything. The AI sat on top of a foundation that took serious money and serious engineering to lay down.

That is the validation. It took a company operating at that scale, with that budget, to connect the systems well enough for an agent to act. If that is what the last mile costs, most companies simply cannot pay it. And the ones that try end up spending their best engineers on EHR integration instead of on the product they set out to build.

The three options every agent company faces

If you are building a healthcare AI agent and you need it to actually execute actions, you have three paths. That is it.

Option one: build it yourself

Hire a team, reverse-engineer each EHR, and maintain the connection forever. Plan on 12 to 18 months to get real coverage, and do it again for every new EHR you support. The systems change under you, so the work never ends. You are now, whether you meant to be or not, an integration company. This is the path R1 took, and it took their resources to do it.

Option two: use legacy middleware

There are older interoperability platforms you can buy. But they come with months of procurement, enterprise pricing, and a services engagement before anything is live. And most of what they give you is read access to clinical data, which is not what an agent needs. Your agent needs to write. It needs to book, update, charge, and upload, in real time. Read-only middleware leaves you exactly where you started.

Option three: use a unified API

Call one API and get real-time read and write access on day one. The same endpoint whether the practice runs eClinicalWorks, athenahealth, Practice Fusion, or ModMed. Book an appointment, verify eligibility, pull a balance, upload a document, all as standardized calls. Someone else absorbs the EHR complexity and keeps the connection working as the systems change. You write your integration once and ship.

That third path is why we built Cobalt. Not because the first two are impossible, but because most teams should never have to walk them.

The integration layer is the moat

Here is the thesis. The companies that win in healthcare AI will not be the ones with the best models. Models are converging, and everyone will have access to something good enough. The winners will be the ones whose agents can actually execute actions in the systems of record.

A great conversation is table stakes now. What separates a demo from a product is whether the appointment gets booked, the payment gets processed, the form gets filed. That is the part buyers pay for, and it is the part that is genuinely hard to build. Which is exactly what makes it defensible.

The integration layer is the moat. Not the prompt, not the model, not the voice. The ability to reach into the EHR and do the work. Whoever solves the last mile, cleanly and across every system, is the one who gets to keep the customer.

Your agent can already talk. The only question left is whether it can do something about it.