The Customer.io AI Agent Will Happily Ship a Re-engagement Campaign To Your Suppressed List. Five Things To Lock Before You Let It

In November 2022, a man named Jake Moffatt visited Air Canada's website to book a flight home. His grandmother had just died. The airline's support chatbot told him he could claim a bereavement discount after travelling and apply for the refund later. He bought the ticket, flew, and submitted the claim.

Air Canada refused. The chatbot had been wrong. The actual policy, sitting one click away on the same website, said bereavement refunds had to be applied for before the flight.

Moffatt took it to the British Columbia Civil Resolution Tribunal. In February 2024, the tribunal ruled. Air Canada's defence was striking: the chatbot was, in the airline's words, "a separate legal entity" responsible for its own statements. The tribunal disagreed. Air Canada owned the website. Air Canada owned the bot. Air Canada owned the bad advice. The airline was ordered to pay CA$812.02 in damages.

The fee was nothing. The precedent was everything. If the thing on your website tells your customer something, you said it.

Now read that sentence with the Customer.io AI Agent in mind. Because it isn't sitting on your support page suggesting refund policies. It's inside your messaging platform, with permission to read segments, draft journeys, and schedule sends.

The Agent shipped in April 2026 in what Customer.io called the largest product release in its history—eight new capabilities, with the Agent at the centre. It's a step-change in marketer productivity, and the post you're reading isn't anti-Agent. It's pro-guardrail. The Agent will save your team hours. It will also, if turned loose without setup, do confident, plausible, expensive things you didn't ask for. Below are the five settings to lock on day one, the smallest viable approval workflow that won't slow you down, and the prompt patterns that produce useful drafts instead of half-finished journeys.

What the Agent actually does, and what it doesn't ask you first

The Customer.io AI Agent is a conversational interface inside the platform that can read your workspace data and execute against it. Customer.io describes it as having "persistent memory," "end-to-end execution," and "compounding intelligence" across sessions. In practice that means three working modes.

The first is build. Ask the Agent to create a re-engagement journey and it will pick a segment, draft the content, set the cadence, and lay out the workflow logic in a single conversation. The product page calls this going "from a prompt to a fully launched campaign." The release notes go further: the Agent "won't give you a generic template" but will "review your existing inactive segments, analyze your engagement data, and propose a solution grounded in your actual setup."

The second is edit. The Agent can iterate on an existing campaign without rebuilding it from scratch, including swapping triggers without starting over.

The third is analyse. Ask it how a journey is performing and it surfaces comparisons, flags underperformers, and recommends what to do next, without you opening a dashboard.

This is not the same surface as LLM Actions, which are a different surface that fires at runtime inside a journey. LLM Actions are decisioning steps the journey calls per profile. The Agent is the marketer-facing collaborator that builds the journey in the first place. They're complementary. They're not interchangeable. And they sit alongside Goals, which shipped in the same April 2026 release as the new outcome layer for measuring whether what you built actually worked.

So what doesn't the Agent ask you first? Three things, primarily. It doesn't ask whether the segment it picked is the right segment. It doesn't ask whether your suppression logic, often managed outside Customer.io, would have excluded those people. And it doesn't ask whether the broadcast size it's about to schedule would damage your sender reputation. Those are the cracks the guardrails below close.

The five guardrails every Customer.io account should lock first

1. Audience scope: restrict Agent-built campaigns to a sandbox segment until reviewed

Create a segment called something like agent_sandbox, give it a hard cap on size, and require that every Agent-built campaign points at that segment until a human re-targets it.

Why? Because the Agent reads your real segments. It is, by design, ready to use them. The smallest prompt error—"build a re-engagement journey for inactive users"—aimed at the wrong inactive segment will queue thousands of sends to the wrong people. The sandbox is a circuit-breaker between the Agent's confidence and your actual list.

You can build the sandbox the same way you'd build any other segment in advanced Customer.io segmentation. The size cap matters more than the membership rules. Two hundred profiles is plenty for a draft review. Two hundred thousand isn't a sandbox, it's a launch pad.

2. Suppression alignment: the Agent does not honour informal exclusion logic from another tool

If you maintain a suppression list in your CDP, in a Reverse-ETL warehouse, or in an analytics tool, and that list is not also a segment or a profile attribute inside Customer.io—then the Agent doesn't know it exists. It will read the Customer.io workspace, see those profiles are eligible, and target them.

This is the failure mode the headline describes. The Agent will happily ship a re-engagement campaign to your suppressed list. Not because it's careless. Because it's working from the workspace data it can see, and "do not contact" lives somewhere it can't.

The fix is to mirror every meaningful suppression source as a Customer.io segment or attribute the Agent will respect. Take your three most-used suppression sources—the unsubscribe table, the bounce list, the legal-hold list—and confirm each one is reflected in Customer.io. Then layer your suppression and frequency management rules on top so the Agent's drafts inherit your fatigue logic by default.

3. Send-volume cap: hard-cap broadcast size below your engaged-30d count

Define a workspace rule that no Agent-built broadcast can target more than your engaged-30-day segment. The exact number depends on your list, but the principle holds: the Agent has no concept of "this send would damage our sender reputation." Hard caps prevent the polite version of a Knight Capital incident.

