What struck me here is how both humans and agents drift into the same failure pattern: once a rule “looks settled” no one checks if reality has moved on. The fix the piece suggests is almost disappointingly simple yet hard to practice in real systems. Decide ahead of time which constraints must always be re-opened at the source and how far anything is allowed to reach when no one is paying close attention. It feels less like an AI safety insight and more like a general lesson in institutional memory and how quietly it goes stale.
The institutional-memory reading is the one I keep coming back to. A "do not contact X" rule in our own outreach list is exactly this: written after a bad day, never revisited, and by the time it is wrong nobody remembers why it was there. The paper says the agents behave the same way for the same reason. The uncomfortable part is that the cheap fix, deciding up front which rules always get reopened, is a policy decision, not a model improvement, so it has to be made by whoever owns the system.
Checking a rule's source takes one step: open the record the memory points to before you act on it. The models in our paper had that step available and took it about one time in five.
The part I did not expect: the fix was not telling the agent "this memory might be old." That did nothing. What worked was deciding in advance which memory gets checked every time, the one that limits your options. Same for people, if Yocco is right: the checking has to be built into the workflow, or it quietly stops.
Which rule would you make your agent re-check every single time, no matter what? I'll go first: anything that says "do not contact X." Those get written after something went wrong, and they are exactly the ones that go stale when the situation changes.
What stood out to me is that the problem isn’t simply whether AI agents have accurate memories, but whether they know when those memories should be questioned. As agents become more autonomous, stale constraints could quietly shape thousands of decisions without anyone noticing. The finding that a simple verification rule dramatically improves performance suggests that good agent memory needs more than storage and retrieval—it needs mechanisms for expiration, provenance, and deliberate re-checking. “Remembering” well may ultimately require knowing what to distrust.
Thank you, Jim. "Knowing what to distrust" is the right frame, and the paper's most uncomfortable detail is that distrust cannot be attached to the memory itself. We tried the obvious thing, telling the model that a memory might be out of date, and it did nothing. The staleness is not visible in the memory; it is only visible at the source, after you have opened it. So expiration by timestamp would not have helped either, because the withdrawn rule was not old, its source had simply moved on.
What moved the number was structural: decide which kind of memory gets its source opened every time, before the task starts. The content-blind version of that rule, "check the memory that limits your options," recovered most of the gap on its own. Which suggests the mechanism you describe, expiration plus provenance plus re-checking, needs one more piece: a standing priority for which record gets the budget when the budget is small. Curious whether you have seen anything like that in the agent frameworks you use, or whether the budget is still spent first come, first served.
What struck me here is how both humans and agents drift into the same failure pattern: once a rule “looks settled” no one checks if reality has moved on. The fix the piece suggests is almost disappointingly simple yet hard to practice in real systems. Decide ahead of time which constraints must always be re-opened at the source and how far anything is allowed to reach when no one is paying close attention. It feels less like an AI safety insight and more like a general lesson in institutional memory and how quietly it goes stale.
The institutional-memory reading is the one I keep coming back to. A "do not contact X" rule in our own outreach list is exactly this: written after a bad day, never revisited, and by the time it is wrong nobody remembers why it was there. The paper says the agents behave the same way for the same reason. The uncomfortable part is that the cheap fix, deciding up front which rules always get reopened, is a policy decision, not a model improvement, so it has to be made by whoever owns the system.
Checking a rule's source takes one step: open the record the memory points to before you act on it. The models in our paper had that step available and took it about one time in five.
The part I did not expect: the fix was not telling the agent "this memory might be old." That did nothing. What worked was deciding in advance which memory gets checked every time, the one that limits your options. Same for people, if Yocco is right: the checking has to be built into the workflow, or it quietly stops.
Which rule would you make your agent re-check every single time, no matter what? I'll go first: anything that says "do not contact X." Those get written after something went wrong, and they are exactly the ones that go stale when the situation changes.
Thank you to AfroTech for sponsoring this issue. Fees and open dates are at https://www.passionfroot.me/glasp-newsletter
What stood out to me is that the problem isn’t simply whether AI agents have accurate memories, but whether they know when those memories should be questioned. As agents become more autonomous, stale constraints could quietly shape thousands of decisions without anyone noticing. The finding that a simple verification rule dramatically improves performance suggests that good agent memory needs more than storage and retrieval—it needs mechanisms for expiration, provenance, and deliberate re-checking. “Remembering” well may ultimately require knowing what to distrust.
Thank you, Jim. "Knowing what to distrust" is the right frame, and the paper's most uncomfortable detail is that distrust cannot be attached to the memory itself. We tried the obvious thing, telling the model that a memory might be out of date, and it did nothing. The staleness is not visible in the memory; it is only visible at the source, after you have opened it. So expiration by timestamp would not have helped either, because the withdrawn rule was not old, its source had simply moved on.
What moved the number was structural: decide which kind of memory gets its source opened every time, before the task starts. The content-blind version of that rule, "check the memory that limits your options," recovered most of the gap on its own. Which suggests the mechanism you describe, expiration plus provenance plus re-checking, needs one more piece: a standing priority for which record gets the budget when the budget is small. Curious whether you have seen anything like that in the agent frameworks you use, or whether the budget is still spent first come, first served.