Your One-Week Exception Is Still Running in Week Six. Give It an End Date Your Agent Can Read

Quick answer: A scheduled agent keeps applying an expired exception because the exception was saved as plain instruction, with no end date, no scope, and no rule for what happens the day after it ends. The fix is to store every exception with four fields the agent can read at run start: who it covers, when it ends, which normal rule it overrides, and where it came from. Then the agent checks whether the exception is still live before it acts, and falls back to the normal rule the moment it is not.

How a one-week exception becomes permanent

A temporary exception usually starts as a short message: one client gets a different report format during a migration, or one segment is skipped during a launch week. Someone types that instruction into a prompt, a note, or a workflow step, and the agent follows it. The problem is what that instruction looks like to the next run. It sees text, not a calendar: "Use the alternate format for Client A." Nothing in that sentence says the migration ended three weeks ago, that it covered one client rather than every similar client, or which normal rule should take over again.

Three things then go wrong, quietly. First, the exception survives its own ending: scheduled runs read whatever memory or instruction file is still in place, not the chat where the exception was approved, so silence reads as approval. Second, the exception spreads: without a stored scope, an agent may apply a skip meant for one segment to a new segment that shares a keyword or tag, and similarity becomes permission. Third, the exception outranks the normal rule forever. When the override never expires, the normal rule never comes back, and each run still looks correct, because the output matches an instruction that is simply out of date.

What breaks is not the agent. It is the missing metadata.

Consider a scheduled reporting agent told to send one client a simplified report during a two-week migration, because the full data feed is unreliable. Six weeks later the feed is reliable again, but the agent still sends the simplified report. The client never complains, because a report still arrives on time. The team only discovers the gap when someone asks why that client's numbers never match the dashboard.

In both cases, the agent did exactly what it was told. A temporary rule without an end date is not temporary. It is a permanent rule nobody reviewed.

Four fields every exception needs

Before a scheduled agent is given an exception, write the exception as a record, not a sentence. Four fields are enough:

1. Scope. Exactly who or what it covers: one client, one segment, one workflow, one account list. If the scope cannot be written in one line, the exception is too broad to hand to an unattended agent.
2. End date. A specific date, not "for now," "temporarily," or "until further notice." "Until Friday" is a date. "For the migration" is not, because nobody has agreed on when the migration ends.
3. Overridden rule. Name the normal rule this exception replaces, so the agent knows what to return to. "Send the full report" is the rule that comes back. Without it, the agent has nothing to fall back to when the exception ends.
4. Source. Where the exception came from: who approved it, and where the approval lives. When the agent later faces a conflict between the exception and a newer instruction, the source tells it which one to trust, and tells a human where to check.

Store those four fields together, where the agent reads at run start. If the scope lives in one doc, the end date in a chat message, and the approval in an email, the agent will only ever see one of them.

The run-start check that makes expiry real

An end date on paper does nothing unless the agent checks it. Add one step at the start of every scheduled run, before any action: for each active exception, is today on or before the end date, and does this run's target fall inside the scope?

If yes, apply the exception. If no, do three things: ignore the exception for this run, apply the normal rule instead, and record that the exception expired.

Also decide the day-after behavior in advance: resume the normal rule immediately, or pause for a human first? For low-risk work like report formatting, resuming is usually right; for money, customer messages, or account changes, pausing for review is safer. Either answer works. Having no answer is the problem, because the agent's default is to keep doing what it did last run. Finally, review live exceptions monthly, one line each with its end date. Anything past its end date that is still active is a bug, and anything with no end date should get one or be removed.

Where the exception should live

An exception stored inside one workflow only helps that workflow. The same exception often matters to more than one agent: the reporting agent, the follow-up agent, and the assistant that answers questions about the account all need the same answer about what is currently true. When each tool keeps its own copy, one copy expires and the others do not, and the tools start disagreeing with each other.

That is the case for keeping agent memory outside any single automation tool, in one place every connected tool can read. Vilix AI is built for that shape: cloud-hosted with nothing to install and no infrastructure to manage, the same memory across every tool over MCP, and full conversation history, not just extracted facts, so the original approval, its scope, and its conditions stay retrievable instead of being compressed into a summary that drops the end date. It is free forever on its free plan, with a 7-day Pro trial that needs no credit card, and your data stays portable: export everything or delete it anytime. Put the dated exception in that shared memory, and every run on every tool checks the same end date and falls back to the same normal rule on the same day.

The checklist

Before the next run, check three things: does every active exception have a scope, an end date, an overridden rule, and a source? Does the run check the end date before it acts? And does it record the moment an exception expires? If any answer is no, the exception is not temporary yet. Give it an end date your agent can read, and week six will finally behave like week six.

Get started with Vilix AI at https://vilix.ai/?utm_source=vilix-blog&utm_medium=article&utm_campaign=scheduled-agent-expired-exception-still-running