Voice AI
Fairy Share Dental AI Receptionist
An inbound dental receptionist that books into the practice management system — and only says “booked” after it has read the appointment back and checked every field.
01 / THE PROBLEM
Why this matters.
A booking agent that says “you are all set” is making a promise on behalf of the practice. The write can fail, the slot can be taken between the offer and the booking, and the caller still hangs up believing they have an appointment. Nobody finds out until the patient arrives.
02 / THE DIRECTION
The solution.
A voice agent over a FastAPI tool layer that talks to Open Dental, built on one rule: check, book, verify, confirm. Availability is offered as real open times carrying a signed slot id. The booking tool re-checks the slot, writes, and returns "created pending verification" — never "booked". Only a separate read-back from Open Dental, with every field matching, lets the agent confirm out loud, and a confirmation message is re-verified before it is ever sent.
My role.
Designed and built the agent, the six webhook tools, the Open Dental adapter and its mock, the verification rule, and the confirmation workflow. V1 covers booking and confirmations; reschedule, cancel and human handoff are the next milestone. Demo only — it runs on Open Dental test data with synthetic patients and is not HIPAA compliant.
03 / ARCHITECTURE
How the pieces connect.
System flow
- 01Caller
- 02Patient lookup · name + date of birth
- 03Real availability · signed slot
- 04Create · pending verification
- 05Read back & field match
- 06Spoken confirmation · email, SMS or Telegram
04 / ENGINEERING DECISIONS
Designed with intent.
- Make “verified” the only path to a confirmation, so the agent cannot promise a booking the system did not make.
- Hand the agent opaque signed references instead of record ids, so it can neither see patient numbers nor invent a slot — and expire a slot offer after 15 minutes.
- Give the agent the minimum it needs: a match status and the words to say, never record fields read back from the practice system.
- Make booking idempotent, so a retried call finds the existing appointment instead of creating a second one.
- Keep health information out of the logs entirely — tool name, conversation id and outcome only.
- Keep a mock of the practice system behind the same interface, so the whole flow runs and is tested offline.
05 / EVALUATION APPROACH
What needs to hold true.
- Unit and contract tests run the full booking flow against the mock practice system; live tests are opt-in.
- A live connection script checks the integration read-only, and can book and verify one synthetic appointment end to end.
- Live booking and verification against Open Dental confirmed on 22 September 2026.
Technology direction.
Challenges & tradeoffs
- The interesting failure is not a wrong answer but a confident one — most of the design exists to stop the agent confirming a booking that did not happen.
- Free hosting sleeps, so the backend needs a scheduled ping before a demo rather than a cold first call.
Results
- Live booking and read-back verification against Open Dental, confirmed end to end.
- Confirmations delivered by email, SMS or Telegram, only after verification.