Your Scheduled Agent Forgot Who Approved That: The Approval Memory Fix

Quick answer: A scheduled agent needs an approval record that survives between runs: who approved, the exact action and arguments, when approval was given, when it expires, and whether it was already used. Without that record, the agent either asks again every run until people stop reading and click yes on autopilot, or it treats an old yes as a permanent permission slip and runs an action that has changed since approval.

Picture a refund agent that runs every morning. It finds a refund needing a human sign-off, posts the request in Slack, and waits. A manager approves it at noon. The next morning, the agent runs again, sees the same refund still in the queue, and has no record of yesterday's approval. So it asks again. By the third morning, the manager has stopped reading the details and approves out of habit. That is not oversight. That is approval fatigue, manufactured by a system that forgets.

Scheduled runs make approvals harder, not easier

A chatbot asks for approval while you are sitting there. A scheduled agent asks at 2 a.m., while the approver is asleep, and the answer may arrive hours later, after the run that asked has already ended. The next run starts fresh. If the approval is not stored somewhere every run can reach, the next run has nothing to check.

A Slack message or email thread is a weak approval store on its own. Messages scroll away, threads get buried, and "yes, go ahead" in a chat thread does not say whether the yes covered one refund or every refund like it. Treat approval as a record, not a conversation. A usable record answers six questions: who approved and who asked, what exact action was approved with what exact arguments, when approval was given, when it expires, whether it was already used, and what happened when it ran. If any answer is missing, the approval is not safe to act on.

One yes means one action, once

The most important rule is also the simplest: one human yes covers one action, once, exactly as described. If the agent retries and generates a new request, the old approval does not carry over. If the arguments change between approval and execution, the approval does not count. The reviewer approved a specific refund amount on a specific order, not a category of refunds. Running a different amount under the old approval is acting without approval.

That rule protects you in both directions. It stops a duplicate send after a retry or a double-click, because an executed approval is marked used and cannot be spent again. It also stops argument drift, where the details change between the approval screen and the tool call. The check belongs in code, not in the model's judgment: compare the action about to run against the action that was approved, and refuse if they differ.

Pending approvals need a safe default too. A request cannot wait forever. The reviewer goes home, the message scrolls off, and the run that asked is long gone. When a pending approval expires, the run should resume with a denial, not a silent drop, and the agent should report that the action was not approved. A day is a reasonable starting window for an ordinary decision. A money-moving action should expire much faster.

Approval is a point-in-time decision

Even a fresh, specific, unused approval can go stale between the yes and the run. Inventory changes, a price changes, a recipient list gets edited. Treating approval as a permanent fact ignores all of that, so the agent should revalidate before it executes: check that the conditions the approver saw are still true, and that the amount, recipient, and target record match the approved arguments. If anything material has changed, stop and ask again.

Set expiry by blast radius, not by convenience. Reversible internal work can carry a longer window. Anything that sends money, messages a customer, publishes to a public channel, or deletes data should carry a short window and a hard stop at expiry. You can loosen a gate after watching the agent work for a week. You cannot un-send a payment that ran on a three-week-old yes.

What to gate, and what to leave alone

Not every step needs a human. Gating everything creates the fatigue problem all over again, and a queue full of trivial approvals trains people to approve without reading. Split the workflow by reversibility and cost. Let the agent run on its own when the step is cheap, internal, and easy to undo: drafting a summary, tagging a record, sorting a queue. Pause for a human when the step leaves the company or moves money: sending a customer message, issuing a refund, publishing to a live channel, or deleting records. If a mistake would be annoying, let it run and fix it later. If a mistake would be expensive or public, gate it.

Where shared memory changes the picture

All of this only works if the approval record is somewhere every run, and every tool, can reach. That is the part scheduled agents usually miss. The approval conversation happens in one tool, the action runs in another, and the next scheduled run starts in a third, with no shared record between them.

This is where a shared memory layer earns its place. With Vilix AI, the same memory follows your agents across tools over MCP, so the approval record is not trapped in one chat thread or one workflow's local state. The full conversation history is stored, not just a summary fact, so a later run can check the actual approval conversation: who said yes, to what, and when.

Vilix AI is cloud-hosted, so there is nothing to set up or maintain to get that shared memory, and your agents do not need separate memory infrastructure per tool. It is free forever on the free plan, with a 7-day Pro trial and no credit card required, and you can export everything or delete it anytime.

A checklist you can use this week

Start with one risky action and one approver. Make sure each approval passes this check: the exact action and arguments are stored, not just a "yes"; the approval has an expiry set by how expensive a mistake would be; one approval executes one action, once, and is marked used after it runs; an expired pending approval resumes as a denial, and the agent says so; before execution, the agent revalidates the approved conditions; and every decision lands in an audit trail with a timestamp and a name.

Scheduled agents do not fail at approvals because people are careless. They fail because the system asks people to remember what the system itself forgot. Give the approval a record that outlives the run that asked for it, an expiry that matches the risk, and a check that the action about to run is the action that was approved.

Learn more at Vilix AI.