Epic Agent Factory is going to eat most of the healthcare AI that lives inside the chart. If a product reads one health system's chart, writes a paragraph and drops it into an Epic workflow, that health system will soon build the same agent itself, inside the EHR it already pays for. I don't think that's bad news for builders. It tells us where to work. Agent Factory won't replace work that crosses the walls of a single Epic instance. That's where outside builders should spend the next year.
The healthcare AI I'd bet on sits next to the EHR, not inside it. It comes in through CDS Hooks, opens a SMART on FHIR app with patient context, and writes results back as FHIR. I've written about the rough edges of that path: what CDS Hooks look like once you try to get them working in Epic, and how MedScrub and eSpiral handle SMART scopes, minimum PHI and audit logs behind a FHIR MCP server. Agent Factory makes that architecture look better. The inside of Epic is now Epic's territory.
When Epic Agent Factory is actually available
Epic calls it its "platform for health systems to build, monitor, and evaluate AI agents." Early adopters are already using it. Training for the first early-adopter group starts in October 2026, and "broader availability" is planned for 2027. So it doesn't simply "ship in 2027." For roadmap purposes, treat it as live now and everywhere in 2027.
The pitch is no-code: start from one of 120 out-of-box AI features, or build your own agent in hours. Reality is messier. ECU Health's two live agents run on "custom Agent Factory flows that Epic built for them," and Epic developers worked alongside every team at the second Build-a-Thon. Epic engineers are doing a lot of the early building. Adoption will be slower than the pitch. It will still happen.
Which healthcare AI features Agent Factory will replace
Look at what health systems built. At the second Build-a-Thon, teams from 25 health systems built agents that read notes for early signs of necrotizing enterocolitis in premature infants. Others flag surgery patients at risk of cancellation, check refill requests against protocol, and catch undocumented critical care time. Every one starts from data in that health system's own chart. Every one ends as a flag, a draft or an outreach for that system's own staff and patients. Nothing has to leave the building. That's exactly why a no-code tool inside Epic can do it.
ECU Health's transfer agent summarizes incoming requests and identifies which facilities can take each case. Epic says it saves 20 hours of staff time a week. That number is Epic's own, and there is no comparison group. Treat it as directional.
Here's the rule I use. If a feature needs only data in one Epic instance, and its output lands in one Epic workflow, it's gone. That covers summaries, transfer triage, inbox and message drafting, refill protocol checks, drafted documentation, and anything that's a light wrapper on one of Epic's 120 out-of-box features.
The distribution math is brutal. More than 85% of Epic customers already use Epic AI. Epic's Phil Lindemann said Epic will build "an entire library of on-platform agents that are just ready to go." A build-a-thon this year drew more than 1,000 agent ideas from customers, and Epic expects customers to share agents across its community.
You won't out-distribute that. If one of these features is your whole product, cut it or give it away as a free way in. Don't make it the line item you sell.
What Epic Agent Factory can't do
Press coverage calls Agent Factory a platform for agents "inside Epic." That word sets the boundary. Four kinds of work sit clearly outside it.
Logic that spans EHRs. Fierce puts Epic at 43.7% of the acute-care EHR market. By bed count, a 2024 analysis puts Epic at 54.9%. Pick either measure and a large share of acute care still runs on something else. Think of a referral network, or a hospital group with Epic at some sites and Oracle Health at others. It needs one rule that behaves the same everywhere. An Epic agent can't be that rule.
Payer-side flows. Prior auth is moving onto multi-vendor rails by regulation. CMS-0057-F makes payer FHIR prior auth APIs due in 2027. Da Vinci PDex profiles CDS Hooks and SMART for payer-to-provider exchange. Half of each of those transactions lives at the payer, not in the provider's EHR. I covered the build in the CMS-0057-F prior auth post.
Edge and device data. A continuous care monitor like MetaVigil starts with sensors, not the chart. Signal processing, baselines and escalation happen before anything is worth writing to an EHR. A chart-centric agent builder isn't designed for that layer.
Evals you control. Epic says Agent Factory lets you evaluate agents. That evaluation presumably runs inside Epic, on each customer's own data. If you sell to ten health systems on three EHRs, you need one labeled eval set and one harness that run the same way at every site. You also need to own it when the model changes underneath you. Here's the minimal version. Regulation points the same way. ONC's HTI-1 rule replaced the old CDS certification criterion with decision support interventions and requires source-attribute transparency for predictive ones. If you can't describe how your model was validated across sites, someone will ask.
Two questions are still open. Epic's public posts don't say whether a customer can bring their own model into an Agent Factory agent, and Epic has announced its own Curiosity foundation models. They also don't say whether an agent can call an outside CDS Hooks service or SMART app. Treat both as unknown until Epic's developer docs answer them, and don't bet a product on either answer.
There's one more gap, and it's about governance, not technology. One practitioner newsletter raises silent failures with no clear owner once the builder leaves. An agent a clinical informaticist built at a hackathon becomes a liability when that person changes jobs. A vendor product has an owner, a changelog and an on-call rotation. Sell that.
How to integrate third-party AI with Epic: CDS Hooks, SMART on FHIR and Provenance
Don't compete with Agent Factory. Build your product so Epic's users can reach it through standard interfaces today. There are three pieces.
CDS Hooks cards and SMART apps are the way in. A CDS Hooks service returns a required cards array and an optional systemActions array. Cards carry information, suggested actions and links that launch an app. The current spec is 2.0.1, an errata release on FHIR R4. Here's a card whose suggestion actually does something:
{
"cards": [{
"uuid": "6d1f0c2a-9b4e-4f7a-a3c1-2e8b5f9d7a10",
"summary": "Prior auth likely required for this MRI",
"indicator": "warning",
"source": { "label": "Your Service" },
"selectionBehavior": "at-most-one",
"suggestions": [{
"label": "Draft prior auth task",
"uuid": "b41e7d3c-0f2a-4c8e-9a61-5d2f8e3b7c90",
"actions": [{
"type": "create",
"description": "Draft a prior auth task for this order",
The action creates a draft Task, not a signed order. Nothing happens unless the clinician picks it, and even then a person works the draft. The card's logic should be deterministic rules. I've argued before that no LLM belongs in order-sign.
A few rules the spec enforces. The summary must be under 140 characters, so write it like a pager message, not a paragraph. selectionBehavior is required once you include suggestions. The CDS client decides how to display your card and whether to auto-apply system actions. You don't control the pixels.
Keep the card uuid. Clients send it back to your feedback endpoint, and that feedback is the most underused eval data in healthcare AI:
POST {baseUrl}/cds-services/prior-auth-check/feedback
{
"feedback": [{
"card": "6d1f0c2a-9b4e-4f7a-a3c1-2e8b5f9d7a10",
"outcome": "accepted",
"acceptedSuggestions": [{ "id": "b41e7d3c-0f2a-4c8e-9a61-5d2f8e3b7c90" }],
"outcomeTimestamp": "2026-10-02T14:05:40Z"
}]
}
Log the inputs behind every card you issue, keyed by uuid. When feedback arrives, join on it. An accepted suggestion is a positive label. An overridden card is a clinician telling you the card was wrong. That gives you a labeled production dataset from every client that sends feedback, on every EHR, in one format. Those are the evals you control, and no agent inside one vendor gets them across sites.
Put anything a clinician needs to inspect behind the smart link. That means a SMART app launched with patient context and the narrowest v2 scopes you can justify, such as patient/Observation.rs, not a wildcard. Ask for less. It shortens security review and limits the blast radius.
FHIR is the contract. Your product reads FHIR and writes FHIR. Support varies by vendor, but FHIR is the only interface Epic, Oracle Health and a payer's API all expose. Build to the standard. If Epic ever opens its agents to outside services, you're already there. If it doesn't, you've lost nothing.
Show your work through Provenance. Epic sells Agent Factory with the line "Agent actions are traceable." An outside product has to meet that bar, or it loses the comparison in the first governance meeting. Every write-back gets a Provenance resource. In R4, target, recorded and agent are required.
{
"resourceType": "Provenance",
"target": [{ "reference": "DocumentReference/draft-note-881" }],
"recorded": "2026-10-02T14:03:11Z",
"agent": [
{ "type": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type", "code": "assembler" }] },
"who": { "reference": "Device/summarizer-v3-2" } },
{ "type": { "coding": [{
The model, versioned as a Device, is the assembler. The clinician who confirmed the output is the verifier. Each source the model relied on is an entity. This is the same draft-then-confirm pattern as the critical care agent from Epic's Build-a-Thon. The difference is that the record travels with the data to any FHIR server, not just one vendor's audit log.
Agent Factory vs custom build: one test per feature
The test is one question: does the feature need anything outside one Epic instance? Run your roadmap through it.
| Feature | Crosses Epic's walls? | Call |
|---|
| Transfer request summary | No | Cede to Agent Factory |
| Refill protocol check | No | Cede to Agent Factory |
| Drafted inbox reply | No | Cede to Agent Factory |
| One referral rule across Epic and Oracle Health sites | Yes: another EHR | Build |
| Prior auth check at order time | Yes: the payer | Build |
| Escalation from home sensor data | Yes: a device | Build |
| Same eval harness across ten customers | Yes: your evals | Build |
If the top half of that table is your business, your job is now helping health systems build those agents well. If it's the bottom half, you're building the right thing.
I've argued that healthcare AI will be won by verticals. Agent Factory narrows the vertical to work that crosses Epic's walls.
