Every healthcare AI product has two jobs, whether or not your team has separated them yet. It decides what should happen, and it makes that decision true inside the system of record your customer lives in. The first job is your core product. The second one is called the execution layer.
An execution layer for healthcare AI is the system that takes an action the AI has decided on and completes it inside the system of record. It is the runtime between decision and record, and it has to be governed, stateful, and deterministic: the note is filed to the right encounter, the referral is submitted and confirmed, the appointment exists on the PMS calendar, and there is evidence of each outcome.
The decision layer decides. The execution layer lands it.
The decision layer is the half your customers love: the models and logic that conclude a note should be filed, a prior auth should go out, a care gap needs a booked appointment. The execution layer is everything between that conclusion and the change landing in the systems your customers already work from: access the portal, find the right patient, enter the AI’s structured output, submit, confirm.
Execution layer vs orchestration vs RPA
Two categories get mistaken for this one. Orchestration platforms and integration engines sequence work across systems you can already reach through an API; they assume the connection exists, and in healthcare it mostly does not. RPA scripts do reach the UI, but they are pinned to screen selectors, so a portal redesign breaks them silently and every new system is a new script to write and maintain. An execution layer is defined by the reach: it completes the action inside systems that offer no API, it reads the screen the way a person does rather than depending on selectors, and it verifies the result rather than assuming it.
Why execution is so hard in healthcare
- No write APIs. The stable APIs other industries automate against mostly do not exist here. Writing a note, an order, a referral, or a payer transaction is at each vendor’s discretion, most of the long tail declined, and the UI is the only write path that always exists. Healthcare will grant your agent a login long before it grants you an API. (The full option-by-option map is in our guide to EHR integration APIs.)
- The wrong-patient problem. A misfiled note or a referral submitted against the wrong record has serious consequences. Identity has to be verified at every step, never inferred.
- No sandboxes. Most portals and long-tail EHRs offer no test environment. The first execution happens against production, with real PHI, under a BAA.
- Hostile sessions. MFA challenges, aggressive timeouts, lockouts, and interfaces that change without notice. These systems were hardened against automation, not designed for it.
- Fragmentation without standardization. Hundreds of certified EHR products, plus payer portals and state systems, configured differently at every site. Every new customer is a new surface, and that customer is a clinic, an agency, or a billing team with no IT department to help you integrate.
- Per-action compliance. Being a compliant vendor is not the bar; every individual execution needs an audit trail someone can review.
Because no universal solution has existed, every healthcare AI company assembles its own patchwork of vendor APIs, RPA scripts, and manual work. RPA does not scale with the number of systems; people do not scale with volume.
What an AI agent execution layer must handle
Six capabilities, one answering each problem above, separate an execution layer from a script that happens to click buttons.
| Capability | The job | The healthcare reality that demands it |
|---|---|---|
| Session and identity | Log in, pass MFA, survive credential rotation, and hold SMART on FHIR or OAuth scopes where a system offers them | Portals enforce MFA and expire passwords on their own schedules; rotation routes to a human or a managed TOTP flow |
| Navigation and state | Reach the right record in the right module at the right site | The same EHR at two customers runs different modules, custom fields, and dropdown semantics; the API contract is generic, the site is not |
| Structured write | Enter the AI’s output so it lands the way the UI files it | A note must land signed and encounter-attached, not as an orphaned document; work queues and task states only change through the screens |
| Verification | Confirm the system accepted the write | A submitted form is a hope; the record’s own state is the fact. Writes are checked, never assumed |
| Typed failure and escalation | Stop with a stated reason and route to a human queue | Identity mismatch, portal redesign, maintenance windows: the layer stops rather than improvises, and a person picks up exactly where it stopped |
| Audit evidence | End every execution in a terminal state with a trail | Whoever audits your customer, a compliance department or an office manager, signs off on evidence; “the agent gave up cleanly and told you why” is a deliverable |
Asteroid: the execution layer for healthcare AI
Asteroid is the execution layer for healthcare AI: one connector for every EHR, payer portal, registry, and desktop app that never shipped a usable write API, with verified execution and audit evidence on top. Live in days, not months. Integration is the connection into a system; execution is the completed, verified action carried over it, and Asteroid provides both. For an AI scribe, that means notes filed into whichever EMR each customer runs. For a voice agent, it is the booking or triage request submitted the moment the call ends. For revenue-cycle AI, it is prior auths, status checks, and eligibility completed inside payer portals that never offered an API. In production, one voice receptionist serving primary-care practices converts about 475 patient calls a day into submitted triage requests across five different online-consultation systems and more than 80 practices, filed in the patient’s own words.
Asteroid Integrate, a catalogue of hundreds of prebuilt automations, is reachable through a single API call and grows every week (available on the Scale plan). When the connector you need is missing, Astro, Asteroid’s agent builder, lets your team build it yourselves in about 30 minutes, on the same rails as every prebuilt one. The agents read screens the way a person does rather than depending on pinned selectors, so most portal changes pass without anyone touching anything. When one does break a workflow, the platform surfaces exactly what failed and Astro recommends the fix, implementing it once someone approves. On Enterprise plans that loop can run as a managed service. Every execution ends in a terminal state with an audit trail, under HIPAA with SOC 2 Type II certification. In production today: 250+ agents across hundreds of healthcare systems, approaching one million executions.
Your AI already knows what should happen next. If your customer’s staff still make it true by hand, bring your hardest customer system to a demo and we’ll run your workflow live.
Further reading: what browser agents are, computer use in healthcare, and the wider guide to healthcare workflow automation.