What should an AI coding agent be allowed to forget?
We talk a lot about giving AI coding agents more context.
But I’m starting to think the hard...
For further actions, you may consider blocking this person and/or reporting abuse
I like the archive framing, but I’d still want hard deletion for a few classes of memory. Failed migrations, temporary flags, and one-off debugging notes are dangerous if they keep voting in retrieval forever. My default split would be small and boring: invariants stay pinned, decisions get an expiry or owner, and raw session notes drop into history unless someone promotes them.
I like this split. Especially the “expiry or owner” idea for decisions — it gives project knowledge an authority boundary instead of treating everything as permanent memory. The hard-delete case is important too; some context should simply stop existing.
I dont think forgetting is good, instead, weighted memory based on relevance is better, because everything done is remembered to some degree and can affect future actions. Though the more important question to ask, is how do you make an AI remember everything, without it bloating it's own context window. That's the real debate, because people try cherry picking data for memories, store context flash cards, graphDbs, semantic lookup tables, you name it, someone's tried it and nobody can agree that any approach is better or worse at it, because not a single 1 is consistent enough to warrant a success story.
The "archive vs. hard delete" distinction is the right path, but it highlights a deeper architectural problem I’ve been hitting recently: forgetting a fact does not automatically retract the conclusions that were built on top of it.
If an AI agent made an architectural decision 6 months ago (e.g., "Use Redis for this queue") and you simply archive that memory today because you migrated to SQS, the downstream code, tests, and documentation that were generated based on the Redis assumption are still there. They are now structurally stale, but the system doesn't know it.
As @reidmarlow pointed out, raw session notes shouldn't keep "voting" in retrieval forever. But just dropping their weight or archiving them creates a dangerous gap: the agent will hallucinate around the missing context, or worse, confidently use the old downstream artifacts without realizing the root decision was invalidated.
This connects directly to the "Immutable Evidence ≠ Immutable Truth" problem we've been debating in agent verification protocols [1]. The memory that an action happened should remain immutable (archived). But the authority of that memory—its semantic truth value—needs an explicit lifecycle.
Instead of just an "archive" flag, memory needs an explicit state transition:
VERIFIED → REFUTED. If a decision expires or is superseded, it shouldn't just be hidden. It must be explicitly marked as refuted so that any downstream agent or retrieval pipeline programmatically knows that dependencies built on it are now suspect.In my own agent experiments, I've found this propagation to be the hardest part. When a root memory is archived, how do you handle the downstream artifacts that relied on it? Do you explicitly flag them, or does the agent just stumble into the breakage later?
That’s a really important distinction. I think simply marking the root memory as archived isn’t enough if other decisions or artifacts depend on it.
The interesting problem is dependency propagation: if a decision becomes superseded, the system should know which downstream context may now be suspect, rather than silently treating everything as valid.
Suraj, you just hit the exact core of the problem.
Simply marking the root memory as archived creates a dangerous blind spot: the downstream artifacts (code, tests, docs) generated from that assumption are still active and will be retrieved as "valid" context, leading to cascading hallucinations.
In my work on the MSCodeBase Intelligence MCP server, I've found that solving dependency propagation requires anchoring memories to the actual code structure graph, not just storing them as text blocks.
When a root decision (e.g., "Use Redis") transitions from VERIFIED → REFUTED, the system needs to cascade that state transition down to any downstream nodes linked via "generated_by" or "depends_on" edges.
The most effective mechanism I've found is declaring an "invalidation trigger" at write-time. When the memory is created, the agent must define what would make it false (e.g.,
anchor: import redis). When the live codebase changes and that anchor disappears, the protocol doesn't just refute the root memory—it automatically flags all downstream dependencies asSUSPECTrather than valid.This forces the retrieving agent to re-verify the downstream context before relying on it, effectively stopping the semantic drift in its tracks. The architecture has to treat memory not as a flat list of facts, but as a dependency tree with a lifecycle.
I think this is the part that makes the problem much harder than a simple memory hierarchy. A coding agent can't just know that a fact is old — it needs to know whether decisions and artifacts derived from it are still trustworthy. I also agree that letting the LLM decide its own trust boundaries feels risky. The interesting question for me is what signals outside the memory itself should be allowed to invalidate or downgrade it.
I think the interesting part is that “forgetting” doesn’t necessarily mean deleting.
For a coding agent, I’d probably want three kinds of memory:
Some things should stick around for a long time — architectural decisions, security constraints, and rules the project really shouldn’t break.
Some things should naturally expire — temporary workarounds, implementation details, assumptions, or context that was only relevant to a particular task.
And then there’s history things like “we tried this approach six months ago and it didn’t work.” That’s still useful, but I wouldn’t want the agent treating it as a current rule unless there’s a reason to.
So maybe the real problem isn’t “what should the agent forget?” but “what should the agent still trust?”
That feels like a much harder, and more interesting, problem to solve.
Anup, your reframe from "what to forget" to "what to trust" is spot on. That is indeed the much harder problem.
But I think the answer depends heavily on the context of the agent's role. The memory architecture for a general chatbot is going to look radically different from an agent that actively modifies a codebase. In a coding agent, if it "trusts" a temporary workaround as a permanent rule, it introduces cascading hallucinations into the code.
Frankly, I don't know what the right "trust" architecture looks like in production yet. Theoretical models are clean, but real-world codebases are messy. We've seen agents confidently trust their own hallucinated assumptions, which makes me very hesitant to let the LLM manage its own trust boundaries.
Has anyone here seen real-world implementations or longitudinal studies where a 3-tier trust system (or similar) actually survived contact with a messy codebase? I'd love to see data or post-mortems on what actually broke when these memory systems hit production, rather than just the design phase.
I think “what should the agent still trust?” is probably the better question. Availability and trust aren't the same thing — old context can still be useful as history without being safe to use as a current constraint. The difficult part seems to be determining what can change that trust over time.
I think what you're implying isnt necessarily 'forgetting', you mean archiving? So it's never lost, just not as fast to remember?
Yeah, archiving is probably closer to what I mean. I don't think historical context should disappear — the important part is preventing it from influencing current decisions when it's no longer authoritative. So maybe the real problem isn't forgetting, but controlling when and how strongly old context is allowed to matter.
Exactly, essentially 'MoE' architecture, but for memories. Remember what's relevant, ignore what isnt. Though easier conceptualized than applied
depends on your use case honestly. for simple stuff stdlib is enough.