They Already Own It. Why Does Your Scheduled Agent Keep Sending Price-Drop Alerts for It?

A customer buys a pair of running shoes at full price on Tuesday. On Thursday, the shoes go on sale. Your scheduled agent spots the price drop and sends a cheerful email: "Good news, the shoes you have been eyeing just dropped in price."

The customer already owns the shoes. They paid more than the price in the email. The alert is not just useless. It tells the customer the business has no idea what they bought, and it hands them a reason to ask for the difference back.

Nothing in the workflow failed. The schedule fired on time, the price check ran, the message went out, and the run log shows success. The failure is quieter: no run ever told the agent the purchase happened, so every run works from the shopper as they were, not from the customer as they are.

Why the purchase gets lost between runs

A scheduled agent usually reads a list, not a life story. The price-drop workflow was built around a watchlist: products a customer viewed, saved, or added to favorites, with a price attached. Each run walks that list, checks the current price, and sends an alert when the number falls. When the customer buys, that change happens somewhere else: a checkout, a payment confirmation, an order record in a different system. If the purchase never gets written back where the agent reads, the next run has no way to know the watchlist item became an order.

The second problem is timing. A customer can pay minutes before the alert job runs. If the job reads its list before the payment lands and sends after it, the alert goes out for a product that already has an owner. The list was correct when it was read and wrong when the message was sent, and nothing in between checked again.

The third problem is identity. A shopper who browsed as a guest and bought with an account, or viewed on a phone and checked out on a laptop, can look like two different people. The watchlist entry never matches the order record, so the exclusion check finds no purchase for that shopper and sends anyway.

The fourth problem is the exclusion list itself. Most price-drop setups are supposed to skip products the customer already owns. But the skip rule is usually a filter someone added once, in one place, months ago. A flow gets copied for a new campaign, a field gets renamed, a segment gets rebuilt, and the filter quietly stops applying. A workflow with no working exclusion does not stop. It just keeps alerting until someone notices the replies.

So the alerts keep coming. Not because the agent is broken, but because no run ever told it to stop.

What a purchase-aware run actually checks

A useful purchase memory is not a flag. It is a short record the next run can act on without guessing. It needs five parts.

First, the product: the exact item, not a category or a search term. A price drop on the same shoes in a different size is a different alert, and a drop on a similar model is not a drop on the one the customer owns.

Second, the buyer: one identity across devices and sessions, so a guest browse and an account purchase resolve to the same person.

Third, the purchase itself: when it happened, what was paid, and whether it was a one-off buy or a replenishable item. The distinction matters, because a price drop on coffee beans a customer buys every month is a useful reminder, while a price drop on the coffee machine they bought once is noise.

Fourth, the alert history: which price-drop emails already went out, for which product, and at which price. Without it, a customer who got one alert for shoes they own can get a second, better one for the same pair.

Fifth, the rule that stops the send: no alert for a product the customer already owns, unless the product is one they buy again. The rule has to be checked at send time, not at list-build time, because a purchase can land in between.

The run should check the purchase before it sends, not after. A re-check inside the job, right before the message goes out, catches the race condition: a payment that landed after the list was read still stops the send. And the check should look for a recent order by shopper, not just by watchlist entry, because the watchlist and the order rarely share an ID.

The tools that get this right already exclude buyers

This is not a new problem, and the established tools solve it by treating the purchase as a first-class fact. Klaviyo's price-drop flow is programmed to send only to people who have never purchased the item, at full price or at the discounted price, so no extra filter is needed. Synerise builds the same idea explicitly: its price-drop workflow creates an aggregate of recently purchased products and uses it to exclude anyone who already bought the item from the alert audience.

The pattern is the same in both cases. The purchase record is not an afterthought bolted onto the alert. It is part of the audience definition, checked every time, before anything goes out. A scheduled agent that cannot see the purchase record cannot apply that pattern, no matter how good its price checking is.

Give the agent a memory it can read every run

The fix is not a smarter price check. It is a shared record that survives between runs, so the agent that sends the alert reads the same purchase history as the store that took the payment.

That is what Vilix AI is built for. It is a cloud-hosted memory layer your agents read over MCP, so there is nothing to install, host, or maintain. The same memory follows the agent across tools and runs: the n8n workflow that checks prices, the Zapier flow that sends the email, and the support agent that answers the reply all read the same record. It stores full conversation history, not just extracted facts, so the next run can see the whole story of a customer: what they viewed, what they bought, what they were already told, and what stopped.

Getting started costs nothing. The free plan is free forever, and the Pro trial runs seven days with no credit card. And the data stays portable: export everything or delete it anytime.

A price-drop alert is a promise that the business is paying attention. Sending one for a product the customer already owns breaks that promise in public, with a price attached. The agent does not need to be smarter. It needs to remember. Once the purchase is part of what the agent reads every run, the alert goes to the people who still need it, and the ones who already bought hear nothing at all.