Pamięć agenta AI - Mem0, Zep, Letta czy LangMem? Jak wybrać i wdrożyć pamięć między sesjami

Pamięć agenta AI to mechanizm, który pozwala modelowi językowemu zachować informacje poza pojedynczą rozmową - bo sam LLM jest bezstanowy i po zakończeniu sesji zapomina wszystko. Którą drogę wybrać? Reguła według tego, co agent ma pamiętać: jeśli o użytkowniku wystarczy kilkanaście stałych pól (imię, plan, preferowany kanał kontaktu), nie potrzebujesz frameworka - wystarczy tabela profilu w bazie. Gdy faktów jest dziesiątki lub setki i powstają w rozmowach, weź Mem0 (najszybszy start, plan darmowy, licencja Apache 2.0). Gdy liczą się relacje i ich zmiany w czasie (kto z kim, od kiedy), wybierz Zep / Graphiti. Gdy agent działa godzinami lub dniami i sam zarządza swoją pamięcią - Letta. Gdy cały system stoi już na LangGraph - LangMem.

Mem0, Zep, Letta czy LangMem - a może wystarczy tabela profilu? Reguła wyboru w jednym akapicie, porównanie licencji, wyników benchmarków i cen, koszt przy 1 tys. i 100 tys. użytkowników, typy pamięci, kod z Mem0, pamięć w n8n i zgodność z RODO.

Klient pisze do Twojego chatbota: „znowu ten sam problem co ostatnio". Agent odpowiada: „Czy mógłby Pan opisać problem?". Klient już wie, że rozmawia z maszyną bez pamięci - i traci zaufanie. Tymczasem człowiek z działu obsługi otworzyłby historię i powiedział: „widzę, że zgłaszał Pan to dwa tygodnie temu, sprawdźmy, czy poprawka zadziałała".

Ta różnica - pamiętanie kontekstu między rozmowami - dzieli zabawkę demonstracyjną od agenta, którego można wdrożyć w firmie. A ponieważ model językowy z natury nie pamięta niczego między wywołaniami, pamięć trzeba zaprojektować i zbudować osobno. Ten artykuł pokazuje, jak to zrobić: od typów pamięci, przez zarządzanie kontekstem i frameworki, po kod, n8n i RODO.

Dlaczego LLM nie pamięta - problem bezstanowości

Każde wywołanie modelu językowego jest niezależne. Model nie ma żadnego „stanu" między żądaniami - dostaje tekst na wejściu, zwraca tekst na wyjściu i natychmiast zapomina. Wrażenie, że ChatGPT „pamięta" rozmowę, jest iluzją: za każdym razem aplikacja wysyła do modelu całą dotychczasową historię rozmowy jako część promptu. To nie model pamięta - to aplikacja dokleja historię.

Ten mechanizm działa do pewnej granicy, a potem napotyka trzy twarde ściany:

• Limit okna kontekstu - nawet modele z oknem 200k-1M tokenów mają górną granicę; długa rozmowa albo obszerne dokumenty w końcu się nie zmieszczą
• Koszt i latency - płacisz za każdy token wejściowy przy każdym wywołaniu; doklejanie pełnej historii do każdego zapytania oznacza, że koszt rośnie kwadratowo wraz z długością rozmowy
• Brak ciągłości między sesjami - gdy użytkownik zamknie czat i wróci jutro, historia jest pusta; bez zewnętrznego magazynu agent zaczyna od zera

Pamięć agenta AI rozwiązuje wszystkie trzy: zamiast doklejać wszystko, przechowuje informacje na zewnątrz i pobiera tylko to, co istotne dla bieżącej decyzji. To dokładnie ten sam pomysł, co RAG dla wiedzy firmowej (pisałem o tym w artykule o budowie bazy wiedzy) - tylko zastosowany do historii interakcji i faktów o użytkowniku.

Cztery typy pamięci agenta AI

