Agentowy system operacyjny dla Claude Code — pamięć, która niczego nie zapomina

2026-06-19 • Simon Scrapes • AI zagraniczne •tutorial •waga 4/5 •18 min czytania

Autor pokazuje, jak złożyć z projektów open source pamięć dla Claude Code: z cytowaniami, wyszukiwaniem znaczeniowym i kontrolą dostępu. Praktyczny plan architektury dla zespołów pracujących z Claude Code na poważnie.

Robocza publikacja redakcyjna na podstawie publicznego transkryptu YouTube. Źródło: YouTube.

Oryginalny tytuł filmu

Claude Code Agentic OS… It Remembers Everything

O czym jest ten film

  1. Fabryczna pamięć Claude Code jest zaskakująco słaba: w repozytorium prowadzonym od miesięcy indeks pamięci zawierał jeden wpis.
  2. Każdy system pamięci agenta odpowiada na trzy pytania: gdzie przechowuje dane, co dostarcza do kontekstu na starcie sesji i jak odnajduje informacje na żądanie — Claude Code domyślnie radzi sobie słabo ze wszystkim trzema.
  3. Autor definiuje „idealną pamięć” biznesową jako cztery elementy zapożyczone z projektów open source: cytowanie źródeł (GBrain Garry’ego Tana), szybkie dostarczanie bieżącego kontekstu (Hermes), wyszukiwanie znaczeniowe (MemSearch) i kontrolę dostępu w zespole (znów GBrain).
  4. W fabrycznej wersji auto memory zapisuje niemal nic, do kontekstu ładuje się głównie CLAUDE.md, a odszukiwanie sprowadza się do kosztownego tokenowo przekopywania starych sesji po słowach kluczowych.
  5. Wybór frameworku autor spina drzewem decyzyjnym: zapis dosłowny czy streszczony (Mem Palace i ClaudeMem kontra MemSearch), ile kontekstu dostarczać na start (zalecany mały, „zamrożony” zrzut à la Hermes), jak dokładne wyszukiwanie (frazy czy hybryda wektorowa) i czy odpowiedź ma być surowym fragmentem, czy syntezą z cytowaniami.
  6. Własny stos autora: zamiast MemSearch — lokalnie działające PGlite z pgvector, bez zewnętrznych zależności, z instalacją na Windows i możliwością ograniczania pamięci per użytkownik; dla zespołów — Postgres w chmurze (Railway) z bezpieczeństwem na poziomie wierszy.
  7. Przepływ w praktyce: mechanizm uruchamiany po każdej turze decyduje, co trafi do pamięci krótkoterminowej; do długoterminowej trafia wszystko; odszukiwanie jest trójstopniowe, a odpowiedź wraca z plikiem, linią i datą źródła.
  8. System potrafi też uzupełnić pamięć wstecz: automatycznie zamienia całą dotychczasową historię sesji w przeszukiwalny magazyn, więc w dniu wdrożenia nie zaczyna się od zera.
  9. Zapowiadany Team OS: dwie zasady — nietechniczni członkowie zespołu edytują kontekst marki i CLAUDE.md w Notion lub Google Drive, a dostęp do bazy jest zakresowany tagami (system/zespół/klient/prywatne) i egzekwowany przez samą bazę.
  10. Gotowa instalacja jedną komendą dostępna jest w płatnej społeczności autora, Agenty Academy.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Oceniaj pamięć agenta trzema pytaniami: przechowywanie, dostarczanie, odszukiwanie

Na czym polega: Każdy system pamięci — fabryczny czy doklejony — odpowiada na trzy pytania: gdzie zapisuje to, co usłyszał, co ładuje do kontekstu na początku sesji i jak znajduje właściwą rzecz na żądanie. Claude Code w wersji domyślnej jest słaby we wszystkich trzech.

