Aktualizacja z 27 lipca 2026: po bliższym przyjrzeniu się faktycznej architekturze pamięci Hermesa i nowym regułom context engineeringu Anthropic dla modeli generacji Claude 5 doprecyzowałem zarzut - z „nieprzejrzystości” na „brak wersjonowania i granic” - i dopisałem trzecią kategorię, którą obaj dostawcy już dziś oferują: plikową auto-pamięć.
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, że agent z pamięcią osiąga 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 jako rzetelne narzędzie pracy.
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. Obietnica agenta, który po prostu zna to wszystko, choć nie muszę mu tego wpisywać, jest naprawdę kusząca. Odrzucam jednak jedną konkretną postać tej obietnicy: pamięć tworzoną przez model, która żyje poza kontrolą wersji, jest współdzielona między sesjami i nie ma granicy egzekwowalnej na poziomie repozytorium. Nie dlatego, że pamięć to zły pomysł. Po prostu już ją mam, a moja pamięć projektów ż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. Pamięć pisana przez model konkuruje z moją historią Git, a ta wygrywa w dwóch najważniejszych dla mnie wymiarach: mogę ją diffować i mogę ją ograniczyć do repozytorium.
Trzeba oddać Hermesowi sprawiedliwość: nie jest czarną skrzynką z embeddingami, którą krytycy tej kategorii - łącznie z pierwszą wersją tego tekstu - tak chętnie atakują. Rdzeń jego pamięci to dwa małe, czytelne pliki Markdown w ~/.hermes/memories/, MEMORY.md i USER.md, a do tego Hermes czyta pliki kontekstu projektu - AGENTS.md, CLAUDE.md, nawet .cursorrules - wprost z katalogu głównego repozytorium. Hermes nie zastępuje kontekstu plikowego - on go konsumuje. Ten fakt zaostrza mój zarzut, zamiast go rozbrajać: nigdy nie chodziło o to, że pamięci nie da się przeczytać. Chodzi o to, że nie ma ona historii w Git i nie kończy się tam, gdzie kończy się repozytorium klienta.
„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ł.
Sam podział, na którym opierałem ten tekst, zdążył się przesunąć. Nowe reguły context engineeringu Anthropic dla modeli generacji Claude 5 wycofują ręczne dopisywanie do CLAUDE.md skrótem klawiszowym na rzecz pamięci automatycznej, a sama implementacja mówi wiele: auto-pamięć Claude Code to pliki Markdown ograniczone do repozytorium Git - czytelne i z granicą, ale przechowywane poza repozytorium, więc nadal nie do przejrzenia w pull requeście. Rdzeń pamięci Hermesa ma ten sam kształt. Między moimi ręcznie pisanymi plikami a nieprzejrzystym magazynem istnieje więc dziś trzecia kategoria: plikowa auto-pamięć - czytelna i ograniczona, ale niewersjonowana. Rozwiązuje problem czytania, a zostawia problem historii. Wszystko, co piszę w tej sekcji o dryfie i cichym zatruwaniu, nadal jej dotyczy: błędny fakt da się już znaleźć, ale wciąż nie widać, kiedy się pojawił.
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ć. Plik pamięci bez historii zmian nie.
Przy wielu repozytoriach pamięć międzysesyjna grozi mieszaniem kontekstu
W mojej sytuacji rachunek zysków i strat 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 projektowe 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ść i rozdzielność projektów. Globalny agent może oferować profile i warstwy pamięci, ale te granice muszą być równie twarde jak checkout repozytorium - a dziś nie są. Hermes ma profile dokładnie do takiej separacji, a otwarty issue dokumentuje, że izolacja profili jest niekompletna: klonowanie profilu kopiuje pamięć, której kopiować nie powinno, a narzędzia plikowe czytają na przełaj między katalogami profili. To nie przytyk pod adresem jednego projektu. To dowód, jak trudny jest problem granic, gdy granica nie jest domyślnym zachowaniem systemu plików.
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 najlepszego. Istnieje rodzaj pracy, w którym Hermes wygrywa - i to dokładna odwrotność mojego.
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 niestrukturyzowanych 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 - i ten dzień jest bliżej, niż był przy pierwszej wersji tego tekstu. Postawiłem cztery warunki: czytelna, możliwa do przejrzenia, wersjonowana, ograniczona do katalogu.
Dwa z tych warunków są już spełnione, choć każdy przez kogo innego. Czytelność daje Hermes: jego pamięć to Markdown, który mogę otworzyć i edytować, a automatyczne tworzenie skilli zapisuje pliki SKILL.md w standardzie agentskills.io - diffowalną pamięć wyuczoną, dokładnie taką, jaką przewidywałem, tyle że dla warstwy metod, a nie faktów o klientach. Granicę daje auto-pamięć Claude Code, bo działa w obrębie jednego repozytorium Git. Brakuje wciąż wersjonowania: pamięci wyuczonej z historią w Git, którą przejrzę w pull requeście. W dniu, w którym któreś z tych narzędzi zacznie commitować pamięć do repozytorium, które ta pamięć opisuje, bronione tu rozróżnienie straci sens - i przyjmę to z ulgą, bo dostanę własny system z lepszą ergonomią.
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 i widać już, że ta zmiana postępuje. 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 ma historii, którą mogę diffować, ani granicy, którą mogę wyegzekwować, 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ę.