Beyond memory: belief states for long-running agents

When you hand an agent a long job, partway through it may go around in circles in the same place, or keep working from a premise that was supposedly fixed long ago. As the conversation grows, “what has been confirmed and what is still unknown” gets buried in the history. The paper “Beyond Memory: Harnessing Long-Horizon Agents with Explicit Belief States”, posted to arXiv on October 1, 2026, answers this problem not with “how to make it remember history” but with “how to give it a current understanding”. I check what the paper says, then think about what it looks like for an everyday agent such as Claude Code.

Organizing history doesn’t give you a current understanding#

There are two broad ways to give an agent a long history: pass it as is, or pass a summary, a compression or a selection of important parts. The paper points out that both are “records of past evidence”, not an understanding that “the world is like this now”. In a history, premises that operations have since changed are mixed with premises that haven’t. The agent has to reread and guess which still hold, every time.

The paper’s example is a robot that records a microwave as both “open” and “closed”. From the records, it can’t decide whether it should open the door before putting in a mug.

The proposed PoS: make the understanding and the unresolved gaps explicit#

The paper’s PoS (Progression of States) is an inference-time framework that needs no additional model training. At every step, the agent holds these four things.

• World state: the objects relevant to the work (Entity), their current states (State) and the connections among them (Relation). States and relations carry evidence and confidence
• Objective: the task’s goal and the conditions for completion
• Knowledge gaps: what is still unknown or lacks evidence
• Achievement gaps: the difference between the goal state and the current state, to be closed by acting

Separating “what you want to know” from “what you need to do” is the method’s feature. When there are several gaps, it picks the single most valuable one as the “focus” and decides its action from there. It doesn’t discard the overall understanding, and only narrows attention.

Each action brings in new observations, so the agent updates its beliefs. But the update is something the agent wrote itself, so it can contain assumptions and hallucinations. So a Belief Sentinel checks the proposed update. It looks for incompatible states attached to the same object (internal contradiction) and for conflicts with the latest observation (external contradiction), and returns its findings to the agent. The agent corrects against the evidence, and then commits the belief.

Detecting wandering as “Belief Trapping”, and getting out by type#

The other pillar is how it handles what the paper calls Belief Trapping. Even when beliefs aren’t contradictory, an agent can get stuck repeating the same useless action, circling the same states, or continuing to gather information unrelated to the goal.

PoS detects a trap by measuring these three things over the last few steps.

• Gap persistence: the share of the initial gaps that remain throughout the period
• Progress stagnation: the share of transitions with no progress
• Belief recurrence: how often the world state related to the focus reappears in the same form

When it detects a trap, it diagnoses the cause on two axes. One is the movement pattern: “stasis”, where the state doesn’t change at all, “cycling”, where it loops through the same states periodically, and “drift”, where the state changes but the focus doesn’t advance. The other is the type of gap that is stuck (a knowledge gap or an achievement gap). For recovery, it combines two constraints and adds them to the choice of the next action. The constraint for the movement pattern is one of suppressing invalid actions, breaking the cycle, or re-anchoring on the focus. The constraint for the gap type is either to require new decisive evidence or to require an action that changes the situation.

Results: it won everywhere, and organizing history wasn’t always an advantage#

The paper used four benchmarks. The execution tasks are ALFWorld (household work) and LOCA-Bench (work done within a long environment description), and the diagnostic tasks are RCA-100 (root causes of failures) and ClinDiag (clinical diagnosis). The models are Qwen3.7-Plus, Kimi-K3 and GLM-5.3.

The existing methods it compared against were these five.

• Raw history (Raw Trajectory)
• ACON, which compresses
• PACE, which varies the granularity of history by relevance
• HiAgent, which organizes by subgoal
• LongHorizon-Harness, which keeps audited task records

In the paper’s Table 1, PoS had the best value in all 12 combinations. With Qwen3.7-Plus, for example, ALFWorld success was 88.81% for PoS against 62.69% for raw history (the strongest existing method was 72.39%), and RCA-100 accuracy was 38.83% against 24.27%.

What stands out is that the existing “organizing history” methods don’t work reliably. PACE fell well below raw history on LOCA-Bench. On ClinDiag with GLM-5.3, none of the existing methods compared beat raw history (46.85%). The paper’s view is that with recent models that can handle long context, the information lost in compression can cancel out the benefit of reducing redundancy.

The experiments that removed parts of PoS also show where it works. Removing the contradiction check dropped Qwen3.7-Plus on ALFWorld to 73.88%. Removing trap diagnosis and recovery gave 33.98% on RCA-100. The conclusion is that results came only when there were checking and recovery, not just holding beliefs.

In an experiment on LOCA-Bench that stretched the environment description from 8K to 256K tokens, PoS stayed broadly stable from 96K to 256K. The interpretation is that continuing to update the current understanding holds up better against context length than rereading history and reconstructing the situation.

The price: about five times the tokens#

The cost isn’t light. In the paper’s Table 2, tokens per run on RCA-100 (Qwen3.7-Plus) were about 356,000 for raw history and about 1.8 million for PoS. The acting agent’s own consumption fell to about 281,000, but building and maintaining beliefs (about 697,000) and the sentinel’s checks (about 822,000) are added on top. The paper notes that removing the sentinel’s checks or trap diagnosis lowers total tokens but raises the acting side’s consumption and lowers accuracy, and concludes that “the value lies in spending compute on maintaining beliefs, not in minimizing tokens”.