Badania nad architekturą agentów (m.in. „Cognitive Architectures for Language Agents") rozróżniają cztery typy pamięci, zapożyczone z psychologii poznawczej. Zrozumienie różnic jest kluczowe, bo każdy typ wymaga innego magazynu i innej strategii pobierania - a najczęstszy błąd to wrzucanie wszystkiego do jednej bazy wektorowej.

• Pamięć robocza (working memory) - to aktywne okno kontekstu: bieżąca rozmowa, wczytane pliki, wyniki narzędzi z tej sesji. Zarządza się nią jak budżetem tokenów, nie jak problemem wyszukiwania - przez kompresję i priorytetyzację, nie przez similarity search
• Pamięć epizodyczna (episodic memory) - zapis tego, co agent zrobił i kiedy: przebiegi rozmów, podjęte decyzje, ślady działań. Służy do audytu, debugowania i uczenia się na podstawie historii. Klucz to zapis chronologiczny, a nie wyszukiwanie po podobieństwie
• Pamięć semantyczna (semantic memory) - fakty o świecie, użytkowniku i domenie: preferencje klienta, wiedza branżowa, dane firmy. To dla niej stworzono RAG - pobieranie po podobieństwie treści jest tu właściwym podejściem
• Pamięć proceduralna (procedural memory) - jak wykonać zadanie: wyuczone procedury, reużywalne umiejętności, rutyny. W praktyce zapisana w promptach systemowych, definicjach narzędzi i kodzie agenta

Najważniejsza zasada projektowa: nie mieszaj pamięci epizodycznej (logi zdarzeń) z semantyczną (fakty) w jednym indeksie wektorowym. Wyszukiwanie po podobieństwie w logach zdarzeń degraduje jakość pobierania dla obu typów - log „użytkownik kliknął X o 14:32" i fakt „użytkownik preferuje kontakt mailowy" wymagają zupełnie innych strategii dostępu.

Pamięć krótkoterminowa - zarządzanie oknem kontekstu

Pamięć krótkoterminowa to zarządzanie tym, co mieści się w oknie kontekstu podczas jednej sesji. W agentach wieloetapowych wyniki narzędzi szybko zajmują większość budżetu tokenów, więc kontekst trzeba ograniczać: przesuwnym oknem ostatnich tur, podsumowaniem kroczącym starszej części rozmowy, kompaktacją przy progu tokenów i przycinaniem wyników narzędzi. Dla większości firmowych zastosowań wystarcza podsumowanie kroczące: ostatnie kilka wymian w całości plus aktualizowane podsumowanie reszty.

Techniki zarządzania kontekstem w obrębie sesji (zapisz, wybierz, skompresuj, rozdziel) i budżet kontekstu w praktyce opisuję szczegółowo w artykule o context engineeringu. Tutaj skupiam się na tym, co przenosi wiedzę między sesjami.

Uwaga na pułapkę: kompresja jest stratna. Każde podsumowanie gubi szczegóły, a jeśli agent będzie podsumowywał podsumowania, po kilku iteracjach zostanie mu mglista karykatura rozmowy. Dlatego ważne fakty (numer zamówienia, ustalenia, decyzje) wyciągaj do pamięci długoterminowej jako ustrukturyzowane dane, zanim trafią pod nóż kompresji.

Pamięć długoterminowa - jak agent pamięta między sesjami

Pamięć długoterminowa żyje poza oknem kontekstu - w zewnętrznej bazie, najczęściej wektorowej - i przetrwa zamknięcie czatu, restart serwera czy powrót użytkownika po tygodniu. Cykl jej działania ma trzy fazy:

1. 1.Zapis (write) - w trakcie lub po rozmowie agent wyciąga istotne fakty i zapisuje je do magazynu. Kluczowe: nie zapisujesz surowej transkrypcji, tylko wyekstrahowane, ustrukturyzowane informacje („klient X preferuje dostawę kurierem", „projekt Y ma deadline 30 czerwca")
2. 2.Pobranie (retrieve) - zanim agent odpowie, przeszukuje pamięć semantyczną pod kątem faktów istotnych dla bieżącego zapytania i wstrzykuje je do okna kontekstu. To rdzeń wzorca RAG: trzymaj wiedzę na zewnątrz, dociągaj tylko to, co potrzebne
3. 3.Aktualizacja (update) - gdy nowa informacja zaprzecza starej, pamięć trzeba zaktualizować, a nie tylko dopisać. Inaczej zgromadzisz sprzeczne fakty („preferuje mail" i „preferuje telefon"), a agent będzie losował

Ostatnia faza jest najtrudniejsza i najczęściej pomijana. Dobre frameworki pamięci robią deduplikację i rozwiązywanie konfliktów automatycznie - wykrywają, że nowy fakt zastępuje stary, i nadpisują go zamiast mnożyć wersje. To dlatego warto sięgnąć po gotowy framework, zamiast budować pamięć na surowej bazie wektorowej: samo zapisywanie i pobieranie napiszesz w godzinę, ale zarządzanie cyklem życia faktów to miesiące dopracowywania.

Czy w ogóle potrzebujesz frameworka pamięci - pierwsza decyzja

Najważniejsze pytanie nie brzmi „Mem0 czy Zep", tylko „czy potrzebuję frameworka pamięci". Framework rozwiązuje jeden konkretny problem: fakty, które powstają w rozmowach, trzeba wyciągnąć, zapisać, zaktualizować przy sprzeczności i pobrać tylko te istotne. Jeśli tego problemu nie masz, framework dokłada tylko koszt i kolejną zależność.

Praktyczna reguła: zacznij od tabeli profilu i podsumowań, a framework dołóż dopiero wtedy, gdy zauważysz, że ważne fakty z rozmów giną albo sobie przeczą.

Mem0 vs Zep vs Letta vs LangMem - porównanie frameworków pamięci

W 2026 rynek pamięci agentowej dojrzał na tyle, że nie trzeba budować jej samodzielnie. Cztery frameworki dominują, każdy z innym podejściem architektonicznym:

Reguła decyzyjna w praktyce:

• Zacznij od Mem0, jeśli nie masz mocnego powodu, by wybrać inaczej - najniższy próg wejścia, managed SaaS zdejmuje z Ciebie obsługę bazy grafowej i skalowania, a self-hosting jest możliwy przy wymogach prywatności
• Wybierz Zep, gdy kluczowe jest rozumienie relacji i ich zmian w czasie - kto z kim pracuje, jak ewoluują preferencje, powiązania między encjami; tu temporalny graf bije czysty wektor
• Rozważ Letta, gdy budujesz autonomicznego agenta działającego godzinami lub dniami i potrzebujesz pamięci jako pełnoprawnego elementu runtime, nie biblioteki doklejanej z boku
• Użyj LangMem, jeśli Twój stack to już LangGraph - dostaniesz narzędzia pamięci pasujące do istniejącej orkiestracji bez wprowadzania nowej zależności

Liczby, które warto znać przed wyborem (stan na październik 2026):

Ważne zastrzeżenie: wyniki benchmarków pochodzą z prac samych autorów (Mem0 i Zep), więc traktuj je jako deklaracje, nie niezależny test. Najlepszym benchmarkiem jest 30-50 prawdziwych scenariuszy powracających użytkowników z Twojej aplikacji.

Nie ma jednego zwycięzcy - wybór zależy od tego, czy ważniejsza jest szybkość wdrożenia (Mem0), trafność i relacje (Zep), kontrola (Letta) czy spójność ze stackiem (LangMem).

Ile to kosztuje przy dwóch skalach

Szacunek dla asystenta, w którym każdy aktywny użytkownik wysyła ok. 20 wiadomości miesięcznie, a każda wiadomość to jeden zapis i jedno pobranie pamięci:

Wniosek jest ten sam co przy bazach wektorowych: hosting zarządzany opłaca się na starcie, bo oszczędza czas zespołu, a przy dużej skali self-hosting wygrywa o rząd wielkości. Koszt ekstrakcji liczyłem dla GPT-6 Luna (0,10 USD za milion tokenów wejścia) i ok. 1 500 tokenów na jedną ekstrakcję. Uwaga na pułapkę w planach Mem0: limit pobrań jest dziesięć razy niższy niż limit zapisów, a to pobrania rosną z każdą wiadomością.

Jak wdrożyć pamięć w kodzie - przykład z Mem0

Najprostsza droga to Mem0. Poniżej agent obsługi klienta, który zapisuje i pobiera pamięć per użytkownik - zaledwie kilka linii poza zwykłym wywołaniem modelu:

from mem0 import Memoryfrom openai import OpenAImemory = Memory()client = OpenAI()def chat(user_id: str, message: str) -> str:    # 1. Pobierz fakty istotne dla biezacego zapytania    relevant = memory.search(query=message, user_id=user_id, limit=5)    context = "\n".join(m["memory"] for m in relevant["results"])    # 2. Wstrzyknij pamiec do promptu systemowego    system = (        "Jestes asystentem obslugi klienta. "        "Znane fakty o uzytkowniku:\n" + (context or "(brak)")    )    resp = client.chat.completions.create(        model="gpt-6-luna",        messages=[            {"role": "system", "content": system},            {"role": "user", "content": message},        ],    )    answer = resp.choices[0].message.content    # 3. Zapisz nowe fakty z tej wymiany (ekstrakcja robi sie automatycznie)    memory.add(        messages=[            {"role": "user", "content": message},            {"role": "assistant", "content": answer},        ],        user_id=user_id,    )    return answer

Trzy rzeczy, które robią tu różnicę:

• user_id izoluje pamięć - każdy klient ma własną przestrzeń; Mem0 nigdy nie wymiesza faktów dwóch użytkowników, co jest krytyczne dla prywatności
• memory.add() nie zapisuje surowej rozmowy - pod spodem LLM ekstrahuje fakty warte zapamiętania i odrzuca small talk; nie zaśmiecasz bazy „dzień dobry" i „dziękuję"
• search() pobiera tylko top-5 - wstrzykujesz do kontekstu kilka najistotniejszych faktów, nie całą historię; koszt i latency pozostają stałe niezależnie od tego, jak długo klient z Tobą jest

Przy self-hostingu (Ollama i vLLM) zamiast OpenAI podstawiasz lokalny endpoint Ollama lub vLLM, a Mem0 skonfigurujesz tak, by używał lokalnego modelu do ekstrakcji i lokalnej bazy wektorowej - cała pamięć zostaje w Twojej infrastrukturze.

Pamięć w n8n i narzędziach no-code

Nie każde wdrożenie wymaga kodu. W n8n węzeł AI Agent ma wbudowane opcje pamięci, które konfigurujesz klikając:

• Simple Memory (window buffer) - trzyma ostatnie N wiadomości w pamięci instancji; pamięć krótkoterminowa w obrębie jednego workflow, najprostsza, ale ulotna (znika po restarcie)
• Pamięć w bazie zewnętrznej - podłączasz Postgres, Redis lub bazę wektorową jako magazyn; pamięć przeżywa restarty i działa między sesjami
• Mem0 / Zep przez węzeł HTTP lub dedykowaną integrację - pełna pamięć długoterminowa z ekstrakcją faktów, bez pisania kodu

Klucz w n8n to klucz sesji (session key) - identyfikator, po którym agent rozpoznaje, czyją pamięć wczytać. Najczęściej to ID klienta z CRM, numer telefonu albo adres e-mail. Bez stabilnego klucza sesji każda rozmowa jest anonimowa i pamięć nie działa między sesjami. To dokładnie ten sam mechanizm co user_id w kodzie - tylko ustawiany w interfejsie.

Dla prostych przypadków (asystent FAQ pamiętający kontekst w obrębie jednej rozmowy) Simple Memory wystarcza. Dla agenta, który ma rozpoznać wracającego klienta i jego historię - potrzebujesz pamięci w bazie zewnętrznej z sensownym kluczem sesji.

Bezpieczeństwo i prywatność pamięci (RODO)

Pamięć agenta to z definicji magazyn danych osobowych - preferencji, historii kontaktów, czasem danych wrażliwych. To stawia ją wprost pod RODO i wymaga zaprojektowania zgodności od początku, nie po fakcie:

• Prawo do bycia zapomnianym (art. 17) - musisz umieć usunąć całą pamięć konkretnego użytkownika na żądanie; dlatego izolacja po user_id jest nie tylko dobrą praktyką, ale wymogiem - bez niej nie wykasujesz danych jednej osoby bez ruszania innych
• Minimalizacja danych (art. 5) - zapisuj tylko fakty potrzebne do działania agenta; ekstrakcja faktów (zamiast surowych transkrypcji) pomaga, ale skonfiguruj ją tak, by nie wyłapywała danych wrażliwych bez podstawy prawnej
• Izolacja najemców (multi-tenancy) - w aplikacji obsługującej wiele firm pamięć jednego klienta nie może nigdy wyciec do kontekstu innego; testuj to celowo, bo błąd izolacji to wyciek danych
• Szyfrowanie i lokalizacja - przy danych wrażliwych rozważ self-hosting pamięci (lokalna baza wektorowa + lokalny model do ekstrakcji), żeby dane nie opuszczały Twojej infrastruktury - to argument za Mem0/Zep self-hosted zamiast managed SaaS
• Prompt injection przez pamięć - jeśli agent zapisuje do pamięci treści od użytkownika, napastnik może wstrzyknąć instrukcję, która wykona się przy następnym pobraniu; pamięć to kolejny wektor z artykułu o prompt injection - traktuj zapisane treści jako niezaufane dane

Praktyczny wniosek: zanim wdrożysz pamięć produkcyjnie, odpowiedz na pytanie „jak usunę dane jednego użytkownika na żądanie?". Jeśli nie masz prostej odpowiedzi, architektura pamięci jest niegotowa na RODO.

Checklist wdrożenia pamięci agenta AI

1. 1.Rozdziel typy pamięci: working (kontekst), epizodyczna (logi), semantyczna (fakty) - nie wrzucaj wszystkiego do jednej bazy wektorowej
2. 2.Dla pamięci krótkoterminowej zacznij od podsumowania kroczącego: ostatnie 8-10 wymian w całości + żywe podsumowanie starszych
3. 3.Ważne fakty wyciągaj do pamięci długoterminowej jako ustrukturyzowane dane, zanim kompresja je zgubi
4. 4.Wybierz framework: Mem0 jako domyślny, Zep dla relacji w czasie, Letta dla autonomicznych agentów, LangMem dla stacku LangGraph
5. 5.Izoluj pamięć po user_id / session key od pierwszego dnia - to fundament prywatności i RODO
6. 6.Konfiguruj ekstrakcję faktów zamiast zapisu surowych transkrypcji - mniejsza baza, niższy koszt, mniej danych osobowych
7. 7.Zadbaj o aktualizację i deduplikację: nowy fakt ma nadpisywać sprzeczny stary, nie dokładać się obok
8. 8.Pobieraj tylko top-K istotnych faktów (3-5) - koszt i latency zostają stałe niezależnie od historii
9. 9.Przy danych wrażliwych rozważ self-hosting pamięci (lokalna baza + lokalny model do ekstrakcji)
10. 10.Traktuj zapisane treści użytkownika jako niezaufane dane - pamięć to wektor prompt injection
11. 11.Zaimplementuj usuwanie pamięci per użytkownik (prawo do bycia zapomnianym) przed wdrożeniem produkcyjnym
12. 12.Mierz jakość: czy agent pobiera właściwe fakty? Testuj na realnych scenariuszach powracających użytkowników

Najważniejsze wnioski

LLM jest bezstanowy - pamięć trzeba zbudować osobno, na dwóch poziomach. Krótkoterminowa to zarządzanie oknem kontekstu przez podsumowania i kompresję; długoterminowa to zapis faktów do zewnętrznej bazy i pobieranie ich wzorcem RAG. Rozdziel cztery typy pamięci (robocza, epizodyczna, semantyczna, proceduralna) i nie wrzucaj wszystkiego do jednej bazy wektorowej. Nie buduj od zera - Mem0 jest domyślnym wyborem, Zep dla relacji w czasie, Letta dla autonomicznych agentów, LangMem dla LangGraph. Od pierwszego dnia izoluj pamięć po user_id, ekstrahuj fakty zamiast transkrypcji i zaplanuj usuwanie danych per użytkownik - bo pamięć agenta to magazyn danych osobowych pod pełnym reżimem RODO i kolejny wektor prompt injection.

Pamięć między sesjami to jedna warstwa. Druga to zarządzanie oknem kontekstu w trakcie jednej sesji - opisuję ją we wpisie o context engineeringu.

---

Pomagam firmom projektować i wdrażać pamięć dla agentów i chatbotów AI - od wyboru architektury i frameworka (Mem0, Zep, Letta), przez integrację z kodem lub n8n, po zgodność z RODO i bezpieczeństwo. Napisz do mnie - zaczynam od przeglądu, co Twój agent powinien pamiętać i czy potrzebuje do tego frameworka.

Powiązane artykuły

• Agenci AI - jak działają
• Systemy wieloagentowe
• LangGraph - workflow agenta AI