The Saturday tour-times failure

Fede called and asked one simple question — what tour times do you have this weekend? — and asked it five times, in two languages, over two and a half minutes. Clara never named a single Saturday time. Along the way she described her own internal data to him, pushed him toward booking when he'd only asked a question, and the one "fact" she finally produced (Saturday office hours) came out of an error message from a rejected booking attempt. This document explains exactly why, from the call's own records, and what fixes it. (An earlier version of this analysis anchored on a voice-sound change that coincided with the call; that was a misdiagnosis and is retired to the appendix.)

The call, in full

Every turn, with the system's own actions shown where they happened. Highlights mark the failures; annotations state what the record proves at that moment.

Finding 1 (the incident): Clara cannot answer "what times do you have on Saturday?"

The call's own data makes the mechanism unambiguous:

• Her briefing only ever contains the earliest two days. The availability injected at call start reads, verbatim: "Earliest tour times (a partial list — NOT the full calendar; never deny an unlisted time from this list alone, attempt the booking instead): Monday, August 24… Tuesday, August 25…" Nothing about the weekend the caller asked for. This is by design — the injection is an "earliest openings" digest, not a calendar.
• She has no way to look a day up. The leasing agent's toolbox has tools to book, reschedule and cancel a tour — but no tool that answers "what times are open on this day." Asked about Saturday, she literally has nowhere to get the answer.
• So her only probe is to attempt a real booking — which her briefing explicitly instructs ("attempt the booking instead"). That's why a caller who asked a question got walked through name and tour-type: those are required fields for the booking attempt, her only way to learn anything. The caller felt it and said so: "I only asked what times you have."
• The attempt taught her office hours, not times. The booking was rejected — 10 AM is outside Saturday office hours (1:00–4:30) — and that error message is the only Saturday information she received all call. Hence the closing line: office hours offered in place of tour times. The rejection worked as designed; the experience it produced did not.

The fix: give her the key — a day-specific availability lookup that returns ready-to-speak times ("Saturday: 1:15, 2:30, or 3:45"). One tool call, only when a caller names a day, replacing today's blind booking attempt — so no added latency on any call, and strictly less awkwardness. This is designed jointly with the Voice Truth Guard work already in flight (its "status-locked speakable outcomes" concept is exactly this: the tool hands Clara the sentence that is true and safe to say). Once the lookup exists, the briefing's "attempt the booking instead" instruction — the root of the question-becomes-booking behavior — is retired.

Finding 2: "The calendar has more slots than what I'm showing here"

That sentence — and its sibling "I don't have the weekend slots pre-loaded" — is Clara repeating her own briefing's caveat to a customer. The injected slot list opens with an internal note ("a partial list — NOT the full calendar…"), and nothing marks that note as internal-only, so under pressure for an answer she doesn't have, she narrates her data access instead. Correct behavior is one of exactly two things: state actual times (finding 1's fix), or say something caller-shaped ("let me check Saturday for you") — never a description of what is or isn't loaded into her head. The prompt fix is one line (mark briefing meta-notes as never-spoken); the real fix is finding 1, which removes the situation entirely.

Finding 3: the same evening's other test call (fees and the unsent text)

Two more failures from Fede's earlier 7:30 PM call on the Willows line, already root-caused and cross-referenced here for one view of the evening:

• The "$200 administrative fee" — CORRECTED (Aug 23): not invented. Later fact-checking found property 45's own config literally contains adminFee: 200 (plus $75 storage and $50 utility-setup fees) in the injected pricing block — Clara read her briefing faithfully; the DATA contradicts Fede's ruling ($38 application fee, no admin fee). The defect is stale/planted test-property data, and the fix is a data reconciliation (purge or align property-45 fees and harness-planted knowledge entries such as the fake "buzz code 0000" office directions), which fixes every model at once with zero latency. The fee-fabrication guard class remains real for genuinely unbacked figures (e.g. the "$152" deposit a lab call produced at raised temperature).
• "I'll text you the application link right after this call" — no text ever arrived (verified against the carrier's records). A post-call sender exists but triggers on caller interest signals and is blind to Clara's own promises — its code comments predicted exactly this. The broken-promise audit (separate report) recommends the structural fix: detect any Clara promise and verify a matching dispatch actually happened, async, zero latency.

Appendix: the sound investigation (a misdiagnosis, kept honest)

The first version of this analysis anchored on the voice-sound change applied four minutes before the call — timing made everyone, this lane included, hear "the voice has severely regressed" as an audio problem. The behavioral complaints above were the real incident. What the sound investigation did establish, and keeps:

• The expressive-delivery switch breaks delivery: stage cues like [reassuring] land in the reply text and the audio carries measured dead silences at those spots — 2.9s and 2.0s in this very call, 2.4s in the sandboxed reproduction. Correction (Aug 23, after the pre-re-apply listen gate): the first isolation concluded "either setting alone is clean" — that was a single-call false negative. A fresh gate test with the cue list completely empty still produced four leaked cues in one call ([reassuring], [warm] twice, [happy] — cues the model invented itself). The expressive switch alone is sufficient to trigger it; the behavior is probabilistic per call, which is exactly why the mandatory listen gate exists — it caught this and blocked a second incident. Final update (Aug 23): temperature-only also failed its gate — two test calls at temperature 0.3 with everything else off produced unprompted wrong-language greetings (Spanish before the caller spoke, twice), a mid-sentence language flip, and a spoken factual contradiction (two different deposit amounts in one sentence, verified in audio). Verdict: no safe warm variant exists on the current voice stack. The warm-sound effort stops here; warmth, if pursued, needs a different underlying approach (a voice model that actually supports delivery cues, or warmth through wording at temperature 0). The repo config has been reset to match the rolled-back production state. Best-supported mechanism unchanged: the phone-call voice model variant doesn't understand bracket cues (documented only for the standalone model).
• Mechanism, captured (Aug 23, per Fede's "go deeper"): a decoy model endpoint intercepted the exact instructions ElevenLabs sends. With expressive delivery ON and our cue list EMPTY, ElevenLabs injects its own teaching paragraph, verbatim: "…you have access to expressive tags… Put emotional emphasis where needed with square brackets e.g. [happy], [sad], [excited], [slow], [fast], [laugh]… Example: I'm [happy] happy to help you!" — so the "invented" cues come from ElevenLabs' own prompt injection, not from anything we configured; our cue list is purely additive on top. With expressive OFF, no bracket instruction exists anywhere. Their docs claim tags are optional; the actual toggle bundles the delivery style and the tag-teaching text inseparably — a vendor product gap. A bug report with the captured evidence is drafted and ready to file on Fede's word. Side finding from the same vantage: the thinking-pause fillers are generated by ElevenLabs' own backend — no request ever reaches our configured model — which is why they sound off-voice.
• The rollback (done within 8 minutes 15 seconds of the apply, before this analysis existed) stays justified as a precaution; exactly one call — this one — happened during exposure, zero real customers.
• Before any warm-sound re-apply: expressive-without-cues first, a real-audio listen test on the exact production brain and voice model in both languages, and an audience line (which properties these agents answer) printed in every apply.
• The testing gap that let it through: the "sounds amazing" ear-tests ran the same settings on the lab agents, whose brain is a different model that doesn't emit the cues. Sound changes now get listened to on the production brain, always.