My AI memory kept a stale diagnosis alive

My weekly planning task stopped producing its Monday file. Over several updates, my AI memory kept recording that the task had failed again. The missing plan became a recurring item to investigate.

Then a saved scheduler check supplied a much simpler explanation: the task was disabled. Its last recorded run was August 17.

I use those memory files to start new AI sessions. A wrong diagnosis in them becomes part of the next session’s starting context, before I have asked a question. In this case, the explanation kept arriving with a recent date attached, which made it look more current than its evidence was.

The records disagree

I have a scheduled task that writes a weekly plan into my Obsidian vault. Another task reads recent work sessions and updates a context map. There is also a shorter working-memory file that points to projects and carries a little current state.

The planning task’s absence was real. The records show missing weekly files. What they did not consistently establish was why those files were missing.

The September 4 working-memory entry said the Monday task had failed for two consecutive weeks. The September 8 context-map update carried the problem forward as a third missed cycle. A September 9 correction, referring to the previous day’s scheduler check, recorded the task as disabled.

That would make a neat story about forgetting to check a switch. The earlier records make it less neat.

A September 1 health-check note had already recorded the task as disabled, then said it had been re-enabled. A later entry said it was enabled and due to run the following Monday. The September 9 correction struck that claim too.

I cannot reconstruct the switch’s complete history from these notes. Perhaps the task was re-enabled and later disabled again. Perhaps a claimed change never persisted. The record does not settle that, and a last-run date cannot tell me when somebody changed a setting.

What I can establish is that my summaries repeatedly described a failing task without a consistent account of whether it was even scheduled to run. The latest saved check contradicted the diagnosis they were carrying.

A missing file is an observation

Years of support work should have made this familiar. A customer says a renewal did not happen. That tells me what to investigate. I still need to establish whether a payment was attempted before diagnosing a failed payment.

My own automation notes skipped that distinction. No weekly file appeared, so the task was failing. Another Monday passed, so it was failing again.

Those sentences imply execution. A disabled task can produce exactly the same absence without attempting anything.

For this incident, the useful distinctions are small:

The last row is easy to overread when it appears in a file I have explicitly told the agent to trust.

My precedence rule answered the wrong question

In July, I wrote about the memory system behind my AI workflow. One file holds the canonical account of project state. Shorter notes defer to it. When records disagree, a dated correction supersedes the older entry.

That rule gives the agent a way to choose between copies. It does not establish whether the winning copy is true.

A summary written on Tuesday can repeat an inference made on Friday. Its date tells me when somebody wrote the sentence. Unless the summary says what was checked, I cannot use that date as the age of the evidence.

My setup made this particularly easy to miss. The daily sync’s job is to keep context current. When it carries an unresolved item into a new entry, that looks like another day of monitoring. But carrying an item forward and checking its state are different operations.

I cannot prove that every later sentence copied the earlier one rather than independently making the same inference. I do not need to. Either way, the saved account accumulated repeated diagnoses without the evidence needed to distinguish a failed execution from a disabled schedule.

The correction was already there, somewhere

While gathering the material for this article, both accounts were still available. The canonical map contained the September 9 correction. The short working-memory file still contained the September 4 failure diagnosis.

An agent following the precedence rule and finding both entries could resolve that disagreement. A session given only the short file would start with the wrong account.

This is an awkward limit of the system I described in July. I had a rule requiring old claims to be superseded, but I could still point to an old claim standing uncorrected in a file loaded at session start. Writing the rule had not made every update follow it.

The original post also described human confirmation before conclusions enter memory. These scheduled updates show why I should distinguish a stated workflow from a guarantee about every sentence it produces. An agent’s own diagnosis needs scrutiny even when all the source files belong to me.

What I would change in the record

For an operational claim, I want the note to preserve the last observation and the time of that observation. A later summary should carry those forward unchanged until another check replaces them.

A proposed replacement for this incident would read:

The weekly plan is missing. The scheduler check reported on September 8 found the task disabled, with August 17 as its last recorded run. An earlier note says it was re-enabled; the available records do not explain the discrepancy. Check the current schedule before diagnosing an execution failure.

That paragraph is longer than “failed again.” It also tells the next session where the uncertainty is and what evidence would resolve it.

I would keep the date the note was edited separate from the date the scheduler was checked. Repeating the paragraph tomorrow would not advance the check date. If the agent could not reach the scheduler, it would preserve the last observation and say that current state was unverified.

The same discipline applies to a pull request described as blocked, or an integration described as broken. Memory can point the agent to the relevant record. Before recommending action, it needs to inspect the state that action depends on.

The check I still owe this system

I have enough evidence to correct the account of this incident. I do not yet have evidence that my memory workflow reliably prevents it from happening again.

The test I want is straightforward: give a session an old note saying a task is broken and a newer scheduler observation saying it is disabled. Ask what needs attention. It should describe the disabled task, preserve the uncertainty about why, and avoid recommending repairs to an execution it has no evidence occurred.

Then run the same question without access to the scheduler. The answer should say what was last observed and when. If it repeats the diagnosis with today’s date, the memory system is still doing the thing that caused this article.