Forgetting & Conflicts

A memory system that remembers everything eventually remembers too much. Session history bloats. Semantic facts accumulate contradictions. The system that never forgets becomes the system that cannot find what matters — an agent with perfect recall and no forgetting is the coworker who answers every question by reading out their entire diary.

Forgetting isn't loss. For an agent, it's closer to hygiene.

The most interesting failures are conflicts

An old episode says issue #9: open, assigned, not approved. The current thread says the approval comment now exists. A weak memory system treats this as a retrieval problem — grab something related, stuff it in the prompt. A strong one treats it as a state problem:

When was this true? What was true then? What is true now? Which procedure governs the current action? What should the agent verify before moving?

Each memory type has its own hygiene

working      needs SELECTION     — what makes the desk this turn
episodic     needs COMPRESSION   — sessions → summaries → facts
semantic     needs CONFLICT      — new truth outranks old truth,
             RESOLUTION            old truth preserved as history
procedural   needs MAINTENANCE   — stale workflows retired before
                                   they drive confident wrong edits

The practical strategies:

• Temporal decay — older memories lose priority unless pinned, recently used, or tied to durable policy
• Contradiction handling — a new fact updates current state; the old one stays as history, not as an equal
• Compression — detailed sessions become summaries; summaries become facts; repeated ways of working become procedures
• Manual curation — some memories are too important for automatic extraction: project rules, approval gates, production-facing checks need an owner

The five questions

When you build or evaluate an agent's memory, ask:

1. What is in working memory right now? What did the model actually see on this turn?
2. Which past session matters? Can the agent find those events, tool calls, outcomes?
3. Which facts are current? How are user facts, project facts, and preferences stored and updated?
4. Which workflow applies? Are procedures encoded as tools, skills, or orchestration code?
5. What should be forgotten? How does old state lose priority? Who owns the procedures?

If you can answer them, you're looking at an architecture. If you can't, you have scattered state — and scattered state works right up until the agent remembers the wrong thing and continues with confidence.

The model can only act on what reaches the context window. The harness decides what gets there. That is where memory becomes architecture.