Someone Told Your Scheduled Agent to Stop. Why Does It Keep Messaging Them?

An opt-out is the clearest instruction a contact can give. Stop. Do not message me again. And yet scheduled agents keep messaging people who already said it. Not because anyone told the agent to ignore them. Because nobody told the agent, in a place the next run would actually read.

Where the opt-out gets lost

Each run loads its instructions, pulls its list, and sends. Anything outside that load path might as well not exist. Opt-outs usually fail in one of four ways.

First, the opt-out lives in a channel the agent never reads. Someone replies "stop" to a text, and the email sequence keeps running, because the email run only checks the email list. The person opted out. The agent's list did not hear about it.

Second, the opt-out lives as a note, not a rule. A human marks it in a CRM comment or a spreadsheet cell, and the agent's prompt never asks about that field. Notes are for people to read. Runs need structured facts they can check: who, which channel, when, and what scope.

Third, the list gets rebuilt and the opt-out gets washed away. A fresh export from the CRM, a re-imported audience, a new segment built from an old snapshot, and suddenly the suppression is gone. The agent did nothing wrong by its own lights. It sent to the list it was given. The list was stale.

Fourth, a new run, tool, or workflow starts without the history. The follow-up agent is not the newsletter agent. The support check-in agent is not the sales agent. If each one keeps its own memory, an opt-out honored by one is invisible to the others, and the contact hears from the one that never learned.

Make the no the first thing every run reads

The fix is to treat suppression as a first-class memory, not an afterthought. It should be the first check in the run, not a filter applied at the end if someone remembers. Concretely, that means five habits.

One, capture the opt-out the moment it arrives, in every channel. A reply, a form, an unsubscribe click, a "please stop calling" on a call: all of them land in the same shared record. If capture depends on a human copying a note from one system to another, some opt-outs will always fall through.

Two, give the suppression record a shape the agent can act on: the person, the channel, the date, and the scope. Scope matters. Opting out of a weekly newsletter is not the same as opting out of every message, and a support conversation is not a marketing list. Write the scope down when the opt-out arrives, while it is unambiguous.

Three, check suppression before building the send list, not after drafting the messages. The run should load the suppression record, remove those contacts, and only then decide what to send and to whom. A check that gates the list cannot be skipped, because there is no list without it.

Four, fail closed when the suppression record cannot be read. If the list is unreachable, malformed, or out of date, the run should pause, not send to the full audience and hope. An unsent run is a delay. A message to someone who opted out is a trust failure, and in some channels it can be a compliance problem too. Rules vary by channel and jurisdiction, so check the requirements that apply to yours, but the principle holds: when you cannot prove someone may be contacted, do not contact them.

Five, keep the suppression record even when you prune everything else. This is the one memory that gets more valuable as other memories fade. Old campaign notes can be compressed or deleted. Old preferences can expire. A do-not-contact entry should survive pruning, survive a list rebuild, and survive a tool change, because the person behind it has not changed their mind just because your stack did. Note the distinction: honoring an opt-out is not the same as deleting a person's data. Deletion removes the record. Suppression keeps exactly one fact, the instruction to stop, so the instruction keeps working.

Prove the check happened

A suppression system you cannot audit is a promise, not a control. Each run should leave a trace: which suppression record it read, how many contacts it removed, and why. When a contact complains, you can point to the run, the record, and the decision. When a run sends anyway, you can see whether the record was missing, stale, or never checked, and fix the right step instead of blaming the schedule.

Where a shared memory layer fits

All of this gets simpler when every run, tool, and workflow reads the same memory. A cloud-hosted memory layer that every agent connects to over MCP means the opt-out captured by the email run is visible to the texting run, the follow-up run, and the support check-in run, on any machine, without anyone re-keying it. The record is not trapped in one tool's notes or one run's context. It is one shared fact, checked the same way every time.

That is how Vilix AI is built to work. It is cloud-hosted, so there is zero infrastructure to manage: no database to provision, no store to babysit. Every agent connects over MCP and reads the same memory, so a suppression saved by one run is a suppression the next run sees. It stores full conversation history, not just extracted facts, so the actual opt-out exchange can be retrieved and checked. It is free to start, with a free plan that stays free forever and a 7-day Pro trial with no credit card required, and your data stays portable: export everything or delete it anytime. See the plans at https://vilix.ai/?utm_source=vilix-blog&utm_medium=article&utm_campaign=scheduled-agent-keep-messaging-unsubscribed-contacts.

The test to run this week

Pick one scheduled agent that messages people. Before its next run, send it a test opt-out through a different channel than the one it sends on. Then watch the next run. Does the suppression appear in the shared record? Does the run remove the contact before building its list? Does the log show the check?

If the answer to any of those is no, you have found the gap, and it is almost certainly in one of the four places above: the wrong channel, a note instead of a rule, a rebuilt list, or a second agent that never learned. Close that gap before you scale the automation. A scheduled agent that remembers everything except the word no is not an abstract memory problem. It is a specific failure, with a specific fix, and the people on the other end notice it first.