Six layers separate a stalled agent pilot from production. Most teams have one.
The pilot got approved in the spring, the EHR vendor confirmed FHIR API access, and the board liked the demo enough to fund the next phase. By every reasonable measure, the hard part looked done.
Months later, the agent still isn’t in production — and the reason has nothing to do with the model. Somewhere between the demo and go-live, compliance asked a simple question: who does the agent log in as? Nobody in the room had an answer.
This story is the normal one, not the unlucky one. In 2026, 43% of health systems are piloting agentic AI, and only 3% have agents running in live workflows. A forty-point gap that wide doesn’t come from bad models. It comes from missing architecture.
Why FHIR makes agents possible at all — we covered earlier this year. This article is the “how”: what has to exist before an agent can work.
The FHIR API Is One Box. An Agent Needs Six.
A FHIR endpoint means structured clinical data can move in and out of the EHR in a standard format. That part is necessary — but for software that acts on its own, it covers about a sixth of what production actually requires. Here’s the full stack:
| Layer | Without it |
|---|---|
| 01 · Identity — who is the agent acting for? | An agent with system-wide credentials sees every patient. That’s an incident report, not an integration. |
| 02 · Authorization — what exactly may it touch? | “Full API access” pilots get shut down by compliance a week before go-live. |
| 03 · FHIR read — live data, not a nightly export | An agent reasoning over yesterday’s med list is a liability with a chat interface. |
| 04 · Write-back — output lands in the EHR | Results live in a tool nobody opens. The pilot “works” and changes nothing. |
| 05 · Audit trail — every action logged | The first legal question ends the deployment. |
| 06 · Human review — a clinician approves consequential actions | Without it, there is no regulatory path at all. |
Most stalled pilots have box 3 in place, sometimes box 4. The identity, authorization, and audit layers usually get borrowed from a regular app integration — and that’s exactly where things break, because an agent is not an app.
SMART on FHIR Was Built for Apps. An Agent Is Not an App.
SMART on FHIR was designed around one scenario: a human launches an application inside their own session and watches it work. An agent breaks every one of those assumptions — it acts when no one is logged in, chains reads and writes across patients, and decides at runtime what data it needs.
The standard still works for agents, but only when it’s used deliberately:
- Backend services flow (system-to-system OAuth), not user-launch — with the narrowest scopes the use case survives on
- Per-action checks, not per-session — the agent re-proves its right to act on every consequential operation
- Short-lived tokens, fully logged — “it had a valid token” won’t answer “why did it read that record”
“The FHIR API is the door. An agent needs the keys, the permission slip, and a camera recording who walked through.”
Same logic across vendors, including Epic-based environments: the Epic API surface is FHIR plus vendor scope approval — an agent has to clear both. This is exactly the operational territory where SMART on FHIR implementations usually go wrong even for ordinary apps; agents just raise the stakes.
Where to Start: Claims, Not Charts
The second decision is which use case goes first. The instinct usually says clinical, because that’s where all the demos are. The safer answer is simpler: start where a mistake costs money, not safety.
Three workflows fit the bill: eligibility checks before the encounter, prior auth tracking (payers move onto FHIR APIs by 2027 under CMS-0057-F), and denial triage by root cause.
The six layers are exactly the same — only the stakes are lower. Build the architecture once, prove it on claims, and extend it to clinical workflows with evidence instead of promises.
What Itirra Builds
We don’t build agents — we build the six layers an agent runs on: identity, authorization, live FHIR integration, write-back, and audit infrastructure.
That layer is what separated the 3% from the 43% this year, and it will separate them again next year, whatever model everyone happens to be piloting by then. The diagram looks the same for every health system. The build never is.
FAQ
Can an AI agent use SMART on FHIR?
Yes — through the backend services (system-to-system) flow, tightly scoped, with per-action authorization checks and a full audit trail. The default user-launch pattern doesn’t fit agents.
What’s different about connecting an agent vs an app to an EHR?
An app acts when a human asks, inside that human’s session. An agent acts on its own schedule and chains operations. The data layer (FHIR) stays the same; identity, authorization, and audit all change.
What should the first AI agent in a health system do?
Revenue cycle work: eligibility, prior auth status, denial triage. Errors are financially correctable and ROI is measurable — the fastest defensible path to production.
Does this apply to Epic-based environments?
Yes. Epic’s API surface is FHIR plus vendor-specific scope approval. Same six layers; plan the approval path into the timeline.
Start the conversation
Working out which of the six layers already exists in your environment — or which one is blocking the pilot?
That’s usually a one-conversation answer. We build EHR integration, FHIR infrastructure, and the authorization architecture agents run on.