The authors add one capability to an existing agent-memory pipeline. The post-task curator agent, which is the only component that writes memory, gets read-only tools into the live environment. It uses them to check, narrow, and refresh each candidate memory before it writes. The task agent does not change. On a database-exploration benchmark with a hidden schema migration, pass rate rose from 39% with no memory to 73% with probed memory, and the cost per task fell by half. The gain over trajectory-only memory is smaller and its confidence intervals overlap.
A long-running agent starts every session with an empty context. Agent platforms add an external memory store with three operations: create a record after a task, update it as evidence arrives, and recall it during a later task. Claude Managed Agents, Copilot Studio, Mem0, and Zep all ship a version of this.
The common design puts a second agent, the curator, after each task. The curator reads the completed trajectory, the log of the task agent's requests, tool calls, observations, and final answer, plus the grade. Then it writes memory records.
The authors' claim is that a trajectory is a weak source of truth. It is one partial and often mistaken pass through the environment. A curator that sees only the trajectory can store the answer to one task instead of the procedure, keep a slow path because it happened to work, claim a scope it never tested, leave blind spots for states the task agent never visited, or keep a fact the environment has since changed.
The paper shows real records from its database benchmark. One says: do not use the average of prc_usd, that gives 52.96 and the correct answer is 96.23. It stores the answer and gives no replacement query. Another says: use table attrs_g3. A migration renamed that table, so the record is stale. The next task agent must spend its own tool calls to find this out, on the user's critical path.
The pipeline has three roles; each runs as a fresh model session. The task agent solves one task with the environment tools, such as SQL queries or document readers, plus one memory tool, memory_read, and no memory write tool. The distiller runs after the task closes. It has no tools, sees no grade, and compresses the raw trajectory into an evidence packet: goal, decisive actions and observations, reusable findings, and unverified assumptions. The curator runs last with the evidence packet, the raw trajectory, the grade, and related existing records. It has memory read, create, update, and delete, and it is the only writer. Each record carries a category, a confidence level, a scope that says when it applies, one claim, and provenance. The curator finishes before the next task starts, so a half-written memory never enters a task.
The paper's addition is small. The curator also gets a read-only subset of the task agent's environment tools: the query interface for the database benchmark, a read-only tool configuration for the document benchmark. The curator prompt gains two blocks. The first says: you have read-only environment tools; they cannot change anything, consume the task budget, or reveal future tasks. The second says: before you create or update a record, use these tools to verify it whenever its correctness, scope, freshness, or actionability is uncertain.
The curator then works in a propose, probe, commit loop. It proposes a candidate record and runs targeted read-only calls to test it; the figure above lists the questions a probe can answer. Then it creates, narrows, updates, deletes, or skips the record.
A code reviewer who sees only the diff can say what looks wrong. One who can run the query against a read replica can say what to run instead, and can confirm that the table still exists. The probes stay off the user-facing path, reuse the platform's authentication and audit log, and need less authority than write access.
The stale rule becomes: use product_attributes_g3, filter on brand, group by value, count distinct ids. The warning that stored only the answer becomes: join items_g2 to taxn_g2 on ref_id, filter on the exact category, keep positive prices, then compare with the filtered average. The record now says what to execute.
The harness is built on the GitHub Copilot SDK, and the main experiments use GPT-5.4 for every role. Four configurations run on the same tasks: no memory; full in-context learning, which prepends every prior trajectory to the prompt; memory with a trajectory-only curator; and memory with a probing curator. Reported task-agent cost excludes the distiller and curator, which the authors track separately.
The first benchmark is CLBench: 40 SQL questions over a hidden SQLite database with undocumented joins and encodings. After question 20 an unannounced migration renames tables, splits columns, and adds soft deletes. The score is a pass-discounted reward: a failed task earns zero, and a passed task earns more when it used fewer tool calls.
No memory passes 39% of questions at 8.8 queries per question and $3.38 per run. Full in-context learning passes 61% with the fewest queries, but its prompt grows with every task and consumes 5.42 million input tokens. Trajectory-only memory passes 70% at 5.6 queries, $1.99, and 2.13 million input tokens. Probed memory passes 73% at 4.7 queries, $1.68, and 1.69 million input tokens. Total reward goes from 8.60 with no memory to 20.00 with trajectory-only memory and 22.60 with probing.
At the migration boundary, probed memory leads trajectory-only memory in cumulative reward, 0.541 against 0.486, and it stays ahead to the end, 0.565 against 0.500. The authors attribute this to the curator refreshing schema records before a later task retrieves them, so no task agent has to detect the migration alone.
A second CLBench schedule without migration tests Sonnet 4.6 and Opus 4.7 in the same roles. Probing gives the highest mean reward on both models, with a larger margin on Sonnet than on Opus.
The second benchmark is 90 management-consulting tasks from APEX Agents, grouped into six document worlds so that file locations and workbook layouts recur. All 18 comparisons of a memory system against the no-memory baseline are positive, and task-agent tool calls fall by 16% to 75%. Probing gives the best reward gain per dollar in five of six worlds. In the most expensive world, tool calls drop from 71.6 to about 18 per task and cost per run from $54.30 to under $9.
The caveats are in the paper's own words. The gap between probed and trajectory-only memory is modest and its uncertainty intervals overlap; the authors call the per-world pattern a mechanism interpretation, not a resolved effect. Full in-context learning wins raw reward in some APEX worlds. The main runs use one model family, five random seeds, and benchmarks the authors adapted. The curator's own probing cost is not in the headline cost figures.
If your agent stack already has a post-task curator, this change is a configuration task. Give the curator a read-only connection: a read replica, a read-only MCP server, or a filtered tool subset. Add the two prompt blocks. Keep write tools out of the curator, and keep memory writes out of the task agent.
Three design rules transfer on their own. One writer per memory store, and it runs between tasks, never during one. Every record has a scope and a confidence field, and the curator may narrow or delete as well as create. Records store procedures and conventions, never the task answer.
The paper also gives a cheap audit for an existing memory store. Read a sample of records and ask of each: does it say what to run, or only what failed? A store full of warnings is one the next agent must re-verify. Probing moves that verification off the critical path.