14 PAŹ 2026Company brain7 min

CONTEXT IS GOLD: company brain, którego kolejny agent użyje bez ciebie

Kontekst ma wartość, gdy inny agent może go znaleźć, ocenić jego ważność, poprawić i użyć ponownie. Zasady z company brain Yempik i mojego second brain.

Pod koniec czerwca Raffaele i ja opublikowaliśmy cowork-os. W poście napisałem “CONTEXT IS GOLD!”. Nadal tak uważam. Od tego czasu company brain Yempik stał się częścią codziennej pracy ludzi i agentów. Pisanie Markdown okazało się łatwą częścią.

Teza: kontekst ma wartość wtedy, gdy inna osoba lub inny agent może go znaleźć, ocenić, kiedy i gdzie obowiązuje, poprawić i użyć bez rozmowy, z której powstał. Format ma małe znaczenie. Liczy się to, kto ma ostatnie słowo, czy da się go ponownie znaleźć, jak długo jest ważny, kto ma do niego dostęp i jak przechodzi między zadaniami. Poniższe zasady wynikają z naszych własnych błędów.

Zatwierdzone nie znaczy prawdziwe.

Gdy przeczytaliśmy cały Brain od początku, znaleźliśmy zatwierdzone wpisy, które można było cytować, choć w treści mówiły „do potwierdzenia” albo „nie sprawdziłem tego”. Status mówił jedno, treść drugie. Agent patrzący tylko na status zamienia hipotezę w decyzję, której nikt nie podjął. Trust me bro, wersja bazodanowa.

Rozdzieliliśmy dwa pytania. Pierwsze: czy twierdzenie trafiło do Brain? Drugie: na ile jest pewne? Hipoteza, propozycja, podjęta decyzja, sprawdzony fakt. Reguła mieści się w jednej linijce: zatwierdzona hipoteza nadal jest hipotezą. Kto jej używa, mówi o tym także w odpowiedzi.

Na szkoleniach wyjaśniam to tak: powiedz agentowi „jestem Simone Bova”, a uwierzy. Powiedz „przypuszczam, że jestem Simone Bova”, a potraktuje to jako hipotezę. Agent nie może zweryfikować prawie niczego, co mu podajesz. Dlatego stopień pewności informacji trzeba zapisać tuż obok niej.

Przekazanie pracy kończy się wtedy, gdy odbiorca może ją odczytać.

Automatyzacje sprzedaży w Yempik kilka razy trafiały na ten sam problem. Zweryfikowane kontakty dostarczone na czacie, ale nigdy niezapisane w Brain. Kolejka pierwszego kontaktu stawała. Rutyna oparta na plikach z mojego laptopa, których zaplanowane uruchomienia w chmurze nie widzą.

Za każdym razem praca była dobra. Ja ją widziałem, kolejna maszyna nie. Zapisaliśmy regułę: każda dana potrzebna w późniejszym kroku musi leżeć tam, skąd ten krok ją odczyta. Każda automatyzacja określa, co czyta, co zapisuje i gdzie. To, co trafia na czat, jest dla foundera. Jeśli potrzebuje tego także maszyna, trzeba zapisać to również dla niej. Test robisz od strony odbiorcy, bo twoja sesja widzi rzeczy, których zaplanowane uruchomienie nigdy nie zobaczy.

Puste wyszukiwanie powinno mówić, dlaczego jest puste.

Daliśmy agentowi pracować z Brain przez cały dzień prawdziwej pracy. Pamięć między sesjami działała. Wyszukiwanie nie znajdowało jednak niczego przy zwykłych pytaniach, które powinny prowadzić do zatwierdzonych wpisów.

Samo wyszukiwanie działało. Krok, który po zatwierdzeniu pozwala znaleźć wpis, zawodził po cichu. Żaden log tego nie pokazywał. Zepsute wyszukiwanie i wyszukiwanie bez wyników dawały tę samą odpowiedź. Teraz check stale porównuje wpisy zatwierdzone z możliwymi do znalezienia. Wyszukiwanie mówi, kiedy ma zaległości. Test, który się liczy, przechodzi całą ścieżkę od zapisu do wyszukania. Jeśli twój brain trzyma pochodną kopię danych, prędzej czy później kopia i oryginał się rozjadą. Porównuj je i spraw, żeby system mówił, kiedy nie wie.

Dwie sprzeczne wersje potrzebują zapisanego powiązania.

Ten sam przegląd ujawnił dwie decyzje dotyczące remindera dla osoby zatwierdzającej wpisy. Jedna mówiła o godzinie, druga o dobie. Obie ważne. Żadna nie była oznaczona jako zastąpiona.

