Every dental practice management system now has an AI page, and they describe very different things. Some answer questions about your data. Some draft notes. Some carry out work. The word on the page does not tell you which.

There is a simple test that separates the two, and it takes one sentence to run.

The test

Pick something you do twenty times a day. Say it out loud to the software.

“Ada cancelled — put her 3pm slot up and book Grace into it.”

Some systems say they cannot help with that. Some answer with instructions for where to click. Some do the first half and lose the second.

A system built for this reads the schedule, works out that Op 2 is free at three, checks that Grace’s crown seat fits the released block, and shows you both changes. Then it waits, because you have not said yes yet.

The difference is not the quality of the language model. Both systems could be using the same one. The difference is whether the application’s own actions are available to the model as tools, and whether the data model was built to be queried by something other than a screen.

Three things that are true of AI-native software

It works where you are. Whether it opens as a side panel or listens through the microphone, it already knows which patient is open, which operatory you are standing in, and what you are allowed to see. If you have to give it the patient’s name while their chart is on the screen, it is not part of the system yet.

Voice executes, it does not transcribe. Dictation into a note field is a 1990s feature with a 2020s speech engine. Saying “26 MOD caries” and watching a mesial-occlusal-distal caries finding land on tooth 26 for the patient in the chair is a different category of thing. One saves you typing. The other removes the step where you put the handpiece down.

Everything the system does is an event. appointment.cancelled, claim.rejected, hygiene.overdue. If important actions do not emit structured events, an AI layer has nothing to subscribe to and no way to act on its own initiative. This is architectural, and it is hard to add later.

The part to ask about

Being able to act creates an obligation that a chatbot never had.

A system that can write to a clinical record has to be extremely clear about when it does. In Girsu there are two answers. A spoken chart entry saves at once, is read back by patient, tooth and surfaces, and is taken back with “scratch that”, because a clinician mid-exam should not stop to click a confirmation. Anything that books, posts money, texts a patient or deletes is shown in full and waits for a yes, and several changes from one sentence are listed together rather than as five dialogs you learn to click through. Signed records cannot change because a model revised its interpretation overnight: a correction is an addendum.

If you are evaluating dental practice management software with AI in it, ask the vendor to show you what happens between the request and the record changing, and how you take it back. A vague answer is the answer.

What to ask on a demo

Show me a task where one sentence produces more than one change.
Show me the screen where I approve it before it happens.
Turn off the internet. What still works?
Show me where I can see what the assistant changed, and who approved it.
Say a chart entry wrong on purpose. How is it corrected?

Any dental PMS can answer the first question with a video. The other four are where the architecture shows.