Fairy Share Dental AI Receptionist: the thinking.
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.
The starting point.
What made this worth building.
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.
The direction I chose.
The approach taken.
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.
How the pieces connect.
Each stage exists because the one before it cannot be trusted on its own.
- 01Caller
- 02Patient lookup · name + date of birth
- 03Real availability · signed slot
- 04Create · pending verification
- 05Read back & field match
- 06Spoken confirmation · email, SMS or Telegram
The decisions behind it.
The constraints I set deliberately, and would defend.
- 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.
What has to hold true.
How I would know it works — and how I would know it does not.
- 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.
Where this stands today.
Stated plainly, with nothing implied.
This project is complete.
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.
Keep going