Every SMS broadcast goes through a Preview + Confirm modal before it actually sends. This is intentional and not optional.
Why
SMS is non-recallable. Once Twilio accepts the send, you can't take it back. So an accidental fan-out of "test test" to 25 band members at 3 AM costs you trust and Twilio dollars.
The preview-confirm dance is the safety net. You see what's about to happen, you click to confirm, then it fires.
What the preview shows
For each channel you enabled (SMS / Email):
- Ready count — how many recipients are deliverable on that channel
- Skipped count — how many will be dropped, with reason breakdown
- Sample names — the first ~8 recipients by name
For SMS specifically, skip reasons are itemized:
no_phone— no SMS channel mappedopt_in_pending— opt-in invite sent but not confirmedopted_out— replied STOP at some point
Agent-side enforcement
When the agent (via SMS) tries to broadcast, the same two-phase commit applies. The first send_comm tool call returns dry-run preview; only after you reply "yes" / "go" / "send" does the agent make a second call with confirm: true that actually fires.
This is enforced in code, not just in the prompt — the model literally can't bypass the preview no matter how confident it is.
When you can't bypass
There is no "skip preview" toggle and won't be. The brevity loss is intentional. If you're sending the same broadcast twice in a row (say, after a typo), it's still two steps each time.
For scheduled automations, the preview-confirm doesn't apply — the automation pre-vetted at create time, so each fire is one-click. See Scheduled automations.
When sends happen instantly
The CONFIRM click is what triggers the actual send. Twilio processes each SMS sequentially (one per recipient, ~200ms each), so a 30-person broadcast takes 5-10 seconds end-to-end. You'll see "sent X" on the comms card when done.
If anything fails (Twilio rate limit, recipient unreachable), the comms history row surfaces the error count.