If you translate it to everyday Claude Code#

From here on is my own reading from outside the paper. PoS is a mechanism evaluated on research benchmarks, and the paper has no way to put it into Claude Code as is. But the core of the mechanism can be translated into how you give instructions.

1. Have it write its “current understanding” in a file, not in the conversation

At the start of a long task, have it create a working note (for example, PROGRESS.md). The aim is that this file alone shows where things stand, without rereading history.

Before starting work, create PROGRESS.md and keep it under these four headings.
Update it as you work, and read it first whenever you decide your next move.

## Confirmed facts (with evidence: command output, file names and lines, etc.)
## Unconfirmed (do not proceed on guesses; also write how to check)
## Not yet achieved (the gap against the completion criteria)
## Current focus (pick exactly one from the two above)

These correspond to PoS’s “world state”, “knowledge gaps”, “achievement gaps” and “focus”. Making evidence mandatory follows the paper, where each state carries evidence and confidence.

2. After each update, have it check for contradictions

A note you wrote yourself will contain your own assumptions. As the equivalent of the paper’s sentinel, ask for the following at every update.

After you update PROGRESS.md, before committing to it, check the following.
- Are there any incompatible statements about the same thing?
- Are there any statements that conflict with the output of the last command or test results?
If there is a conflict, fix it based on the output before moving on.

On large tasks, you can also hand the check alone to a separate subagent. But in the paper too, the sentinel’s checks were a large part of the cost. Whether to do it every time or only at milestones depends on how heavy the work is.

3. Decide the signs of wandering in advance

The paper’s three measures translate directly into how to write “conditions to stop”.

If any of the following applies, stop work and report.
- Trying the same command or the same fix three times gives no change in the result (stasis)
- The last few moves are going back and forth between the same states (cycling)
- Work is progressing, but the "current focus" has not moved forward even once (drift)
In the report, say which type it is, and whether the stuck gap is "unknown" or "not yet done".

The number “three” is a rough guide, not a value from the paper.

4. Match the recovery instruction to the type too

After it stops, an instruction matched to the type makes more sense than saying “try harder”. In the paper too, constraints matched to the type gave better results across all benchmarks than a generic “please recover” instruction.

• When stuck on something unknown: “Your next move may only be one that gets evidence to narrow down the candidate causes”
• When stuck on something not yet done: “Your next move may only be one that actually changes the situation. Repeating the same operation is forbidden”
• When cycling: “Don’t use the move you just tried. Propose a different route”

The same idea in practice: documents over memory#

Separately from the paper, a blog post by developer Kevin Liao published on October 3, 2026, “Agents Don’t Need Memory. They Need Documentation.”, reaches a similar conclusion. The “memory” here means the typical build of a memory plugin: it makes fragments from conversations, puts them in a vector database, and inserts the few most similar ones with each prompt. The post says this build has these weaknesses.

• It only selects by similarity, so it can’t tell which is correct, whether it is still valid, or what is missing
• Code changes every day, but past fragments are treated as truth
• An agent can’t search for what it doesn’t know
• You can’t audit which stored fragments are old or wrong

What it proposes instead is a set of Markdown documents the agent reads and writes itself. Have it leave specifications, decisions, research and an index in documents, read them before work, and update the outdated parts after work. The explanation is that the flow changes from “request → build → forget” to “request → read documents → build → update documents”. The author has released this idea as a plugin, Operator Memory, which according to its README uses neither a vector database nor embeddings, and whose documents are managed in Git and can be shared by a team.

What overlaps with the paper’s PoS is that it stops digging back through history and keeps updating a document that states the “current understanding”. The difference is that PoS updates beliefs at every step within a single task, while this makes knowledge that persists between tasks (across sessions) into documents.

What to note is how weak this post’s evidence is. The author writes that he used his own tool for about a year, but shows no figures comparing it with other methods. Unlike the paper, which was validated on benchmarks, the flat claim that “memory plugins aren’t useful” remains this post’s own claim.

Claude Code itself also separates two mechanisms. The official documentation explains that CLAUDE.md, the file of instructions people write, and auto memory, the notes Claude writes itself, are both loaded at the start of a session. Both are plain Markdown that you can open, edit and delete yourself. Auto memory loads only the first 200 lines or 25KB, and the official page also says these are treated as context, not as enforced configuration. In other words, even if you write something in a document, the agent doesn’t always follow it. It is easier to sort out if you use the working note in the previous section (PROGRESS.md) for one task, and CLAUDE.md for rules that last.

What to keep in mind before trying it#

• The paper’s results are at the preprint stage. The evaluation is on benchmarks, and the models are in research settings. The same improvement won’t necessarily appear in Claude Code
• Cost goes up. Adding notes and checks to a short task just makes it a detour. It is reasonable to try it first on work that tends to wander beyond a few dozen moves
• As limits, the paper names the cost of maintaining beliefs and the dependence on knowledge about the domain and the task. For tasks where you don’t know what to write as state, the quality of the note won’t improve either

An agent’s accuracy depends not only on how smart the model is, but also on whether you can give it, every time, a clear picture of “what is certain now, and what is unresolved”. You can start by widening what goes in the first line of your instructions, so it covers not only “what to do” but also “what is not yet known”.