Stale AI project memory

Stale AI project memory is any note, finding or piece of evidence that an agent reads as current but that describes an older state of the project. It is the quiet failure of every memory system. Writing things down solves forgetting, then the code moves on and the written record does not. A task note says the cache is disabled in tests; someone re-enabled it last week. A finding cites line 88 of a file that has since been reorganized. A test result was recorded before the last three commits. The agent cannot tell, so it acts on the old picture with full confidence. Staleness is detectable in part: dates, commit identifiers and content hashes can show that something changed since a record was written. They cannot show that the record was right to begin with, or that a change somewhere unlinked made it wrong. This article covers how staleness happens, how to detect it and where detection stops. Stale test results in particular have their own page, stale test results.

How project memory goes stale

Most staleness comes from a few ordinary sources.

The code changed after the note. Someone, perhaps another agent, edited the file a finding refers to. The note still points at a function name, a line number or a behavior that no longer exists.

A decision was replaced but its old record still reads as current. Without a clear superseded marker, an agent that finds the old record follows it; recording architecture decisions covers how to avoid that.

Evidence outlived its revision. A pass recorded on Tuesday is attached to the task as if it still applied on Friday, after a merge.

The branch changed underneath. A note written on a feature branch describes code that was never merged, or was merged differently.

The outside world moved. A library version, an API contract or an environment setting changed, and nothing in the repository recorded it.

Copies drifted. The same fact was pasted into three places and only one was updated.

The common thread is that the note was correct when written. Staleness is not a writing error; it is the absence of a link between the record and the thing it describes.

Detecting staleness: dates, revisions and hashes

You can make most records self-checking by storing what they depend on alongside them.

Dates: every finding and result gets the date it was recorded. Dates are weak on their own, since an old note can still be true, but they tell a reader how much might have changed.

Revisions: record the commit a result applies to. 'Tests passed at 4f2a1c.' Anyone can then compare that commit with the current one and see whether the relevant files changed in between, using ordinary version-control history.

Content hashes: record a hash of each supporting file when evidence is captured. Later, recompute and compare. A mismatch says the bytes changed. This is precise and cheap, and it works even outside version control.

Record revisions for the notes themselves: if two sessions edit the same task record, a revision number lets the second writer notice that the record changed since it was read, instead of overwriting the newer version.

The most practical rule is that a record should name what it is about in a checkable way: files, commits, versions. 'The export works' cannot be checked for freshness. 'test_export passed at commit 4f2a1c, export.py hash 9b1e' can.

What a freshness check cannot tell you

A freshness check answers one question: have the recorded supporting files changed since the evidence was captured? It is easy to read more into it than that.

It cannot tell you the record was true. A hash that still matches proves the bytes are the same, not that the original finding or check was correct or sufficient.

It cannot see unlinked dependencies. A test on a BRAIN FLUID development build on October 30, 2026 shows this. In a disposable four-card project, a shared cents() helper changed from round(value * 100) to int(value * 100). Evidence for the changed source correctly flipped from current to stale [D6]. But a CSV export that imported the helper without a declared link had no evidence pointing at that file, so nothing on the export's side was flagged, even though its check now failed with 123 instead of 124.

It cannot see changes outside the recorded set: environment, data or a remote service.

It cannot judge relevance. A changed comment flips a hash just as a changed formula does.

So treat 'fresh' as 'not known to be stale', and 'stale' as 'needs a look', not 'wrong'. Declaring dependencies, covered in declared versus inferred dependencies, widens what freshness can see.

A practical freshness routine

Build freshness into the moments when memory is used, not into a periodic cleanup nobody does.

At task start: before acting on a task record, have the agent compare the recorded commit and files with the current state, and list any finding whose files changed. That list goes at the top of its plan.

Before accepting work: re-run the checks rather than relying on a recorded pass. Evidence is a pointer to how to verify, not a substitute for verifying.

After a dependency changes: when a shared module changes, look for task records and approvals that depend on it and mark them for review. Dependency changes and stale approvals covers this case.

On write: refuse to overwrite a record that changed since it was read. Reload and merge instead.

Weekly: scan active records for findings older than the last significant merge in their area, and either reconfirm or mark them historical.

Keep the vocabulary simple: current, stale, unknown. Unknown is a real answer. A record with no commit or hash should say so rather than borrow confidence from its tidy formatting. The broader case for durable records is in AI agent project memory.

QUESTIONS

How can I tell if my AI agent's notes are out of date?

Check what the notes depend on. If each finding records a date, a commit and the files involved, you can compare those with the current repository and see what changed since. Notes without any of those anchors cannot be checked and should be treated as unknown, not current.

Does a matching file hash mean my project notes are correct?

No. A matching hash shows the file's bytes have not changed since the note was recorded. It says nothing about whether the note was accurate, whether the check behind it was adequate or whether something outside that file changed. It rules out one kind of staleness only.

How often should I review the notes an AI agent reads?

Review them when they are used: at the start of a task and before accepting work. Add a light weekly pass over active records to mark old findings as reconfirmed or historical. Scheduled cleanups alone tend to be skipped, while checks at the point of use actually happen.

RELATED GUIDES

• How to read BRAIN FLUID reports and provenance
• How to read project progress in BRAIN FLUID Build

RELATED HARNESS PAGES

• Stale test results Stale test results describe code that has since changed. Bind each result to a revision and rerun checks on every completion attempt.
• When a dependency changes, which approvals go stale? When a dependency changes, which approvals go stale? How evidence tied to source bytes goes stale, and what a stale flag does and does not tell you.
• Declared vs inferred dependencies in change-impact analysis Declared vs inferred dependencies in change-impact analysis: what task links and import graphs each catch, where each is blind, how to combine them.
• AI agent project memory AI agent project memory explained: why durable project records beat chat history, and how BRAIN FLUID keeps context with the work.