Scratchpad

A model doing something long has intermediate work: partial findings, a list of files still to check, an evolving theory of a bug. That work has to live somewhere. By default it lives in the conversation, where it competes with everything else for space and gets summarised away at the worst moment.

A scratchpad gives it somewhere else to live.

Two forms, different jobs

In-context, as a section of the response the model is told to use for working before answering. Cheap, needs no tooling, and disappears with the session:

Use a <scratchpad> section to work through this before answering.
Only the text after </scratchpad> is shown to the user.

On disk, as a file the model appends to and re-reads. Survives compaction and the session ending, and is inspectable by you. This is the form that matters for long tasks:

## Investigating: intermittent 500s on /checkout

Checked
- app logs: no stack traces at failure times
- db slow query log: nothing above 200ms

Current theory
- upstream timeout, not our code. Next: check the payment gateway's status page.

Why it helps beyond tidiness

• Findings stop being lost. Without a scratchpad, "already checked the db logs" lives only in history, and after a compaction the agent checks them again.
• The theory becomes correctable. You can read the current theory and say "no, it started after Tuesday's deploy" rather than watching it pursue a dead end.
• It separates working from output. The answer stops carrying the reasoning debris that made it.

Keeping it useful

• Append, then prune. A scratchpad that only grows becomes the thing it was meant to prevent.
• Record conclusions, not keystrokes. "db logs clean" beats pasting the log.
• Say explicitly when to read it back. A file the model writes and never re-reads is a diary, not memory.