AI agents that run autonomously hit a wall that looks like a context window problem and is not one. The process runs for hours, gets interrupted, comes back, and either repeats work it already finished or takes a path that contradicts a decision it made an hour earlier. Making the window bigger does not fix it, because the thing being stored was never the right thing.
Conversation history is a log of what was said. Agent memory is a structured record of what was learned, what was tried, what worked, what failed, what the current state of each task is, and how the entities involved relate to each other. Those are different data structures with different lifetimes, and treating one as the other is where most agent builds go sideways.
Working Memory vs Long Term Memory
Working memory is the active context for a single task execution: the current goal, the plan, intermediate results, the step the agent is on, and freshly discovered information that has not been validated yet. It is fast, small, and volatile. In practice it maps to the context window plus whatever scratchpad or state variables you keep during one agent loop.
Long term memory is the persistent store of validated knowledge accumulated across every session. It holds facts about the environment (which services depend on which databases, who owns each component), learned procedures (the sequence of steps that actually diagnosed a connection pool issue last time), and episodic records (specific incidents, their causes, their resolutions). It is slower to reach because retrieval is a step, but it survives restarts and it grows.
The interesting part is the promotion between them. The naive approach dumps the whole conversation into long term storage, which fills the store with low value intermediate steps and quietly degrades retrieval quality the longer the system runs. The effective approach is selective: when a task completes, store the outcome, the key decisions, and anything surprising, then discard the step by step reasoning that led there. It is roughly what memory consolidation does during sleep, keeping the pattern and dropping the noise.
How Multiple Agents Share One Store
Multi agent systems create memory problems single agents never face. Without a shared store, two agents investigating the same incident will independently rediscover the same fact, and neither will benefit from what the other ruled out. There are a few patterns worth knowing.
A shared memory bus gives every agent read and write access to one store. Simple, and it works when agents have complementary roles and low risk of conflicting writes. The weakness is pollution: one agent writing verbose low confidence notes degrades retrieval for everyone.
Scoped namespaces give each agent its own write space with read access to the others. Agent A writes to research, Agent B writes to execution, both can read both. This prevents write conflicts while preserving sharing, and a coordinator can promote validated findings into a shared namespace.
The blackboard pattern posts observations to a common space where a control component decides which agent runs next based on what is on the board. Event driven updates go further: a new memory fires an event that wakes the agent whose specialty it touches. That cuts coordination overhead, at the price of needing circuit breakers so Agent A's finding does not trigger Agent B whose finding retriggers Agent A.
Whatever the pattern, conflicts are inevitable, and last write wins is the wrong default. When two agents record contradictory explanations, keep both with source attribution and confidence scores. Later corroboration raises one and lowers the other, and the retrieval ranking sorts it out without anything being silently deleted.
Checkpointing Facts Instead Of Transcripts
Any agent that runs long enough will be interrupted. Checkpointing is the standard answer: at each significant step, write the current goal, the plan, which steps completed, and the results so far. Checkpoint after every tool call and you get fine grained recovery with latency on every operation. Checkpoint at task boundaries and you get coarser recovery with much lower overhead, which is the right trade for most systems.
The detail that matters is what goes into the checkpoint. LLM agents do not have deterministic state, so replaying a stored conversation can produce a different continuation than the one that already ran. Store the factual state instead, then rebuild a fresh context from those facts on resume. The restarted agent decides from what is known rather than from a transcript that might lead it somewhere new.
Event sourcing is the alternative: log every action and observation as an immutable event and replay to reconstruct state. You get a complete audit trail and the ability to inspect any past point in time, at the cost of replay time growing with the log, so long running agents need periodic snapshot compaction. It earns its complexity when you need the audit trail for compliance or for reviewing high stakes decisions after the fact.
The Takeaway
If your agent forgets, the question to ask is not how big the window is. It is whether anything is being written down that is not a transcript. Working memory for the live task, long term memory for what survived it, selective promotion between them, checkpoints holding facts rather than chat, and namespaces with confidence scores once more than one agent is involved.
Full breakdown of the patterns, the benchmarks behind the failure modes, and the implementation guides: https://www.adaptiverecall.com/ai-agent-memory/
Top comments (0)