Your Scheduled Agent Keeps Missing New Items. The Gap Is Between Its Runs

Every morning, the scheduled agent files its report, and every morning, something is missing from it: the lead that came in while the agent was running, the ticket filed during the nightly sync, the order placed ten minutes after the run started. The agent runs on time, finishes without errors, and reports success. It never sees the items that arrive in the gap between one run's window and the next.

That gap is the whole problem. A scheduled agent does not watch a feed continuously. It wakes up, asks a source for what is new, works through the answer, and goes back to sleep. If the question is "what arrived since my last run," the definition of "last run" decides what gets seen, and in most setups that definition quietly leaves a hole.

How the gap opens

Picture a nightly triage agent that runs at 2 a.m. and takes forty minutes. At 2 a.m. it asks the CRM for everything created since yesterday at 2 a.m. and starts working. At 2:20 a.m., while it is still scoring leads, three new leads arrive. At 2:40 a.m. the run finishes and records its progress as last run completed at 2:40 a.m.

Tomorrow at 2 a.m., the agent asks for everything created since 2:40 a.m. yesterday. The three leads from 2:20 a.m. are older than that cutoff, so they are excluded, and they were never in yesterday's list either, because that list was frozen at 2 a.m. They arrived after the query and before the checkpoint, and no run will ever ask for them again.

This is not a rare edge case. It is the default shape of any polling agent that saves a "last run" timestamp at the end of a run and queries from it at the start of the next one. The longer the run, the wider the gap: a five-minute run loses five minutes of arrivals, a forty-minute run loses forty.

Using the run's start time instead just flips the failure: the next run re-fetches processed items. Operators who "fix" those duplicates by switching to the end time trade duplicates for skips. Neither timestamp, on its own, is the right bookmark.

Why a timestamp alone is a weak bookmark

A timestamp says when something happened. It does not say whether the agent handled it. Those are different facts, and conflating them is what creates the gap.

A timestamp checkpoint cannot say "items 101 through 140 were processed, but 141 through 143 arrived during processing and are still unhandled." It cannot survive a clock change or a source system that records creation times in a different timezone than the agent assumes. And when a run crashes halfway, the timestamp is either the old value, which reprocesses everything, or the new value, which skips the unprocessed half.

The fix is to stop bookmarking time and start bookmarking progress. What the next run needs is not "when did I last run" but "which items have I already handled, and where exactly did I stop." That is a per-item record: a list of processed item IDs, or a cursor that advances item by item as each one is completed, saved somewhere that survives the run ending, crashing, or being redeployed.

What a real progress record looks like

A durable progress record has four parts, and each one closes a different hole.

First, a processed-items ledger. As the agent finishes each item, it records that item's ID as handled. The next run skips anything already in the ledger. An item that arrived mid-run is simply absent from the ledger, so the next run picks it up.

Second, a cursor that advances per item, not per run. Instead of one checkpoint written at the end, the cursor moves forward as each item completes. If the run dies after item 87 of 120, the cursor sits at 87 and the next run resumes at 88. The crash costs one restart instead of a full rerun.

Third, a run-state note that distinguishes "finished" from "interrupted." A run that completed its list and a run that stopped halfway must not look the same to the next run. The note should say which: finished cleanly, stopped at item 87, or never started because the source was unreachable. A run that never started must not advance any checkpoint, since that would silently declare unhandled items handled.

Fourth, a reconciliation pass. Even with a good cursor, sources change: items get deleted, backdated, or imported in bulk with old timestamps. A short weekly sweep of the last seven days against the ledger catches what falls through every other mechanism. It should report what it found so the gap stays visible instead of silent.

Where Vilix AI fits

This is where a shared memory layer changes the shape of the problem. Vilix AI 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 progress record before it plans the run and updates it as items complete, instead of reconstructing "where did I stop" from a timestamp every night. Because Vilix AI stores full conversation history, not just extracted facts, the agent can also pull back the actual past discussion behind a disputed item when a skipped record needs its backstory.

Each run loads the ledger and the cursor, marks each item handled as it finishes it, and writes the run-state note at the end. The next run reads the same record, because the memory lives outside the automation platform rather than inside a single workflow's local state.

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.

How to check whether this is your gap

Confirm the diagnosis with one check. Take an item you know was missed and find its creation time, then find the run that should have caught it and the run before that. If the item's creation time falls between the earlier run's query time and its finish time, you have found the gap: the item arrived while the agent was working, after the list was frozen and before the checkpoint moved past it.

If that pattern repeats, a faster run or a tighter schedule will not fix it: shortening the run narrows the gap but never closes it, and running more often just creates more gaps per day. The fix is a progress record that advances per item and lives outside the run itself, so the next run starts where the last one stopped, including the items that arrived while it was working. A scheduled agent should miss nothing it was supposed to see. When it keeps missing new items, they are falling into the space between runs, and that space only exists because nothing remembered the run's progress item by item. Close the gap with a real bookmark, and the morning report stops having holes in it.