Rozdzielaj stan, wiedzę i interfejs

Większość narzędzi do wiedzy zlepia trzy różne zadania w jedną aplikację: śledzenie tego, nad czym pracujesz, pamiętanie tego, czego się nauczyłeś, i dawanie ci sposobu interakcji z jednym i drugim. Ten zlepek wydaje się wydajny i jest źródłem niemal każdego długoterminowego trybu awarii.

Zasada

KMS ma co najmniej trzy odrębne warstwy, każda o innym kształcie i cyklu życia:

Stan — co jest aktualnie aktywne. Priorytety, otwarte pytania, praca w toku. Mutowalny, lekki, często nadpisywany.
Wiedza — co jest trwałe. Koncepcje, encje, decyzje, wnioski, źródła. Głównie append, linkowana, wolno zmieniająca się.
Interfejs — jak wchodzisz w interakcję. Rozmowa, dashboard, wyszukiwanie, agent. Adaptacyjny do chwili.

W skali zespołowej pojawia się czwarta warstwa: hurtownia dla strukturalnego ogona — zdarzenia, tickety, rekordy klientów — z której synteza wiedzy czerpie, ale której nie jest właścicielem.

Dlaczego to ma znaczenie

Stan i wiedza mają przeciwne wzorce aktualizacji. Stan chce być zmazywany i pisany od nowa. Wiedza chce narastać i się łączyć. Wepchnięcie ich w jedno narzędzie oznacza, że wiedza zaśmieca się zwietrzałym stanem („aktywny projekt: …" sprzed sześciu miesięcy), a stan jest pogrzebany pod wiedzą, przez którą nie może się przebić.

Interfejs też chce swojej własnej swobody. Właściwym sposobem dodania notatki ze spotkania jest 30-sekundowa rozmowa. Właściwym sposobem odczytania jej z powrotem jest wyszukanie na żądanie. Właściwym sposobem wyniesienia jej w kontekście jest agent wciągający ją do bieżącego zadania. Żaden z nich nie jest tym samym UI.

Jak to działa

Każda warstwa dostaje własny dom:

Stan żyje w małym zbiorze mutowalnych plików markdown (tracker.md, priorities.md), które agent swobodnie przepisuje.
Wiedza żyje w folderach strukturyzowanych według typu encji, ze stabilnymi slugami i wikilinkami.
Interfejsem jest jakakolwiek powierzchnia, na której aktualnie znajduje się użytkownik — Claude w terminalu, otwarty na iPadzie skarbiec Obsidian, wiadomość do bota na Slacku.

Ten sam agent czyta ze wszystkich trzech, ale pisze do każdej przez inne reguły. Stan jest nadpisywany. Wiedza jest dopisywana. Interfejs nie produkuje żadnego artefaktu.

W prymitywach Claude

CLAUDE.md deklaruje trzy warstwy jako nazwane katalogi i reguły dla każdej — „pliki pod state/ mogą być zmazywane; pliki pod knowledge/ są głównie append; nigdy nie pisz do interface/".
Umiejętności są podzielone według warstwy — update-tracker (stan), save-concept (wiedza), surface-relevant (interfejs).
Pamięć (pamięć sesji Claude) jest brudnopisem warstwy interfejsu; trwała wiedza jest jawnie zapisywana na dysk.

Gdzie to widziałem

W osobistym KMS-ie, którego używam codziennie, podział to state/ kontra vault/ kontra powierzchnia rozmowy. W zespołowym KMS-ie do pracy z klientem stan żyje w bazie aplikacji, wiedza w markdownie, interfejs na czacie — a warstwa hurtowni (zdarzenia, rekordy klientów) karmi syntezę wiedzy, nie będąc jej właścicielem. W aplikacyjnym „drugim mózgu" KMS tryb awarii nierozdzielenia stanu i wiedzy to bug, który ciągle rozgrywamy od nowa.

Czytanie pod prąd

Wygląda to na przeinżynierowanie dla jednej osoby. Nie jest. Koszt zbudowania trzech warstw od pierwszego dnia jest niski; koszt ich rozplątania po dwóch latach mieszania to koszt zaczynania od nowa.