# Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents

**ArXiv:** [2607.08716v1](https://arxiv.org/abs/2607.08716) (2026. július)
**Szerzők:** Yifan Wu, Zhuokai Zhao (correspondence)
**Kód:** https://github.com/yifannnwu/proactive-memory-agent
**Formátum:** AI agent kutatási paper (~6200 szó)
**Relevancia a rendszerünkre:** **MAGAS** — a cikk a Hermes Agent memória-kezeléséről szól. A "proactive memory agent" minta (külön agent az action agent mellett, strukturált memory bank + szelektív intervention) közvetlenül alkalmazható a mi rendszerünkre.

## Kulcsmondatok

- **"Behavioral state decay":** long-horizon agent feladatoknál a döntéshozatalhoz szükséges state (task requirements, environment facts, prior attempts, open subgoals) szétszórva van a trajectory-ben, és ahogy a trajectory nő, kikerül a kontextusból. Ez a primary failure mode.
- **Memória ≠ passzív retrieval.** A cikk fő tézise: a memóriát aktív intervenciós mechanizmusnak kell tekinteni. Egy külön "memory agent" fut az action agent MELLETT, változatlan formában.
- **Plug-and-play.** A memory agent bármely frontier action agent-tel és meglévő agent harness-szel együttműködik.
- **Eredmények:** +8.3 pp Terminal-Bench 2.0 (Sonnet 4.5), +6.8 pp τ²-Bench (task-weighted avg, Sonnet 4.5). Az erősebb action agent (Opus 4.6) is profitál, de kisebb mértékben (+2.4 / +2.5 pp).
- **Ablations:** a szelektív intervenció > passzív bank exposure > always-on injection > advisor-only guidance > sima retrieval.
- **Open-weight memory policy:** Qwen3.5-27B-t treníroztak SETA-n (SFT + GRPO), részleges transfer a Terminal-Bench-re — early step toward API-független memory agent-ek felé.

## Epizód áttekintés

Három fő téma, három részben feldolgozva:

1. **A probléma + Related Work:** behavioral state decay, memória mint aktív intervenció, kapcsolódó irodalom (reflection, context engineering, learned memory policies).
2. **Method:** a két-fázisú architektúra (memory management + intervention), a triggering logika, a tanítható memory policy (SETA + SFT/GRPO).
3. **Experiments + Ablations + Conclusion:** két benchmark (Terminal-Bench 2.0, τ²-Bench), fő eredmények, ablations, qualitative analysis, open-weight Qwen3.5-27B training.

---

## Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents — Összefoglaló
**Forrás:** arXiv:2607.08716v1 (2026. július 9.) — *Yifan Wu, Lizhu Zhang, Yuhang Zhou, Mingyi Wang, Bo Peng, Serena Li, Xiangjun Fan, Zhuokai Zhao* (Meta AI; levelezés: yfwu@meta.com, zhuokai@meta.com)
**Kód:** https://github.com/yifannnwu/proactive-memory-agent
**Rész tartalma:** 1. Introduction + 2. Related Work (1–60. sorig terjedő fold-kibontás); 1740 szó.

---

## 1. A probléma — "behavioral state decay"

- A long-horizon LLM agent feladatok (többkörös tool use, környezeti interakció) kiértékelésénél a siker nem csak a lokális problémamegoldástól függ, hanem attól is, hogy a jövőbeli viselkedést korlátozó információk fennmaradjanak. Tipikus hibaformák: a korai felismerésű requirement későbbi megszegése egy unrelated bug fix közben; egy már elbukott command/parameter későbbi újrapróbálása közel azonos formában; egy diagnosticált error pattern későbbi „újként” való kezelése (1. §).
- A szerzők ezt a failure mode-ot **behavioral state decay**-nek nevezik: a trajectory növekedésével a döntéshozatalhoz szükséges állapot — task requirements, environment facts, previous attempts, failure diagnoses, intermediate discoveries, open subgoals — kikerül a kontextus ablakból, vagy ha bent is marad, már nem befolyásolja megbízhatóan a következő döntést (vö. liu2024lost a „lost in the middle” jelenség).
- A puszta kontextus-ablak növelés nem elég: a hosszabb history önmagában nem oldja meg, hogy a releváns információ „active” maradjon. A kérdés tehát nem csak az, hogy *mi* kerüljön a memóriába, hanem az is, hogy *mikor* hasson a következő action-re.
- A long-horizon feladatok failure mode-jai igen változatosak: van, ahol a hasznos memória egy korai hard requirement, máshol egy environment fact, egy elbukott command, egy bug diagnosis vagy egy befejezetlen subgoal — ezért egyetlen fix summarization policy nem tudja eldönteni, hogy egy adott emléknek meg kell-e szakítania a következő lépést.
- A cikk kulcsmegkülönböztetése: a legtöbb memória-megközelítés (MemGPT, MemoryBank, Generative Agents, Mem0) a *tárolás és retrieval* kérdését vizsgálja; a szerzők ezzel szemben azt állítják, hogy az aktív task execution-ban a memóriának egy erősebb kontroll-kérdést kell megválaszolnia: **intervenció** — kevés memória → ismételt hibák; túl sok memória → latency, token-pazarlás, az agent figyelme elterelődik a lokális előrehaladástól.
- A bevezető konkrét benchmark-említései: Terminal-Bench 2.0 (merrill2026terminalbench, command-line), MLE-Bench (chan2024mlebench, multi-step ML engineering), τ²-Bench (yao2024taubench, barres2025tau2bench, interactive tool use domain rules alatt) — ezek képezik a kísérleti talajt is.
- A cikk fő empirical claim-je (már az absztraktban és intro-ban): Claude Opus 4.6 memory agent + Claude Sonnet 4.5 action agent kombináció **37.6% → 45.9%** Terminal-Bench-en és **55.0% → 61.8%** τ²-Bench-en; erősebb action agentnél (Opus 4.6) a gain nem tűnik el: +2.4 pp és +2.5 pp.

## 2. Memória, mint aktív intervenció (nem passzív retrieval)

- A cikk központi tézise: **a memóriát aktív intervenciós mechanizmusnak kell tekinteni, nem passzív retrieval-nek**. A memory agent nem csak tárol vagy lekérdez, hanem dönt: most kell-e emlékeztetőt injektálnia a következő action-agent hívásba, vagy hallgatnia kell.
- Az architektúra egy **külön memory agent**, ami az action agent **mellett** fut, és az action agentet **változatlanul hagyja** (unmodified). A memory agent fix időközönként: (i) frissíti a strukturált memory bank-ot a friss trajectory-ből; (ii) eldönti, hogy a bank-ból származtatott rövid reminder-t (elfeledett requirement, stabil environment fact, failed attempt, diagnosis) be kell-e injektálnia, vagy maradjon csendben.
- A modul **plug-and-play**: bármely frontier action agent-tel és meglévő agent harness-szel együttműködik, anélkül, hogy az action agent belső promptját, policy-ját vagy toolingját módosítaná. Ez a két-fázisú architektúra szétválasztja a *memory maintenance*-t a *action selection*-től.
- A különbség a passzív memory rendszerekhez képest (MemGPT, MemoryBank, Generative Agents, Mem0): ezek retrieval-on-demand működnek; a memory agent ezzel szemben azt dönti el, hogy a memória **belépjen-e a control loop-ba**. Vö. zhang2025memact („Memory-as-Action”) — a szerzők itt jegyzik meg, hogy ők erősebb kontroll-kérdést tesznek fel: *should memory enter the control loop*?
- A különbség az advisor modellekhez képest (asawa2025advisor; anthropic2026advisor): a memory agent **korlátozott** — kizárólag memory-grounded reminder-eket ad, nem általános stratégiai guidance-ot. A kimenet mindig az action agent következő döntését korlátozó execution state-ből származik.
- A bevezető a *summarizer vs. intervention* distinkciót emeli ki: a summarizer azt kérdezi, *mit tartsunk meg*; a memory agent azt kérdezi, hogy *a megtartott execution state bármely része aktiválódjon-e a következő action-agent döntésben*. Az intervenció szelektivitása kulcs: nem mindig ír, nem mindig olvas — kalibrálnia kell, hogy az adott feladat environment dynamics-e, observability-e és failure mode-ja mit igényel.
- A cikk ígérete a további szekciók felé: a szelektív intervenció felülmúlja a passzív bank exposure-t, az always-on injection-t, az advisor-only guidance-ot és a sima retrieval-t (ezek az ablations a későbbi részekben jönnek).

## 3. A kutatás fő eredményei (a későbbi szekciókból előretekintve)

- **Headline számok (absztrakt + intro):** Terminal-Bench 2.0-n **+8.3 pp**, τ²-Bench-en **+6.8 pp** átlagos pass@1 javulás a memory agent bevezetésével — és ez **mind gyengébb, mind erősebb action agenteknél** kimutatható (nem csak a Sonnet 4.5-ön).
- **Konkretizált eredmények:** Claude Sonnet 4.5 action agent + Claude Opus 4.6 memory agent kombináció **37.6% → 45.9%** Terminal-Bench-en (Δ ≈ +8.3 pp) és **55.0% → 61.8%** τ²-Bench-en (Δ ≈ +6.8 pp). Erősebb action agentnél (Opus 4.6 mint action agent) a gain kisebb, de nem nulla: **+2.4 pp** Terminal-Bench-en, **+2.5 pp** τ²-Bench-en.
- **Ablations (a cikk állítása szerint, a későbbi szekciókból):** a szelektív intervenció felülmúlja a (i) passzív bank exposure-t, (ii) always-on injection-t, (iii) advisor-only guidance-ot és (iv) sima retrieval-t. Ez bizonyítja, hogy nem elég memóriát adni — a *mikor és hogyan* a döntő.
- **Open-weight memory policy irány:** a szerzők a **Qwen3.5-27B** modellt **SETA** adathalmazon finomhangolják **SFT + GRPO** kombinációval memory agentként. A validation reward javul, és a tanult policy részleges transfer-t mutat a Terminal-Bench-re. A szerzők ezt „early step toward open-weight memory policies”-ként keretezik, tehát nem állítják, hogy zárt modelleket teljesen kiváltanának.
- **A cikk explicit contribution listája:** (i) a behavioral state decay azonosítása mint központi failure mode; (ii) egy két-fázisú memory intervention architektúra, ami szétválasztja a memory maintenance-t az action selection-től, empirikus igazolással, hogy a maintained memory + selective intervention nyer; (iii) preliminary evidence, hogy az intervention policy tanulható open-weight modellel.
- **Miért nem elég a hosszabb kontextus:** a cikk hangsúlyozza, hogy a long context window önmagában nem garantálja a prior információ megbízható felhasználását — a kontextus pozíciójától függően a model under-utilizálhat információt (lost-in-the-middle, liu2024lost). A memory agent ezt a pozíció- és kontextus-problémát hidalja azzal, hogy mindig az action agent aktuális promptjába emeli a releváns állapotot.

## 4. Related Work — Memory for language-model agents

- A 2.1 szekció a **long-horizon language agents** irodalmát térképezi: ReAct (yao2023react), Reflexion (shinn2023reflexion), Voyager (wang2024voyager) — közös pont az interleaved reasoning-and-acting, többkörös tool use, revise-olt terv. A szerzők ezen belül a behavioral state decay-re fókuszálnak, szemben a single-turn reasoning benchmarkokkal.
- A 2.2 szekció a **memory for language-model agents** vonalat tárgyalja: (a) retrieval-augmented modellek (guu2020realm, lewis2020rag) — nem-parametrikus store-okkal javítják a factual groundingot; (b) long-context memory architektúrák (wang2023longmem) — past representations cache-elése a hatékony kontextus kiterjesztéséhez; (c) agent memory rendszerek (park2023generative — Generative Agents; zhong2024memorybank — MemoryBank; packer2023memgpt — MemGPT; zhang2024memorysurvey) — natural-language recordok long-term interaction-höz, személyre szabáshoz, viselkedés-generáláshoz; (d) lifelong agents (wang2024voyager — Voyager: reusable skills retrieval); (e) production memory layers (mem0ai2026mem0 — persistent user/session/agent memory, hatékony storage és retrieval). A szerzők ezeket **komplementernek** tekintik: nem a persistent storage/retrieval optimalizálását célozzák, hanem azt, hogy *a megőrzött execution state mikor aktiválódjon intervencióként* az ongoing loop-ban.
- A 2.3 szekció a **learned memory policies és context management** vonalat mutatja be: a long context window nem garantálja a megbízható felhasználást (liu2024lost), ezért a kutatások egyre inkább a kontextus tömörítése, a memory editing és a learnable context curation felé mozdulnak. Kulcs referenciák: **Memory-as-Action** (zhang2025memact) — a working-memory management explicit editing action-ökként formalizálva, a task performance-szel együtt optimalizálva; **Context-Folding** (sun2025contextfolding) — az agent sub-trajectories-ba branchel, majd a kész branch-eket tömör summary-kba foldolja, RL reward a decomposition-re és context management-re; **Mem-α** (wang2025memalpha) — tool-based memory operations szekvenciális rész-okon, downstream QA accuracy a reward signal a teljes interaction history felett. A szerzők ezekkel a „memory és context management downstream outcome-okra optimalizálva” nézetet osztják, de **más kontroll-problémát** céloznak: nem tanítják az action agentet, hogy saját kontextusát kurálja; nem memory construction-t optimalizálnak későbbi QA-hoz; nem foldolják a kész sub-taskokat summary-kba — ehelyett egy **külön memory agent** repeated observation-t végez a live multi-turn task trajectory-ről, strukturált execution state-et tart fenn, és dönt, hogy abból bármi beavatkozzon-e a következő action-agent hívásba. Ez heterogénebb credit-assignment problémát teremt: feladatonként a memory vagy csendben marad, vagy ismétlődő hibákat előz meg, vagy újraaktivál diagnosisokat és open sub-goalokat — és a felesleges intervenció inkább káros, mint redundáns.
- A 2.4 szekció a **reflection, critics és advisor models** vonalat tárgyalja: **Self-Refine** (madaan2023selfrefine) — a modell outputjainak iteratív javítása self-generated feedback-kel; **Reflexion** (shinn2023reflexion) — verbális reflexiók tárolása prior attempts-ről episodic memory bufferben; **Tree of Thoughts** (yao2023tree) — inference-time reasoning kiterjesztése search-szel intermediate thoughts-ok felett; valamint újabban az **advisor-style** módszerek (asawa2025advisor; anthropic2026advisor), ahol egy második modell natural-language guidance-dal steereli a black-box / executor modellt. A memory agent ezekhez a supervisory megközelítésekhez áll közel, de **korlátozottabb**: nem ad broad strategic advice-ot, nem végez általános deliberation-t; kimenete kizárólag memory-grounded reminder, ami a fenntartott execution state-ből származik (task requirement, environment fact, failed attempt, diagnosis, open subgoal), és kifejezetten az action-agent viselkedésére hat inaktívvá váló állapotokkal szemben.
- A 2.5 **Positioning** szekció összefoglalja a cikk hozzájárulását: a korábbi munka (memory, retrieval, reflection, context compression, auxiliary guidance) mind javíthat language agent-eket; a szerzők újdonsága a memória **selective intervention policy**-ként való formalizálása long-horizon execution-re. A központi kérdés nem csak az, hogy *mit* jegyezzünk meg vagy summarize-áljunk, hanem az, hogy *whether, when, and how* a remembered execution state belépjen az action agent kontextusába úgy, hogy megváltoztassa a következő döntést felesleges token- és latency-overhead nélkül. Mivel a feladatok environment dynamics-ben, observability-ben és failure mode-okban jelentősen különböznek, ez **intervention calibration**-t igényel, nem fix summarization policy-t.

## Saját rendszerünkre alkalmazható

- A „proactive memory agent” minta — külön dedikált folyamat az action agent MELLETT, strukturált memory bank frissítése és szelektív reminder-injection — közvetlenül leképezhető a Hermes Agent architektúrájára: a jelenlegi `memory` eszköz és a skill-rendszer passzív retrieval-ként működik; ha egy háttér-hook (pl. `openclaw-orchestration` mintára) bizonyos tick-számonként lefuttatna egy „memory review” lépést a session- és project-szintű kontextus felett, és csak akkor injectálna emlékeztetőt a system promptba, amikor egy korai requirement / failed attempt / open subgoal „elhalványul”, az a cikk központi tézisét ültetné át.
- A „silence by default” elv (a memory agent sokszor csendben marad) kulcs a token- és latency-overhead elkerüléséhez — a mi rendszerünkben is ez felelne meg a „ne szórakoztasd el az agentet a lokális előrehaladástól” imperatívusznak, és a cikk ablations-e (passzív exposure < always-on < szelektív intervenció) empirikus alátámasztást ad alá.
- A Qwen3.5-27B SFT+GRPO-val tanított memory policy-ból kiindulva a saját rendszerünkre is alkalmazható egy „memory policy” tanítása saját session-logokon (GRPO reward: javult-e a downstream task outcome, ha a memory agent egy adott típusú reminder-t adott vs. hallgatott) — így a memory intervention lépésről lépésre learnable policy-vá válhat a saját telemetry-n felhasználva.
- A plug-and-play jelleg (az action agent változatlan marad) kompatibilis a Hermes jelenlegi „tool-on-demand” modelljével: a memory agent nem módosítja a futó action agent policy-ját, csupán a promptjába ír egy rövid, structure-öltött reminder-t, ami megfelel a meglévő context-engineering boundary-nek.
- A behavioral state decay keretrendszer diagnosztikus eszközként is használható: a saját multi-step agent futásaink failure mode-jait (ismételt parancs, elveszett requirement, újra felfedezett bug) ezen a négy-öt kategórián (task requirement / environment fact / failed attempt / diagnosis / open subgoal) osztályozva priorizálható, hogy a memory agent melyik típusú intervencióra tanítható a legnagyobb hatással.

---

## 2. rész
## ArXiv:2607.08716v1 — "Remember When It Matters" — 2. rész (Method szekció)

> **Forrás:** /tmp/arxiv_chunk2.txt (~1737 szó, 56 fold-sor). A chunk valóban a Method szekciót (3.1–3.5) tartalmazza — a cikk 3-as fő szekcióját. A chunk a 3.5 "Learning Memory Intervention Policies" szekció közepe tájánál zárul ("We"), így a Qwen3.5-27B / SETA / GRPO / Terminal-Bench részletek valószínűleg a 3. chunkban (Results) jönnek — ezeket itt NEM állítom, csak ami a Method szövegben olvasható.

## 5. Problem Setup — az action agent

- A cikk egy **action agent**-et tekint kiindulásnak: egy long-horizon nyelvi agent, amely egy trajectory τ = (o₁, a₁, o₂, a₂, …, o_T) mentén dönt és cselekszik, ahol a_t ∼ π_A(a_t | x, τ_<t) egy LLM-alapú, tool-use scaffolldal implementált action policy.
- A trajectory teljes hossza mentén az action agent kontextusát a scaffold **csonkolhatja, összegzi vagy szűrheti** — nem minden információ marad elérhető minden lépésnél. A cikk ezt a problémát nevezi meg központi kiindulópontnak.
- Az action agentbe **külön π_M memory agent** kerül bevezetésre, amely az action agentet **változatlan formában hagyja** — plug-and-play architektúra. Csak egy új, opcionális memória-kontextust kap az action agent a memóriától.
- A memory agent az első lépésben, majd egy trigger függvény (alapértelmezetten fix intervallum) szerint fut le. Minden memória-lépésnél a következő inputokat látja: a **task description (x)**, egy **w_t = W_k(τ_<t, o_t) sliding window** az utóbbi lépésekből, és az aktuális **B_{t-1} memory bank**.
- Formálisan a memory agent két lépést hajt végre időlépésenként: először a bank frissítése (B_t ∼ π_M^edit(· | x, w_t, B_{t-1})), majd egy intervenciós döntés (i_t ∼ π_M^intervene(· | x, w_t, B_t)), ahol i_t ∈ {∅, text reminder}.
- A cikk kiemelt fogalma az **"execution state"**: a teljes trajektóriában jelen lévő, de a kontextusból kikerülő döntésbefolyásoló információk (feladat-követelmények, környezeti tények, korábbi próbálkozások, hiba-diagnózisok, felfedezések, nyitott subgoals). A cél: ezt az execution state-et külön karbantartani, és **szelektíven visszainjektálni** az action loopba, amikor hatással lesz a következő döntésre.

## 6. Memory Bank — a strukturált memória

- A memory bank egy **kompakt, strukturált reprezentáció**, amelyet a memory agent folyamatosan frissít, és amely három komponensből áll: **B_t = (s_t, K_t, P_t)**.
- **s_t — status (privát)**: a memory agent saját progress-nyomkövető mezője, amely **soha nem kerül az action agent kontextusába**. Lehetővé teszi, hogy a memory agent munkamodellt tartson fenn a feladatról anélkül, hogy szennyezné az action agent kontextusát.
- **K_t — knowledge memory**: viszonylag stabil tények, amelyek a feladat során várhatóan érvényesek maradnak — feladat-követelmények, környezeti tulajdonságok, fájl-útvonalak, konfigurációs részletek, user/tool által verifikált tények, evaluation-relevant megfigyelések. Ez az ág felel meg a **"mit tanultunk a feladatról/környezetről"** kérdésnek.
- **P_t — procedural memory**: kísérletek és kimenetelek — sikertelen parancsok, sikeres javítások, kizárt hipotézisek, diagnosztikai jelek, empirikus javítások. Ez az ág felel meg a **"mit próbáltunk és mi történt"** kérdésnek, hogy későbbi döntések elkerülhessék az ismételt hibákat és újrahasznosíthassák a sikeres evidenciákat.
- Minden memory entry egy **rövid azonosítóból**, természetes nyelvű tartalomból és metaadatokból (létrehozás ideje, hozzáférési statisztikák) áll. Az azonosítók lehetővé teszik a memory agent számára a **stale entryk explicit frissítését vagy törlését**.
- A gyakorlatban az entryk **kompakt, tagezett formátumban** íródnak (pl. environment facts, paths, task facts, bugs, performance observations) — ez strukturálisan ösztönzi a memory agentet, hogy megkülönböztesse a kényszereket (knowledge) a procedurális evidenciától (procedural).
- A cikk hangsúlyozza: a memory bank **NEM egyszerű "summary of past"** — hanem **executable state**: célzottan csak azokat az információkat tartja meg, amelyek várhatóan befolyásolják a jövőbeli döntéseket, és amelyeket a memory agent később vissza tud injektálni.

## 7. Memory Agent — az intervenciós mechanizmus (Two-Phase)

- A memory agent egy **külön LLM call** (vagy kisebb modell), amely minden memória-lépésben egy **kétfázisú workflow**-t futtat: **Phase 1 = memory bank management**, **Phase 2 = proactive intervention selection**.
- A memory agent a bankot **nem közvetlenül írja felül** — Phase 1-ben egy előre definiált **tool-call interface**-en keresztül kommunikál: `memory_update_status`, `memory_save_knowledge`, `memory_save_procedural`, `memory_delete`. A rendszer ezeket a tool callokat sorrendben hajtja végre, és az eredmény lesz az új B_t.
- Ha a memory agent nem ad vissza tool callt, **a bank változatlan marad** — a csend Phase 1-ben is explicit cselekvés.
- A tool-call interface **explicit és korlátos**: a Phase 1 outputja nem szabad formátumú összegzés, hanem egy explicit bank-edit szekvencia. Ez a struktúra kényszeríti ki, hogy a memory agent externalizálja az execution state-et (nem teljesített követelmények, verifikált környezeti tények, sikertelen parancsok, sikeres javítások) hosszú trajektóriákon át is strukturáltan.
- **Phase 2 — intervention selection**: a frissített bank és a recent trajectory alapján a memory agent vagy kibocsát egy **r_t reminder**-t, vagy egy **∅ null intervention**-t. A reminder az action agent következő hívásához **transient memory context**-ként csatolódik; az action agent alap utasításai, eszközei és dekódolási procedúrája **változatlan** — csak az opcionális memória-kontextus jelenik meg.
- A **null intervention explicit cselekvés**: a memory agentet arra ösztönzik, hogy csak akkor interveniáljon, ha egy megőrzött elem várhatóan befolyásolja a következő döntést. Hasznos intervenciók: közelgő követelmény-szegésre figyelmeztetés, az aktuális observationt megmagyarázó környezeti tény, ismétlendő korábbi próbálkozás elleni figyelmeztetés, releváns diagnózis, elhanyagolt nyitott subgoal.
- A memory agentet **lebeszélik** arról, hogy széles stratégiai tanácsot adjon, a jelenlegi observationból már látható információt ismételjen, vagy átvegye az action agent tervezését. Az intervenció időzítése a **memory policy része**, nem pedig automatikus mellékterméke minden bank-frissítésnek.
- A teljes formalizmus lényege: a memória **policy over interventions** — a memory agent nem csak azt dönti el, hogy mit tartson meg, hanem **mikor érdemes a megőrzött state-et visszainjektálni** az action loopba.

## 8. Triggering the Memory Agent — mikor interveniáljon

- A memory agent indítása egy **trigger függvény g(t)** alapján történik, amely eldönti, hogy adott action-agent lépésnél fusson-e a memory agent.
- A cikk **fő implementációjában a trigger az első lépés, majd fix N lépésenkénti periodikus hívás**. Ez az egyszerű ütemezés lehetővé teszi, hogy a memory agent szorosan kövesse a trajektóriát, és maga döntse el, hogy marad-e csendben vagy interveniál.
- A szerzők említenek szelektívebb trigger-lehetőségeket is: **tool error, failed test, repeated command, large context shift** — de a fix intervallumot választották, hogy **izolálják a memory intervention policy hatását** a trigger-mechanizmus hatásától.
- Fontos koncepcionális pont: a triggering és az intervention **két külön döntés**. A trigger eldönti, hogy a memory agent **fut-e**, az intervention-phase pedig eldönti, hogy **mit (ha egyáltalán) injektáljon**. A cikk hangsúlyozza, hogy a memory agent saját döntése (emit reminder vs. `<no_intervention/>`) a kulcselem — nem a fix periodikus hívás.
- A Phase 2 kimeneti formátuma az ábrán is jelzett: vagy egy **`<context_for_action>` reminder**, vagy egy explicit **`<no_intervention/>` token** — a csend explicit és gépileg értelmezhető.

## 9. Learning Memory Intervention Policies — a trenírozható memory agent

- A memory-intervention architektúra **nem igényli új modell trenírozását** — a fő implementációban a memory agent **promptolt modell** is lehet, amely követi a fenti kétfázisú interfészt.
- A szerzők elismerik, hogy a promptolt memory agent nem feltétlenül a legpraktikusabb deployment: **extra inference költséget ad**, és az intervenciós döntések **kalibrációja nem tökéletes**.
- Ezért a memory agent **trenírozható is** — ez a cikk által **korai explorációnak** tekintett irány, amely megmutatja, hogy az intervenciós policy **tanulható, nem csak promptolható**.
- A tréning során **csak a memory agentet tanítják, az action agent fix** marad — ez tisztán elkülöníti a memória-policy tanulását az action policy tanulásától.
- A tréning két fázisban történik: **(1) Supervised fine-tuning (SFT)** — egy promptolt memory agent trajektóriáiból desztillálva tanítja a modellt a memory-bank műveletekre és a targeted reminder vs. null intervention közötti választásra. Ez a fázis főleg az **interfész és az alapvető memória-menedzsment fegyelem** tanítja: kompakt írás, stale state frissítése, szükségtelen emlékeztetők kerülése.
- **(2) Reinforcement learning (RL) kalibráció** — mivel az imitáció önmagában nem optimalizálja a downstream intervenciós hatást, egy RL fázis hangolja a modellt. A cél **nem a memóriahasználat maximalizálása**, hanem az intervenciós policy javítása: a modell megtanulja, **mikor segít valószínűleg egy megőrzött execution state** a következő döntés, és **mikor jobb a csend**.
- A tréning-tanulmány a szerzők szavaival **"preliminary evidence"**, hogy a memory intervention **desztillálható open-weight policy-vé** — és az architektúra **független** a tréning-procedúrától (a promptolt és a tanított memory agent ugyanazt a kétfázisú interfészt használja).
- *Megjegyzés: a konkrét modell- és tréning-részletek (Qwen3.5-27B, SETA adathalmaz, SFT + GRPO kombináció, Terminal-Bench transfer-eredmények) a rész szövege alapján **a 3. részben (Results szekció) találhatók** — ezeket itt nem részletezem, mert ez a Method rész nem tartalmazza őket.*

## Saját rendszerünkre alkalmazható

- A **proactive memory agent** minta (külön LLM az action agent mellett, strukturált memory bank, szelektív intervenció) **közvetlenül adoptálható** a Hermes Agentbe: a jelenlegi kontextus-sűrítés/truncation helyett egy dedikált, tool-call-alapú memória-ág (knowledge vs. procedural split) jobban megőrizné a hosszú session-ök cross-task execution state-jét.
- A **kétfázisú write-then-decide interfész** (Phase 1: explicit bank edit, Phase 2: reminder vs. null) pontosan illeszkedik a Hermes meglévő tool-use scaffoldjához — minimális invazivitás, az action agent változatlan marad.
- A **null intervention explicit cselekvés** tanulsága: a mi rendszerünkben is érdemes a "csend" opciót first-class citizen-ként kezelni, nem pedig a memória-elmulasztás csendjét — ez csökkenti a kontextus-zajt és védi az action agent fókuszát.
- A **fix periodikus trigger + saját döntés a intervencióról** kombináció jó kiindulópont (a cikk ezt validálja mint baseline-t); a Qwen3.5-27B / SETA / GRPO / Terminal-Bench részletek a 3. rész feldolgozása után mérlegelhetők, hogy open-weight, lokálisan futtatható memória-policy-t trenírozzunk-e a Hermes saját trajectory-iből.

---

## 3. rész
## Proactive Memory Agent for Long-Horizon Agents — 3. rész — Magyar összefoglaló

## 10. Benchmarks és Setup (4.1)

A memory agent kiértékelése két long-horizon agent benchmarkon:

- **Terminal-Bench 2.0:** Autonóm agent-ek realistic command-line környezetben — fájlok inspect, parancsok futtatása, kód szerkesztése, hibák debuggolása, hidden verifier tesztek. 89 task, ebből 85 paired task (4 docker hiba kizárva). A **behavioral state decay** itt a **local debugging loopok**-ban jelenik meg: a agent-ek elfelejtik a korábbi requirements-eket, ismétlik a sikertelen parancsokat, figyelmen kívül hagyják a környezet megfigyeléseket, vagy elvesztik a diagnosztizált hibák nyomát.
- **τ²-Bench:** Conversational tool-use agent-ek, dinamikus task környezetek, valós service domain-ekből (airline, retail, telecom). A decay itt **más forrásból** ered: fontos tényeket a user, a tool-ok vagy a domain policy-k mondják, de később a döntésekből kiesnek. **278 task konfigurációnként** (50 airline + 114 retail + 114 telecom).
- **Két action agent erősség:** Claude Sonnet 4.5 és Claude Opus 4.6. A **memory agent mindig Opus 4.6** (a legerősebb modell). A memory agent a **first step-en** + minden további step-en fut. Látja: task description, **recent trajectory window k=8 message**, current memory bank. Először frissíti a memory bank-ot, aztán vagy inject-ál context-et, vagy silent marad.

## 11. Main Results (4.2) — pass@1 javulás minden konfigurációban

A memory intervention javítja a pass@1-et mindkét benchmarkon és mindkét action agent erősségen:

| Benchmark | Domain / Split | Action Model | n | Baseline | +Memory | Δ |
|-----------|----------------|--------------|---|----------|---------|---|
| Terminal-Bench 2.0 | full set | Sonnet 4.5 | 85 | 37.6% | 45.9% | **+8.3 pp** |
| Terminal-Bench 2.0 | full set | Opus 4.6 | 85 | 43.5% | 45.9% | +2.4 pp |
| τ²-Bench | airline | Sonnet 4.5 | 50 | 68.0% | 78.0% | +10.0 pp |
| τ²-Bench | retail | Sonnet 4.5 | 114 | 49.1% | 58.8% | +9.6 pp |
| τ²-Bench | telecom | Sonnet 4.5 | 114 | 55.3% | 57.9% | +2.6 pp |
| τ²-Bench | task-weighted avg | Sonnet 4.5 | 278 | 55.0% | 61.8% | **+6.8 pp** |
| τ²-Bench | airline | Opus 4.6 | 50 | 76.0% | 76.0% | +0.0 pp |
| τ²-Bench | retail | Opus 4.6 | 114 | 64.9% | 69.3% | +4.4 pp |
| τ²-Bench | telecom | Opus 4.6 | 114 | 63.2% | 64.9% | +1.8 pp |
| τ²-Bench | task-weighted avg | Opus 4.6 | 278 | 66.2% | 68.7% | +2.5 pp |

**Fő megállapítások:**
- A Sonnet 4.5 (gyengébb action agent) **nagyobb javulást** mutat (+8.3 pp Terminal-Bench, +6.8 pp τ²-Bench átlag)
- Az Opus 4.6 (erősebb action agent) **kisebb, de nem nulla** javulást mutat (+2.4 pp, +2.5 pp) — a benefit **nem csupán a limited capacity kompenzálása**
- A **Sonnet lift legnagyobb airline és retail** esetén (+10.0 és +9.6 pp), **telecom kisebb** (+2.6 pp) — összhangban a "memory = domain-sensitive intervention policy" keretrendszerrel, nem fix summarization mechanizmussal

## 12. Ablations (4.3) — két fázis: memory management + intervention

A memory agent két fázisa: (1) **memory management** — persistent memory bank of user facts, tool observations, procedural evidence, open subgoals; (2) **intervention** — eldönti, hogy kell-e reaktiválni a remembered state-et, és concise memory-grounded reminder-t generál.

**Ablation variánsok (Sonnet 4.5 action agent, Opus 4.6 memory agent, τ²-Bench):**

| Variáns | Phase 1 (memory) | Phase 2 (intervention) | Macro avg | Micro avg |
|---------|------------------|------------------------|-----------|-----------|
| Sonnet 4.5 baseline | — | — | 57.5 | 55.0 |
| **Full memory agent (ours)** | bank management | **selective reminder / silence** | **64.3** | **61.2** |
| Full-bank context | bank management | expose full bank | 61.5 | 58.6 |
| Always inject | bank management | forced reminder every step | 63.5 | 61.5 |
| Injection-only (no bank) | skipped | selective guidance / silence | 61.0 | 60.8 |
| Mem0 (vector+BM25 top-10) | — | retrieval | 62.1 | 60.8 |

**Insights az ablations-ból:**
- **A full memory agent adja a legjobb macro-average-ot** (64.3) — legkiegyensúlyozottabb javulás a domain-eken át
- **Full-bank context** javít a baseline-hoz képest, de 2.8 macro / 2.6 micro ponttal marad el — a memory bank karbantartása hasznos, de az **összes remembered state exposúra nem elég**; a memory agent-nek **szelektálnia kell, mi releváns**
- **Always inject** micro-average-on 0.3 ponttal vezet, de ez **a run variance-en belül van**, és macro-average-on a **selective silence jobbnak bizonyul** (különösen airline)
- **Injection-only (advisor-style)** bizonyos domain-eken segít (telecom), de airline-en **a baseline alá esik** — persistent memory nélkül a guidance **nem kellően grounded**
- **Mem0 (general memory retrieval)** javítja az átlagot, de airline-en **nem javít a baseline felett** — a retrieval és az intervention policy **nem ugyanaz**

**Konklúzió:** Sem a passzív memory exposure, sem az always-on reminder, sem a generic auxiliary guidance nem elég. A legkiegyensúlyozottabb eredményt a **maintained execution state + selective intervention policy** kombinációja adja.

## 13. Qualitative Analysis (4.4) — milyen state reaktiválódik sikeresen

A memory agent nem generic summarization-t végez — akkor segít, amikor **a specifikus execution state reaktiválódik** pont akkor, amikor az action agent épp ignorálni készül. A state típusa domain-függő:

**Öt mechanizmus a sikeres intervention-ökre:**

1. **Requirement / policy reactivation** — task vagy domain rule az allowed action-ről. Példa: τ² airline compensation, retail modification rules.
2. **Environment grounding** — runtime facts, paths, tool limitations, system quirks. Példa: Terminal-Bench Git server setup, ARS file-write failure.
3. **Failure-loop avoidance** — korábbi attempts és miért bukott el. Példa: adaptive rejection sampling, telecom diagnostic retries.
4. **Diagnostic carryover** — bug vagy negatív signal root cause. Példa: regex edge cases, SQLite gcov configuration.
5. **Progress / entity tracking** — melyik user, order, line, branch, subgoal aktív. Példa: τ² telecom line lookup, retail authentication state.

**Benchmark-specifikus megfigyelések:**

- **Terminal-Bench: debugging continuity.** A memory az iterative debugging során a leghasznosabb — a action agent halmozza a megfigyeléseket, de később elveszti, melyek constrain-elnénék a következő commandot. Pl. `regex-log` task-ban a memory reaktiválja a boundary condition-t (single-digit IPv4 octets). Pl. `adaptive-rejection-sampler` task-ban a memory track-eli a repeated failed file edit-eket és surface-eli az environment-specific workaround-ot.
- **τ²-Bench: policy és interaction state reaktiválás.** A hasznos execution state gyakran policy- vagy interaction-specifikus. Airline + retail task-ok gyakran megkövetelik egy rule alkalmazását sok turnnel azután, hogy a releváns fact-ot megfigyelték. Pl. airline: a user Gold státuszt állított, de a tool output Regular tagot mutatott — a baseline a user claim alapján adott compensation-t, a memory-enabled agent emlékeztette az action agentet, hogy **a verified records-ra kell hagyatkozni**. Pl. basic-economy flight modification: a memory reaktiválta a policy clause-t, hogy ezek a flight-ok **nem módosíthatók**.

**Remaining failures:** calibration hibák, nem memory storage hibák. Pl. a memory agent túl nagy confidence-dal speculative inference-t surface-el, ismétli a már ismert információt, vagy felesleges verifikációt okoz — ezek a **silence döntés tanítását** motiválják.

## 14. Training Open-Weight Memory Agents (4.5) — Qwen3.5-27B SETA-n

A prompted Opus memory agent javítja a long-horizon agent-eket, de **frontier-model call** kell minden memory step-nél, és az intervention calibration imperfect. A szerzők ezért **Qwen3.5-27B-t treníroznak** memory agent-ként, miközben a **Qwen3.5-122B-A10B action agent frozen** marad.

**SETA dataset:** executable terminal-agent task-ok, verifier rewards-kal. SFT-re és RL-re is használják. **Terminal-Bench 2.0 held out** (külső validáció).

**Eredmények (a cikk 4.5 szekciójából):**
- A trained Qwen3.5-27B memory agent javítja a **validation reward-ot** (SETA-n)
- **Részleges transfer** mutatkozik a Terminal-Bench 2.0-ra — a tanított policy generalizál a held-out benchmarkra
- Ez egy **early step toward open-weight memory policies** — nem kell API-alapú frontier modell a memory agent-hez

## Saját rendszerünkre alkalmazható

- **Két-fázisú memory agent minta** közvetlenül alkalmazható a Hermes Agent-re: a jelenlegi `MEMORY.md` rendszer egy **passzív** memória (kézzel írom, kézzel olvasom); a cikk egy **aktív** mintát javasol, ahol egy külön "memory agent" minden session-ön fut, frissíti a memóriát a trajectory-ből, és szelektíven injektál emlékeztetőket.
- **A "silence" döntés kritikus** — a cikk ablations-ból kiderül, hogy az always-on injection rosszabb, mint a selective silence. A mi rendszerünkben most a MEMORY.md-t mindig betöltjük — egy jövőbeli fejlesztés lehetne egy "relevance filter", ami csak a session-releváns részeket tölti be.
- **A "failure-loop avoidance" mechanizmus** különösen értékes — a memory agent nyomon követné a korábbi sikertelen próbálkozásokat, és a új session-ben emlékeztetne, hogy "ezt már megpróbáltad, nem működött, próbáld másképp".
- **A "diagnostic carryover"** a podcast-processing pipeline-ra alkalmazható — amikor egy subagent summary készítése elbukik (pl. rész-topics mismatch), a memory agent a következő session-ben emlékeztetne, hogy melyik rész-feldolgozási minta volt a helyes.
- **Az open-weight Qwen3.5-27B memory agent** a jövőben egy lokálisan futtatható alternatíva lehet (Mac mini, MLX), nem kell API-alapú frontier modell — ez a költséghatékonyság és privacy szempontjából is fontos.
- **A cikk 5.5-szeres token-pazarlás-figyelmeztetése** ("adds a frontier-model call at each memory step") a mi rendszerünkre is érvényes — a memory agent bevezetése ELŐTT mérni kell a token-költséget és a pass rate javulást.

**Forrás:** `/tmp/arxiv_chunk3.txt` (arXiv:2607.08716v1, ~2738 szó)
**Epizód/paper:** "Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents" (arXiv:2607.08716v1, 2026)