Every week I talk to a practice that has bought AI. Not “an AI” — AI, plural. A scribe from one vendor. A scheduling bot from another. A website chat widget. A phone assistant on trial. A recall-texting tool the office manager found on a webinar. Each one demoed beautifully. Each one solved the exact problem it was sold against. And somehow the practice is not meaningfully better off.
That pattern has a name. I call it AI sprawl: the steady accumulation of disconnected AI tools that each work on their own and never add up to anything. And it is the predictable result of a deeper mistake — the healthcare industry has become obsessed with the most difficult applications of AI while neglecting the layer that determines whether patients ever benefit from those advances.
Put plainly: we are building healthcare AI backwards. Racing to automate the hardest, highest-stakes layer — the clinical one — while the layer underneath it, the one every patient actually touches, stays overloaded and analog. We are building the roof before the foundation.
I have spent years building operational AI for medical, dental, and veterinary practices — conversational systems that answer the phone, capture intake, schedule, follow up, and hand off to staff. That work gave me one strong conviction, and it is the whole of this post:
Healthcare becomes AI-native from the operations up, not from the algorithm down.
I call this framework Operations-First AI, and everything else I write is evidence for that one sentence. Clinical AI makes medicine smarter. Operational AI makes healthcare work. You do not get the second by buying more tools. The opposite of AI sprawl is not a better tool — it is an architecture.
A tool automates a task. An architecture decides how the pieces fit.
A tool answers a question: can AI do this one thing? Can it transcribe the visit, book the appointment, answer the FAQ, draft the message. The answer is increasingly yes — which is exactly why tools are easy to sell, easy to buy, and easy to accumulate without getting anywhere.
An architecture answers a harder set of questions. What talks to what — when the phone assistant books a visit, does the reminder system know? Who decides what — which calls belong to the model, and which must a human make? Where does the human step in, and how gracefully? And in what order do you build, so each layer makes the next one more valuable instead of just adding another login?
None of those are questions about capability. They are questions about design. And they are exactly the questions a pile of point solutions leaves unanswered — which is why the tools accumulate while the practice stays the same.
This is not only a small-practice problem. Deloitte describes an “AI divide” opening between organizations that embed AI into their core operating model and those still confining it to isolated point solutions (Deloitte). McKinsey now argues the next phase of healthcare AI is a shift toward a coordinated, modular architecture rather than a collection of standalone models (McKinsey). The consultants have the diagnosis right. What they describe from the boardroom, I have watched play out one front desk at a time.
Operations-First AI in one minute
Before the evidence, here is the entire framework, so you know where this is going.
The thesis: healthcare becomes AI-native from the operations up. Operational AI is the foundation; clinical AI compounds on top of it and is worth far less without it.
Four principles hold the architecture together:
- Operations first. The operational layer — access, scheduling, intake, workflow, follow-up — is the foundation. The sequence is not optional.
- Humans decide, AI operates. AI does the repetitive, high-volume, coordination work. Humans do judgment, empathy, ambiguity — and make every clinical call.
- Architecture over tools. Every new capability answers to the whole system, not just to its own demo.
- Production over demos. The only capability that counts is the one that survives thousands of messy, real interactions.
That is Operations-First AI. The rest of this post is why each principle is true, starting with the picture I want you to remember.

