Checking what the Bot claims before it is sent

Overview

A classic problem with AI support is the Bot saying it did something it did not do: "I've booked you for tomorrow at 2pm", when the calendar refused that slot — or when the calendar was never even called. The customer walks away trusting something that does not exist, and the team only finds out later, when the customer shows up at the door.

The platform now runs a final check before the reply is delivered. It works like this:

1. The Bot writes the reply.
2. Before sending, the platform compares what the reply claims with what that turn actually executed (which actions ran, and whether they succeeded).
3. If the reply claims a result that does not hold up, that claim is removed and replaced with a neutral line saying the Bot will confirm and get back.
4. The rest of the message is preserved — the conversation continues normally.

Two other things changed alongside it:

• Failures of internal actions become a private note in the conversation, so the team can see what broke.
• The Bot's content filters now apply to every output — text, audio and buttons — not just the written message.

Read the limits section before you tell the team about this. It does not make the Bot infallible. It can still be wrong; what the platform does is take down the claim that does not hold up.

Prerequisites

• Maestro enabled and a Bot configured on the inbox handling the conversation.
• The per-module tools the Bot uses (calendar, tasks, payments, catalog, contact records…) must be enabled — their result is the reference the check compares against.
• Administrator permission to review the Bot configuration and the content filters.
• Someone responsible for the conversation (assigned agent or team) to receive and act on the private note.
• There is no switch to flip: the check is automatic and runs on every Bot reply.

Step by step

The check happens on its own. The steps below are for you to observe and validate that it is working in your operation.

1. Open a conversation handled by the Bot that involves a concrete action (booking, charging, creating a task, registering an order).
2. Read the message delivered to the customer. If the Bot tried to claim a result that did not happen, in its place you will see a line saying it will confirm and get back — instead of "done".
3. Open the conversation's private notes. Failures of internal actions are recorded there, with an indication of what did not work.
4. Fix the cause. It is usually one of these: a disabled tool, a credential/integration that is down, a required piece of data missing (time, amount, document), or a module rule blocking the operation.
5. Redo the action manually if the customer is waiting, and reply confirming it.
6. If the same point keeps failing, adjust the Bot's instructions or enable/fix the corresponding tool.

Settings & options

About the private note: it is internal by nature. Customers never see private notes on any channel — not on WhatsApp, not by email, not in the website chat. It shows up only for your team, inside the conversation.

About the content filters: if you configured the Bot to avoid certain terms, promises or formats, that rule is now applied to the audio reply and to button/list options as well. Before, a button option could slip past a filter that only covered text.

Use cases

• Calendar: the Bot tries to book, the slot is already taken, and the reply would claim "booked". The claim goes away, the follow-up line takes its place, and the team gets the private note to reschedule.
• Payment: the charge was not created because of a missing tax detail. The customer does not get a "link sent" that never arrived; they get a note saying confirmation is coming.
• Task / human handover: the Bot would say "I've escalated you to a specialist", but the handover failed. Without the check, nobody would know — with it, there is a trail in the conversation.
• Catalog / order: the item could not be added. Better an "I'll confirm" than a ghost order.
• Auditing: when reviewing conversations, failure private notes show where automation breaks most often.

Tips, limits & best practices

This is the most important part of the article. Set expectations with your team using exactly these terms — promising more than the platform delivers destroys trust at the first exception.

The check recognizes the most common shapes of a claim, not all of them. It spots the usual ways of saying "I did it" — "booked", "created", "registered", "sent", "cancelled" and close variations. A sentence written in an unusual, indirect, very long or roundabout way may slip through.

It does not stop the Bot from being wrong. The check does not fix reasoning, does not validate real-world information and does not guarantee the answer is correct. It does one thing: it removes the claim of a result that does not hold up against what that turn executed.

Do not describe it as "the Bot can no longer make things up". That is not true. The Bot can still state something incorrect and have the sentence go through. Describe it as: "the platform removes the most common claims of a completed action when the action did not happen".

Other limits, equally honest:

• The check looks at the current turn. A claim made in an earlier reply is not reviewed retroactively.
• The reference is what the turn's tools did — not the overall state of the system. If the action happened through another path (an agent did it by hand at the same moment, or a slow process only finished afterwards), the Bot may still be corrected "unnecessarily".
• The removal is surgical: the claim goes out, the neutral line comes in. The resulting text can read slightly dry — which is better than a false promise.
• The private note does not replace monitoring. It is a trail inside the conversation, not an alert dashboard.
• Content filter and reply check are different things: the filter deals with what must not be said; the check deals with what must not be claimed as done.

Best practices:

• Treat private notes as a work queue: a recorded failure means a customer is waiting.
• Actually enable the tools the Bot needs to use. A disabled tool produces exactly the scenario the check corrects — and frustrates the customer all the same.
• For sensitive actions (money, cancellation, contact data), combine it with human approval. The check is the last net; approval prevents the problem earlier.
• Review failure private notes weekly to find the point that breaks the most.

Troubleshooting

• "The customer got 'I'll confirm and get back', but the action worked": the action probably completed outside the turn (more slowly, or through another path). Confirm it in the corresponding module and reply to the customer; nothing needs to be undone.
• "The Bot claimed something that did not happen and the sentence went through": this is a known limit — the wording fell outside the recognized shapes. Save the excerpt, adjust the Bot's instructions to be more direct at that point and, if possible, turn that step into an action with approval.
• "The customer saw an internal remark": a private note is never delivered on any channel. If the customer received the text, it was sent as a normal message, not as a note — review who replied and how.
• "The audio said something different from the text": filters now cover audio too. If you find a difference, record the example and review the Bot's instructions and filters.
• "A button option I had banned showed up": filters now apply to buttons/lists. Confirm the term is actually in the Bot's filter configuration, and not only in the written instruction.
• "I cannot find the private note": confirm you are looking at the right conversation and that your profile can see internal notes on that inbox.

See also

• Turn verification and holding the reply
• Automation triggers about the AI (Maestro)
• What Maestro AI and the Account Brain are
• Bot autonomy modes and human approval (HITL)
• Maestro tools by module
• Generative copilot: propose, confirm and execute
• Replying, private notes and mentioning teammates