Jak stosować: Zrób audyt własnego setupu dokładnie w tym układzie. Sprawdź, co realnie zapisuje się w plikach pamięci po miesiącach pracy (u autora był to jeden wpis), co dokładnie ładuje się na start sesji i czy da się cokolwiek odnaleźć inaczej niż przez identyfikator sesji.

Na co uważać: CLAUDE.md to nie pamięć — to instrukcja, nie magazyn historii. Powiększanie go do tysięcy linijek pogarsza odszukiwanie zamiast je naprawiać.

2.Odpowiedź bez źródła to tylko domysł

Na czym polega: Wzorzec zaczerpnięty z GBrain Garry’ego Tana: każdy fakt wraca z cytowaniem — plik, linia, data — a gdy system odpowiedzi nie znajduje, mówi to wprost zamiast konfabulować.

Jak stosować: W własnym mechanizmie odszukiwania dodaj etap ponownego porządkowania wyników (rerankingu) i składania odpowiedzi ze źródłami; w promptach wymagaj, by agent zawsze podawał pochodzenie faktu i przyznawał się do braku danych.

Na co uważać: Cytowanie podnosi wiarygodność, ale nie gwarantuje poprawności — model może źle odczytać kontekst źródła. Przy kluczowych decyzjach zajrzyj do źródła samodzielnie.

3.Na start sesji dostarczaj mały, wyselekcjonowany zrzut kontekstu

Na czym polega: Wzorzec Hermesa: ograniczony, „zamrożony” pakiet kluczowych informacji — aktualne decyzje, preferencje, kontekst marki, dziennik danego dnia — wczytywany automatycznie na początku każdej sesji.

Jak stosować: Zbuduj własny memory.md jako krótki, starannie dobrany zestaw i podłącz go do hooka (mechanizmu uruchamianego przy zdarzeniu); sięgnij dodatkowo po pliki w duchu user.md i dziennik bieżącej pracy.

Na co uważać: Zrzut musi mieć limit rozmiaru. Przepełniony kontekst degraduje jakość odpowiedzi i podnosi koszt tokenów — im więcej w oknie, tym trudniej odszukać to, co ważne.

4.Łącz wyszukiwanie znaczeniowe ze słowami kluczowymi

Na czym polega: Hybrydowe podejście z MemSearch: rozmowy dzielone są na fragmenty (chunki), zamieniane na wektory i przeszukiwane po znaczeniu, z równoległym dopasowywaniem fraz. Zapytanie o obsługę płatności odnajdzie też wzmianki o Stripe, choć nie mają wspólnych słów.

Jak stosować: Projektując pamięć długoterminową, planuj cały łańcuch: podział rozmów na fragmenty → zamiana na wektory → baza wektorowa → zapytania hybrydowe (wektor plus fraza).

Na co uważać: Wyniki zależą od sensownego podziału na fragmenty i od tego, czy dane faktycznie trafiają do bazy. Wyszukiwanie znaczeniowe nie pomoże, gdy odpowiedzialny za zapis etap prawie nic nie utrwala — a dokładnie tak działa fabryczne auto memory.

5.Przechowuj rozmowy w markdown — pamięć ma być przenośna

Na czym polega: Najlepsze frameworki (MemSearch, OpenClaude i inne) zapisują sesje jako pliki markdown, z których później da się odbudować całą bazę. Dzięki temu pamięć nie jest zakładnikiem jednego narzędzia.

Jak stosować: Trzymaj pełne zapisy rozmów jako pliki tekstowe obok bazy wektorowej — to naturalna kopia zapasowa i ułatwienie przy ewentualnej migracji.

Na co uważać: Markdown to warstwa surowa, nie indeks. Bez wektorów zostaje wyszukiwanie frazowe, które nie znajdzie ustaleń opisanych innymi słowami niż te w zapytaniu.

6.Pamięć krótkoterminowa wymaga sprzątania

Na czym polega: Przy każdym zapisie system sprawdza istniejący plik pamięci pod kątem duplikatów i informacji unieważnianych przez nową decyzję — fakt o zmienionej cenie ma zastąpić stary, a nie dopisywać się obok.

