Your Scheduled Agent Reports Success. The Work Never Happened.

Your nightly agent finishes on time, the dashboard shows a green checkmark, and the run log says completed. In the morning, a customer asks where the message they were promised went. You check, and there is no message. No error either. The run did not fail. It reported success for work it never did.

This is the most expensive failure mode in scheduled automation, because it hides. A crash pages someone. A false success tells everyone the job is handled, so nobody looks. Days can pass before a human notices the gap, and by then the next runs have already built on top of it, each one trusting the last one's report.

Done is a claim, not a fact

A scheduled agent usually decides it is done the way a person decides a chore is done: it reached the end of its steps without anything exploding. That is a statement about the run, not about the world. The agent finished its loop. It did not necessarily change anything outside itself.

Three shapes of false success show up again and again.

The first is the empty input. An upstream source returns nothing: no new rows, no new messages, an empty list where a list should be. The agent treats "nothing returned" as "nothing to do," writes a tidy summary, and exits clean. It never asks whether the source was actually empty or whether the query broke, the credential expired, or the filter silently excluded everything.

The second is the skipped item. The agent reads 200 rows and writes 140 records, and reports the run complete. The 60 rows it could not parse, match, or deliver were dropped inside a loop that counts attempts, not results. Skipping feels safe to the code: one bad row should not kill a whole run. But a run that never names what it skipped has quietly redefined success as "whatever survived."

The third is the unconfirmed write. The agent calls a tool, gets a response that looks fine, and moves on. The response was a 200 status carrying an error body nobody parsed, a partial write that accepted half the batch, or a message queued into a system that later rejected it. The agent's memory of the run says "sent." The destination says otherwise.

None of these require a broken model or a bad prompt. They require only an agent that measures its own success by whether it finished talking, instead of by whether the work landed.

Why the next run makes it worse

A false success does not stay contained to one night, because the next run reads the previous run's report as its starting point. The report says the leads were scored, the messages were sent, the records were updated. The next run therefore skips that work. It does not re-check it, because re-checking work marked done would defeat the purpose of a schedule.

That is the real damage. A crash loses one run. A false success loses the work and also removes it from the queue. The job stops being "pending" and becomes "done" in every record the business keeps, while the customer, the spreadsheet, or the downstream system still waits.

More logging does not fix this. A false success already produces clean logs. What is missing is evidence about the outcome, stored where the next run must read it before deciding anything is finished.

The fix: receipts, not reports

Stop letting a run grade its own homework. For each scheduled job, write down the acceptance condition before the agent runs, in terms a later run can check without trusting the earlier run's summary:

• Input count versus output count. How many rows were read, and how many records, messages, or updates actually landed? A run that read 200 and wrote 140 has not finished. It has 60 items to name.
• Named evidence, not adjectives. A completed run should leave identifiers behind: record IDs created, message IDs sent, file names written. "Done" is an adjective. An ID is a receipt a later run can verify.
• An explicit skipped list. Every item the run could not process goes on a list with a reason, and that list is itself an output of the run. Skipped work that is named gets handled. Skipped work that is silently dropped gets forgotten.
• A re-check step at the start of the next run. Before the next run plans anything, it reads the previous run's receipts and asks one question: does the evidence match the claim? If the counts do not reconcile, the run re-queues the missing work instead of skipping past it.

This changes what memory is for. Memory stops being a diary of what the agent said it did and becomes a ledger of what can be proven. The diary is what lets a false success compound. The ledger is what stops it at the next run.

Where a shared memory layer fits

A ledger only works if every run, on every tool, reads the same one. When each workflow keeps its own notes in its own format, the receipt from Monday's run lives in a place Tuesday's run never looks. The fix has to sit outside any single automation platform, in a store every agent reaches the same way.

That is the job a hosted memory layer is built for. Vilix AI is cloud-hosted, so there is no infrastructure to run and nothing to install. Your scheduled agent connects to the same Vilix AI account over MCP as the rest of your tools, so the receipts from one run are readable by the next run even when it runs on a different tool. It stores full conversation history, not just extracted facts, so a later run can trace a completion claim back to the actual exchange that produced it instead of trusting a compressed summary that already rounded the gap away.

The free plan is free forever, the Pro trial runs seven days with no credit card required, and the data stays portable: you can export everything or delete it at any time.

Start with one job

Pick the scheduled job whose false success would hurt most: the nightly report, the lead routing, the invoice sync. Write its acceptance condition in one sentence, with counts and IDs. Then change the run so it cannot report success without leaving those receipts in shared memory, and change the next run so it reads them before it skips anything.

Your agent will still fail sometimes. That is normal for real work in real systems. What stops being normal is a failure dressed as a green checkmark, quietly removing work from the queue while everyone believes it is handled. Learn more about giving your agents one shared memory at Vilix AI.