Agent memory: problemem nie jest przypominanie, lecz zapominanie

Gdy ludzie martwią się o agent memory, niemal zawsze martwią się o przypominanie: czy agent zapamięta to, co powiedziałem mu trzy sesje temu? To intuicyjny lęk i w większości niewłaściwy. Badania z 2026 roku nad długoterminową agent memory zbiegły się ku bardziej niewygodnemu obrazowi, w którym trudne porażki w ogóle nie dotyczą pamiętania. Dotyczą tego, jak memory jest zaprojektowana, jak jest retrievowana — i tego, czego nikt nie projektuje — jak jest zapominana. Przypominanie to łatwa część. Wszystko wokół niej to miejsce, gdzie agenci się sypią.

Ma to znaczenie, bo to memory odróżnia sprytne narzędzie jednorazowego strzału od agenta, z którym faktycznie da się pracować przez dłuższy czas. Zrób to źle, a agent jest albo amnezyjny, albo — co gorsza — pewny siebie w błędnych, nieaktualnych faktach. Warto więc zrozumieć, co naprawdę znalazły benchmarki, bo każda z trzech porażek ma inny fix.

Okno kontekstu to nie memory

Zacznij od najczęstszego błędu architektonicznego, nazwanego bez ogródek przez pracę z 2026 roku, The Missing Memory Hierarchy (arXiv 2603.09023): „The context window of a large language model is not memory. It is L1 cache: a small, fast, expensive resource that the field treats as the entire memory system.” To jedno przeformułowanie tłumaczy mnóstwo złego designu agentów. Zespoły upychają wszystko do okna, bo to jedyna pamięć, jaką zainżynierowały — a potem dziwią się, że jest droga, marnotrawna i nie skaluje się.

Praca zmierzyła marnotrawstwo na produkcji: 21,8% strukturalnego marnotrawstwa w 857 produkcyjnych sesjach i 4,45 miliona tokenów wejściowych. Piąta część tego, co jest w oknie, średnio rzecz biorąc, nie musi tam być. Fix jest tym, który systemy operacyjne rozgryzły dekady temu — hierarchia pamięci z demand paging: trzymaj working set w szybkim, deficytowym oknie, trzymaj resztę w tańszej pamięci i stronicuj istotne kawałki na żądanie, zamiast trzymać wszystko rezydentne. Zysk, jaki raportują, jest spory: nawet 93% redukcji kontekstu na żywej produkcji (jedna sesja spadła z 5038KB do 339KB), przy zaniedbywalnym fault rate na poziomie 0,0254% w 1,4 miliona symulowanych eviction. Potraktuj okno jako L1 cache zamiast jako memory, a większość rozdęcia — i kosztu — znika.

To systemowy odpowiednik punktu, który postawiliśmy w context engineeringu: okno to deficytowy zasób do zarządzania, a nie wiadro do napełnienia. Memory hierarchy to architektura, która nim zarządza.

Retrieval jest stratny i pomija to, co ważne

Załóżmy, że faktycznie budujesz pamięć poza oknem. Teraz pytanie brzmi, co wciągasz z powrotem, i tu jest druga porażka: większość memory systems retrievuje źle. AMA-Bench (arXiv 2602.22769), benchmark zbudowany na realistycznych trajektoriach agentów — stanach, akcjach, obserwacjach, outputach narzędzi, nie tylko logach czatu — ustalił, że „existing memory systems underperform because they fail to capture causal and objective information and rely heavily on lossy similarity-based retrieval.”

Ten zwrot, lossy similarity-based retrieval, jest sednem sprawy. Standardowe podejście embedduje wszystko i retrievuje to, co jest najbardziej semantycznie podobne do bieżącego zapytania. Ale podobne to nie to samo co istotne — fakt, którego przyczynowo potrzebujesz, by odpowiedzieć na pytanie, często nie jest tym, który wygląda najbardziej jak pytanie. Zapytaj agenta „dlaczego deploy na staging się wywala?”, a similarity retrieval ochoczo wyciąga każdą przeszłą wiadomość zawierającą „deploy” i „staging” — podczas gdy faktyczna przyczyna, zmiana konfiguracji trzy sesje temu, która nigdy nie wspomniała żadnego z tych słów, plasuje się nigdzie. Memory nośna przyczynowo i memory podobna tekstowo to różne zbiory, a similarity search optymalizuje pod niewłaściwy. Agent retrievuje więc kontekst wyglądający wiarygodnie i pomija nośny szczegół. Nawet zbudowany na potrzeby pracy system, AMA-Agent — który buduje causality graph i używa tool-augmented retrieval zamiast surowego similarity — sięga raptem 57,22% dokładności, przewyższając najsilniejszy baseline o 11,16%. Czytaj to jako sufit stanu sztuki: najlepszy testowany memory system odpowiada poprawnie ledwie na więcej niż połowę pytań, i robi to właśnie dzięki wyjściu poza similarity ku strukturze przyczynowej. Retrieval daleko mu do rozwiązania.

Najtrudniejszym problemem jest zapominanie

