DentinFlow

DentinFlow automates the front desk for dental practices. The product is Mila, an AI voice agent that answers inbound calls, books and reschedules appointments through normal conversation, and hands the call to a human the moment one is actually needed.

The problem

A dental front desk is a queue with no backpressure. Calls arrive in bursts (the lunch hour, the first hour after opening), and every ringing phone competes with the patient already standing at the counter. When the desk is underwater, calls roll to voicemail, and a voicemail from someone trying to book a paying appointment is usually a lost patient, not a deferred one.

The usual fixes all leak. Voicemail assumes the caller phones back, and plenty don't. A generic answering service can take a message but can't see the schedule, so it can't actually book anything. Mila is built to close the loop inside the call: understand the request, check the real schedule, and commit the appointment before the caller hangs up.

How it works

The system splits cleanly into a real-time voice layer and a transactional booking layer, and that split is the whole design.

• Voice, on Vapi. Vapi owns the hard real-time parts: telephony, speech recognition, turn-taking, and speech synthesis (the voice itself is an ElevenLabs voice). The conversation runs on gpt-4o, which reasons over the live transcript and decides when to reach for a tool.
• Tools, on Express. The backend exposes a small, sharp set of functions the agent can call mid-conversation: pull the practice's hours and providers, find open slots, book or move an appointment, take a callback, transfer to a human. The agent calls these. It never reaches the database itself.
• State, on Prisma and Postgres. Practices, providers, services, the appointment ledger, and call records live in Postgres behind Prisma. The schedule is the source of truth; the agent is just a caller against it.
• Practice knowledge. Each practice's facts (hours, insurance accepted, provider specialties, new-patient policy, common questions) are embedded and retrieved by similarity, so Mila answers from this practice's reality instead of a generic script.
• Outcomes, on PostHog. Every call is tagged with how it ended (booked, rescheduled, transferred, message taken, question answered, no availability, caller hung up), so the funnel is something you measure rather than guess at.

The hardest part: an agent that can't lie about the calendar

The failure mode that matters in this product isn't an awkward sentence. It's a confidently wrong booking. An agent that cheerfully says "great, you're all set for Tuesday at 2" when that slot is gone does more damage than no agent at all: a patient shows up to a conflict, and the practice eats the trust.

So the governing rule is that the model is never allowed to invent the schedule. Availability is read live from Postgres at the moment of booking, never inferred from earlier in the conversation, and the write is owned entirely by the backend, not the model. If the slot is already taken, the booking is refused at the backend and Mila recovers inside the call, offering the next real opening instead of asserting a success that didn't happen.

That is the risk-desk instinct applied to a voice agent: assume the system will be asked to do the wrong thing, and put the hard stop in the code path that commits, not in the part that talks. The conversation can be flexible; the booking cannot. The next hardening step is signed slot tokens, so the model can only ever commit a slot the backend has already pre-approved, closing the gap between "checked" and "committed" for good.

Status

In active development, with the voice loop, the booking tools, and the practice-knowledge layer working end to end for a single practice. The first target is solo and small-group practices, where one missed call really is one lost patient. The honest version of impact, calls handled and hours handed back to the front desk, goes here once there are numbers worth standing behind.