What broke when we called our own AI receptionist

Five minutes and forty-five seconds, on a demo agent configured for a dermatology practice — nobody but us has ever called this number. A caller asked for tomorrow with a specific provider. The agent offered times, and the caller picked one. Straightforward — until I deliberately tested how the agent would handle an email correction.

The test was this: give the agent an email address, let it read it back, then provide a different version and see if the agent would overwrite the first one and use the new address instead. Not a case of struggling to spell something. An intentional correction, repeated multiple times, to verify whether the agent treats the first address as permanent or whether it can actually update to a newer one.

Here's what happened, unedited:

The agent kept re-reading the first address even as I provided corrections. What I was testing: does the agent discard the old address and adopt the new one on each correction, or does it revert to and stick with whatever it captured first?

But there was something worse underneath. After I reviewed the database, I found that the appointment was booked with no email at all. The agent was reading back some version of the address on each turn (not always the right one), and the caller confirmed the final version — but caller_email in the database was null. The agent was never persisting any email, not even the confirmed one, because it wasn't sending any email to the booking tool.

The prompt had a gatekeeping instruction: "If the client doesn't have an email field configured, do not ask the caller for an email address — book the appointment without one." That's not "don't ask proactively." That's "never include email, period." So when I volunteered and corrected an email anyway, the agent dutifully repeated it back (following the separate Speech Formatting rule that applies to any address offered), but then obeyed the Flow instruction and left email out of the book_appointment call.

The database path itself was never the issue — caller_email flows straight through to the Appointment row whenever the LLM sends it. The prompt just never told the agent to send it.

This affects every client without the email opt-in field configured. A volunteered email — even a corrected, confirmed email — will be read back to the caller correctly, but then silently dropped from the booking.

One prompt edit in agent_prompt.py:181. The opt-out instruction now reads:

"Do not ask the caller for an email address. If they volunteer one anyway, confirm it per Speech Formatting and pass it as caller_email."

The booking logic itself didn't change — the fix is purely in telling the agent to include a volunteered email in the tool call. We also tightened the tool parameter description to remove the ambiguous wording that suggested "only if they asked for email confirmation."

We added a regression test that locks in this behavior — it references this call's ID (call_e85fbe75382c633441fb78d89ca) in a comment, so if anyone changes this logic again, the test will catch it.

This fix is deployed and confirmed. We ran a live test call and the email was saved to the appointment record — the gate we were waiting on has passed. Every client without an explicit email field now captures volunteered and corrected emails instead of dropping them silently.