(In 2012, Knight Capital pushed faulty trading software to one server out of eight and the live algorithm ran for 45 minutes before anyone caught it. Loss: roughly $440m. The lesson isn't "AI is dangerous." It's "automation without circuit-breakers compounds errors at machine speed.")

For lifecycle teams, a single oversize Agent-built broadcast to disengaged subscribers can torch the sender reputation you've spent months building. The cap doesn't have to be sophisticated. It needs to exist.

4. Draft-only role: use Customer.io roles so the Agent saves to draft, never sends

This is the single highest-leverage guardrail in the list.

Customer.io has a roles and permissions model. Use it. Give the Agent's operating user a role that can build, edit, and save—but cannot start a campaign or send a broadcast. The Agent does its work. The output lands in drafts. A human approves, schedules, and launches.

Everything else in this list is a safety net. This one is the actual switch.

5. Campaign-naming convention: prefix all Agent-built campaigns so audit logs are filterable

Every campaign the Agent builds should start with a fixed prefix. agent- works. [AI] works. The shape doesn't matter, the consistency does.

Why? Because when something goes wrong—an unintended send, a draft that escaped review, a Liquid block that rendered blank—you need to filter the audit log to "everything the Agent touched in the last 24 hours" in one query. If Agent-built campaigns blend into your existing naming, that filter becomes a manual review of every recent change.

Set the convention before the Agent ships its first campaign. Write it into the prompt template ("name this campaign agent-<purpose>-<date>"). The Agent is happy to follow naming rules. It's just not going to invent one for you.

The smallest viable approval workflow

Don't build a workflow with eight reviewers and a Jira ticket. The whole point of the Agent is that it removes the slow steps. Pile review on top and you've recreated the bottleneck in a different colour.

One reviewer. Fifteen-minute checklist. Ship.

The checklist:

1. Target segment—is it the one you'd have picked?
2. Suppression—did the Agent honour your exclusions?
3. Send window—right timezone, right cadence?
4. Copy—two-pass read for tone and accuracy?
5. Kill-switch—saved as paused, not scheduled?

If the reviewer can't get through the checklist in 15 minutes, the campaign is too complex for the Agent to have built unsupervised. Send it back for a tighter prompt.

A holdout group on the campaign is a free upgrade. Customer.io reduced holdout testing to a checkbox on every A/B test flow, so there's no engineering effort to add one. Tick the box. You'll thank yourself in three months when finance asks whether the Agent-built campaigns actually drove revenue.

Prompt patterns that produce useful drafts vs ones that produce trouble

Good prompts are specific. They tell the Agent the segment, the goal, the channel, the cadence, and the constraint. Bad prompts ask the Agent to make commercial decisions you should be making yourself.

Good prompt:

Build a 3-email re-engagement campaign targeting the segment agent_sandbox (cap 200), goal: clicked at least once in the last 7 days. Channel: email only. Cadence: day 0, day 3, day 7. Use Human Clicked as the success metric, not email_opened. Exit on conversion. Save as draft, prefix the campaign name with agent-.

That prompt produces a draft you can review in 15 minutes. It defines the segment, the goal, the channel, the metric (more on that in a moment), the exit condition, the save behaviour, and the naming convention. The Agent is constrained to the structure you wanted.

Bad prompt:

Build a re-engagement campaign for inactive users.

Three problems. "Inactive users" is undefined, so the Agent picks a segment. "Re-engagement" is undefined, so the Agent picks a goal. There's no channel, so the Agent picks channels. You end up reviewing an Agent-defined commercial decision wrapped inside a draft, and the draft looks confident, so it slips through.

A note on metrics. If your good prompt asks the Agent to branch on "email opens," the journey will fire for most of your list whether they read the message or not. That's because Apple Mail Privacy Protection pre-fetches the tracking pixel for every Apple Mail recipient. The fix is to use Human Opened and Human Clicked, which Customer.io introduced for this problem. Specify the right metric in your prompt or the Agent will use what it finds.

One more note. The Agent writes Liquid. Liquid breaks silently when a property goes null. Before approving any Agent-built campaign, run the Liquid through the QA pattern that catches the six silent-failure modes. The Agent isn't worse at Liquid than a human. It's not better either. Treat its output the same way.

Your first 30 days with the Agent

Don't roll the Agent out across the team in week one. Stage it.

Week 1: read-only. Use the Agent for analysis prompts only. "How did the Q1 onboarding sequence perform?" "Which broadcast last month had the lowest engaged-click rate?" Get a feel for what it can see and what it gets right.

Week 2: drafts only. Let it build. You review and edit before saving. Don't approve anything to launch yet. Watch which prompts produce clean output and which ones produce noise.

Week 3: supervised launch. One reviewer, one campaign, one segment. Use the sandbox. Use the kill-switch. Ship a single Agent-built campaign end-to-end and see what breaks.

Week 4: approved patterns. Lock in three prompt templates the team can use without case-by-case review. These become the house style for Agent prompts. Update them quarterly.