Jak stosować: Do pamięci krótkoterminowej promuj tylko to, co wraca w każdej sesji: decyzje, ceny, preferencje, czynniki środowiskowe. Każdy wpis opatrz datą i autorem.

Na co uważać: Sprzeczne wpisy o jednej sprawze wprowadzają agenta w błąd; bez znaczników czasu nie da się rozstrzygnąć, który jest aktualny.

7.Odszukiwanie trójstopniowe: kontekst → wyszukiwanie → uporządkowanie wyników

Na czym polega: Agent najpierw sprawdza krótkoterminowy zrzut już obecny w kontekście; potem zamienia zapytanie na wektor i sięga do bazy; na końcu porządkuje pięć–dziesięć trafień i składa z nich odpowiedź.

Jak stosować: Nie każ agentowi od razu grzebać w całej historii — najpierw tania warstwa (kontekst sesji), dopiero potem droższe wyszukiwanie. Ogranicz liczbę zwracanych wyników i dołóż reranking przed złożeniem odpowiedzi.

Na co uważać: Przekopywanie pełnych starych sesji jest bardzo drożne w tokeny i często zawodzi — szukanie frazowe nie przypomni ustaleń sprzed pół roku opisanych innym językiem niż dzisiejsze pytanie.

8.Zamień dotychczasową historię sesji w pamięć od pierwszego dnia

Na czym polega: Autor dodaje uzupełnienie wstecz (backfill): automatyczny import całej historii rozmów do pamięci długoterminowej i krótkoterminowej w dniu instalacji systemu.

Jak stosować: Przy wdrożeniu uruchom jednorazowy proces, który przerobi istniejące zapisy rozmów na wektory i wyłuska z nich kluczowe fakty — zamiast zaczynać od pustej bazy.

Na co uważać: Stare sesje bywają zaszumione i pełne powtórzeń; po imporcie przejrzyj wyekstrahowane fakty pod kątem sprzeczności oraz danych, których w pamięci być nie powinno.

9.Kontrolę dostępu egzekwuj w bazie danych, nie w prompcie

Na czym polega: Zespołowa wersja opiera się na Postgresie z bezpieczeństwem na poziomie wierszy: każdy wpis ma tag (system, zespół, klient, prywatne), a każde zapytanie jest filtrowane według pytającego — wymusza to sama baza, nie instrukcja w prompcie.

Jak stosować: Pracujesz samodzielnie — lokalne PGlite z pgvector, bez zewnętrznych zależności, z instalacją na Windowsie. W zespole — Postgres hostowany w chmurze (np. Railway) z regułami dostępu do wierszy i pełną izolacją klientów oraz projektów.

Na co uważać: Źle nadany tag ujawnia dane — tagowanie trzeba pilnować jak ognia. Właściciel bazy widzi wszystko, więc zakresy nadaje świadomie i okresowo je przegląda.

10.Rozdziel role: nietechniczni edytują w Notion i Drive, agent pilnuje reszty

Na czym polega: W zapowiadanym Team OS pliki takie jak kontekst marki czy CLAUDE.md mają swoją wersję podstawową w Notion lub Google Drive, by osoby nietechniczne mogły je redagować; Claude Code zajmuje się umiejętnościami i pamięcią, a wszystko jest archiwizowane i wersjonowane w GitHubie.

Jak stosować: Wyznacz w zespole jedno, znajome każdemu miejsce edycji kontekstu firmowego i dopilnuj, by zmiany stamtąd trafiały do repozytorium agenta wraz z kopią zapasową.

Na co uważać: Powstaje ryzyko dwóch źródeł prawdy — jeśli ktoś zacznie edytować pliki bezpośrednio w repozytorium, wersje się rozjadą. Ustal jedną ścieżkę zmian i jej pilnuj.

Redakcyjne tłumaczenie

