Sprzedawca Hermesa powiedziałby mi, że moim problemem jest zapominanie. Obietnica na 2026 rok jest prosta: osobisty agent pamięta wszystko między sesjami, buduje model mojego sposobu pracy i oszczędza mi codziennego tłumaczenia stacka od nowa. W tej samej kategorii mem0 raportuje około 26% względnej poprawy w benchmarku pamięci. Pamięć nie jest już dodatkiem. Stała się podstawowym oczekiwaniem wobec agenta, który chce być traktowany poważnie.
Prowadzę JC WebStudio. W typowym tygodniu mam w jednym oknie wtyczkę WooCommerce dla klienta używającego prefiksu acme_, w drugim wtyczkę WordPressa z prefiksem globex_ dla kogoś innego, do tego kilka stron marketingowych w Astro 5 i aplikację w Laravelu, która pokrywa sporą część rachunków. Obietnica agenta, który po prostu zna to wszystko, choć nie muszę mu tego wpisywać, jest naprawdę kusząca. Odrzucam jednak jej konkretną wersję: nieprzejrzystą pamięć tworzoną przez model, współdzieloną między sesjami i trudną do sprawdzenia lub ograniczenia. Nie dlatego, że pamięć to zły pomysł. Po prostu już ją mam, a moja żyje w Git.
Prawdziwa obietnica agenta z pamięcią brzmi: „brakuje ci kontekstu”
Po odjęciu marketingu Hermes opiera się na jednym założeniu: mój kontekst pracy jest zamknięty w głowie, ulotny i odtwarzany przy każdej sesji. Dla wielu osób to prawda. Wartość agenta z pamięcią rośnie wraz z chaosem w kontekście użytkownika. Jeśli każdy projekt istnieje wyłącznie w pamięci krótkotrwałej, agent, który stopniowo buduje model nawyków, jest realnym usprawnieniem. Wynik z benchmarku może wręcz nie oddawać całej różnicy odczuwalnej w codziennej pracy.
W moim przypadku to założenie jest błędne. Kontekst mam zapisany w zwykłych plikach, które orkiestrator ładuje na żądanie: wersjonowanym skills-vault dla metod wspólnych dla wielu projektów, osobnych .cursor/rules dla każdego repozytorium, pliku CLAUDE.md w katalogu głównym projektu i PRD dla projektu klienta. Warstwa wspólna przechowuje zasady pracy, a informacje o klientach pozostają w ich repozytoriach. Sprzedażowa opowieść trafia więc na kogoś, kto problem pamięci rozwiązał już innym mechanizmem. Nieprzejrzysta pamięć agenta konkuruje z moją historią Git, a ta wygrywa w najważniejszym dla mnie wymiarze: mogę ją przeczytać.
„Pamięć” w moim workflow to cztery role, nie jeden mózg
Świadomie dzielę pracę między czterech agentów. Ten podział działa tylko dlatego, że żaden z nich nie jest właścicielem kontekstu. Claude Chat zajmuje się planowaniem i dłuższą analizą. Claude Code robi implementację i refaktoryzacje. Codex CLI obsługuje zadania ratunkowe oraz prace asynchroniczne, które uruchamiam i zostawiam. Cursor służy mi do iteracyjnej edycji kodu pod ścisłym nadzorem. Analiza Pragmatic Engineer z marca 2026 prowadzi do podobnego wniosku: Claude Code i Cursor uzupełniają się, zamiast konkurować. Jak dzielę pracę wspomaganą przez AI między narzędziami podąża za tym samym wzorcem. Ten model jest trwały tylko dlatego, że wspólny kontekst ma postać plików, a nie prywatnego magazynu wewnątrz każdego narzędzia.
Tego właśnie nie uwzględnia obietnica pamięci. Cursor ma własną funkcję memories, ale ja polegam przede wszystkim na indeksie kodu. Wyszukiwanie semantyczne, dzięki któremu edycje w Cursorze wydają się trafne, czyta mój kod, a nie model mojej osoby. Gdy chcę, żeby agent znał moje konwencje, nie czekam, aż wywnioskuje je po dwudziestu sesjach. Zapisuję je raz w .cursor/rules, commituję, a każdy agent na każdej maszynie czyta to samo źródło prawdy. Indeks odnajduje kod; .cursor/rules i CLAUDE.md definiują konwencje. Oba czytają artefakty z repozytorium. Żaden nie buduje prywatnego modelu mnie. Orkiestrator ładuje właściwy plik skilla we właściwym momencie. To wyszukiwanie w artefakcie, który sam napisałem, a nie odtwarzanie wiedzy z notatek stworzonych o mnie przez model.
Kontekst w plikach wygrywa, bo każdą zmianę widać w diffie
Oto scenariusz awarii, który przesądza sprawę. Automatyczna pamięć agenta - wzorzec, w którym LLM pisze między sesjami notatki o projekcie, podobnie jak opcjonalna pamięć w tle w Cursorze - to nadal LLM produkujący prozę. Te notatki dryfują. Model zapisuje jednorazową konwencję tak, jakby była regułą. Pomija rzeczy, na których faktycznie mi zależy. Co gorsza, pamięć może psuć się po cichu. Wystarczy jeden błędny fakt na początku, a błąd utrwala się w kolejnych sesjach bez diffa pokazującego, gdzie powstał.
CLAUDE.md ma realne koszty i nie zamierzam ich ukrywać. Przy dużym rozmiarze nie zawsze jest ładowany w całości. Nie oferuje wyszukiwania semantycznego. To płaski dokument, a agent lepiej uwzględnia treści z początku niż instrukcje zakopane niżej. Plik dezaktualizuje się, gdy zmieniam konwencje i zapominam go poprawić. Jego utrzymanie wymaga ręcznej pracy, której system pamięci budowanej automatycznie nie pokazuje jako osobnej pozycji kosztowej.
Ale to nadal Markdown w Git. Gdy agent robi coś źle, otwieram plik i widzę instrukcję, która go do tego skłoniła. Zmiany kontekstu przeglądam w pull requeście tak samo jak kod. Wzorzec z dowiązaniem symbolicznym do AGENTS.md pozwala używać jednego pliku w wielu narzędziach bez powielania treści. Koszt utrzymania kupuje mi audytowalność, a przy pracy dla klientów nie jest ona opcjonalnym dodatkiem. Gdy wtyczka z prefiksem globex_ wypuści błąd, muszę odtworzyć, dlaczego agent podjął daną decyzję. Diff może na to odpowiedzieć. Nieprzejrzysty magazyn embeddingów nie.
Przy wielu repozytoriach pamięć międzysesyjna grozi mieszaniem kontekstu
W mojej sytuacji rachunek zmienia się radykalnie. Trwała pamięć współdzielona przez wszystkie projekty, bez ścisłego ograniczenia do konkretnego repozytorium, tworzy ryzyko mieszania kontekstu. Agent zapamiętuje, że acme_ jest prefiksem jednego klienta, a potem stosuje go w repozytorium klienta używającego globex_. Pamięta modyfikację checkoutu, za którą zapłacił jeden klient WooCommerce, i podsuwa ją innemu. To nie fantazja o awarii, lecz przewidywalny skutek używania jednego magazynu pamięci dla klientów o podobnych problemach.
Podejście oparte na plikach zapewnia użyteczną domyślną granicę: repozytorium. Pliku CLAUDE.md jednego klienta nie ma w katalogu roboczym drugiego, a warstwa wspólna zawiera metody pracy, nie dane poszczególnych klientów. Nie jest to absolutna gwarancja bezpieczeństwa, bo orkiestrator nadal może załadować niewłaściwy plik. Zakres kontekstu pozostaje jednak jawny, możliwy do sprawdzenia i zgodny z tym, jak działają poufność oraz rozliczenia. Globalny agent może oferować profile i warstwy pamięci, ale dopóki ich granice nie są równie widoczne i egzekwowalne, nie mogę ufać im w ten sam sposób. W zastosowaniach osobistych zacieranie granic bywa zaletą. Przy równoległej pracy dla wielu klientów jawne granice są częścią rozwiązania. Ta sama zasada stoi za traktowaniem skilli wielokrotnego użytku jako infrastruktury workflow: ograniczenie jest funkcją.
Gdzie agent z pamięcią faktycznie wygrałby z moim systemem
Nie byłoby uczciwe przedstawianie kontekstu w Git jako rozwiązania zawsze lepszego. Istnieje rodzaj pracy, w którym Hermes wygrywa, i jest on odwrotnością mojej.
Pierwszy przypadek to długotrwały projekt osobisty bez granicy poufności i drugiego recenzenta. Koszt utrzymania CLAUDE.md może wtedy przewyższać korzyść z audytu. Jeśli sam pracuję w jednej bazie kodu, pomyłka pamięci ma mniejsze konsekwencje, a wartość kontekstu widocznego w diffie spada. Agent, który przez miesiące gromadzi wiedzę o jednym projekcie, rzeczywiście mógłby zaoszczędzić mi pisania.
Jeszcze mocniejszym przypadkiem są sprawy osobiste poza kodem. Informacje o tym, że wolę głęboką pracę rano, pewien klient pisze w piątki albo regularnie porzucam podobne projekty poboczne, tworzą rozmyte wzorce między sesjami. Automatyczna pamięć radzi sobie z nimi lepiej niż plik, którego i tak nie chciałoby mi się utrzymywać. Nie zamierzam pisać LIFE.md i przeglądać zmian własnych nawyków w pull requestach. Przy nieustrukturyzowanych szczegółach życia zawodowego nieprzejrzystość pamięci kosztuje mnie niewiele, bo nie ma tam decyzji do audytu ani danych klienta do ochrony.
Zasada jest prosta: pamięć budowana przez model wygrywa tam, gdzie granice mają mniejsze znaczenie, a kontekst jest zbyt rozmyty, by utrzymywać go ręcznie. Moja praca dla klientów wygląda odwrotnie: ma twarde granice i uporządkowane konwencje, które warto zapisać.
Kiedy bym to przemyślał ponownie
Przesiadłbym się, gdyby pamięć tworzona przez model stała się widoczna w diffie. Gdyby Hermes udostępniał swój magazyn jako wersjonowane, czytelne artefakty, które można przejrzeć w pull requeście i ograniczyć do katalogu, bronione przeze mnie rozróżnienie straciłoby sens. Byłby to mój system z lepszą ergonomią i chętnie bym go przyjął. To samo dotyczy wyszukiwania semantycznego w moich plikach Markdown: może rozwiązać problem rozmiaru bez oddawania kontroli, o ile nadal widzę każde źródło i każdą zmianę. Właśnie na taką zbieżność stawiam. Obowiązuje tu ta sama zasada co przy audytowalnych bramkach jakości AI: zachowaj własne źródło prawdy, a narzędziom pozwól je indeksować.
Pytanie nie brzmi „pamięć czy jej brak”, tylko „kto jest właścicielem kontekstu”
Ujmowanie tego jako sporu między agentem stanowym i bezstanowym prowadzi w złą stronę. Nie pracuję bez stanu. Przeciwnie, świadomie przechowuję go bardzo dużo. Różnica polega na tym, że mój stan składa się z artefaktów, które sam napisałem i mogę przeczytać, porównać oraz ograniczyć do katalogu. Pamięć stworzona przez model może zawierać użyteczny kontekst, ale jeśli nie widzę w pełni jej źródeł i granic, nie mogę nadać jej takiego samego autorytetu.
Dla samodzielnego programisty pracującego nad jednym długim projektem oddanie części własności kontekstu w zamian za wygodę może być uczciwym kompromisem. W studiu prowadzącym równolegle wiele repozytoriów klientów błędnie zapamiętany fakt może jednak stać się problemem rozliczeniowym albo naruszeniem poufności. Nie chodzi o samą pamięć. Chodzi o opiekę nad kontekstem. Dopóki agent nie zapewni mi kontekstu czytelnego, możliwego do przejrzenia i ograniczonego do właściwego repozytorium, będę przechowywał go w Git. Tam dokładnie widzę, co system uznaje za wiedzę.