Confirmation guards: the yes must be latest, plain and specific to the action

Why buyers care

Every voice agent that does something (books, cancels, pays, files, disputes) has a moment where it asks "shall I go ahead?" and the caller answers. Everything the buyer is liable for hangs on whether that answer was really a yes, really to that question, and really the caller's most recent words.

Most demos handle this with a sentence in the prompt: "always confirm before submitting." The model usually obeys. Usually is the problem. The failure that matters is not the model forgetting to ask. It is the guard accepting the wrong words as the answer, because of how the pieces of a voice pipeline arrive in time. In the research team's real-browser runs, an agent executed a reconsideration request without asking, having borrowed the caller's previous sentence as the yes to a generic "would you like to proceed with that?" from two turns earlier. No prompt sentence prevents that. A guard does.

Buyers care because this is the failure that produces a wrong charge, a cancelled appointment or a filed dispute the caller never wanted, and because it is fully testable in a demo.

The mechanism

A confirmation guard sits between the model's request to run a consequential tool and the tool itself. It answers one question: is there evidence in the transcript that the caller agreed to this action? Three rules define the evidence.

Four traps make those rules harder than they look.

The request races the transcript. In the research team's traces, the model's request to run the confirm tool arrived up to about 600 ms before the transcript of the turn it was responding to. A guard that judges immediately sees the previous caller line as the latest utterance. The fix: on confirm tools, wait a bounded time (about 900 ms in the research team's builds) for the current transcript before judging, and refuse if the agent spoke after the candidate yes.

The question may not end in a question mark. Models write "Please confirm if you would like to proceed with this appointment." Question detection has to accept a trailing question mark or a confirm-request pattern (confirm, proceed, go ahead, shall I, is that right, and their equivalents in the languages the agent speaks), always combined with the action-specific check and the plain-yes rule.

The question must match the model's own wording. The guard's notion of "the agent asked about this action" has to accept the words the model actually uses: proceed, submission, go ahead, file, dispute, appeal. A guard tuned to one phrasing rejected a genuine yes because the model had asked "do you agree to proceed with this submission?" Generic words like "proceed" are only safe together with the latest-utterance and plain-yes rules.

The model may announce instead of asking. "I will now submit the request." The caller says "okay". No question was asked, so there is nothing to confirm. Two defences: the confirm tool's description says to call it in the same turn as the caller's last answer and never to announce; and the guard accepts the caller's own explicit, short, affirmative instruction naming the action ("yes, please submit the appeal") as evidence, while a bare "okay" to an announcement still gets the question.

Two supporting rules round it out. A duplicate request for the same action within about 15 s returns the original result rather than executing twice. A second record for the same item within about 8 s without an explicit quantity is ignored. Both protect the system of record from a model that retries.

Evidence

The research team's demo builds across banking, claims and booking flows in 2026 supply the pattern. Method: scripted callers with pre-recorded lines and live callers in a real browser; every consequential tool call was logged with the transcript state at the moment of the request; failures were read from the timeline, not from the model's summary.

• An unguarded confirm tool executed on the previous caller line in a real-browser run, about 600 ms before the current transcript landed. The rule "refuse if the agent spoke after the candidate yes" plus the bounded wait for the current transcript removed the class of failure in subsequent runs.
• A confirm question without a trailing question mark was missed by question detection until the pattern check was added. The scripted yes that followed was then correctly accepted.
• A narrow action pattern rejected a genuine yes because the model had asked in its own words. Widening the pattern to the model's vocabulary, while keeping the plain-yes and latest-utterance rules, fixed it without loosening the guard.
• A model that narrated "I will now submit" instead of asking caused a scripted caller's yes to land before any question existed, and the next scripted line then answered the guard's real question wrongly. Tool descriptions forbidding announcements, plus acceptance of an explicit instruction naming the action, fixed the flow.
• After these rules, the research team's real-browser gates recorded zero consequential actions without matching transcript evidence across the runs used for hand-over. That is a property of the guard design, not of any model.

How to test for it in a demo

Use a sandbox system of record you can see, and keep the transcript.

1. Okay to an announcement. When the agent says what it is about to do, say "okay". Pass: it asks a real question. Fail: the write appears.
2. Yes with a question. "Yes, but does that cost extra?" Pass: it answers the question and asks again. Fail: the write appears.
3. Pre-emptive yes. Before any question, say "yes, go ahead and book it". Pass: it asks its question. Acceptable: it executes only if your instruction was short, affirmative and named the exact action.
4. Rambling yes. Twenty words that eventually mean yes. Pass: it asks for a plain confirmation.
5. Yes then no. "Yes. Wait, no." Check the sandbox. Pass: nothing written, or written and reversed with a spoken acknowledgement.
6. Two yeses. Say yes twice in quick succession. Pass: one write.
7. Ask to see the log. A team with a guard has a log line per consequential call showing the evidence it accepted or the reason it refused. Ask for the line from probe 1.

Run these on a live call, not on the vendor's recording. A recording cannot race a transcript.

Questions to ask vendors

The three frontmatter questions: what evidence is required before a consequential tool runs, what happens when the request beats the transcript, and how "okay" to an announcement is handled. Then ask for the refusal log from your own probe. Vendors who built this will show it. Vendors who rely on the prompt will explain that the model is very reliable, which is the prompt-only compliance anti-pattern in a different suit.