Wstęp: podatek płacony przy każdej sesji

Narzędzie tak dobre jak Claude Code ma zaskakująco słabą pamięć w wersji fabrycznej. Decyzje, które już podjęliście, ustalenia, które już tłumaczyłeś, praca, którą wykonałeś — wszystko to znika. Z czasem każda sesja zaczyna od tego ciążyć, a to realny koszt Twojego czasu.

Przez ostatnie miesiące rozbierałem na części najlepsze systemy pamięci. Przyjrzeliśmy się Hermesowi, GBrain, MemSearch i kilku innym, żeby ustalić, co każdy z nich robi inaczej. Następnie zbudowałem najlepsze elementy każdego z nich w jeden, własny system — „mózg” dla Claude Code. Pamięć, która odnajdzie półroczną decyzję, choć zapytasz o nią zupełnie innymi słowami. Pamięć, która wskazuje dokładną rozmowę stojącą za każdą odpowiedzią, żeby można jej było ufać. I wreszcie pamięć, którą może dzielić cały zespół: każdy dostaje to, czego potrzebuje, nikt nie widzi tego, czego widzieć nie powinien. Na końcu tego materiału będziesz mieć plan, jak zbudować to samodzielnie.

Cztery filary idealnej pamięci

Zacznijmy od samej idei. Dla firmy zdefiniowałem idealną pamięć jako cztery konkretne właściwości — każdą zapożyczyłem z innego projektu open source, który swój kawałek układanki rozwiązał lepiej niż cokolwiek, co widziałem gdzie indziej.

Po pierwsze: cytuje źródła. Kiedy system mówi ci coś, mówi też, skąd ta informacja pochodzi. Nie tylko z jakiego pliku — dostajesz rzeczywisty kontekst rozmowy: dokładne słowa, którymi coś ustalono, i datę tamtego ustalenia. A jeśli czegoś nie wie, mówi o tym wprost, zamiast wymyślać. To kluczowe, zwłaszcza gdy pracujesz z innymi: pamięć może przekazywać ci cudze decyzje, a własne przecież pamiętasz dużo łatwiej. Ten element zainspirował GBrain — projektem, który zbudował Garry Tan z Y Combinator; szczerze polecam zapoznać się z jego zasadami.

Po drugie: szybki dostęp do bieżącego kontekstu. To, co omawiasz z Claude Code na co dzień — ceny, aktywni klienci, aktualne ustalenia — powinno być pod ręką w każdej sesji. Sztuczka polega na małym, wyselekcjonowanym zrzucie kontekstu, który dyskretnie ładuje się na starcie każdej sesji dzięki hookowi (mechanizmowi uruchamianemu automatycznie przy określonym zdarzeniu). Trzeba go przy tym ograniczyć rozmiarem, żeby nie spuchł i nie zepsuł jakości odpowiedzi — nadmiar kontekstu działa tu na niekorzyść. To dokładnie wzorzec „zamrożonego zrzutu” z agenta Hermes: za każdym razem dostarcza on do rozmowy ograniczoną porcję kluczowych informacji. Oszczędza to górę czasu w porównaniu z przekopywaniem się przez dużą bazę wspomnień, z których większość i tak jest nieaktualna — albo z sytuacją, w której nie ma żadnej pamięci.

Po trzecie: długoterminowe wyszukiwanie po znaczeniu. Coś, co uzgodniłeś pół roku temu — powiedzmy, w zapisie ze spotkania — powinno wrócić, gdy znów stanie się aktualne. Nie dlatego, że użyłeś dokładnie tych samych słów, ale dlatego, że zapytałeś o coś pokrewnego, a agent rozpoznał, że tamten kontekst jest ważny. To jest wyszukiwanie znaczeniowe, wywodzące się z baz wektorowych; w pamięci agentów chętnie korzystają z niego frameworki open source, m.in. MemSearch. Schemat jest taki: wszystkie rozmowy dzieli się na fragmenty, streszcza lub zachowuje dosłownie, zamienia na wektory — i odtąd można ich szukać po znaczeniu. Warto to połączyć z podejściem hybrydowym, dopuszczającym też słowa kluczowe. Jeśli zapytasz o obsługę płatności, system znajdzie nie tylko wyniki z tą frazą, ale i wypowiedzi o Stripe — bo rozumie, że Stripe i płatności to jeden temat. Nawet gdy zapisy nie mają ani jednego wspólnego słowa, informacja wraca.

