Skip to article
david sheffer.
← All notes

Engineering memory · Evidence

Your agent remembered. Did it actually learn?

Building Hunch pushed me to separate four things that are too easily collapsed: recall, claimed use, verification, and actual improvement.

A convincing story is easy to generate

Imagine an assistant finishes a change and says: “I remembered your architecture rule, applied it, and the tests passed.” That sounds like a complete chain of evidence. But it contains several different claims, and one does not automatically establish the next.

Perhaps the rule was present in the prompt but ignored. Perhaps the code would have followed it anyway. Perhaps the agent applied it, but ran tests before its final edit. Perhaps the tests passed because they never exercised the relevant behavior.

Building Hunch made this distinction a product problem for me. A memory tool that reports its own success too generously can make an agent appear more dependable while giving the person supervising it less useful information.

Four claims, four standards of evidence

The first question is delivery: which revision of a lesson reached this task? The second is application: what action does the agent say it took because of that lesson? The third is verification: which checks actually ran, with what result, against which source state?

Then comes the harder question: did the memory improve the outcome? Answering that requires more than a delivery receipt and a successful command. It involves comparison, evaluation, and a careful definition of what improvement means.

Hunch’s task reports keep the earlier questions separate. An agent can identify the exact delivered record and describe its use. A verification wrapper can observe a command’s exit result and source snapshots. The report preserves the difference between agent attribution and observed checks.

EvidenceWhat I can reasonably say
A delivered lesson revisionThis context reached this task
An agent-linked actionThe agent reports using this lesson
A command result and source snapshotThis check ran against this source state
A controlled outcome comparisonWe can investigate whether memory helped
A reporting model, not a claim that every task has all four kinds of evidence.

A green test can describe yesterday’s code

Source identity turns out to matter as much as the command name. “Build passed” is incomplete if the agent edited the source afterward. The pass may be perfectly real and no longer answer the question being asked.

Hunch’s verification flow records bounded source snapshots around a check. If the source changes during the check or differs afterward, the report should preserve that limitation. It should not quietly present an old observation as proof of the current state.

This is an engineering habit I recognize from QA and production work: establish what was tested before deciding what the result means. Automation makes the evidence easier to collect; it does not make the distinction unnecessary.

Remembered context should not silently become authority

There is another boundary beside evidence: permission. A recorded convention can explain how a team has worked. It does not automatically authorize a deployment, a message to a customer, or a new rule that blocks future changes.

Hunch is advisory by default. Blocking behavior requires an explicitly trusted rule and enforcement. A frequently observed habit, an imported document, and a human-approved constraint are different things, even when all three are stored in the same broader memory system.

Keeping that distinction visible gives people room to change their minds. Memory should preserve the reason behind a decision, including its scope and history, so that a new decision can be made with better context.

The report I actually want to read

I want a completion report to let me reconstruct what happened: here is the context, here is the action attributed to it, here is the observed check, and here is what remains unknown. Missing evidence should stay missing.

That may sound less impressive than “the agent learned.” It is much more useful when you are responsible for the software. It gives you a place to investigate, a claim you can challenge, and a record another person can understand.

The lesson I keep returning to is that memory quality includes honesty about its own contribution. Remembering more is valuable only when the system also becomes better at describing what it knows.

NEXT NOTEI made it stream. It got slower.