How Does Your Scheduled Agent Know What Changed Since Its Last Run?

Your scheduled agent runs at 7 a.m., does its job, and goes quiet. At 7 a.m. tomorrow it runs again. The question nobody asks until something goes wrong is simple: how does it know what happened in between?

Most scheduled agents do not know. They open the same inbox, dashboard, or spreadsheet, read everything from the top, and try to work out what is new. That works when the list is short. It breaks the moment the list grows, items get edited instead of added, or yesterday's work gets buried under today's noise. The agent either repeats work, misses an edit, or burns its whole run re-reading history it already handled.

Re-reading everything is not the same as noticing change

Picture a scheduled agent that watches a support inbox. Every morning it scans for urgent tickets. Without a record of its last run, it has to decide freshness from the data alone: timestamps, statuses, maybe a "read" flag if the tool provides one. That logic holds until a ticket is reopened, a customer replies to an old thread, or a ticket is edited without changing its status. The ticket looks old, so the agent skips it, even though the new reply is the most urgent thing in the queue.

The same failure shows up in a lead follow-up agent. A prospect who was "not interested" last month replies with a question today. Nothing about the lead record's creation date changed, only the latest message, and an agent that scans by creation date walks right past it.

What a last-seen snapshot actually is

A last-seen snapshot is a short, durable record the agent writes at the end of every run and reads at the start of the next one. It answers four questions:

1. When did you last run, and did that run finish?
2. What was the last item you processed, in the source system's own ordering?
3. What did the world look like when you last saw it?
4. What is still open, and what did you decide last time?

That third question is the one most teams skip. A list of processed IDs tells you what you handled. It does not tell you whether an item you handled has since changed. For that, you need a fingerprint of each item's state: a hash of its important fields, a version number, or an updated timestamp from the source system. On the next run, the agent compares the current fingerprint with the stored one. Same fingerprint means nothing changed. Different fingerprint means something changed, even if the item itself is months old.

Stored this way, change detection becomes a comparison, not a guess. New items have no stored fingerprint. Edited items are the ones whose fingerprint moved. Deleted items are stored but no longer present. Each category gets different handling: new items get triaged, edited items get re-read, deleted items get noted and closed out.

What belongs in the snapshot

Keep the snapshot small and specific. A useful one usually holds:

• The last successful run time and the last processed cursor, such as the newest ticket ID or the latest event timestamp.
• Fingerprints for the items the agent is tracking, not full copies of every record.
• Open items and their status: what is waiting on a human, what is waiting on a third party, what was deferred and why.
• Decisions and corrections from the last run: which items were dismissed as noise, which threshold was adjusted, which contact asked not to be messaged again.
• Failures: what errored, what was retried, and what should not be retried blindly tomorrow.

The snapshot is an index, not an archive. It points at what matters and records what changed. The full history lives elsewhere, where the agent can pull it back when a specific item needs its backstory.

The snapshot has to live outside the runner

The snapshot belongs in a memory layer that outlives any single run, machine, or tool. When the agent's memory sits outside the automation platform, a redeploy costs nothing: the next run reads the same snapshot, from the same place, no matter where it executes. A correction made in a chat session on Tuesday is visible to the scheduled run on Wednesday, because both read the same memory.

Vilix AI is built for exactly that shape. It is cloud-hosted, so there is nothing to provision or keep running on the agent's side, and the same memory is available to every connected AI tool over MCP. The scheduled agent reads its snapshot and open items before it plans the run, and saves the new snapshot when the run ends. Because Vilix AI stores full conversation history, not just extracted facts, the agent can pull back the actual past discussion behind a decision when an edited item needs its context.

The terms are straightforward: a free plan that is free forever, a 7-day Pro trial with no credit card required, and data that stays yours. Export everything whenever you want, or delete individual memories or the whole account at any time.

What the next run should do with the changes

Once the agent can tell what changed, the run gets a clear shape. Start by reading the snapshot, then fetch current state, then compare. Work only the three categories: new, changed, and gone. Everything else is already handled.

Nothing changing is also a valid outcome. A run that finds no changes should say so, briefly, and stop. It should not invent work, re-notify people about items they already saw, or reprocess old items for the appearance of activity.

Finally, handle the missing-snapshot case explicitly. If the snapshot is absent or corrupt, the agent should rebuild from a bounded window, such as the last seven days, and flag that the rebuild happened. Silent rebuilds are how an agent spams a whole list it already contacted.

A short checklist for your next scheduled agent

Before your next scheduled agent goes live, check that on its second run it can answer: what was the last item processed, and where did it stop? Which tracked items changed, and what exactly changed? What is still open, and what was already decided? Where does that record live if the runner is replaced tonight?

If it cannot answer those questions, the gap is specific and fixable: no last-seen snapshot. Give it one, store it outside the runner, and the next run stops re-reading the world from scratch and starts noticing what actually changed.

Learn more about giving scheduled agents shared memory at Vilix AI.