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.
| Evidence | What I can reasonably say |
|---|---|
| A delivered lesson revision | This context reached this task |
| An agent-linked action | The agent reports using this lesson |
| A command result and source snapshot | This check ran against this source state |
| A controlled outcome comparison | We can investigate whether memory helped |
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.
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.