Po czwarte: kontrola zakresu dostępu — między klientami i w zespole. Praca dla jednego klienta musi być całkowicie odseparowana od pracy dla drugiego; bywa, że podobnie między projektami. Gdy dołączasz współpracownika, widzi swoich klientów — i tylko swoich. Pamięć wie, kto pyta, bo dostęp do wspólnego mózgu jest ograniczany według osoby. To znowu pomysł „mózgu firmowego” z GBrain: jedna wspólna pamięć, w której każdy zapis jest otagowany właścicielem, a każde zapytanie filtruje się według pytającego — każdy sięga tylko tam, gdzie ma prawo.

Składając to w całość: cytowania z GBrain, dostarczanie kontekstu od Hermesa, wyszukiwanie po znaczeniu z MemSearch i zakresowanie dostępu, ponownie, z GBrain.

Dlaczego fabryczny Claude Code nie wystarcza

Zanim pokażę, jak to wdrożyliśmy, szybko wyjaśnię, dlaczego Claude Code prosto z pudełka nie jest wystarczający. Każdy system pamięci na świecie odpowiada w gruncie rzeczy na trzy pytania: gdzie i jak przechowuje to, co mu powiedziano? Co dostarcza do krótkoterminowego kontekstu na początku nowej sesji — czyli co trzyma lokalnie pod ręką? I jak odnajduje właściwą rzecz, gdy o nią zapytasz? Powiem bez ogródek: Claude Code domyślnie radzi sobie słabo ze wszystkimi trzema.

Przechowywanie. Claude Code ma funkcję auto memory — w praktyce notatki, które sam zapisuje na podstawie twoich poprawek i preferencji. Ale utrwala tylko pojedyncze rzeczy, które sam uzna za ważne, więc realnie zostaje niewiele. Przykład: mogę uruchomić w Claude Code komendę /memory, która wypisze różne zestawy pamięci — auto memory jest włączone. Po otwarciu folderu auto memory w repozytorium, nad którym pracuję od miesięcy, widzę dosłownie dwa pliki: indeks memory.md z jednym odnośnikiem, dotyczącym jednego konkretnego projektu. Miesiące pracy, jeden zapis. Chyba że wprost powiesz „zapamiętaj ten fakt”, prawie nic nie zostanie utrwalone. A trudno sobie cokolwiek przypomnieć, jeśli niczego nie zapisano.

Dostarczanie do kontekstu. Gdy otwierasz sesję, Claude Code ładuje CLAUDE.md — i w zasadzie niewiele poza tym. Dołącza wspomniany plik pamięci, ale skoro prawie nic się tam nie zapisuje, równie dobrze mógłby go w ogóle nie być. Nie ma wyselekcjonowanego zrzutu typu „to naprawdę ważne w tej firmie”, „to kontekst marki”, „to świeże ustalenia”. O ten kontekst musisz zadbać ty, nie on — nadal bardzo, bardzo ręcznie.

