Your Scheduled Agent Crashed Mid-Run. Why Does the Next Run Start From Zero?

A scheduled agent runs at 2 a.m. It pulls the new leads, scores them, routes the hot ones to sales, and starts drafting the morning summary. Then the API it depends on times out, or the process runs out of memory, or the platform kills the run for exceeding its time limit. The run dies with three quarters of its work done.

The next run does the most expensive thing possible: it starts over. It re-scores the same leads, re-routes the same prospects, and drafts a second summary that contradicts the first in small, embarrassing ways. The crash was a routine failure. The restart-from-zero design turned it into duplicate work, duplicate messages, and a report nobody trusts.

Scheduled agents do not need to be crash-proof. They need to be resumable. And resumability is a memory problem, not a reliability problem.

A crash is normal. Losing the run is a choice.

Every long-running automation will eventually hit a failure it cannot prevent: a vendor API down for ten minutes, a rate limit tripping halfway through a batch, a file that takes longer to process than the platform allows, an approval step that sits unanswered until the run times out. None of that means the agent was badly built. It means the agent was doing real work in a real system, where interruptions happen.

What turns an interruption into damage is the absence of a record of progress. If the only record of a run is its final output, then a run with no final output has, as far as the next run is concerned, never happened. All of its intermediate work evaporates with the process. The next run cannot skip what is already done because it cannot see what is already done.

What a checkpoint actually is

A checkpoint is a small, durable record of where a run stopped and what it already finished. It is not the agent's general knowledge, and it is not a log file for humans to read later. It is the next run's starting point, written in a form the next run can act on without re-deriving anything.

A useful checkpoint holds five things: the run identity (which agent, which schedule, which run); the completed steps by stable identifier, the exact lead IDs already scored, not "processed some leads"; the outputs of those steps, the scores and routing decisions; the next step, including anything waiting, such as an approval or a vendor response; and the decisions made along the way, which rule was applied and which item was deliberately skipped and why.

The duplicate-send problem is the real cost

Wasted compute is real: re-scoring hundreds of items, re-reading dozens of documents, re-running model calls that already produced good answers. But the sharper cost is the side effect that happens twice.

Take that nightly lead-triage agent. It scores 200 leads and routes 30 to sales, sending a notification for each one. It crashes after routing lead number 22. The next run, with no checkpoint, routes all 30 again. Eight sales reps get a second notification about a lead they already contacted, and the system now shows two routing events for the same lead. Nobody can tell which notification was the real one, because both were.

Checkpointing fixes this only when paired with one more rule: before acting on an item, check the checkpoint first. The resumed run's first job is not to plan. It is to load the checkpoint, skip every completed item, and continue from the recorded next step. A checkpoint that is written but never read on startup is decoration.

Checkpoint memory is not agent memory

It is easy to confuse a checkpoint with long-term memory, because both involve saving things between runs. They serve different purposes, and a scheduled agent needs both.

Long-term memory answers questions like: what are this customer's preferences, what decision was made last quarter, what rule applies to this kind of request? It stays useful across many runs.

A checkpoint answers a narrower question: where did this specific run stop? It is useful for exactly one resumed run, and once the run completes, the checkpoint can be archived or discarded. Keeping checkpoints forever would bloat retrieval with stale run state, which is the opposite of helpful.

Putting it together

A resumable scheduled agent follows a simple loop that can be written into its instructions in plain language. On startup, load the latest checkpoint for this schedule. If a previous run is incomplete, skip its completed items and continue from its next step. If none exists, start fresh. After each meaningful unit of work, save the checkpoint before starting the next unit, recording completed IDs, outputs, and the new next step. Save before moving on, not after, because a crash between the work and the save is the same as no save at all. Before any outward-facing action, check the sent-flag for that item. On completion, mark the run complete, promote anything durable into long-term memory, and archive the checkpoint. On failure, leave the checkpoint exactly as it is. Do not clear it or write a summary pretending the run finished. The next run's ability to resume depends entirely on the failed run's honesty about where it stopped.

Where Vilix AI fits

This is where a shared memory layer earns its place in a scheduled automation stack. Vilix AI is a cloud-hosted memory layer that agents reach over MCP, so there is no infrastructure to host and no per-tool memory store to keep in sync. The same memory follows the agent across tools and devices, instead of living inside one automation platform where a different tool cannot reach it.

Vilix AI stores full conversation history, not just extracted facts, so a run's progress record can be traced back to the actual exchange that produced it. When a scheduled run saves its checkpoint into that shared memory, the next run, even on a different tool, can retrieve it before it plans anything. Vilix AI has a free plan that stays free, with a 7-day Pro trial and no credit card required, and data can be exported or deleted at any time.

The test to run this week

Pick the scheduled agent most likely to crash. Add three things: a checkpoint save after each batch, a read-before-work step at startup, and a sent-flag check before every outward action. Then simulate the failure: kill a run halfway through, on purpose, and watch the next run.

If the next run skips the completed batches and sends nothing twice, the agent is resumable. If it starts over, the checkpoint gap is now visible and fixable.

Scheduled agents will keep crashing. Vendors will keep timing out, rate limits will keep tripping, and long runs will keep hitting walls. The question was never whether the run would fail. It is whether the next run has to pay for the failure all over again. Give it a checkpoint, and it does not.