O czym jest ten film
- Wszystkie „drugie mózgi” budowane z pomocą AI mają bardzo podobną strukturę — i przez to ten sam defekt.
- Baza wiedzy takiego systemu z czasem gnije: agent wyciąga informacje, które przestały być prawdziwe.
- Źródłem problemu jest nieunikniona redundancja — te same fakty siedzą w pamięci rdzeniowej, w grafie wiedzy i w materiałach zebranych z zewnątrz.
- Najgroźniejszy tryb awarii: kontekst ładowany na starcie rozmowy sprzeczny z tym, co agent doczyta później.
- Autor pokazuje to na fikcyjnym, ale realistycznym przykładzie agencji automatyzacji i zmieniającej się stawki dla klienta.
- W teście agent znalazł dwie stare wartości kontraktu, a przegapił najnowszą — mimo że wszystkie były w bazie.
- Sedno diagnozy: domyślnie drugi mózg działa wyłącznie w trybie dopisywania i nigdy nie sprawdza, czy nowa informacja unieważnia starą.
- Rozwiązanie: każdy przychodzący fakt klasyfikować jako stan (nadpisywalny) albo zdarzenie (tylko dopisywane, ze znacznikiem czasu).
- Autor spakował to w gotową umiejętność (skill) do Claude Code, która robi audyt istniejącej bazy i wdraża regułę na przyszłość.
- Ważny kontrast: samo polecenie „datuj wszystko i pilnuj świeżości” zadziałało u autora tylko w 8% przypadków — dopiero wymuszona procedura dała efekt.
Redakcyjne tłumaczenie
Wszyscy budujemy to samo — i wszyscy trafiamy na ten sam mur
W internecie jest dziś mnóstwo poradników o budowaniu własnego „drugiego mózgu”. To naprawdę jedno z najpopularniejszych i najbardziej praktycznych zastosowań AI. Są też otwartoźródłowe repozytoria na GitHubie — jak Hermes czy Open Claw — dzięki którym można taki drugi mózg pobrać i uruchomić w ciągu paru godzin.
(Informacja dodatkowa: „drugi mózg” to osobista baza wiedzy w formie plików tekstowych, którą przeszukuje i uzupełnia agent AI — w praktyce najczęściej agent kodujący uruchomiony w katalogu z notatkami.)
I niezależnie od tego, co zrobisz, twój drugi mózg przyjmie kształt bardzo podobny do wszystkich pozostałych. Zwykle masz dokumenty z podstawowym zachowaniem agenta i pamięcią rdzeniową. Masz dzienne logi, które narastają wraz z tym, co robisz z systemem. I zwykle masz coś w rodzaju wiki w stylu Karpathy’ego, gdzie budujesz zbiór pojęć i bytów opisujących twoje życie i firmę — w miarę jak coraz mocniej wpinasz drugi mózg w swoje codzienne działanie.
Bardzo powszechna struktura. Ale skoro każdy drugi mózg jest zbudowany podobnie, to każdy ma też tę samą słabość. I o tym jest ten materiał — bo twój drugi mózg prawdopodobnie gnije w tej chwili.
Mózgi AI degradują się tak samo jak ludzkie. Poradniki w sieci i gotowe systemy do instalacji nie poświęcają temu wystarczająco dużo uwagi. Buduję i używam swojego drugiego mózgu od ponad pół roku i jestem pewien, że zauważyłeś to samo, co ja, jeśli korzystasz ze swojego od przynajmniej kilku miesięcy: system czasem odtwarza informacje, które przestały być aktualne albo są po prostu błędne. Bo twoje życie i firma się zmieniają. Agent sięga po wspomnienia, które zdążyły zwietrzeć — jakiś byt, jakieś pojęcie, jakiś wpis w dziennym logu — i taka informacja szkodzi bardziej, niż pomaga, bo po prostu nie jest już prawdziwa.
Na to trzeba zaprojektować rozwiązanie: drugi mózg musi umieć wykryć przeterminowaną informację i ją zaktualizować albo usunąć. Chcę najpierw wyłożyć problem możliwie prosto, a potem pokazać, że rozwiązanie jest naprawdę łatwe do wdrożenia.
Co właściwie trzymamy w bazie wiedzy
Zacznijmy od ustalenia wspólnego punktu wyjścia: co przechowujemy w drugim mózgu i jak budujemy bazę wiedzy dla agenta.
Możliwości jest nieskończenie wiele. Możesz zapisywać wspomnienia z samych rozmów z drugim mózgiem, spinać go z pocztą i kalendarzem, wrzucać transkrypty rozmów z klientami albo ze swoim zespołem, przychodzące zapytania sprzedażowe. To oczywiście zależy od tego, jaki prowadzisz biznes, ale spokojnie można założyć, że w każdym drugim mózgu będziesz mieć kilkanaście czy kilkadziesiąt źródeł — bo dochodzą jeszcze informacje o projektach, nad którymi pracujesz, a nawet integracja z twoimi repozytoriami kodu.
Wszystko, co przechwytujesz, trafia do bazy wiedzy, która zwykle składa się z trzech elementów. Warto zrozumieć, że informacje przechowujemy na kilka różnych sposobów — bo dopiero to pozwala pojąć, jak działa gnicie i jak je naprawić.
Jeśli robisz z drugim mózgiem cokolwiek poważnego, twoja baza wiedzy zrobi się ogromna. Dlatego potrzebujemy eleganckiego sposobu przechowywania. Niezależnie od tego, skąd informacja pochodzi — z rozmów czy z integracji — budujemy z niej rodzaj grafu wiedzy złożonego z bytów i pojęć. Do tego dochodzi kilka dokumentów rdzeniowych, zawsze ładowanych do kontekstu agenta: pamięć podstawowa, opis oczekiwanego zachowania, informacje o tobie.
Skąd bierze się sprzeczność
Problem polega na tym, że pewna redundancja jest tu nieunikniona.
Po pierwsze, w pamięci rdzeniowej potrzebujemy zwięzłej wersji — to jest zawartość katalogu z pamięcią: memory.md i podobne pliki. Po drugie, mamy graf wiedzy, który stara się odwzorować wszystko, żeby agent mógł doszukać się szczegółów, kiedy naprawdę ich potrzebuje. Ale ponieważ przechowujemy tam ten sam typ informacji, agent bywa zdezorientowany, gdy wyciągnie dokument mówiący o tym samym co memory.md — tyle że nie w stu procentach zgodnie. Takie sprzeczności są dla agenta bardzo mylące. A jednocześnie naprawdę potrzebujemy obu reprezentacji.
Bywa też, że nawet w samej bazie wiedzy masz różne byty czy pojęcia opisujące to samo, tylko innym językiem. Okazji do pomyłki jest mnóstwo, bo agent nigdy nie będzie za każdym razem idealnie wkładał właściwej informacji do właściwego dokumentu.
A nawet gdy sprzeczności nie ma, informacja i tak może być zwietrzała — bo zmieniłeś umowę z klientem albo plany dotyczące jakiegoś repozytorium i po prostu nie odbyłeś tej rozmowy z drugim mózgiem, więc nie miał on nawet szansy dowiedzieć się, że jego wiedza jest już nieaktualna.
I żeby skomplikować sprawę jeszcze bardziej: jest trzecia warstwa — informacje zewnętrzne wciągane do systemu. Zwykle robisz z drugim mózgiem jakieś zadania researchowe i budujesz pakiety materiałów ściąganych z internetu. One również potrafią stać w sprzeczności z resztą bazy wiedzy.
Sedno jest takie: informacja może i musi być reprezentowana na wiele różnych sposobów, a to w naturalny sposób prowadzi do sprzeczności i przeterminowanych zapisów.
Najgroźniejszy tryb awarii
Ten problem już rozwiązałem — dlatego w ogóle nagrywam ten materiał. Ale największa awaria, jaką sam zaobserwowałem, budując własny drugi mózg, wygląda tak: informacja podana agentowi na starcie stoi w sprzeczności z tym, co agent doczyta w dalszej części rozmowy.
Mam wizualizację tego, co trafia do kontekstu mojego agenta na początku każdej rozmowy. Są tam reguły globalne, czyli claude.md. Jest dokument z zachowaniem agenta, żeby wiedział, kim jestem. Są pamięci rdzeniowe, lista repozytoriów, nad którymi pracujemy, i zwykle podsumowanie tego, co robiłem z agentem przez ostatnie 24 godziny. To cały kontekst, jaki ma od razu.
Czasem to wystarcza. Ale czasem agent uznaje, że musi wyciągnąć coś jeszcze z bazy wiedzy. Czyta wtedy indeks na górze mojej wiki, orientuje się, że dany byt albo pojęcie jest istotne dla tego, czym się teraz zajmuję, i sięga po ten dokument.
Wtedy dzieje się jedna z dwóch rzeczy. Albo agent zapomniał wcześniej zaktualizować memory.md — czyli doczytana informacja jest w istocie bardziej aktualna, ale mamy sprzeczność i agent się gubi. Albo odwrotnie: pamięć rdzeniowa jest w pełni świeża, a agent wyciąga stary dokument z nieaktualnymi danymi i być może to jemu daje pierwszeństwo.
Nigdy nie wiesz, co agent wybierze. Dlatego w bazie w ogóle nie może być informacji zwietrzałych ani sprzecznych. To po prostu niedopuszczalne — nie możemy zawsze liczyć na to, że agent będzie dość bystry, by rozpoznać, że dana informacja jest zła.
Materiał sponsorowany: Granola
Sponsorem tego odcinka jest Granola — notatnik AI dla ludzi żyjących w spotkaniach jeden po drugim. Wpisuje się to idealnie w temat drugiego mózgu, bo cały system ma sens tylko wtedy, gdy faktycznie wychwytujemy wiedzę, a najtrudniejsza do wychwycenia jest ta z rozmów: z narad, na których zapadają decyzje. Granola jest narzędziem, którym to wszystko łapię.
Na twoje rozmowy nie dołącza żaden bot. Narzędzie po prostu transkrybuje dźwięk z komputera w tle, więc możesz być na Zoomie, w Google Meet, a nawet na spotkaniu osobistym. Robię zdawkowe notatki, tak jak zwykle, a po rozmowie Granola przerabia je na czyste podsumowanie z decyzjami i zadaniami do wykonania.
I tu następuje wpięcie w drugi mózg, bo Granola ma konektor MCP — moje agenty mogą odpytywać notatki ze spotkań bezpośrednio. Mogę na przykład zapytać: „Co ustaliliśmy na spotkaniu w sprawie użycia subagentów do researchu?”. Wiem, że odpowiedź jest w jednej z notatek. Agent wywołuje serwer MCP, odpytuje notatki — i dostajemy idealną odpowiedź. To pokazuje, że Granola potrafi zamienić wszystkie nasze spotkania w ustrukturyzowaną wiedzę do użycia z agentami.
(Informacja dodatkowa: MCP — Model Context Protocol — to otwarty standard Anthropic pozwalający agentom AI odpytywać zewnętrzne narzędzia i źródła danych przez jednolity interfejs.)
Granola jest darmowa, a nowi użytkownicy dostają 100% zniżki na pierwszy miesiąc. Link w opisie.
Praktyczny przykład: znikająca stawka
Wróćmy do gnicia. Bierze się ono z tego, że różne pliki mówią o tej samej rzeczy w różny sposób. Pokażę to na konkretnym przykładzie.
Drugi mózg użyty w tym materiale jest fikcyjny — nie mogę pokazać intymnych dokumentów z własnego systemu, mam nadzieję, że to zrozumiałe. Ale to, co zbudowałem, jest wiernym odwzorowaniem problemów, na które sam się natknąłem.
Ten drugi mózg należy do Dany. Prowadzi Northpath Automation, agencję automatyzacji AI. Jedną z rzeczy, do których używa systemu, jest zarządzanie klientami — mamy tu Harbor Point Foods, a tutaj Northwind, jednego z klientów automatyzacyjnych. Dana z pomocą drugiego mózgu ustala kontrakty, wysyła faktury, planuje pracę. Przez miesiące współpracy z tym klientem odbywa więc mnóstwo rozmów ze swoim systemem.
A przy pracy z klientem zwykle zmienia się zakres prac. Może na początku pobierasz 4000 dolarów miesięcznego abonamentu, ale kończysz pierwszy pakiet zadań, dobudowujesz kolejne rzeczy i abonament rośnie do 9500 dolarów miesięcznie.
Problem w tym, że Dana używa drugiego mózgu do pracy z Northwind właśnie w trakcie zmieniania się kontraktu. W jej rdzeniowym memory.md coś zwietrzało i utknęło na 4000 dolarów miesięcznie — mimo że w jednym z dziennych logów kwota wzrosła do 6000, a potem w kolejnej rozmowie Dana powiedziała systemowi, że stawka poszła do 9500.
Owszem, agent często zaktualizuje memory.md. Powinien być na tyle rozgarnięty. Ale gwarancji nie ma. Dana zostaje więc z systemem, w którym drugi mózg czasem sięgnie po ten plik, a czasem po tamten. Nigdy do końca nie wiadomo. Nie da się mu zaufać, że poda właściwą kwotę kontraktu z Northwind.
Przepuściłem to przez prawdziwy test — mam skrypt, który zadaje agentowi jedno pytanie i pozwala mu przeszukać bazę wiedzy. Spytałem: „Ile pobieramy od Northwind Logistics?”. Widać, że agent zachował się dość inteligentnie: wiedział, że 4000 dolarów miesięcznie jest w memory.md, bo ten plik ładuje się od razu. Ale znalazł też plik dziennego logu mówiący o 6000 dolarów. Zorientował się więc, że informacja zmieniała się w czasie — a mimo to całkowicie przegapił najświeższą wartość, zapisaną w innym dziennym logu.
To pokazuje istotę problemu. Przykład jest lekko spreparowany, ale w moim własnym drugim mózgu takie rzeczy działy się bez przerwy.
Sedno: baza tylko dopisuje
Kluczowa rzecz, którą chcę ci pomóc rozwiązać, brzmi tak: twój drugi mózg jest domyślnie systemem wyłącznie dopisującym. Kiedy przychodzi nowa informacja, po prostu doklejamy ją do jakiegoś dziennego logu albo jakiegoś bytu — i nie oglądamy się wstecz, żeby sprawdzić, czy unieważnia ona coś, co już mamy w bazie.
I w części przypadków jest to zachowanie poprawne. Bo — i tu wchodzimy już w rozwiązanie — każda informacja wpływająca do drugiego mózgu z dowolnego źródła jest albo stanem, albo zdarzeniem.
Zdarzenie to coś, co się wydarzyło, i ono naprawdę powinno być tylko dopisywane: dostarczyliśmy jakiś kontrakt, zdecydowaliśmy o zbudowaniu czegoś w danym repozytorium. To po prostu dokłada się do wszystkiego, co już zrobiliśmy dla tego klienta czy w tym kodzie.
Ale jeśli to stan — nasza stawka, nasza mapa drogowa, cokolwiek tego rodzaju — musimy zastąpić wszystko, co w bazie wiedzy właśnie stało się nieaktualne.
Przy każdym przyjmowaniu informacji jest więc decyzja: którą ścieżką idziemy z tym konkretnym faktem. I tego właśnie brakuje w większości drugich mózgów.
Rozwiązanie: umiejętność robiąca audyt
Pokażę teraz, jak zbudować ten proces bez zmieniania czegokolwiek innego w twoim drugim mózgu — nie chcę robić z tego wielkiego przedsięwzięcia. Chodzi tylko o to, żeby przy każdym przyjmowaniu nowych rzeczy do bazy system potrafił wybrać właściwą ścieżkę i nie zostawiał w niej zwietrzałych danych.
Żeby maksymalnie to ułatwić, zapakowałem workflow, przez który sam przeszedłem, w umiejętność (skill). Za chwilę pokażę, jak ją pobrać, ale to jest krok po kroku procedura przeprowadzenia audytu. Twój drugi mózg przejrzy własną bazę wiedzy, wskaże informacje już przeterminowane, pomoże je poprawić, a potem wbuduje rozróżnienie na stan i zdarzenie dla wszystkiego, co napłynie w przyszłości.
(Informacja dodatkowa: „skill” w Claude Code to zestaw instrukcji dla agenta, uruchamiany komendą ze slashem — działa jak zapisany, powtarzalny sposób postępowania.)
Umiejętność znajduje się w moim repozytorium ze skillami, które opublikowałem niedawno. Trzymam tam wszystkie podstawowe umiejętności, z których korzystam na co dzień, i zamierzam je dalej rozbudowywać.
Instalacja to dwa polecenia dla Claude Code — i masz wszystkie skille, w tym audyt drugiego mózgu. Tak, robię to konkretnie pod Claude Code, bo to moje główne narzędzie, ale możesz je zainstalować ręcznie dla innych agentów kodujących, jeśli wolisz.
Kiedy już to masz, wchodzisz w /plugins, potem w listę zainstalowanych — i widać moje skille. Wtedy możesz uruchomić /second-brain-audit. Chcesz to odpalić z Claude Code (albo innym agentem kodującym) otwartym w katalogu twojej bazy wiedzy, bo przejdzie przez wszystkie pliki i pomoże też wdrożyć podział na stan i zdarzenia.
Odpalam — i już po kilku minutach działania wykrywa tę rozbieżność w sprawie Northwind między memory.md a różnymi dziennymi logami. Ustala, co należy teraz naprawić, i pomaga zbudować proces zapobiegający temu na przyszłość.
Zachęcam do ostrożności z tą umiejętnością. Chcesz nadzorować, co zmienia się w twojej bazie wiedzy, żeby usunąć rzeczy faktycznie przeterminowane, a zachować te aktualne. Traktuj skill jako punkt wyjścia — mówi ci: „oto co znalazłem jako zwietrzałe, a oto jak możemy zbudować z tego proces”.
Jak wygląda plik przed i po
Pozwoliłem umiejętności popracować dłużej i widać, że zatrzymała się, zanim cokolwiek zmieniła w bazie wiedzy. Wbudowałem to bardzo świadomie — nie chcę, żeby narzędzie skasowało rzeczy, które nie powinny zniknąć. Powierzasz mi zaufanie, więc chcę mieć pewność, że jesteś w pętli decyzyjnej tam, gdzie powinieneś być.
Mogę pozwolić jej przekonwertować plik, ale pokażę raczej przykład czegoś, co już zostało przerobione, i jak wyglądało wcześniej.
To Northwind Logistics bez żadnej konwersji na stan i zdarzenia. Mamy podstawowe informacje o firmie, o współpracy i notatki. I to są dokładnie te rzeczy, które mogą zwietrzeć w dowolnym momencie — mogą wejść w sprzeczność z innym dokumentem w bazie albo z plikiem pamięci rdzeniowej.
A tu Harbor Point Foods, kolejny fikcyjny klient — przykład pliku już przekonwertowanego. Umiejętność przeszła po nim i utworzyła sekcję stanu oraz log.
Mamy więc w jednym miejscu wszystko, co może zwietrzeć, a w drugim wszystkie zdarzenia, które nigdy nie zwietrzeją, bo są po prostu zapisem tego, co się wydarzyło w danym momencie. Wszystko jest też opatrzone znacznikiem czasu, żeby agent czytający ten plik wiedział: to zdarzenie miało miejsce bardzo dawno, więc pewnie nie ma się nim czym przejmować — a to są rzeczy, o których wiem, że są aktualne.
Zastrzeżenie i dlaczego to i tak działa
Największe zastrzeżenie do całego procesu jest oczywiste: polegasz na tym, że agent poprawnie rozpozna, czy ma do czynienia ze stanem, który wymaga edycji czegoś istniejącego, czy ze zdarzeniem, które po prostu dopisujemy.
Twierdzę jednak, że to rozróżnienie jest dla dużego modelu językowego dość proste. Bez trudu wskaże dokumenty, które może trzeba edytować, i będzie wiedział, co gdzie należy. Nawet jeśli używasz słabszego modelu — na przykład napędzasz drugi mózg lokalnym AI — ten system będzie u ciebie działał solidnie.
Nie musisz też korzystać z mojej umiejętności. Nawet jeśli po prostu weźmiesz tę ideę, przekażesz ją swojemu drugiemu mózgowi i każesz mu ją wdrożyć, poradzi sobie znakomicie — bo w gruncie rzeczy to prosta rzecz. Dzielimy każdą informację na dwie możliwości.
Można myśleć o tej ramie jako o ćwiczeniu myślowym, przez które zmuszamy agenta do przejścia za każdym razem, gdy coś wpływa do bazy wiedzy. Wymuszamy strukturę — a to znacznie lepsze niż alternatywa.
Dlaczego samo „datuj wszystko” nie działa
Moje pierwsze rozwiązanie było takie, że kazałem systemowi dopisywać datę przy każdej informacji trafiającej do bazy wiedzy. I powiem ci: takie polecenie, bez struktury i bez mechanizmu, sprawdziło się fatalnie. Tylko w 8% przypadków — przynajmniej w zestawie testowym, który sobie wziąłem — agent faktycznie zastosował się do konwencji albo w ogóle rozpoznał jakąkolwiek przeterminowaną informację.
Zakładałem, że skoro wszystko będzie datowane i każę mu na podstawie dat wykrywać rzeczy nieaktualne, to zadziała dobrze. A prawie nigdy nie działało.
Na tym polega piękno ramy: to proces, przez który zmuszamy agenta do przejścia, zamiast ogólnikowego „pilnuj, żeby przy nowych informacjach nic nie zostało nieaktualne”. Musimy go nauczyć: oto jak przeszukujesz i budujesz bazę wiedzy, żeby szybko rozpoznać, jakie rzeczy mogą zwietrzeć, a jakie zdarzenia po prostu dopisujemy.
Niezależnie więc od tego, czy chcesz użyć mojej umiejętności, czy tylko wziąć samą ideę, zachęcam do przejścia przez ten proces. Nie mam go u siebie uruchomionego bardzo długo, bo doszedłem do tego stosunkowo niedawno — ale już przez te ostatnie kilka tygodni zrobiło ogromną różnicę w tym, jak często mój agent wyciąga zwietrzałe informacje. Praktycznie przestał to robić, bo zrobiłem audyt i naprawiłem to, co już miałem, a od tego momentu wszystko jest bardzo ostre.
Jeśli materiał ci się przydał i czekasz na więcej rzeczy o budowaniu drugich mózgów i używaniu ich do programowania, będę wdzięczny za łapkę i subskrypcję. Zachęcam do wypróbowania umiejętności — do zobaczenia w kolejnym materiale.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Bazy wiedzy AI degradują się i trzeba to zaplanować
Na czym polega: Osobista baza wiedzy dla agenta nie jest archiwum, tylko żywym systemem — a życie i firma zmieniają się szybciej, niż zapisy się aktualizują. Po kilku miesiącach agent zaczyna serwować rzeczy nieprawdziwe.
Jak stosować: Traktuj utrzymanie bazy jako osobną, cykliczną czynność, a nie jako coś, co dzieje się samo przy okazji rozmów. Wpisz sobie audyt do kalendarza tak samo jak porządki w backlogu.
Na co uważać: Objaw jest podstępny — agent nie zgłasza błędu, tylko pewnie podaje nieaktualną wartość. Brak skarg nie oznacza, że baza jest zdrowa.
2.Podziel każdą informację na stan i zdarzenie
Na czym polega: To główna idea materiału. Zdarzenie — „dostarczyliśmy X”, „zdecydowaliśmy Y” — jest niezmienne i tylko się je dopisuje. Stan — stawka, mapa drogowa, ustalenia bieżące — ma dokładnie jedną prawdziwą wartość i musi nadpisywać poprzednią.
Jak stosować: W każdym pliku encji wydziel sekcję stanu (aktualnego) i sekcję logu (zdarzeń ze znacznikami czasu). Do instrukcji agenta dopisz regułę: przy każdej nowej informacji najpierw zdecyduj, do której z tych dwóch kategorii należy.
Na co uważać: Klasyfikacja spoczywa na modelu. Autor uważa ją za łatwą nawet dla słabszych modeli, ale sam nazywa to głównym zastrzeżeniem całego podejścia — pojęcia graniczne („zmieniliśmy zakres prac” to i stan, i zdarzenie) warto zapisywać w obu miejscach.
3.Domyślny tryb „tylko dopisuj” jest źródłem problemu
Na czym polega: Większość drugich mózgów nigdy nie ogląda się wstecz. Nowa informacja ląduje w dziennym logu i nikt nie sprawdza, czy unieważnia coś wcześniejszego.
Jak stosować: Sprawdź swój system pod tym jednym kątem: czy jakikolwiek zapis w instrukcjach każe agentowi szukać i poprawiać zapisy sprzeczne z nowym faktem. Jeśli nie — masz bazę wyłącznie dopisującą, niezależnie od tego, jak dobrze wygląda.
Na co uważać: Nie przestawiaj wszystkiego na nadpisywanie. Historia zdarzeń ma realną wartość; chodzi o selektywne nadpisywanie tylko stanów.
4.Najgroźniejszy jest konflikt kontekstu startowego z doczytanym
Na czym polega: Pamięć rdzeniowa ładuje się na starcie rozmowy, reszta jest doczytywana w trakcie. Gdy te dwa źródła się nie zgadzają, wybór agenta jest nieprzewidywalny — może wygrać zapis świeższy albo starszy.
Jak stosować: Testuj tę konkretną ścieżkę: zadaj pytanie o fakt, który zmieniał się w czasie, i sprawdź, którą wersję dostaniesz. To najszybszy sposób wykrycia gnicia.
Na co uważać: Model potrafi wykryć część zmian i mimo to przegapić najświeższą — w teście autora znalazł dwie stare wartości, a nie znalazł aktualnej. Częściowa inteligencja jest gorsza od jawnego błędu, bo brzmi wiarygodnie.
5.Ogólna instrukcja nie zastępuje wymuszonej procedury
Na czym polega: Autor najpierw kazał agentowi datować wszystko i na tej podstawie wykrywać przeterminowane wpisy. Zgodność z konwencją wyniosła 8% w jego zestawie testowym.
Jak stosować: Zamiast ogólnych zaleceń („pilnuj świeżości”) zapisuj konkretne kroki: gdzie szukać, jak porównać, co i kiedy nadpisać. Struktura procesu bije intencję.
Na co uważać: Ta liczba pochodzi z pojedynczego, niesformalizowanego testu autora, nie z systematycznego badania — traktuj ją jako sygnał kierunku, nie jako benchmark.
6.Redundancja jest konieczna, więc kontrola sprzeczności musi być jawna
Na czym polega: Te same fakty muszą istnieć w wersji zwięzłej (pamięć rdzeniowa) i szczegółowej (graf wiedzy). Nie da się tego wyeliminować, bo obie warstwy pełnią inną funkcję.
Jak stosować: Skoro duplikatów nie usuniesz, ustal jawną hierarchię: który plik jest źródłem prawdy dla danej klasy faktów, a które go tylko streszczają. Zapisz tę hierarchię w instrukcji agenta.
Na co uważać: Kuszące jest „uproszczenie” przez skasowanie jednej z warstw — stracisz wtedy albo szybki kontekst startowy, albo szczegóły do doczytania.
7.Materiały zewnętrzne to trzecia, łatwo pomijana warstwa ryzyka
Na czym polega: Pakiety researchu ściągane z internetu też lądują w bazie i też potrafią przeczyć twoim własnym ustaleniom.
Jak stosować: Trzymaj zewnętrzny research w osobnym obszarze i oznaczaj datą pozyskania, żeby agent widział, że to nie jest twój stan faktyczny, tylko materiał źródłowy.
Na co uważać: Research bywa napisany bardzo autorytatywnie i przez to potrafi przebić twoje własne, lakoniczne notatki w konkurencji o uwagę modelu.
8.Audyt musi mieć człowieka w pętli
Na czym polega: Umiejętność autora celowo zatrzymuje się przed wprowadzeniem zmian i pokazuje listę znalezisk do zatwierdzenia.
Jak stosować: Jeśli budujesz taki proces sam, wymuś krok raportu przed krokiem edycji. Zmiany rób partiami, żeby dało się je przejrzeć.
Na co uważać: Automatyczne czyszczenie bazy wiedzy to operacja destrukcyjna. Zanim cokolwiek uruchomisz na prawdziwych notatkach, zrób kopię — najlepiej trzymaj bazę w repozytorium z historią wersji.
9.Znaczniki czasu przy zdarzeniach są częścią mechanizmu
Na czym polega: W przekonwertowanym pliku każde zdarzenie ma datę, dzięki czemu agent widzi, co jest odległą historią, a co bieżącym stanem.
Jak stosować: Datuj wpisy w logu zdarzeń konsekwentnie i w jednym formacie. To daje modelowi tanią heurystykę oceny istotności.
Na co uważać: Same daty to za mało — autor wprost pokazał, że datowanie bez podziału na stan i zdarzenie nie zadziałało. Data jest dodatkiem do struktury, nie jej substytutem.
10.Ramę można wdrożyć bez cudzych narzędzi
Na czym polega: Autor udostępnia gotowy skill do Claude Code (dwa polecenia instalacji, komenda /second-brain-audit), ale sam podkreśla, że idea jest na tyle prosta, iż można ją po prostu opisać własnemu agentowi.
Jak stosować: Jeśli nie używasz Claude Code, przekaż swojemu agentowi regułę stan/zdarzenie i poproś o audyt bazy plik po pliku. Efekt merytoryczny jest ten sam.
Na co uważać: Instalowanie cudzych umiejętności daje agentowi instrukcje działania na twoich prywatnych notatkach — przejrzyj ich treść przed uruchomieniem. I pamiętaj, że autor testuje to u siebie dopiero od kilku tygodni.