Working Memory
The model can only see what is in the window. Overflow silently drops the system prompt or the user's goal.
Your desk: only what is on it is usable. The rest is in a cabinet.
Visual Workflows
Start here — scroll inside each diagram frame to explore, then use + / − to zoom up to 200% if needed.
Overview
Scroll inside the frame to explore · use + / − to zoom up to 200%
Scroll inside the frame to explore · use + / − to zoom up to 200%
One reasoning step
Scroll inside the frame to explore · use + / − to zoom up to 200%
Everything the model reads this step is working memory.
Key Takeaways
- 1.Working memory is the agent's RAM — what fits in the context window now. It holds the prompt, recent turns, tool results, and scratch notes.
- 2.When the window fills, oldest or least useful tokens must go. Watch token count every step of a long task.
- 3.Working memory is not a database. It is the messages you send this call.
- 4.Truncate, summarize, or slide when you approach the cap.
Learn elsewhere
- →Summarization — later in this phase
- →Long-term stores — Long-Term Memory
Real Example
Scenario
A 20-step coding agent keeps the current file, last terminal output, and five user messages — not the whole repo.
What you would do
In Agent Memory, apply Working Memory to this scenario: A 20-step coding agent keeps the current file, last terminal output, and five user messages — not the whole repo. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.
Commands
Commands to Remember
Working memory = this call's tokensCount tokens every stepTruncate or summarize when fullNever drop the system prompt first
Cheat Sheet
Quick recap
quick ref- •RAM, not a filing cabinet
- •Prompt + history + tools
- •Cap is hard
- •Protect the system prompt
Common Mistakes
- ✕Appending every tool dump forever
- ✕Letting the system prompt fall off the front
- ✕Ignoring token counts until the API errors