When people picture an AI receptionist for a clinic, they usually imagine one clever model doing everything: answering patients, checking the diary, moving appointments and sending reminders. That is the design I avoid. On a dental clinic project I built, the AI does one job, which is the conversation. Everything that decides who is next lives in the database.
This post explains that split and why I think it is the safer default for any practice.
The problem: one late appointment moves everything
In a busy clinic, one appointment running late shifts every appointment after it. The patients affected need an accurate update, and reception needs one reliable view of the day. Without a system, that means phone calls, a paper or spreadsheet schedule, and messages typed by hand.
It is tempting to hand all of this to a language model: "here is the schedule, a patient is 20 minutes late, work out the new times and tell everyone." It will usually produce a sensible answer. But a clinic schedule cannot be usually right.
The design: the AI talks, the database decides
The system I built has three layers:
- Conversation. An AI receptionist workflow in n8n answers patients and collects details. It runs a LangChain agent through OpenRouter, and conversation memory is stored in Postgres.
- Business logic. Queue recalculation lives in PostgreSQL stored functions. That is the single source of truth for who is next and what changes when someone runs late.
- Dispatch. The backend and n8n are thin dispatchers. They call the database functions and send the resulting messages, such as delay notices and a scheduled reminder job.
The AI never calculates a queue position. When something needs to change, it calls a function, and the function decides.
Why this is the safer default
Results are deterministic. The same delay always produces the same new queue. You cannot get that from a prompt, however well it is written.
You can test it. Queue recalculation is ordinary database logic, so cascade cases, such as one delay affecting every later appointment, can be checked directly instead of by chatting with a model and hoping.
There is one place to change a rule. If the clinic changes how long a check-up takes, you change one function. You do not hunt through prompts and workflow nodes.
The AI cannot corrupt the schedule. Every change to queue state goes through a database function, never through free-form model output.
Staff see the truth. Admin, reception and dentists each get a role-based dashboard over the same live queue.
What the AI is still good for
None of this makes the AI less useful. It is good at the part people find tedious: understanding a message written any way at all, asking for missing details politely, and turning the database's answer into a clear message for the patient. It should do that well and nothing else.
The honest status
This was built for a dental clinic project. I am not claiming a production deployment or active clinic use, and the WhatsApp channel for the receptionist is still being tested end to end. Regulatory requirements are not claimed to be met; they would be assessed for each practice.
If you are planning an AI receptionist, ask one question of any design you are shown: when the schedule changes, who decides, the model or the database? If the answer is the model, ask how they will test it.
You can read the full case study, including the stack and the safeguards, on the AI Dental Reception & Live Queue System page, or see how the same idea applies to running-late updates for dental clinics.