It Was Refunded Last Week. Why Does Your Scheduled Agent Offer to Refund It Again?

The refund already went out. The payment system shows it, the customer saw it land, and the case should be closed. Then the next scheduled run wakes up, scans the same open complaint, and sends a fresh message: sorry about the trouble, a refund can be arranged right away. At best the customer is confused. At worst a second refund gets approved before a person notices the first one.

That second offer rarely comes from a reckless model. It comes from a run that starts with no memory of the run before it. The complaint still looks open in the queue the agent reads, the refund that resolved it lives in a different system, and nothing in the new run connects the two. Yesterday's decision was real. It just never became part of today's starting picture.

Two different duplicate problems, and only one is a retry problem

Search results on duplicate refunds focus heavily on retries inside a single run: a timeout, a tool called twice, a payment request fired again before the first response returns. Idempotency keys and approval gates help there, and they belong in any refund flow.

A scheduled agent creates a second, quieter problem across runs. Run one investigates, decides, and issues the refund. Run two, hours or days later, is a brand new session. It does not inherit run one's reasoning, its tool results, or its outcome unless something outside the agent saved them. It re-reads the ticket, sees a frustrated customer and no visible resolution in the text it was given, and reaches the same generous conclusion again. Every run is internally sensible. Together they double-pay.

The distinction matters because the fixes differ. A retry guard stops the same call from firing twice in one execution. It says nothing about a new execution next Tuesday that sincerely believes no refund has happened yet.

Why the ticket queue cannot be the memory

Teams often assume the helpdesk or store system is the shared record. In practice the refund state is scattered. The refund itself sits in the payment provider. The promise to refund sits in a chat transcript. The ticket status depends on a human remembering to close it, or on an integration that syncs once a day, or on a note field the automation never reads.

So the scheduled agent works from a partial snapshot. It sees the complaint, not the settlement. Even a careful check-the-status step fails when the status it can check is stale, in another tool, or written as free text it was never taught to trust. The result is predictable: open-looking work gets reworked, settled cases get reopened, and money that already moved gets offered again.

What a refund-ready run should know before it acts

Before offering anything, a scheduled support or billing agent needs three facts loaded at the start of every run:

• What was already decided for this customer and this order, including refunds issued, store credit given, replacements sent, and apologies already made.
• What is still genuinely open, separated from cases that only look open because a status field lagged behind.
• What the customer was told last time, in full, so the next message continues the conversation instead of restarting it with a bigger offer.

That is not a longer prompt. A prompt can tell the agent to be careful, but careful needs data. The data has to live somewhere persistent, outside any single run, written at the end of one run and read at the start of the next.

One memory that every run checks first

This is the gap Vilix AI is built to close. Vilix AI is a cloud-hosted memory layer for AI tools and agents, with zero infrastructure to run and nothing to self-host. The same memory is reachable from every connected tool over MCP, so an n8n workflow, a Make scenario, and a chat assistant are not each keeping a private, drifting note of what happened. They read and write one shared record.

Vilix AI stores full conversation history, not just extracted facts. For a refund case that difference is practical: the next run can see the actual exchange where the refund was promised and confirmed, the amount, and the tone already used, instead of a bare flag that says resolved. It can close the loop with a follow-up about delivery or satisfaction rather than opening the wallet again.

A run shaped by shared memory looks like this:

1. The run loads the customer and order history before drafting anything.
2. If a refund was already issued for that order, the refund offer is skipped and the case moves to follow-up or closure.
3. The run writes back what it did and learned, so the following run, and every other agent, starts from the updated state.

Control stays with the team that owns the money

Memory that touches billing decisions has to stay inspectable and removable. Vilix AI has a free plan that runs forever, so a single scheduled support workflow can start with real shared memory without putting a card down, plus a 7-day Pro trial with no credit card when higher limits are needed. Everything stored can be exported or deleted at any time, so the history your agents rely on stays an asset you hold and can audit, not a black box inside one automation tool.

The short version

A scheduled agent offers a second refund because, from its seat, the first refund never happened. Retries inside one run are only half the story; the other half is a new run waking up blind to last run's decision. Put the decision in one persistent, shared memory that every run reads before it acts and updates after it acts, and the already-refunded case stops looking like an open opportunity to be generous with your money. Start free at vilix.ai.