Episodic and semantic stores live mostly outside the model. Working memory is what the agent can attend to right now: the context window, scratchpad, ReAct trace, and graph state. It is the bottleneck that makes retrieval, summarization, and planning necessary.
LangGraph makes working memory explicit as typed state; agent loops grow it every tool call. The next lecture, long-term memory, is what you persist when this scratchpad is gone.
Learning Objectives
By the end of this lesson, students should be able to:
- Define working memory as capacity-limited, task-local state in the current run.
- Map working memory onto context windows, scratchpads, and graph state objects.
- Explain why tool results and RAG chunks compete for the same token budget.
- Apply compaction: summarize, drop, or offload to long-term/episodic stores.
- Contrast ReAct scratch vs LangGraph state vs multi-agent message buffers.
- Avoid the “infinite chat log” anti-pattern.
Working memory is the agent’s short-lived workspace for the active goal: messages, thoughts, tool observations, retrieved snippets, and intermediate artifacts that must fit in the model’s attention (or an equivalent state object) to influence the next action.
The Token Budget Is the Architecture
Every extra tool observation, RAG chunk, and chat turn consumes working memory. When the window fills, the model forgets early constraints, repeats tools, or ignores HITL instructions. Treat the prompt as RAM, not a warehouse. Long-term and episodic stores are disk; retrieval is a page fault.
| Working-memory slot | Role in the loop | Overflow tactic |
|---|---|---|
| System + goal | Hard constraints | Never drop; pin at top |
| Scratch / thoughts | ReAct / plan notes | Summarize every N steps |
| Tool observations | Fresh evidence | Keep last k; archive rest |
| Retrieved semantics | Facts for this step | Re-retrieve; don’t accumulate |
| HITL messages | Human corrections | Pin until goal changes |
Three Implementations You Will See
Context Window
- Raw messages to the LLM
- Simplest; opaque to code
- Hard token cliff
Scratchpad Object
- Structured fields in code
- You choose what to serialize
- Used by ReAct agents
Graph State
- Typed dict / reducer
- LangGraph checkpoints
- Resumable + HITL interrupts
Compaction Sketch
A production single-agent loop should compact working memory before each LLM call. The pattern below keeps pinned constraints, a rolling recap, and only the latest observations.
Multi-Agent Working Memory
Multi-agent systems multiply scratchpads: each role has a buffer, plus a shared blackboard. CrewAI and AutoGen often leak entire chat histories between agents—that is working-memory explosion, not collaboration. Prefer passing artifacts (a research brief, a schema, a recap) rather than full transcripts.
Strengths
- Immediate control over next action
- Explicit state enables HITL resume
- Compaction is a measurable skill
- Maps cleanly to graph reducers
Tradeoffs
- Hard capacity (tokens / RAM)
- Over-summarization loses details
- Hidden dumps in frameworks
- Vanishes when the process dies unless checkpointed
“A 128k context means we do not need memory architecture.” Long windows still degrade attention, raise cost/latency, and mix stale tool junk with fresh goals. Working memory is a design problem: what is pinned, what is summarized, what is offloaded to long-term stores.
Knowledge Check
- Short Answer: What is working memory for an LLM agent? Answer: The capacity-limited live workspace (prompt/state) for the current goal.
- True/False: Chat history unbounded is a valid working-memory strategy. Answer: False—it is an anti-pattern.
- Multiple Choice: LangGraph working memory is typically: (a) typed graph state, (b) a CSS theme, (c) GPU firmware. Answer: (a).
- Short Answer: Name one overflow tactic for tool observations. Answer: Keep last k and summarize/archive the rest.
- True/False: HITL corrections should usually be pinned in working memory. Answer: True.
- Multiple Choice: Semantic RAG chunks in the prompt are: (a) long-term disk only, (b) working memory once retrieved, (c) episodic by definition. Answer: (b).
- Short Answer: Why do multi-agent chats explode working memory? Answer: Full transcripts are copied between agents instead of compact artifacts.
- True/False: A large context window removes the need to retrieve from long-term stores. Answer: False.
- Multiple Choice: Compaction happens: (a) after training CNNs, (b) before/during LLM calls in the loop, (c) only at deploy time. Answer: (b).
- Short Answer: What persists after working memory is gone? Answer: Long-term memory (and written episodes/semantics).
Key Takeaways
- Working memory is the live, limited scratchpad: prompt, ReAct trace, or graph state.
- Pin goals/constraints/HITL; compact observations; re-retrieve facts.
- Long context ≠ infinite attention or free cost.
- Multi-agent designs must pass artifacts, not raw transcripts.
- Continue with Long-Term Memory.
Lab: Run a 12-step dummy tool loop with and without compaction; plot prompt tokens and whether the model still recites the original constraints.
Whiteboard: RAM vs disk: working vs long-term/episodic/semantic. Mark checkpoint = snapshot of working memory for HITL resume.
Recap: Working memory is scarce attention. Continue with Long-Term Memory.