Memory and State Management
Working Memory
What it is
The small set of items an agent is actively manipulating to finish the step in front of it: the current sub-goal, the result of the tool call that just returned, the half-built answer, the loop variable it is iterating over. Its defining property is not where it is stored but that everything in it competes for one attention budget, so admitting an item costs the salience of the items already there. It is rewritten on every iteration and is not expected to survive the step that created it.
Why it matters
Long agent runs rarely fail because a fact was missing. They fail because the fact was present and crowded out — the task statement sixty turns back, the constraint stated once in the system prompt, the identifier buried in a 40,000-token API response. Deciding what is in front of the model at the moment of a decision, as distinct from what merely exists somewhere retrievable, is the whole of this capability. Everything else in a memory system is upstream of it.
Key decisions
- Whether the active set is implicit in prompt assembly or an explicit structure the agent reads and writes with named operations. Externalising it removes the capacity ceiling and adds a read step to every decision the agent makes.
- Whether the goal and constraints are restated near the point of decision each step or stated once at the top and left to compete with everything appended after them.
- Whether tool results enter whole or are reduced on arrival. Reduction on arrival is the only control that prevents one oversized payload from displacing the plan.
- Eviction order once the active set exceeds its budget: oldest first, lowest-salience first, or a hand-ordered priority that pins the goal and the constraints permanently.
- Whether the active set is renderable and inspectable as one artefact, so that a failed step can be diagnosed from what the model actually had rather than from what it should have had.
Failure modes
- Goal drift. The instruction sits at position zero, forty tool outputs accumulate behind it, and the agent begins optimising whatever it read most recently.
- A single large tool result evicts the plan, and the agent re-plans from scratch mid-task with no memory that it had already chosen an approach.
- On-arrival reduction discards the one identifier the next step needed; the agent re-issues the same call to recover it, reduces it the same way, and loops.
- The externalised scratchpad grows without limit because appending is trivial and compaction was never written, so the capacity problem returns in a different store.
- The active set is assembled by string concatenation in three unrelated code paths, and nobody can reconstruct what the model saw on the turn that went wrong.
- The scratchpad is overwritten in place, so one bad write destroys the last state the agent could have resumed from.
Related capabilities
- Short-term Memory — the session-scoped pool a step draws items from
- Memory Retrieval — how an item from any store gets selected into the active set
- State Checkpointing — making the active set durable at a resumable point
- Memory Consolidation — what reduces an overflowing set into fewer, denser items
Applies: Production readiness · Design questions