What is working memory?
Working memory is the active, in-progress state an agent maintains while carrying out a single task, intermediate reasoning steps, tool results gathered so far, a plan’s current progress, distinct from the conversational memory covered elsewhere in this collection, which tracks dialogue turns, and from persistent memory, which survives across entirely separate sessions. Working memory exists specifically for the duration of one task’s execution, accumulating and organizing the information an agent needs to actually complete that task correctly, and it’s discarded once the task finishes, unless something within it gets deliberately carried forward into longer-term storage.
Why a multi-step task needs its own dedicated state beyond conversation history
A simple, single-turn request doesn’t need much beyond the conversation itself, but a genuinely multi-step task, researching a topic across several tool calls, working through a multi-part calculation, executing a sequence of dependent actions, accumulates state that isn’t naturally captured just by the back-and-forth conversational exchange covered throughout this collection’s discussion of conversational memory. An agent midway through a five-step task needs to track which steps are already complete, what each completed step actually produced, and what still remains to be done, information that’s structurally different from a simple record of what’s been said in conversation.
Working memory exists specifically to hold this task-execution state in an organized, purpose-built form, rather than forcing an agent to reconstruct its own progress by re-reading and re-interpreting an undifferentiated conversation transcript every time it needs to know where a task currently stands. This connects directly to the broader discussion of agent harnesses and execution loops covered throughout this collection, a well-built agent harness maintains working memory as a first-class part of its architecture, not as an afterthought inferred loosely from conversation history.
What actually gets held in an agent’s working memory during a task
Working memory typically holds several distinct kinds of information together, the task’s current plan or intended sequence of steps, results already gathered from completed tool calls or retrieval operations, and any intermediate conclusions or partial results the agent has reasoned its way to so far. This is meaningfully different from simply appending every tool call’s raw output to a growing conversation, working memory organizes this information in a structured way that reflects the task’s actual shape, which step produced which result, what still depends on what, rather than as an undifferentiated, chronological log a model has to parse and reinterpret from scratch at every step.
This structural organization matters directly for task reliability, covered throughout this collection’s broader discussion of agent verification, an agent working from well-organized working memory can more reliably track exactly what it has and hasn’t already established, reducing the risk of redundantly repeating an already-completed step or, worse, proceeding with a later step based on a misremembered or garbled understanding of an earlier one’s actual result.
Why working memory has the same capacity constraints context does, but for a different reason
Like conversational memory, working memory ultimately has to fit within a model’s context window for the model to actually use it during reasoning, connecting directly to the context management discussion covered throughout this collection. But the pressure on working memory’s capacity comes from a genuinely different source than conversational memory’s, a long conversation grows because of how much back-and-forth dialogue has accumulated, while a complex task’s working memory grows because of how many steps, tool calls, and intermediate results that task’s actual execution has required, a task can generate a large amount of working memory even within what looks like a fairly short, simple conversation from the outside.
This distinction matters for how a system manages working memory as a task grows more complex, the same compression and summarization techniques covered throughout this collection’s discussion of memory compression apply here too, but applied specifically to task-execution state, summarizing completed, no-longer-actively-needed steps while preserving full detail for whatever’s still actively relevant to the task’s remaining, unfinished work.
Why losing track of working memory mid-task produces a distinctly disruptive failure
An agent that loses or garbles its working memory partway through a multi-step task doesn’t just produce a slightly worse response, it can genuinely derail the entire task, repeating already-completed steps unnecessarily, contradicting an earlier established result, or proceeding as though a step succeeded when it actually failed, connecting directly to the agent verification concerns covered throughout this collection’s broader discussion of that topic. This failure mode is distinctly more disruptive than a comparable lapse in conversational memory, since a multi-step task’s later steps often depend directly and specifically on earlier steps’ actual results in a way ordinary conversation usually doesn’t require with the same precision.
This is why working memory deserves particularly careful engineering for any system executing genuinely multi-step, dependent tasks, treating it as a structured, actively maintained record rather than something loosely inferred from conversational context, since the cost of losing track of working memory partway through a complex task is considerably higher than the cost of a comparable lapse in simpler, single-turn conversational memory.
How working memory relates to the broader memory hierarchy this collection covers
Working memory, conversational memory, and persistent memory form a natural hierarchy by scope and duration, working memory lasts for one task’s execution, conversational memory lasts for one conversation, persistent memory lasts across a system’s entire relationship with a user or an ongoing body of work. Information can flow between these layers deliberately, a conclusion reached in working memory during one task might get summarized into conversational memory for the rest of that conversation, and something established in conversation might eventually get promoted into persistent memory if it’s judged significant enough to retain long-term, covered throughout this collection’s discussion of persistent AI memory.
Recognizing this hierarchy clearly helps a team design each layer with the scope and lifespan it actually needs, rather than conflating all three into one undifferentiated notion of “memory” and applying the same techniques uniformly across layers that genuinely operate on different timescales and serve different purposes within an agent’s overall architecture.
Common mistakes teams make around working memory
1. Relying purely on raw conversation history to track multi-step task progress rather than maintaining structured, purpose-built working memory.
2. Applying conversational memory management techniques directly to working memory without accounting for how differently their capacity pressure actually builds up.
3. Underestimating how disruptive losing track of working memory mid-task actually is compared to a comparable lapse in ordinary conversational memory.
4. Conflating working memory, conversational memory, and persistent memory into one undifferentiated concept rather than designing each layer around its actual scope and lifespan.
5. Having no deliberate mechanism for promoting genuinely important conclusions from working memory into longer-lived conversational or persistent memory once a task completes.
What connects these mistakes is underestimating how much a genuinely capable agent depends on well-organized, purpose-built working memory specifically for tracking multi-step task execution, a capability that’s structurally distinct from simply remembering what’s been said, and a system that treats working memory as an afterthought tends to produce agents that lose track of their own progress in ways that are considerably more disruptive than an equivalent lapse in ordinary conversational memory.
The deeper point about working memory is that completing a genuinely complex task requires more than access to information, it requires actively tracking where a task currently stands, what’s already been established, and what remains, and building that tracking capability deliberately, rather than hoping a model reconstructs it correctly from an undifferentiated history every single time, is what separates an agent capable of reliably executing multi-step work from one that only handles simple, single-turn requests well.