Turn verification and holding the reply

Overview

Between the moment the Bot finishes writing and the moment the contact receives the message, there is now a checkpoint. It runs on every delivery path — text, voice, and also the tools that talk to the contact directly — and does two things:

1. It checks the surface of the reply. Leaked internal markup, phrases and personal data blocked in the configuration, the wrong language, unresolved template fields ({contact.name}, [NAME]), a link/phone/price that appears nowhere in what the account has on record nor in what that turn looked up, a near-identical repeat of the previous message, and size caps.
2. It reconciles what the reply claims with what the turn executed. If the message says "I've booked you" and the calendar tool never ran — or ran and failed — the claim does not hold up.

When something is caught, the platform has a ladder of reactions, from lightest to heaviest:

Read the limits section before presenting this to your team. This layer does not make the Bot incapable of being wrong. It removes the most common forms of "I already did it" when the doing never happened — and there are ways of writing that get past it.

Prerequisites

• Maestro enabled and a Bot configured on the inbox.
• The per-module tools the Bot uses must be enabled — their execution is the evidence reconciliation compares against. No execution, nothing to compare with.
• Account records up to date (products, prices, domains, teams). That is what makes a fabricated link or price recognizable; whatever is not on record tends to be treated as fabricated.
• Administrator permission to change the Bot's hold policy.
• To hold: somebody on duty to approve. With nobody watching the queue, holding is the same as not replying.

Step by step

The check is automatic and has no on/off switch. What you configure is the hold.

1. Open the Bot configuration (the Maestro agent) used by the inbox.
2. Find "Hold the reply for human approval".
3. Pick one of the three options (detailed in the next section). The default is Always deliver.
4. As soon as you move away from "Always deliver", the screen shows a highlighted warning: while the reply is held, the contact waits. Read it before saving — that is the real cost of the option.
5. Save.
6. To follow up: a held reply creates a private note on the conversation and enters the approval queue in the Maestro panel, alongside the other approvals.
7. When reviewing you can approve (the reply goes out exactly as it was), edit and send (your version goes out) or reject (nothing is sent; the conversation can optionally be handed off to a human).

Settings & options

The three hold options

What "hold" means, without euphemism: while held, the message does not exist on any channel. The contact sees no typing indicator, gets no notice, receives nothing — they see silence until somebody approves. If the hold happens at 7pm and the queue is only checked at 9am, the contact waited all night.

That is why the default is Always deliver, and why the warning appears the moment you change the option. Turn holding on when:

• somebody is on duty watching the approval queue during the hours the Bot answers; and
• the cost of a wrong claim is higher than the cost of the delay (money, health, legal, calendar commitments).

If you have nobody on duty, the most balanced combination is usually Always deliver plus the automation trigger Reply claimed an action that never ran alerting a supervisor. The contact does not wait, and someone chases the damage within minutes.

What the check hands back to the conversation

• The delivered message already comes corrected (sentence deleted, fabricated token removed).
• Internal failures become private notes — they never reach the contact.
• The automation triggers about the AI let you react automatically (label, assign, alert). See the article under "See also".

Use cases

• Clinic / provider with a full calendar: "Hold when the reply claims something the turn did not do", with the front desk watching the queue during business hours. The patient never receives an appointment that does not exist; on every other message the reply is immediate.
• Billing and payment links: same option. A payment link claimed but never generated is the kind of mistake that produces support tickets, not sales.
• 24h operation with no night shift: Always deliver. Holding overnight protects nobody — it turns a rare mistake into guaranteed silence.
• New Bot, first week in production: some teams switch Hold every reply on for a few days, with one dedicated person, purely to calibrate tone and instructions. It is expensive and does not scale; use it as a trial period, not as a permanent setting.
• Account with lots of branded content (links, prices): keep the records up to date before enabling holds, otherwise you will be manually approving correct replies whose legitimate link simply was not on record.

Tips, limits & best practices

