It Was Refunded Last Week. Why Is Your Scheduled Agent Still Following Up?

The refund went through last week. The money is back in the customer's account, the order is closed in your system, and the case should be over. Then your scheduled agent sends another follow-up: a check-in about the delivery, a satisfaction survey, or an offer to help with the same order. The customer replies, confused or annoyed, and your team has to explain that yes, the refund already happened.

The agent ran on schedule and followed its instructions. The problem is specific: the run that sent the follow-up did not know the refund had already happened. It woke up with the order as it was when the automation was first set up, not as it stands now.

A refund is a change of state, not a new fact to look up

Most scheduled agents are built around a list. Every morning, or every hour, the agent pulls open orders, checks a status field, and acts on whatever matches its rules. That design works while an order stays in one state. It falls apart when the order moves on.

A refund changes what the order means. It is no longer an order waiting for delivery, a customer waiting for help, or a sale waiting for a review. It is a closed chapter. But a scheduled run that only sees the original order record, or a snapshot taken before the refund, cannot tell the difference. It sees an order, a customer, and a task, and it does what it was told to do with orders like that.

The gap gets wider when the refund lives in a different place from the follow-up. The payment system knows the money went back, and the support tool knows the ticket was closed, but the automation reads from its own starting point: a list built at the start of the run. If the refund is not in that starting point, the follow-up goes out anyway.

Why checking the order again is not enough

The obvious fix is to tell the agent to check the order status before it sends anything. That helps, but it does not solve the whole problem, because a single status check answers only one question: what does this order look like right now?

A refund follow-up needs more than a status. It needs the story around the refund. Was the refund full or partial? Was it for a damaged item, a duplicate charge, or a cancelled order? Did the customer already get an apology and a confirmation? Did a human already close the loop? An agent that checks only a status field can still send a generic follow-up that contradicts what the customer was already told.

Then there is the second follow-up. The customer replies to say they were already refunded, and the next run treats that reply as a new conversation and may reopen the case, because it does not remember the previous mistake.

What a run needs to remember about a refund

The fix is not a longer prompt. It is a shared record that every run can read before it acts and write to after it acts. For refunded orders, that record needs a few specific things.

First, the outcome itself, stated plainly: this order was refunded on this date, for this reason, in this amount. Not a vague note that the order is closed, but the refund as an event the next run can recognise and respect.

Second, what has already been sent since the refund. If a confirmation went out, the next run should know not to send another one. If an apology was already made, the next run should not start the conversation from scratch. The record of what was communicated matters as much as the refund itself.

Third, the boundary: do not follow up on this order. That sounds simple, but it is the piece most automations lack. A list of open orders does not carry a do-not-contact rule. A memory that every run reads does. When the boundary is written down in a place the agent checks first, the follow-up stops before it starts, instead of being caught after it goes out.

Fourth, the exceptions. Some refunded customers do need a follow-up, for example when a replacement is on its way or a partial refund needs a second step. Those exceptions should be explicit too, so the agent can tell the difference between a refund that closes the order and a refund that starts a new task. Without that distinction, the safe move is to stop all follow-ups, and real work gets missed.

When those four pieces live in one place that every run reads, the behaviour changes. The agent starts by asking what has already happened to this order, not just what the order is. It skips the refunded orders that are truly closed, it handles the ones with an open next step, and it leaves a note for the run after it. The customer stops getting messages about money they already got back.

How Vilix AI fits this pattern

This is the kind of shared state that Vilix AI is built to hold. Vilix AI is a cloud-hosted memory layer, so there is no infrastructure to run and nothing to install. Your scheduled agent connects to the same Vilix AI account over MCP as the rest of your tools, and every run can pull the relevant context at the start and save what it did at the end.

In practice, that means the refund outcome, the messages already sent, and the do-not-follow-up boundary are available to the next run, whichever tool runs it. The agent reads the full conversation history, not just a set of facts, so it can see what the customer was already told. The next run wakes up informed, instead of working from a list that stopped being true days ago.

Vilix AI is free forever on the free plan, with a 7-day Pro trial and no credit card required. Your data stays portable: you can export everything or delete it anytime. The point is to give every scheduled run the same memory, so a refund recorded once is respected by every run after it.

A short checklist before the next run

If your agent keeps following up on refunded orders, check these points in order. Does the run read the refund before it sends anything, or does it work from a list built earlier? Does it record what it sent, so the next run knows the customer was already contacted? Does it carry an explicit do-not-follow-up rule for closed refunds, separate from the open-order list? And does it distinguish a closed refund from a refund with a real next step?

A refund should end the conversation about that order, unless there is a clear reason to reopen it. When your scheduled agent remembers that, customers stop getting messages about money they already have back, and your team stops spending its mornings apologising for an automation that forgot what already happened.

Get started for free with Vilix AI at vilix.ai.