Odszukiwanie — największa luka. W praktyce nie ma tu żadnego wyszukiwania. Gdy poprosisz o przypomnienie, Claude Code ma dwie drogi: przejrzeć plik auto memory (który, jak widzieliśmy, jest prawie pusty) albo przeszukać wcześniejsze sesje — a to w praktyce przekopywanie całego ich kontekstu. Pożera mnóstwo tokenów i często w ogóle nie potrafi szukać po znaczeniu: zostają słowa kluczowe, które mniej więcej pasują do intencji pytania. Można co prawda wznowić dawną rozmowę poleceniem resume, ale trzeba znać jej identyfikator albo trafić frazą. Pytanie „co ustaliliśmy na tamtym spotkaniu z klientem pół roku temu?” nie przyniesie wiarygodnej odpowiedzi — często nie przyniesie żadnej. Przy takich brakach narzędzie odpada w chwili, gdy zaczynasz prowadzić prawdziwych klientów i projekty w perspektywie miesięcy.

Drzewo decyzyjne: jak wybrać framework pamięci

Skoro wiadomo, gdzie Claude Code zawodzi, można ocenić, co oferują rynek open source i rozwiązania płatne. Najpierw trzeba jednak rozstrzygnąć kwestie przechowywania, dostarczania i odszukiwania — to one przesądzają, który framework pasuje do twojego przypadku. Przeprowadzę cię przez logikę i pytania, które zadaliśmy sobie w każdym węźle tej decyzji.

Pierwszy rozdział: dosłownie czy streszczenie. Czy musisz przechowywać wszystkie rozmowy słowo w słowo i odtwarzać je verbatim, czy wystarczy ci streszczenie większości z nich plus kluczowe fragmenty? Jeśli zależy ci na pełnym, dosłownym odtwarzaniu, najlepiej na rynku wypadają Mem Palace i ClaudeMem. Jeśli wolisz wyselekcjonowany zestaw kontekstu z każdej rozmowy — sięgnij po MemSearch; podobne wzorce stosuje też OpenClaude. Co czyni te frameworki naprawdę mocnymi: zapisują rozmowy w markdown, więc później można je z plików odbudować — pamięć jest w pełni przenośna.

Drugi rozdział: ile kontekstu dostarczać na start. Na początku sesji — nic, trochę czy wszystko? Odradzam ładowanie wszystkiego, czyli upychanie tysięcy linijek w CLAUDE.md: takie przeładowanie bardzo utrudnia odszukiwanie. Lepiej pójść śladem Hermesa i wstrzykiwać zamrożony zrzut: pliki soul.md, user.md i memory.md — starannie dobrany zestaw niedawnych ustaleń, a nie to, co notuje fabryczne auto memory — oraz dziennik pracy z danego dnia. Krótko mówiąc: ograniczona, „zamrożona” porcja pamięci, trafiająca do każdej rozmowy.

Trzeci rozzdział: dokładność odszukiwania. Wystarczą słowa kluczowe, czy potrzebujesz znaczenia? Hermes domyślnie szuka po słowach; MemSearch ma hybrydę wektorową — szuka i po znaczeniu, i po frazach. Jak wspominałem: zapytanie o obsługę płatności rozpozna, że Stripe to trafienie, i wróci z lepszym kontekstem.

Czwarty rozdział: forma odpowiedzi. Chcesz surowych fragmentów prosto z bazy wektorowej, czy odpowiedzi złożonej w całość, z cytowaniami — skąd to wiemy, z której linii, z jakiego dnia? Jeśli to drugie, trzeba dołożyć warstwę w duchu GBrain Garry’ego Tana: wyniki są ponownie porządkowane, a na ich podstawie powstaje odpowiedź wskazująca dokładne źródło. I rzecz może jeszcze ważniejsza — system przyznaje się, gdy odpowiedzi nie znajduje.

Widać zatem, że wdrażane przez nas funkcje to świadomy wybór z różnych frameworków pod konkretne zastosowania — i dokładnie tak samo powinieneś postąpić. Możesz wziąć Hermes czy MemSearch z półki, ale bardzo zachęcam, żebyś wiedział, jak dane narzędzie podchodzi do przechowywania, dostarczania i odszukiwania.

Nasz stos: od MemSearch do PGlite i pgvector

