It Was Discontinued Months Ago. Why Is Your Scheduled Agent Still Recommending It?

A customer replies to your recommendation email with a simple question: can they still buy the product your agent just pitched? The answer is no. That product was discontinued months ago, and the replacement has a different name. Yet your scheduled agent recommended it with total confidence, as if nothing had changed.

That is not a hallucination in the usual sense. The agent did not invent a product out of thin air. It recommended something real, something your business used to sell. The problem is timing. The agent's picture of your catalog is frozen at some earlier point, and nothing in its run ever updates it.

Your agent recommends from a snapshot, not from your catalog

A scheduled recommendation agent usually works from one of a few sources. It may have a list of products pasted into its prompt. It may read a spreadsheet of bestsellers. It may pull from old support tickets, old campaign copy, or a knowledge base that was loaded once and never revised. All of those are snapshots. They describe your catalog as it was on the day someone wrote them down.

Discontinuations rarely live in those snapshots. When a product is retired, the update happens somewhere else: a status change in the catalog system, a supplier email, a merchandiser removing the item from the storefront. None of that automatically reaches the agent's prompt, its spreadsheet, or its knowledge base.

This is why the failure repeats so reliably. Each run starts from the same frozen sources, so each run produces the same stale recommendation. Fixing one email does nothing, because the next run reads the same list again. The agent simply never encounters the discontinuation.

Removing the product from your store is not enough

It feels like deleting the product page or removing the item from the storefront should settle the matter. For human shoppers, it mostly does: they cannot find what is not listed. For a scheduled agent, it does not, because the agent does not shop your storefront. It reads its own inputs.

Those inputs keep the retired product alive in several quiet ways. The prompt may still name it as a top recommendation. The spreadsheet may still carry its row, marked as a bestseller from last quarter. A knowledge base may still hold the launch announcement and the FAQ entry, all written while the product was current. Each of those is a vote for the old product, and the agent counts votes, not dates.

There is also a distinction the agent usually misses: out of stock, discontinued, and replaced are three different states. An out-of-stock product may come back. A discontinued product will not, so recommending it is a dead end. A replaced product has a successor, so the right move is to point the customer to the replacement. An agent working from a snapshot cannot tell these apart, because the snapshot never recorded the status change.

Give the agent one current catalog memory to check

The fix is to stop letting the recommendation step read a frozen list, and start making it read a current status record before it recommends anything. That record needs only a few fields: the product, its current status, the date the status changed, and, when there is one, the replacement product.

Three habits make that record work. First, read it before planning, not after drafting. If the agent drafts the recommendation first and checks status later, the stale product is already baked into the copy, and the check becomes an edit pass that may or may not catch it. When the status check comes first, a discontinued product never enters the draft at all.

Second, replace the old entry instead of adding a note beside it. A memory that says both "Product X is our top pick" and "Product X was discontinued in March" is a contradiction the agent will often resolve in favor of the older, more repeated claim. One entry, updated in place, removes the ambiguity.

Third, check status at recommendation time, every run. Products retire, replacements launch, and bundles change. A check that runs every time the agent recommends is the only version that sees the latest change.

With that record in place, the agent stops pitching dead ends and points customers to the replacement instead. That is a better customer experience than a confident recommendation of something nobody can buy, and a better use of the recommendation slot itself.

One memory your whole stack reads

The deeper problem is that the discontinuation usually lives in one system while the agent reads from another. The catalog system knows. The prompt does not. As long as each tool keeps its own copy of the catalog, every copy can drift, and the agent will keep reading the one that drifted.

This is the problem Vilix AI is built to solve. Vilix AI is a cloud-hosted memory layer, so there is no infrastructure for you to run. Your agents reach it over MCP, and the same memory follows them everywhere: the scheduled recommendation agent, the support agent, the chatbot, and the tools on your laptop and phone all read and write the same store. When the catalog status changes in that shared memory, every agent sees the change on its next run, not just the one tool you remembered to update.

Vilix AI stores full conversation history, not just extracted facts, so a run can revisit what actually happened last time instead of a summary of a summary. Your data stays portable: export everything or delete it anytime. There is a free plan that stays free forever, and a 7-day Pro trial with no credit card.

A shared memory does not remove the need to record the discontinuation. Someone still has to write down that the product ended and what replaced it. What it removes is the need to chase that fact through every prompt, spreadsheet, and knowledge base your agents read from. Write it once, in the place every agent checks, and the stale recommendation stops at the source.

A short check before your next recommendation run

If your scheduled agent has recommended a retired product, run through these questions before the next send. Where does the agent get its product list, and when was that list last updated? Does anything in that list record status, or only names and descriptions? Is there a replacement recorded for each discontinued product? And does the agent check status before it drafts, or only after?

If any answer is vague, that is where the stale recommendation comes from. A scheduled agent can only recommend what it can see, and right now it sees your catalog as it was, not as it is. Give it a current catalog memory, checked every run, and the discontinued product finally stops showing up in your customers' inboxes.

Vilix AI gives your scheduled agents one shared memory to check, so a product retirement recorded once reaches every agent on its next run.