„Użyj najnowszego dokumentu” tu nie wystarczy. Data zapisania wpisu, początek jego obowiązywania i koniec to różne fakty. Teraz zamknięta inicjatywa zachowuje datę zakończenia zamiast znikać. Każda odpowiedź wskazuje, która obowiązuje. Gdy dwa źródła sobie przeczą, zachowujemy oba i zapisujemy relację: jedno obala drugie, jedno zastępuje drugie albo dotyczą różnych przypadków.

Brain powinien wiedzieć, gdzie jest prawda operacyjna, bez kopiowania jej.

Spisaliśmy umowę między naszymi systemami. Company Brain trzyma to, co Yempik musi pamiętać. Linear trzyma to, co trzeba zrobić. GitHub to, co zbudowaliśmy. CRM to, z kim pracujemy. Czaty nie są źródłem prawdy. Jeśli informacja występuje w kilku miejscach, ma jednego właściciela, a pozostałe miejsca do niego odsyłają.

Najbardziej użyteczna linijka dotyczy kończenia pracy: po zakończeniu zadania Brain zmienia się tylko wtedy, gdy zmieniła się trwała prawda. Zwykła poprawka nie staje się wpisem. Bez tej reguły Brain wypełnia się stanem, który po tygodniu jest nieaktualny. Agent czyta go tak, jakby był prawdziwy dzisiaj.

Powiązanie też jest informacją. W grafie Brain widzisz połączenie tylko wtedy, gdy masz dostęp do obu łączonych dokumentów. Powiązanie zaproponowane przez agenta czeka na człowieka, zanim zacznie się liczyć. Możesz chronić treść dwóch dokumentów i nadal ujawnić fakt, że są połączone.

Zanim zmienisz model, sprawdź instrukcje, które dostaje.

Tej jesieni zauważyłem, że Claude Code świetnie zapisuje źródła w moim second brain, a słabo w innej pamięci podłączonej z zewnątrz. Ten sam model, ta sama możliwość zapisu. Różniły się zasady, które model miał przed sobą. W vault reguły projektu są zawsze w kontekście, a źródła czytane w całości. Na drugiej ścieżce model dostawał narzędzia i uboższą instrukcję. Popychała go do rozbijania wszystkiego na fragmenty i nie mówiła, kiedy praca jest skończona.

Połączyłem zasady w jeden zestaw wspólny dla obu ścieżek. Pomiar przed zmianą i po niej jest jeszcze do zrobienia. Z tej pracy wyszły dwie reguły, które stosuję wszędzie.

  • Przetworzenie źródła jest skończone, gdy przyszły czytelnik może odtworzyć decyzję, powody, alternatywy, ograniczenia i otwarte pytania.
  • Udane zapisy i poprawne linki dowodzą niewiele. Skończone oznacza: odczytać zapisany materiał, porównać go ze źródłem i podać, co pozostaje otwarte.

Najmocniejszy kontrargument: to tylko notatki, model niczego się nie uczy.

Znajomy founder powiedział mi wprost na callu: to, czego agent się „uczy”, nigdy nie dociera do modelu. To pliki tekstowe z notatkami. Ma rację. Odkrycie z dzisiejszej sesji nie zwiększa jutro możliwości modelu.

Odpowiadam, określając dokładnie, co się poprawia. Poprawiają się dowody dostępne agentowi, jego zdolność do ponownego znalezienia ich i sposób wykonywania procesu. Model zostaje ten sam. Gdy ktoś obiecuje ci „agenta, który uczy się twojej firmy”, zapytaj, którą z tych rzeczy ma na myśli.

Jest też przeciwny zarzut: więcej pamięci zawsze jest lepsze. Na szkoleniach proszę o przeczytanie każdej linijki własnych plików pamięci co najmniej raz w tygodniu. Mówię też, że można wyłączyć pamięć, jeśli przeszkadza w pracy.

L'importante è che sia una scelta vostra e soprattutto consapevole. Czyli: ważne, żeby to był twój wybór, a przede wszystkim wybór świadomy.

Od poniedziałku

  • Oddziel zatwierdzenie wpisu od stopnia jego pewności. Zachowaj to rozróżnienie aż do odpowiedzi agenta.
  • Przy każdej automatyzacji zapisz, co czyta, co zapisuje i gdzie. Potem sprawdź ją ze środowiska, w którym będzie działać.
  • Spraw, żeby system mówił, kiedy pusta odpowiedź wynika z brakujących danych. Stale porównuj dane źródłowe z ich kopiami.
  • Gdy dwa źródła się różnią, zapisz ich relację. Zamkniętym inicjatywom nadaj datę zakończenia.
  • Każdemu rodzajowi informacji przypisz właściciela. Brain trzyma powody i powiązania. Bieżący stan pobieraj z systemu, który za niego odpowiada.
  • Zanim zmienisz model, zestaw obok siebie instrukcje, które dostaje na każdej ścieżce.