Widzowie moich wcześniejszych materiałów o pamięci pamiętają może, że na długi magazyn wybraliśmy pierwotnie MemSearch. W trakcie wdrażania wymieniliśmy go jednak na lokalnie hostowane PGlite i magazyn wektorowy. (Informacja dodatkowa: PGlite to odchudzona wersja Postgresa działająca lokalnie, bez stawiania osobnego serwera bazy.) Logikę MemSearch zachowaliśmy — markdown przede wszystkim, dzienne logi, hybrydowe wyszukiwanie znaczeniowe i słowami kluczowymi — ale przenieśliśmy ją na PGlite z pgvectorem z trzech powodów. Po pierwsze, brak zewnętrznych zależności: wszystko działa lokalnie na twoim komputerze, jeśli nie musisz się z nikim dzielić. Po drugie, instaluje się na Windowsie — z MemSearch było tam naprawdę krucho, bo, jak się okazało przy wdrażaniu, wymagał konta chmurowego. Po trzecie, najważniejsze: pozwala ograniczać pamięć per użytkownik. A dla członków naszej społeczności, którzy chcą to uruchomić zespołowo, pomagamy postawić bazę Postgres na Railway (Informacja dodatkowa: Railway to platforma chmurowa do hostowania baz danych i aplikacji) — hostowaną w chmurze, z bezpieczeństwem na poziomie wierszy, które ogranicza dostęp danego użytkownika do wybranych projektów, klientów i dowolnych innych zakresów. To dla nas fundament pod zespołowy dostęp.

Cały przepływ: od wypowiedzianego faktu do cytowanej odpowiedzi

Jak to wygląda w praktyce, od początku do końca? Załóżmy, że wczoraj powiedziałem Claude’owi: postanowiliśmy wprowadzić trzeci plan cenowy, bo obniża próg wejścia dla naszej społeczności.

Najpierw wkracza hook stop — mechanizm uruchamiany po każdej turze. System ocenia, czy zapisać coś w pamięci krótkoterminowej jako trwały fakt. Niezależnie od tej decyzji rozmowa trafia też do długoterminowego, przeszukiwalnego magazynu. Do pamięci krótkoterminowej promowane są rzeczy według własnego osądu systemu: czy to decyzja? zmiana ceny? preferencja? czynnik środowiskowy, który chciałbym mieć pod ręką w każdej sesji? Jeśli tak — ląduje w pliku memory.md, a przy okazji system przegląda istniejące wpisy i sprawdza, czy nowy nie dubluje informacji albo nie unieważnia czegoś, co już tam jest.

Obok widać roboczy kontekst Claude — w tym okolu widać dokładnie, co się ładuje. Cała pamięć krótkoterminowa dostarczana jest do następnej sesji: to właśnie ten zamrożony zrzut, który po restarcie Claude trafia do nowej rozmowy. Podobnie jak Hermes dodajemy soul, user i pamięć oraz „dziś” — świeże fakty podawane do kontekstu roboczego.

Niezależnie od tego wszystko archiwizuje się długoterminowo. Rozmowa przechodzi przez proces dzielenia na fragmenty i zamiany na wektory, dzięki czemu później jest przeszukiwalna. Gdy zapytam „co ustaliliśmy w kwestii planów?” — choć nie padną słowa „plany cenowe” ani „społeczność” — system ma cały kontekst, żeby to połączyć i ocenić, co jest istotne.