Operations first: the foundation is load-bearing
Look at the stack. Most of the AI industry’s attention — and most of its funding — points at the top two layers. That is understandable; the clinical layer is where the science is exciting. But value is built from the bottom up, and the industry is starting at the top.
Here is why the bottom is load-bearing. Clinical AI is high-stakes, slow to validate, heavily regulated, and genuinely hard to deploy into a daily workflow. Operational AI is repetitive, high-volume, bounded, verifiable, and — critically — deployable now. And clinical AI’s value is gated by operational maturity. A brilliant diagnostic model is worth almost nothing in a practice that can’t get patients booked, can’t reach them in their language, and loses a third of its calls to voicemail. Modernize the operational layer first and everything you add later lands on a foundation that can actually act on it. Build clinical AI on top of broken operations and you have built a beautiful room on a cracked slab.
To be clear, Operations-First AI is not a rejection of clinical AI. It is a sequencing strategy. Clinical AI delivers its greatest value precisely when it sits on an operational layer that can put its insights into action.
This is the difference between the two sentences I keep coming back to. Clinical AI makes medicine smarter — a better diagnosis, a faster read, a sharper plan. Operational AI makes healthcare work — it changes whether a patient can get in at all. One improves the care. The other decides who receives it. I have made the fuller version of this case in AI in Healthcare: A Builder’s Guide to What Actually Works and shown the real examples working today.
The other three principles, briefly
Humans decide, AI operates. This is not a soft value; it is increasingly the law. CMS’s Medicare Advantage rules, California’s SB 1120, and multiple ongoing cases converge on the same line: an algorithm may assist, but a licensed human must make the medical decision. Design to that line and you are both safer and ahead of the regulation. Under Operations-First AI, the model is never the thing that says no to a patient’s care.
Architecture over tools. Every capability has to answer to the whole. Does it write back into the systems the rest of the loop depends on? Does it preserve context when a patient calls Monday, texts Tuesday, and emails Wednesday? A tool that can’t connect isn’t part of the architecture, no matter how well it demos — it is just one more disconnected island. Orchestrating a patient journey across channels is where value compounds; automating one isolated task is where it stalls. Bain’s work with KLAS found the same thing from the investment side — healthcare AI is finally moving “from pilot to production,” and the projects that scale are the ones wired into real operating workflows rather than run as standalone experiments (Bain).
Production over demos. A demo shows what a system can do on its best day. An architecture is judged on what it reliably does on an average one — the noisy call, the interrupted sentence, the mid-conversation language switch, the patient who gives the wrong number and corrects it. That gap is brutal in healthcare voice specifically, which is why I wrote AI Voice Agent Architecture and LLM-as-a-Judge for Voice Agents.
This scales far beyond a single practice
The reason I care about getting the principles right, and not just the products, is that the principles are what scale. A two-dentist clinic and a national health plan share the same shape: a patient reaching in, an overloaded front door, a neglected operational layer, and clinicians who should be spending their judgment on judgment. Most organizations, large and small, are barely off the analog starting line — a few digital tools bolted onto manual work, nowhere near AI-native. The gap is not capability. It is architecture.
That is why I believe Operations-First AI applies equally to a two-provider practice, a national health system, and a public payer. The scale changes. The architecture doesn’t. Even the largest players prove the point in their own numbers: when UnitedHealth Group talks about AI on its earnings calls, the concrete payoff is overwhelmingly operational — calls routed, workflows automated, claims adjudicated — not the clinical moonshots. The money shows up first exactly where this framework says it will.
What it looks like when you actually build it
This is not theory for me. It is the category we build at Viva AI — a conversational operational layer that answers calls, texts, web chats, and emails for practices, in more than one language, books directly into the schedule, collects payments, runs recall, and hands off cleanly to the human team when a situation calls for judgment. It is deliberately the front-office layer of the stack, not the clinical box, because that is where the foundation is poured. Get it right and everything above it has something solid to stand on.
The front office is where I would have any organization start — the highest-volume, most bounded, most measurable, most deployable part of the whole system, and the part patients actually touch. I made that specific case in The AI Front Office.
The bottom line
Stop shopping for AI tools. The alternative to AI sprawl is Operations-First AI — an architecture built on purpose, in order: operations as the foundation, humans on the decisions, orchestration over isolated automation, production reality over the demo.
The organizations that win the next decade of healthcare AI will not be the ones with the most tools, or even the best clinical model. They will be the ones whose operational layer can actually act — the ones that became AI-native from the operations up. That is true for a single practice and for a national payer alike. The implementation changes. The principles don’t.
Because healthcare won’t become AI-native because we invented better models. It will become AI-native because we finally built organizations that know how to use them. And that work starts at the foundation.
Frequently asked questions
What is Operations-First AI?
Operations-First AI is the framework I use for building AI into healthcare organizations: the operational layer — access, scheduling, intake, workflow, communication, follow-up — is the foundation, and clinical AI compounds on top of it. Its core claim is that healthcare becomes AI-native from the operations up, not from the algorithm down, and it rests on four principles: operations first, humans decide while AI operates, architecture over tools, and production over demos.
What is an AI architecture for healthcare, and how is it different from an AI tool?
A tool automates a single task; an architecture decides how all the tasks, workflows, and handoffs fit into one coherent system — what connects to what, which decisions belong to humans, and in what order you build. Accumulating disconnected tools (“AI sprawl”) never produces an architecture, no matter how good each tool is.
What’s the difference between operational AI and clinical AI?
Clinical AI supports medical decisions — diagnosis, imaging, treatment. Operational AI runs the work around care — access, scheduling, communication, follow-up, payments. Clinical AI makes medicine smarter; operational AI makes healthcare work, because it decides whether a patient can get care at all. Operational AI is also more bounded, verifiable, and deployable today, which is why it pays off first.
Why do you say the industry is building healthcare AI “backwards”?
Because most attention and funding point at the clinical layer — the hardest, slowest, most regulated one — while the operational layer that every patient touches stays analog. Value is built from the foundation up, but the industry keeps starting at the top. That’s building the roof before the foundation.
Where should an organization start?
The front office. It’s the highest-volume, most repetitive, most measurable, and most deployable part of the organization, and the part patients actually experience. Get the operational foundation working before adding clinical AI on top.
Does Operations-First AI apply to health systems and payers, or only small practices?
Both. The same architecture scales from a two-provider clinic to a national payer because they share the same shape — the same overloaded front door and neglected operational layer. The scale changes; the principles don’t. Smaller organizations often deploy faster, because they don’t carry the committee and integration drag that traps large systems in pilots.
Read next
- The AI Front Office
- AI in Healthcare: A Builder’s Guide to What Actually Works
- AI in Healthcare: Real Examples That Work Today
- AI Voice Agent Architecture: What I Learned Building the Same Agent Three Times
- LLM-as-a-Judge for Voice Agents
Sources and further reading
- Deloitte — Agentic AI and the health care operating model
- McKinsey — The coming evolution of healthcare AI toward a modular architecture
- Bain — Healthcare IT Investment: AI Moves from Pilot to Production
- CAQH Index — automation cost-savings in US healthcare (via AJMC)
- Healthy People 2030 — Access to Health Services