Automation triggers about the AI (Maestro)

Overview

Platform automation has always had more than a hundred triggers — conversation created, label changed, order paid, contract signed — and none about the Bot. You could automate on almost anything except the event that matters most to anyone running AI-assisted support: the Bot claiming an action it never executed.

There are now five triggers about the health of an AI turn. They appear in the same Automation screen you already use, with the same catalog of actions (assign, label, private note, priority, status, webhook…).

All five are reaction, not prevention: they alert and organize work after the fact. To stop a doubtful reply from reaching the contact, the mechanism is a different one — holding the reply, in the turn-verification article (under "See also").

Prerequisites

• Maestro enabled on the account and a Bot configured on the inbox handling the conversation.
• Administrator permission to create and edit automation rules.
• The per-module tools the Bot uses must be enabled — their execution is what produces the "failed" and "claimed without executing" signals.
• An owner (agent or team) to receive whatever the rule dispatches. A trigger with no recipient is just noise.
• Nothing else to provision: the events come from the Maestro service itself. On an account without Maestro the rule simply never fires — it stays inert rather than erroring.

Step by step

1. In Settings → Automation, create a new rule.
2. Give it a clear name — names like "AI claimed a booking" save minutes of investigation later.
3. For the trigger, pick one of the five "Maestro —" events in the list.
4. There will be no filters to choose. That is expected and explained in the settings section below. The rule applies to every occurrence of that event on the account.
5. Pick the actions. For these triggers the most useful ones are usually:
   • Add label (e.g. review-ai) — cheap, silent, and lets you measure volume before turning on notifications;
   • Add private note mentioning the supervisor — the mention fires the native notification;
   • Assign to a team and change priority;
   • Change status (for example, un-resolve when the turn failed);
   • Webhook, if you track this on an external dashboard.
6. Save and leave the rule active.
7. After a day of operation, filter the conversation list by the label the rule applies. That is your volume thermometer before escalating to notifications.

Settings & options

Filters (conditions): not available yet for these five triggers

When you pick one of these triggers, the conditions area stays empty. That is a deliberate decision, not a missing field: the turn-specific information (verdict, which tool failed, severity) travels in the event, but there is still no server-side matcher that can compare it. Offering a filter field that would in practice match everything is worse than offering none — it would look like it works and it would not.

Practical consequence: the rule fires on every occurrence. Size the action accordingly. Start with a label, measure, and only then add notifications or assignment.

Available actions

The full conversation action catalog works, because the event resolves to the conversation where the turn happened.

Be careful with "send a message" on these triggers. These are events about an internal failure. Sending the contact an automated message when the Bot stumbled usually makes things worse. Prefer private note, assignment, label and priority.

What the event does not carry

For privacy, the event carries only identifiers and the kind of occurrence. Reply text, tool arguments and the prompt never travel. You cannot (and will not be able to, from here) print the reply content in an automated note — to read what was said, open the conversation.

One name, two meanings

There is a notification called "Maestro Approval" (approval of a Brain department run) that internally uses wording similar to the Handoff to a human requested trigger. They are different things in different places: one is a Brain notification, the other is an automation rule trigger. If you look for one on the other's screen, you will not find it.

Use cases

• Supervisor alerted when the Bot claims a booking that never happened — trigger Reply claimed an action that never ran → private note mentioning the supervisor + assign to the scheduling team
  • high priority + label review-ai. This is the classic case: the contact leaves believing they have an appointment, and somebody needs to call before they show up at the door.
• Contact left hanging — trigger Turn failed without replying → assign to a human immediately and set the status to open. The urgency here is higher than in the other four: nobody answered at all.
• Handoff queue — trigger Handoff to a human requested → assign to the right team and set priority, so the Bot's request does not die in an unowned conversation.
• Broken integration surfacing early — trigger Tool call failed → label tool-failed. Three days later the label shows which module is failing most often (expired credential, missing required data, module rule blocking the operation).
• Weekly quality review — trigger Reply altered by verification → label only. Expect this to be the noisiest of the five: every cosmetic correction counts. Use it as a Friday reading sample, not as an alert.

Tips, limits & best practices

• These triggers prevent nothing. They react afterwards. When you need the reply not to go out, the path is holding for verification or human approval — not an automation rule.
• Start with a single rule. Five rules with notifications, all switched on the same day, produce five times more noise than the team can read — and the natural reaction is to turn everything off.
• Label first, notify later. It is the cheap way to learn your operation's real volume before committing someone's attention.
• No filters means no exceptions: you cannot restrict the rule to one inbox, one time window or one kind of verdict. If you need a slice, it has to happen when reading (via the label), not in the rule.
• Nothing is written to a table of its own by these events: they route the signal into automation. The durable turn record lives in Maestro. In other words: if you create no rule, the event passes and leaves no trace in the automation area.
• Failures are isolated per rule: if one rule's action breaks, the other rules on the same event keep running.
• Combine with human approval on sensitive actions (money, cancellation, records). The rule is the safety net below; approval prevents the fall.

Troubleshooting

• "I created the rule and it never fires": check, in this order — the rule is active; the inbox has a Bot answering; Maestro is enabled; and the event actually happened. A turn that goes well produces none of the five — silence can be good news.
• "It fires too much": expected behavior while there are no filters, especially on Reply altered by verification. Switch to a cheap action (label), or turn that specific trigger off and keep the other four.
• "I cannot find the filters/conditions": they do not exist yet for these five triggers. It is documented above — it is not a problem with your account.
• "The contact received a strange message": one of these rules has a send message action. Replace it with a private note.
• "The private note showed up for the customer": private notes are not delivered on any channel. If the text reached the contact, it went out as a normal message — review the rule's action.
• "I want to know exactly what the AI said": the event does not carry the text. Open the conversation and read the delivered message and the private notes.

See also

• Automation rules: triggers, conditions and actions
• Turn verification and holding the reply
• Checking what the Bot claims before it is sent
• Bot autonomy modes and human approval (HITL)
• Maestro tools by module