That's it. By the end of week four, the team has a working sense of the Agent's strengths and the kinds of campaigns it's safe to delegate. The five guardrails stay in place. The approval workflow stays in place. The Agent gets more leverage, not less supervision.

Frequently asked questions

Q: Is the Customer.io AI Agent the same as the MCP server or LLM Actions?

No, they're three separate surfaces. The AI Agent is the conversational interface inside the Customer.io UI that builds and analyses campaigns on your behalf. LLM Actions are runtime steps inside a journey that call a model per profile to generate content or branch on inferred intent. The MCP server is a connector that lets external tools, like Claude or other AI clients, read and write to Customer.io from outside the platform. The Agent is the marketer-facing collaborator. LLM Actions are decisioning steps. MCP is integration plumbing.

Q: Can the Agent send a broadcast on its own?

Yes, if the user role it operates under has send permissions. Strip those permissions and the Agent can build and edit but not launch. This is Guardrail 4, and it's the single most important setting in the list. The Agent's default behaviour is to execute, which is what makes it productive. The role boundary is what makes it safe.

Q: Does the audit log show what the Agent did?

Yes. Every Agent action is attributed to the operating user in the workspace audit log. The prefix convention in Guardrail 5 makes those entries filterable. Without the prefix, you can still find Agent-built campaigns, but you'll be searching by user account and timestamp instead of campaign name, which is slower in an incident.

Q: How do AI credits get used when the Agent works in the background?

LLM Actions consume AI credits at runtime, billed per call. The Agent itself uses credits when it invokes LLMs to reason about your workspace data and generate content. Every paying Customer.io account receives a one-time grant of 100,000 credits, valid for 90 days from the date of becoming a paying customer. Additional credits cost $10 per 100,000. Treat credit burn as a separate budget item from your normal Customer.io subscription.

Q: Can I scope the Agent to a single workspace or environment?

Yes. The Agent operates inside whichever workspace it's invoked from. Use a staging workspace for Agent experimentation before granting access to production. Many teams use this pattern for everything from Liquid template QA to broadcast review.

Q: How do I roll back a campaign the Agent built?

The same way you'd roll back any campaign: pause it in the campaign view, or delete the draft if it hasn't been launched. The Agent doesn't create irreversible state. What it can do is queue a send before you notice, which is why the draft-only role in Guardrail 4 matters. If the role is set correctly, rollback is "delete the draft." If it isn't, rollback is "explain to legal why your suppression list got messaged."

Q: Does the Agent honour suppression lists imported from Reverse-ETL?

Only if the suppression data is materialised as a segment or profile attribute inside Customer.io. The Agent reads the Customer.io workspace. It does not query your warehouse, your CDP, or your downstream tools. If your suppression logic lives outside CIO, mirror it in CIO before granting the Agent build permissions.

Q: Does Customer.io use my workspace data to train its models?

No. Customer.io's own announcement states that data sent to hosted models is not used for training. That's the vendor position as of April 2026. Verify the current contract terms if you're in a regulated industry where this matters legally.

Q: What happens if the Agent picks the wrong segment?

If Guardrail 4 is in place, nothing—the campaign sits in draft until a human reviews it. If the draft role isn't set, the campaign can ship to whoever the Agent targeted. This is why the sandbox segment in Guardrail 1 matters as a second line of defence. Even a misfired send to the sandbox only reaches a capped number of profiles.

Q: Can I see exactly what the Agent did in a given session?

The workspace audit log shows the actions taken. The Agent's reasoning—the prompt, the chain-of-thought—is visible in the Agent conversation pane during the session. Customer.io's product description says the Agent has "compounding intelligence" with persistent memory across sessions, so context from previous conversations does influence later ones. If you need a clean slate, start a fresh session.

Q: Do I need the Agent if I already use LLM Actions?

They solve different problems. LLM Actions decide things at runtime for each profile. The Agent helps you build the journey in the first place. If your team is small and you're already comfortable building journeys manually, the Agent's payoff is faster builds and easier edits. If you're building lots of similar journeys, the Agent will save you more hours per week than LLM Actions will save you in personalisation lift. Most teams will end up using both.

Q: Will the Agent send to my suppression list if it's stored outside Customer.io?

Yes, unless you've reflected that suppression as a Customer.io segment, attribute, or exclusion rule. The Agent has no view into your CDP, your warehouse, or your other tools. This is the failure mode in the title of the post, and it's the most common reason teams get burned. Audit your suppression sources before the Agent ships its first campaign.

Sources

• Customer.io's biggest product release: AI Agent and more — Customer.io, April 2026
• AI Agent product page — Customer.io, 2026
• Use Customer.io with AI — Customer.io Docs, 2026
• AI Credits documentation — Customer.io Docs, April 2026
• Deploying agentic AI with safety and security: A playbook for technology leaders — McKinsey, 2025
• Understanding AI agents: New risks and practical safeguards — IAPP, November 2025
• Air Canada found liable for chatbot's bad advice — CBC News, February 2024
• BC Tribunal Confirms Companies Remain Liable for Information Provided by AI Chatbot — American Bar Association, February 2024
• Knight Capital Group Form 8-K, August 2012 — SEC, August 2012