She Upgraded Last Week. Why Is Your Scheduled Agent Still Treating Her Like a Free User?

A customer upgrades on Tuesday. The payment clears, the billing system updates, and the account page shows the new plan. Then your scheduled agent runs on Thursday and sends her the free-plan limit warning, offers her the upgrade she already bought, and routes her question to the slow support queue. Nothing broke in the billing system. The agent simply never heard about the change.

That gap is easy to miss because every part of the setup looks correct on its own. Billing is right. The workflow ran. The message went out on schedule. The only thing wrong is the date on the information the agent used. It acted on who the customer used to be.

The upgrade lives in one system and the agent reads another

Most scheduled agents do not check the billing system on every run. They read a list, a sheet, a variable, or a snapshot that was copied into the workflow when it was built or when the customer first appeared. That copy was accurate once. Then the customer changed, and nobody updated the copy.

Upgrades make this worse than most other changes because an upgrade changes what the customer is owed: higher limits, faster support, features that were locked before. When the agent works from the old tier, it does not just send a slightly wrong message. It withholds something the customer already paid for, and it tries to sell something the customer already owns. Both feel insulting, and both are avoidable.

There is a second copy problem. The tier often lives in several places at once: the billing tool, the CRM, the workflow's own list, and the prompt that tells the agent how to treat each tier. Change one and the rest stay old. The next run picks whichever copy it happens to read, so the same customer can get the premium treatment from one workflow and the free treatment from another on the same day.

An upgrade is an event, not a label

The fix starts with treating a plan change as an event with a date, not as a label that gets edited in place. A useful plan-change record answers four questions: who changed, what changed, when it changed, and what triggered it. The trigger matters because it separates a real upgrade from a test account, a refund, or a billing retry. A record that says "Premium since Tuesday, payment confirmed" leaves no room for the agent to guess.

That record also needs a rule for what happens to the old tier. The old tier should be kept as history and retired as current truth. If the new plan is simply added next to the old one, the next run has two competing answers and will pick one by accident. The newest confirmed change wins, and the older one stays readable for context, not for decisions.

Downgrades follow the same rule in reverse. A customer who moves down a tier should stop getting premium treatment, and the agent should stop promising features that are no longer included. The record works both ways, or it works for neither.

What a run should read before it acts

Before a scheduled agent sends anything to a customer, the run should be able to answer three questions without searching logs or opening another tool:

• What plan is this customer on right now?
• When did that plan last change, and what triggered the change?
• What does this plan entitle them to in this specific run: limits, speed, features, and support route?

If the run cannot answer those three, it should not guess from an old list. It should read the current record, or hold the message until the record is available. A delayed message is a small cost. A message that treats a paying customer like a free user is a churn risk.

At the end of the run, the agent should write back anything it learned: a reply that mentions a new plan, a support ticket that changed the account, a billing event it observed. A run that only reads memory will slowly fall behind. A run that reads and writes keeps the next run honest.

Where Vilix AI fits

This is the gap Vilix AI is built to close. Vilix AI is a cloud-hosted memory layer, so there is no infrastructure to run and nothing to install. A scheduled agent connects to the same Vilix AI account over MCP as the rest of your tools, and every run reads and writes the same memory.

That shared memory is what makes a plan change survive from one run to the next. The upgrade is captured once, with its date and trigger, and it is available to the next run, to a different workflow, and to an assistant on another device, all reading from the same account. Vilix AI stores the full conversation history, not just extracted facts, so the next run can revisit what the customer actually said about the upgrade, including whether it was meant to apply immediately or from the next billing cycle.

The setup stays simple: a free plan forever, a 7-day Pro trial with no credit card, and data that stays portable, with export or delete anytime. Get started for free. Free forever, no credit card.

Before the next run

Check these four things before your scheduled agent messages another customer:

• Can the agent state the customer's current plan, the date it changed, and the trigger, without opening the billing tool?
• Is there exactly one current plan per customer, with older plans kept as history rather than competing answers?
• Does a plan change in billing reach the agent's memory before the next run, rather than at the next manual sync?
• Does the run write back what it learns, so a customer who upgrades mid-sequence is treated as upgraded from the next message on?

If any answer is no, the agent will keep embarrassing itself in front of the customers who just paid more. The fix is not a friendlier upgrade email. It is a plan memory: read it at the start, act on it during the run, and save what changed at the end. Customers do not expect your agent to guess what they bought. They expect it to remember what they already paid for.