What Is a Scratchpad in AI Agents? Working Memory Explained

Agents need somewhere to put what they have worked out, and the default is to let it accumulate in conversation history where it mixes with everything else. A deliberate scratchpad separates conclusions from transcript, which improves both the agent's performance and your ability to understand what it did. This explainer covers how to design one. It complements what is an agent loop and what is a context budget, and reflects FISTA Solutions' approach in AI agents delivery.

What does it hold?

What the agent has established. Findings from tool calls — this customer's account status, this record's contents. Decisions made and why. Constraints discovered along the way. Open questions still to resolve.

That is different from conversation history, which records what was said. A scratchpad records what is now known, which is both smaller and more useful to carry forward.

Content	Belongs in scratchpad	Belongs in history
Established facts	Yes	No
Decisions and rationale	Yes	No
Open questions	Yes	No
Raw tool responses	No, filtered	Traced separately
User's exact wording	Sometimes	Yes
Constraints stated	Yes	Yes

Why is structure better than free text?

Because structured fields can be validated, pruned, and carried forward selectively. A scratchpad with named slots — findings, decisions, open questions, constraints — can drop resolved questions and keep established facts, mechanically.

Free text cannot be pruned reliably, since nothing marks which parts still matter. It grows across a run until it dominates the context, and summarising it requires another model call whose fidelity is unverified.

How does it affect the context budget?

Directly, because the scratchpad is included in every subsequent step. An unbounded one consumes an increasing share of the window as the run progresses, crowding out the goal, the constraints, and the retrieved evidence.

That is a common and under-diagnosed cause of agents that start well and degrade after several steps. The symptom looks like the model losing track; the cause is that the goal is now competing with eleven steps of accumulated notes. See what is a context budget.

Why does it help debugging?

Because it shows what the agent believed at each point. A failed run's scratchpad usually pinpoints where a wrong conclusion entered — a tool result misread at step three, a constraint dropped at step five — which the final output and the tool call sequence do not reveal.

For agent systems it is frequently the single most informative artefact in an investigation, which is an argument for making it explicit rather than leaving it implicit in history.

When should it persist?

Whenever a run can pause. Approval gates, rate limits, dependency outages, and long-running operations all interrupt agent work, and a persisted scratchpad is what allows resumption rather than restarting.

That requirement — serialisable working state — should be designed in early, because retrofitting it means changing how every step communicates.

What should go in it?

Decided, not accumulated. The temptation is to append everything, which recreates the unbounded history problem inside a new container. Defining what each step should record — and what it should not — is the design work, and it is what keeps the scratchpad useful at step twenty.

What should you do first?

Take a failed agent run and try to determine where it went wrong from your current telemetry. If you cannot, an explicit scratchpad is what would have told you, and adding one is usually a contained change to how steps pass state.

How does this relate to memory?

A scratchpad is working memory for one task; agent memory persists across tasks and sessions. They are frequently conflated and should not be, because the retention rules differ: a scratchpad is discarded when the task completes, while memory is retained deliberately and needs its own policy on what is kept and for how long.

Mixing them produces either a scratchpad that never clears — accumulating irrelevant history from unrelated tasks — or a memory that loses everything when a task ends. Separating them lets each follow the rules it needs.

Should users see it?

Sometimes, and it is worth deciding rather than defaulting. For long-running tasks, showing what the agent has established so far is reassuring and lets a user correct a wrong conclusion early rather than after the outcome. For short interactions it is noise.

Where it is shown, it should be the structured content rather than raw reasoning, because a reasoning trace presented to a user invites them to evaluate the process rather than the result, and they are rarely equipped to do that usefully.

How FISTA Solutions helps

FISTA Solutions designs agent scratchpads as structured state with defined fields rather than accumulated free text, prunes resolved content to protect the context budget, persists working state so runs can pause and resume across approvals and outages, and uses scratchpad traces as the primary debugging artefact, through AI agents, AI enablement, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To build agents that hold their reasoning without losing the thread, message FISTA on WhatsApp, or read what is an agent loop.