A patient asks for an appointment. The agent reads the provider’s real open slots out of the EHR, offers them wherever the request came from, a scheduling queue, a patient flow, a voice agent mid-call, and books the chosen one: re-checked at the moment of writing, patient verified, and confirmed by a human before anything lands on the calendar.
Overview
This is the workflow behind “just get the patient booked.” First the agent looks: it signs in and pulls the provider’s actual open slots for the window you care about, the same availability a scheduler would see on screen, returned as data your systems can use. Zero openings is an answer, not an error. Then it books: the chosen slot is re-verified as still free, the patient is matched in the chart by name, date of birth, and MRN, and the appointment is created in the practice’s own timezone, daylight saving included, never the machine’s.
It runs today in eClinicalWorks and in a widely used practice-management scheduling system, and the two builds differ in a way that matters: one system’s calendar can only be trusted visually, while the other is driven through the product’s own internal API from the logged-in session. Same guardrails either way, and the looking and booking halves also run separately when all you need is one of them.
Step by step
Structured output
Every run ends as a record like this in your system, not a portal screenshot someone transcribes. This is the part your team stops doing by hand.
{ "provider": "SAMPLE, JANE MD", "total_slots": 14, "coverage": "2026-07-21 to 2026-07-25", "open_slots": [ { "date": "2026-07-22", "times": [ "09:20", "09:40", "11:00" ] }, { "date": "2026-07-23", "times": [ "08:00", "13:20" ] } ]}{ "slot_available": true, "appointment_created": true, "appointment_id": "APT-2026-•••318", "date": "2026-07-22", "start": "09:20", "end": "09:40", "duration_minutes": 20}In one major ambulatory EHR, booked appointments render as overlay elements that are invisible in the page’s DOM: a scraper reading the markup sees a free slot where a patient already sits. The booking agent judges availability from what’s visually on screen, the way a scheduler would, precisely because the “clean” programmatic answer is wrong. That’s the honest case for browser agents in scheduling: not that clicking is elegant, but that the UI is the only interface telling the truth.
At scale
Export feeding booking is the whole “find a slot, then take it” flow, and it’s built to sit downstream of anything that talks to patients: voice agents answering practice phones hand structured requests to exactly these workflows. The same pair extends across systems via appointment read/write on secondary EHRs, and the category view is the scheduling workflow library. And the public face of the calendar, marketplace profile sync and cancellation, keeps external bookings honest against it.
Human in the loop
Every run executes on HIPAA-compliant, SOC 2 Type II infrastructure under a BAA, with an execution-level audit trail of every slot read and every appointment written. Full posture on the security page.
The booking write itself.
A human confirms before the appointment is created; the agent does the verification, a person owns the commit.
A conflict at write time.
If the slot filled between export and booking, that’s reported as slot-taken, and nothing is overwritten.
A wrong or ambiguous patient match.
Name, date of birth, and MRN must agree with the chart; anything less stops the run.
Patient not in the system.
Reported as patient-not-found, a structured outcome that chains into patient creation rather than a dead end.
Questions
Schedulers spend their day being the API between the phone and the calendar. The scheduling workflow library is what replacing that looks like, system by system.
Disclaimer
Third-party names, including government agencies and registries, are used only to identify systems commonly involved in healthcare operations workflows. Asteroid is not affiliated with, endorsed by, sponsored by, or certified by those third parties unless expressly stated. Workflow availability depends on customer authorization, account permissions, configuration, and applicable system terms.