"REM: What to Store, When to Recall, What to Forget in Experience Memory for Coding Agents" — new paper (NeurIPS 2026 CLEA Workshop, arXiv 19 Oct 2026). arxiv.org/abs/2610.27377 In plain terms: a coding agent works through a task in hundreds of steps, and the full log of those steps (its "trajectory") is usually thrown away. REM is "experience memory": it saves past runs so the next run can reuse them. The point is that how you store and manage that memory matters more than how well you search it. 3 distinct takeaways for product builders: - Store a short structured note, not the raw log. REM compresses each finished run into a ~270-token "phased document" (sections for: find the bug, understand it, fix it, verify; a token is roughly 3/4 of a word), about 100x smaller than the log. Pasting the same past run as a raw log or a free-form summary did not raise the share of bugs fixed, even when it was the exactly right past run. Decision: invest in the format of what you save before investing in better search. - Hold back the heavy details until the agent is stuck, then remove them. REM gives the short note at the start, and only shows the bulkier record of past edits the first time the agent fails a check (tests written by the agent itself don't count), then deletes it from the agent's working memory after one look. Showing that record from the start fixed 25.3% vs 27.6% for REM and cost more tokens (423K vs 374K per task). Decision: gate expensive memory on a visible "struggle" signal, and evict it after use. - Memory can hurt your strongest model. Across 5 models, the weaker/mid ones (fixing 31.3% or less without memory) never lost from the note, gaining up to ~4 points, while the two strongest (above 47%) lost under every memory setup, e.g. Opus 4.8 dropped from 47.5% to 39.4%. Decision: measure memory per model; turn it off where it lowers results. Experiment setup (from the paper): - Benchmark: SWE-ContextBench Lite, 99 real repository bug-fixing tasks, plus a pool of 300 already-solved past runs with a label for which past run relates to each task. "Resolved" = the benchmark's hidden tests pass on the agent's patch. - Agent: built on the Strands framework with 6 tools (bash, read, write, edit, grep, glob) in a Docker container per task, max 100 turns; Claude Sonnet 4.5 by default, 5 models in the sweep (incl. Haiku 4.5, Opus 4.8). - Results: bugs fixed 27.6% vs 24.9% with no memory, higher in all 3 repeats (27/29/26 vs 23/26/25 tasks), at 17% lower cost (452K to 374K weighted tokens per task). Match@1 (how often the top-ranked past run is the labeled related one): 68.7% vs 55.6% for LangMem, the best prior system; Mem0 25.3%, Supermemory 23.2%, OpenViking 38.4%. - Caveat: at 99 tasks the fix-rate gain is not statistically significant on a single test; the authors rest it on consistency across repeats.

"Cache Engineering for Agents" — new paper (arXiv preprint, 20 Oct 2026). arxiv.org/abs/2610.28577 In plain terms: when a model reads your agent's history, it stores a working copy of every word it has processed, called the KV cache (key-value cache: saved intermediate math so earlier text is not recomputed). In long agent runs, re-reading that cache becomes the main bill: 82.4% of API cost in the authors' measurement. Today's fix is to trim or summarize old messages, but changing anything early in the history throws away all the saved work after it and forces a costly re-read (re-prefill). This paper lets the agent delete pieces of the cache directly instead, leaving the text history untouched. 3 distinct takeaways for product builders: - Summarizing history is not free and can hurt. Summarizing at 48K tokens (tokens = word pieces) cut cost only about 7% but lowered accuracy 5 points. Dropping old tool outputs straight from the cache, keeping the latest 12, beat threshold-triggered summarization by 1.7 points on average at 27.7% lower cost. If your harness summarizes when the context fills up, measure what it actually saves. - Choose what to forget by message type. Old tool outputs (search results, file dumps) get little attention from the model, while its own reasoning notes matter more: dropping reasoning instead of tool outputs lowered the SWE-Verified score from 41 to 36.5. Prune tool responses first, keep the agent's reasoning. - Watch the position limit, not just the size. Each saved entry carries a position number (where it sits in the sequence), and these keep growing even after deletions, so a run can hit the model's limit with a small cache. Renumbering kept entries raised the BrowseComp-Plus pass rate from 55% to 62%. Long-running agents need position resets, not only deletions. Experiment setup (from the paper): - Method: AKV, a serving engine built on SGLang (an open-source model server) that accepts cache-drop and reposition instructions through a normal stateless API; default policy keeps the latest 12 tool responses. - Baselines: Standard (summarize at 96K tokens, 192K for MiroThinker) and Text Engineering (summarize at 48K). - Models: MiniMax-M2.7, GPT-OSS-120B, MiroThinker-1.7-Mini. - Benchmarks (standard test sets): BrowseComp-Plus and xbench-DeepSearch (web research), GAIA-Text (103 general assistant tasks), SWE-Verified (fixing real GitHub issues). - Metrics: success rate, per-task API cost, latency and throughput on 8 NVIDIA A800 GPUs. P95 latency (the slowest 5% of requests) fell from 43.6s to 25.9s at 8 concurrent requests. - Self-improvement: MiniMax-M2.7 rewrote the cache policy on 20 tasks; on 100 held-out tasks it cut cost a further 7.1% over the hand-designed policy.

"More Memory, Worse Agents: Error Reproduction and Anti-Persistence in LLM Agents" — new paper (arXiv preprint, Oct 19 2026). arxiv.org/abs/2610.27406 In plain terms: many agents "self-improve" by saving notes from past runs and reading them back on later tasks. Two kinds of notes: trajectories (the raw step-by-step log of what the agent did and whether it worked) and abstractions (rules, tips or skills the model summarizes from those logs). The paper shows a wrong saved rule can keep coming back: the agent follows it, that bad run gets logged, and the next summary re-learns the same mistake. They call this error reproduction. Their fix, Anti-Persistence, keeps only the raw logs and outcomes and writes fresh, throwaway guidance for each task. 4 distinct takeaways for product builders: - Saved rules did not reliably help. Memory that stored summarized rules, alone or next to the raw logs, did worse than raw-log-only memory in 7 of 9 benchmark/model settings. Default to keeping the raw record of what happened; treat saved "lessons" as something to prove, not assume. - Throw generated guidance away after use. Same method, the only change being discard vs store the per-task guidance: discarding won in all 4 settings tested, e.g. Llama-4-Scout on ALFWorld 54.7% vs 26.7% task success. Regenerate tips from the logs for each task instead of growing a rules file. - Deleting a bad rule is not the same as fixing memory. The logs it influenced stay behind, so the rule can be re-learned. AutoRefine (a baseline that scores and prunes stored skills) beat plain rule memory in only 1 of 6 settings, and Anti-Persistence beat AutoRefine in all 6. If you prune, also think about the logs the bad rule produced. - Let a small selector decide how to use memory per task. A contextual bandit (a lightweight learner that picks the option that worked best on similar past tasks) chooses between reusing past logs directly or writing a strategy, imitation or correction note. It beat every fixed choice and random choice, and Anti-Persistence had the lowest average number of model calls per task of the four memory designs. Experiment setup (from the paper): benchmarks ALFWorld (text-based household chores), WebShop (simulated online shopping) and ScienceWorld (text-based science experiments), with fixed train and held-out splits (held-out = tasks never used for learning). Base models stay frozen (never retrained): Llama-4-Scout, Qwen3-Coder-Next, Gemma-4-31B-it. Compared against trajectory memory, abstraction memory, joint memory, and agent baselines ReAct, Reflexion, ExpeL and AutoRefine, over ten memory-update rounds. Metrics: held-out success rate over 3 random seeds, and cost = average model calls per held-out task.

"A Strong Harness Narrows the Model Gap: A Comparative Evaluation for Legislative Document-to-XML Conversion" — new paper (arXiv preprint, 14 Oct 2026). arxiv.org/abs/2610.19999 In plain terms: a "harness" is the ordinary code you build around an AI model — the tools it can call, the checks on its output, and the order of steps. The authors convert U.S. state bills from PDF into strict XML (a tagged, machine-readable format) that must match the source exactly, and test what matters more: a better harness or a bigger model. The harness wins. 3 distinct takeaways for product builders: - Fix the harness before paying for a bigger model. The smallest model (Claude Haiku 4.5) inside the full pipeline scored 0.948, beating the largest (Claude Opus 4.6) with no harness at 0.806 (scores run 0 to 1). With zero-shot (one prompt, no tools) the three models spread from 0.68 to 0.81; in the full pipeline they all land near 0.95. - Splitting the work across specialist agents helps a weak model most, even with the same tools. One agent holding all 47 tools was compared with 7 sub-agents, each with a narrow job, its own small context (the text the model sees at once) and saved checkpoints between steps. Haiku rose from 0.872 to 0.948 overall, and its citation resolving from 0.103 to 0.801. If you must run a cheap model, give it narrow steps instead of one long do-everything loop. - Facts that live outside the model must come from a lookup, not from generation. Turning a law reference into its official ID (citation normalization) scored at most 0.282 for any model without tools, because that mapping is not in what the model learned. With a deterministic lookup tool in the full pipeline it reached 0.80 to 0.95. For IDs, codes and prices, call a source of truth. Experiment setup (from the paper): - Task and data: 153 expert-made gold (reference answer) bills, 103 from Idaho and 50 from New Jersey; PDF to XML that must validate against a fixed, confidential schema (a DTD, the rulebook for allowed tags). - Models: claude-haiku-4-5, claude-sonnet-4-6, claude-opus-4-6; one run per model/harness/document. - Harnesses: T1 = zero-shot; T2 = one agent, 47 tools via MCP (Model Context Protocol, a standard plug for giving a model tools), 9-step playbook; T3 = 21-step playbook, 7 sub-agents, 17 tools, persisted state, modeled on a pipeline running in production at a legal publisher. - Metrics: Overall = average of NED (normalized edit distance: share of characters reproduced unchanged), TEDS (tree-edit similarity: does the section structure match) and an exact-match score on inserted/struck amendment words. Citations scored separately: localization (found) and normalization (resolved to the right ID). 95% bootstrap confidence intervals; Haiku-T3 vs Opus-T1 paired bootstrap p < 0.001.