This is the most important section of the article. Use these words with your team — promising more than the platform delivers costs more than the gap the promise would hide.

Do not describe this as "the AI can no longer hallucinate". That is false. The Bot can still assert something wrong, and can still do it in a way that gets past the check.

Reconciliation is lexical. It recognizes ways of writing, not meaning. The patterns cover the direct, first-person way of saying something was done ("I've booked", "it's scheduled", "I created", "I sent the link") in Portuguese, English and Spanish. Paraphrase escapes. An indirect sentence, a roundabout one, a very long one, passive voice, or an unusual phrasing gets through reconciliation — including when it asserts exactly the same thing.

This is a design choice, not a bug to be fixed later: the false-positive limit is hard. Sentences in the future tense and questions ("can I book you for tomorrow?", "I'll check and confirm") never trigger a claim, because deleting those would break legitimate conversations all the time. The price of that safety is precisely the lower recall.

Other limits, equally honest:

• Seven families of claim are recognized: booking, record created, document sent, payment link, handoff to a human, price quoted and promised follow-up. Outside those seven, there is no reconciliation at all.
• The reference is the current turn, not the state of the system. If the action happened by another route (an agent did it by hand at the same moment, or a slow process finished afterwards), the reply may be corrected "unnecessarily".
• Deleting the sentence is not rewriting. What remains can read dry. Better than a false promise, but do not expect elegance.
• Fabricated links and prices depend on what the account has on record. A legitimate domain that is not on record may be removed by mistake until you add it — that is an expected false positive, and the fix is to add it.
• The check does not validate real-world facts. It does not check whether the information is correct, whether the reasoning makes sense, or whether the policy the Bot quoted exists. It verifies one thing only: whether the reply asserts a result that the turn does not support.
• Holding does not fix what got through. If the claim was written in a way reconciliation does not recognize, the "Hold when the reply claims something the turn did not do" option holds nothing — the reply goes out normally. Anyone who wants a total barrier needs "Hold every reply", with the cost that carries.
• Redo is limited to once per turn. A turn that was already corrected and fails again is softened or held, not redone indefinitely.

Best practices:

• Treat failure private notes as a work queue: a logged failure is a contact waiting.
• Actually enable the tools the Bot needs. A disabled tool produces exactly the scenario the check corrects — and frustrates the contact just the same.
• For sensitive actions, prefer human approval of the action (hybrid autonomy) over holding the reply — it is cheaper, because it prevents the problem before the text exists.
• Review weekly where the check acts most. Repetition at the same point almost always means an ambiguous instruction or a broken integration, not "bad AI".

Troubleshooting

• "The contact got 'I'll confirm and get back to you', but the action worked": the action probably completed outside the turn. Confirm in the module and reply to the contact; nothing needs to be undone.
• "The Bot claimed something that did not happen and it got through": known limit — the phrasing fell outside the recognized patterns. Keep the excerpt, make the Bot's instructions more direct at that point, and if the risk is high turn that step into an action with human approval.
• "I turned holding on and the contact was left with no reply": that is the documented behavior. While held, the reply does not go out. Check the approval queue; if nobody watches it during those hours, go back to Always deliver.
• "The reply came out clipped/dry": the offending sentence was deleted. If it happens often on the same topic, adjust the instructions so the Bot does not promise a result before executing it.
• "A legitimate link of ours disappeared from the message": the domain is not on the account's records. Add it and the problem stops.
• "The Bot answered in the wrong language and the message did not go out": the check treats a language mismatch as a surface problem. Pin the language in the Bot configuration if your operation is monolingual.
• "Where do I see what was held?": on the conversation, via the private note, and in the approval queue of the Maestro panel — the same place as the other approvals.

See also

• Checking what the Bot claims before it is sent
• Automation triggers about the AI (Maestro)
• Bot autonomy modes and human approval (HITL)
• Maestro tools by module
• What Maestro AI and the Account Brain are