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

ArXiv: 2607.08716v1 (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)