Working Memory: Scratchpads, Blackboards, and Agent Notebooks
Agent working memory using scratchpads, typed state, notebooks, and multi-agent blackboards.
A conversation buffer does not reliably represent task state. A long-running coding agent may retain recent messages yet lose the list of migrated files, unresolved questions, and rejected approaches. Working memory gives the harness a structured task state that can be updated and re-injected independently of chat history.
The task-state contract
Working memory is structured task state that the harness serializes into the prompt. It may use typed fields, a key-value store, a graph node, or a file. The agent updates it through an explicit tool or structured directive, and it survives eviction of the messages that produced it. At task completion, the harness can discard it or promote selected items into episodic or semantic memory.
The short-term conversation buffer remains message-shaped and is usually evicted by age or token pressure. Long-term episodic storage persists across tasks, while model activations disappear after each forward pass. Working memory occupies the middle: an editable, auditable notebook for the current task.
Chain-of-thought scratchpads
The simplest working-memory substrate. The model writes structured prose into a thought channel (the <thinking> block in extended-thinking mode, the Thought: line in classic ReAct, or an unstructured “scratch” assistant turn) and the harness either keeps that text in the buffer or extracts it into a side channel for the next turn.
When this is right. Short-horizon tasks, single-shot reasoning chains, anywhere the cost of structured state would exceed the cost of letting the model recompute. The original ReAct paper (Yao et al., 2022) uses exactly this; the thought/action/observation sequence is the scratchpad, replayed in full to the model on every step.
When this is wrong. Anything that runs past 20 turns. The scratchpad grows linearly in the chat log, falls into the eviction-middle of the short-term memory buffer, and the lost-in-the-middle effect kicks in. By turn 60 the model has the scratchpad textually but isn’t attending to most of it. The structured-state substrate below is the upgrade.
Anthropic’s “think” tool is the modern incarnation. Anthropic’s think-tool post (March 2025) describes it as “a designated space to stop and think about whether it has all the information it needs to move forward” during response generation, not before. The think tool is a chain-of-thought scratchpad with a tool boundary; the model invokes it explicitly, the contents land in a tool_use block, and the harness can choose to keep or evict it on the next turn. τ-Bench airline-domain numbers in the post show a 54% relative improvement when paired with optimized prompting. Treat it as a structured CoT scratchpad with explicit eviction control rather than something exotic.
Typed state objects
The harness exposes a typed state schema. The agent (model + tools) reads and writes named fields. The harness re-serializes the schema into the prompt on every model call, optionally elided to the fields the current node needs.
This is the default in LangGraph, OpenAI’s Agents SDK RunContextWrapper, and Letta’s core memory blocks.
Python: LangGraph state with overwrite vs append channels
| |
The point is the separation. messages is the conversation buffer (short-term memory). plan, completed, notes are working memory; typed, explicit, with per-field reducers chosen for the access pattern. On turn 90 the chat buffer can be aggressively trimmed; the working-memory block is re-injected in full and the agent never loses the plan. This is also how you avoid the token-accumulation bug in recursive agent loops: an overwrite reducer on plan keeps the field bounded even after 200 revisions, where an append reducer would grow linearly.
TypeScript: OpenAI Agents SDK with a typed context
The OpenAI Agents SDK (TypeScript) exposes the same idea through a typed context object accessible from tools and lifecycle hooks.
| |
The instructions function is the working-memory renderer. The typed WorkingMemory is the actual state. The two are coupled by the agent’s contract: tools mutate the typed state, the instructions render it back into the prompt on every turn. This is the typed-dataflow-graph substrate in OpenAI-Agents-SDK terms. The official cookbook Context Engineering for Personalization is the production-grade reference for the pattern.
External notebooks
The model invokes a tool to write to a file or key-value store outside the prompt. Reads happen via the same tool on demand. The notebook persists across turns and, with a backing store, across sessions; at which point it starts to overlap with long-term memory (a related article in the subtree).
Anthropic’s memory tool, released as the memory_20250818 server-side tool type, is the canonical reference. The tool exposes view, create, str_replace, insert, delete, and rename commands operating on a client-side /memories directory. The harness implements the file operations locally; the model invokes them via tool calls. The auto-injected system-prompt instruction tells the model to always view the memory directory before doing anything else and to record progress as it goes; explicitly framing the tool as a working-memory substrate that survives both context-window eviction and full-session resets.
| |
The trade with the notebook substrate is explicitness for latency. Every read costs a tool round-trip. The typed-state-object substrate is free to read (it’s in the prompt every turn); the notebook is paid-per-read. The right call depends on working set size: if the working memory fits in a 2KB block, render it every turn and skip the tool; if it grows past tens of KB and most of it is irrelevant to most steps, the notebook lets the agent page in only what it needs; the same JIT-vs-AOT context engineering decision, applied at the working-memory layer instead of the retrieval layer.
Letta’s core memory blocks implement the same idea with a different boundary: a fixed set of small, addressable working-memory blocks (persona, human, scratchpad) that the agent edits through core_memory_append and core_memory_replace tools, with the contents always visible in the prompt. Same pattern, different ergonomics; Letta’s blocks are always in-context; Anthropic’s /memories directory is in-context only on demand.
Shared blackboards
When working memory is shared across multiple agents, the substrate becomes a blackboard. The 1971 Hearsay-II architecture is the canonical reference: a global typed store, multiple knowledge sources reading and writing concurrently, a scheduler activating the next knowledge source based on board state.
The 2025 LLM blackboard papers replay the same pattern with LLMs as the knowledge sources: a central controller posts the problem onto a shared board, sub-agents inspect the board and self-nominate based on what’s relevant to their role, results land back on the board, the loop continues until the controller decides consensus has been reached. The reported gains over baselines come from two places; agents self-selecting based on board state (no central router), and shared visibility cutting redundant work across agents.
The implementation surface is what you’d expect from a distributed shared-memory system: every read needs a stable snapshot; every write needs conflict resolution (last-writer-wins is the floor; CRDT-style merges are the ceiling); the split-brain failure mode from the multi-agent orchestration article is the same disease here, applied to the working-memory layer instead of the messaging layer. The deeper treatment lands in the multi-agent shared memory article; the four sharing patterns (supervisor-mediated, shared-block, cross-thread store, blackboard) and the four consistency questions every one of them has to answer; for now the takeaway is that the blackboard is the multi-writer specialization of the typed-state-object substrate, with concurrency control bolted on.
Further reading
- Cognitive Architectures for Language Agents (Sumers, Yao, Narasimhan, Griffiths, 2023); §3 defines the working-memory concepts used here.
- Anthropic; Memory tool; the official reference for the
memory_20250818server-side tool, the auto-injected memory protocol, and the security/path-traversal model. The cleanest official answer to “what does a notebook substrate look like in production.” - LangChain; Context Engineering for Agents (July 2025); frames scratchpads as “write context” alongside compress/select/isolate. The clearest taxonomy of where in an agent harness working memory fits.
- Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture (Lu & Sasaki, 2025); the modern revival of the Hearsay-II blackboard pattern for LLM agents, with empirical numbers on commonsense, reasoning, and math benchmarks. Pair with the Hearsay-II retrospective to see how little the architecture has changed in fifty years.