Trzecia porażka to ta, której prawie nikt nie projektuje, i jest najgroźniejsza. Memora (arXiv 2604.20006), benchmark obejmujący konwersacje trwające tygodnie-do-miesięcy, postawił sobie za cel zbadanie nie tylko tego, czy agenci pamiętają, ale czy potrafią aktualizować — i wprowadził metrykę dokładnie do tego: FAMA, Forgetting-Aware Memory Accuracy, która karze poleganie na przestarzałej lub unieważnionej memory. Wynik otrzeźwia: „Evaluations of four LLMs and six memory agents reveal frequent reuse of invalid memories and failures to reconcile evolving memories. Memory agents offer marginal improvements.”

Posiedź nad frequent reuse of invalid memories. Użytkownik zmienił pracę; API zostało zdeprecjonowane; decyzja architektoniczna została odwrócona w zeszłym miesiącu — a agent wciąż działa na starym fakcie, pewny siebie, bo zapamiętał go perfekcyjnie. Pamiętanie jest łatwe. Wiedza, że coś, co pamiętasz, nie jest już prawdą, jest trudna, a obecne systemy są w tym słabe. Co gorsza, dedykowane memory agents — systemy zbudowane specjalnie do zarządzania tym — oferują tylko „marginal improvements” wobec zwykłych modeli. Zapominanie nie jest rozwiązanym podproblemem memory; jest otwartym, i jest porażką najbardziej skłonną po cichu uczynić długowiecznego agenta niegodnym zaufania.

I zauważ, dlaczego jest to strukturalnie trudne. Naiwny memory system jest append-only: zapisuje nowe fakty, ale nigdy nie cofa starych, więc sprzeczne informacje kumulują się, a krok retrieval nie ma pryncypialnego sposobu, by wiedzieć, która wersja jest aktualna. Naprawa to nie tylko „zapisz timestamp” — agent musi rozpoznać, że nowa obserwacja unieważnia starą (a nie ją jedynie uzupełnia), co często wymaga zrozumienia, że dwa różnie sformułowane fakty dotyczą tej samej rzeczy. To problem rozumowania w przebraniu problemu przechowywania, i dokładnie dlatego doczepiane warstwy memory ledwo ruszają liczby FAMA: poprawiają przechowywanie i retrieval, pozostawiając osąd invalidation modelowi, którego nigdy o niego nie poproszono.

Memory to dyscyplina inżynierska, a nie cecha modelu

Złóż te trzy razem, a wniosek jest jasny: agent memory to nie coś, co dostajesz, wybierając większy model albo dłuższe okno kontekstu. To system, który projektujesz, z trzema odrębnymi problemami do rozwiązania. Architektura: potraktuj okno jako L1 cache i zbuduj hierarchię, która stronicuje informacje na żądanie. Retrieval: wciągaj to, co istotne przyczynowo, a nie tylko to, co powierzchownie podobne. Invalidation: zdecyduj, co zapomnieć, i pogódź fakty w miarę ich zmiany — część bez dobrego domyślnego ustawienia. Większe okno czyni cache większym; nie robi nic dla jakości retrieval ani dla invalidation. To problemy inżynierskie i mieszkają w harnessie wokół modelu, a nie w wagach.

Dlatego też memory nie może być generycznym, kupionym z półki komponentem. To, co liczy się jako „working set”, co jest „istotne przyczynowo” i co czyni fakt „przestarzałym”, to wszystko osądy zależne od domeny. Memory system dla agenta obsługi klienta i ten dla agenta kodu nie zgadzają się co do wszystkich trzech, a tylko ktoś, kto rozumie domenę, potrafi je wyspecyfikować.

Dlaczego sprzyja to Azji Południowo-Wschodniej

Oto część, która ma znaczenie dla tego regionu, i ma znajomy już kształt. Projektowanie memory agenta — jego hierarchii, jego logiki retrieval, jego reguł invalidation — to czysty systemowy osąd inżynierski. Nie kosztuje żadnych GPU ani żadnego frontierowego modelu; kosztuje uważne przemyślenie tego, co agent musi zachować, pobrać i odrzucić. To dyscyplina laptopa i dokładnie ten rodzaj trwałej, lekkiej kapitałowo zdolności, którą — jak wciąż argumentujemy — region powinien budować — ta sama dźwignia bez GPU co praca nad pętlą i kontekstem, obok której siedzi.

A zależność od domeny to przewaga, nie brzemię. Nie ma memory systemu z półki dla agenta do dokumentów prawnych w języku khmerskim, dla compliance workflow kambodżańskiego banku ani dla wojewódzkiego koordynatora logistyki — bo to, co istotne i co przestarzałe w tych domenach, mogą wyspecyfikować tylko ludzie z ich wnętrza. Zespół, który dobrze zrobi memory dla własnego problemu, buduje coś, czego frontierowe laboratorium nie ma ani motywacji, ani zdolności replikować. Dostawcy modeli będą dalej rozszerzać okno kontekstu i nazywać je memory. Zespoły, które rozumieją, że to tylko L1 cache — i inżynierują wokół niego prawdziwy memory system — to te, których agenci wciąż będą godni zaufania tysiąc tur później.