Odszukiwanie działa trójstopniowo. Najpierw czytany jest krótkoterminowy kontekst: często to, czego szukasz, już tam jest. Jeśli nie — system schodzi głębiej: zamienia zapytanie na wektor i szuka w bazie podobnych wektorów, łącząc wyszukiwanie wektorowe ze słowami kluczowymi. Zgarnia pięć–dziesięć najbardziej trafnych fragmentów i ponownie je porządkuje, żeby wyłuskać najlepszą odpowiedź na pierwotne pytanie. A ponieważ wyniki są składane w całość i cytowane, do rozmowy wraca na przykład coś takiego: „Ustaliłeś, że trzeci plan cenowy obniży próg wejścia dla twojej społeczności. Decyzję podjął Simon, cena startowa to 37 dolarów. Źródło: ten plik, ta linia, ta data — tylu dni temu”. Może dojść dodatkowe potwierdzenie: sprawdziłem pozostałe rozmowy i od tamtego dnia nie było nowych dyskusji o cenach. Czyli: odpowiedź złożona, zacytowana i uczciwa co do własnych luk. Masz w ten sposób wielopoziomowy system przechowywania, dostarczania i odszukiwania, który pracuje z tobą dzień w dzień wewnątrz roboczego kontekstu Claude.

Uzupełnienie wstecz: stara historia sesji od razu staje się mózgiem

Ten przepływ obejmuje rozmowy nowe. Zadaliśmy sobie jednak pytanie: mamy już miesiące sesji, których pamięć nie widzi. Wszystko sprzed instalacji systemu — wszystkie decyzje i cała wykonana praca — leży w historii sesji i nic z tego nie wynika. Potrzebowaliśmy więc jeszcze jednej zdolności: zamienienia w pamięć wszystkiego, co już powiedziano. System bierze całą dotychczasową historię sesji i automatycznie tworzy z niej wspomnienia długoterminowe i krótkoterminowe. W praktyce oznacza to, że w dniu wdrożenia nie zaczynasz od zera: od pierwszej minuty masz zapamiętane, przeszukiwalne znaczeniowo i zacytowane wszystko, co kiedykolwiek powiedziałeś Claude’owi w tym projekcie. Twój dotychczasowy dorobek od razu staje się mózgiem.

Team OS: zakresowany dostęp i edycja dla nietechnicznych

Czwartego elementu — zespołowego systemu operacyjnego — nie znalazłem działającego nigdzie indziej, więc logikę zbudowaliśmy sami; inspiracją był setup Garry’ego Tana z GBrain. To wciąż rozwój: fundamenty stoją już na lokalnej bazie wektorowej PGlite, niedługo dojdzie hostowana baza na Railway. Sam Team OS wydamy w ciągu kilku tygodni i obejmie on zakresowany dostęp każdego członka zespołu do tego, co wskażesz w bazie. Przyświecały nam dwie zasady.

Pierwsza: pozwól współpracownikom nietechnicznym wnieść swój wkład. Kluczowe pliki — kontekst marki, CLAUDE.md — będą miały swoją wersję podstawową w Notion albo Google Drive. Claude Code zajmie się resztą: umiejętnościami i funkcjami pamięci, wszystkim tym, czego zespół nie musi ruszać ani oglądać. A całość będzie archiwizowana i wersjonowana w GitHubie, na twoją rzecz.

Druga: ograniczaj dostęp per użytkownik. Korzystamy z bazy Postgres z bezpieczeństwem na poziomie wierszy — to mechanizm, w którym to sama baza decyduje, które wiersze dana osoba może odczytać. Każdy wiersz dostaje tag: system, zespół, klient albo prywatne. Każde zapytanie jest filtrowane według pytającego i egzekwuje to baza, a nie prompt. Właściciel bazy może potencjalnie widzieć wszystko. Junior przypisany do jednego klienta widzi systemy, swój zespół, tego klienta i własną pracę — ani klientów, do których nie ma dostępu, ani zakresów, których właściciel mu nie przyznał.

Na koniec

I to jest cała droga: wszystkie decyzje i wszystkie przesłanki, które doprowadziły nas do własnego agentowego systemu operacyjnego z pamięcią na tyle dobrą, by szukać po znaczeniu i wskazywać dokładną rozmowę stojącą za każdą odpowiedzią — z cytowaniem, któremu można zaufać. Jeśli wolisz gotowca do zainstalowania jedną komendą, znajdziesz go w naszej płatnej społeczności Agenty Academy — link w opisie. Dziękuję za obejrzenie.