O czym jest ten film
- Autor przedstawia model pięciu warstw, według którego można budować dowolny „agentic OS” (system operacyjny oparty na agentach AI) — od tożsamości, przez reguły i hooki, umiejętności (skills), po zmaterializowanych agentów i warstwę narzędzi/API/MCP.
- Porównuje strukturę systemu do warstw skorupy ziemskiej — im głębiej, tym bardziej stabilne i rzadziej aktualizowane elementy; im bliżej powierzchni, tym bardziej zmienne.
- Wprowadza pojęcie „rot rate” (tempa dezaktualizacji) — każda warstwa systemu ma inną żywotność i wymaga innego rytmu aktualizacji.
- Omawia warstwę tożsamości (soul file / agents.md / CLAUDE.md) jako fundament, który rzadko się zmienia, ale kosztuje najwięcej pracy na starcie.
- Wyjaśnia różnicę między regułami (silne sugestie) a hookami (deterministyczne wyzwalacze zdarzeń).
- Opisuje umiejętności (skills) jako powtarzalne, ale nie w pełni zdeterminowane procesy z udziałem człowieka, oraz sposób ich cyklicznego doskonalenia.
- Tłumaczy, kiedy warto „zatrudnić” materializowanego agenta zamiast mnożyć skille, i ostrzega przed nadmiarem agentów jako pułapką utrzymaniową.
- Omawia warstwę narzędzi, API, MCP i CLI jako warstwę danych łączącą system z rzeczywistymi źródłami informacji (np. QuickBooks, HubSpot, Fathom).
- Pokazuje dwa praktyczne przykłady własnych systemów: biznesowy (pseudo-CFO) i osobisty (system zdrowotny oparty na danych DNA i badaniach krwi).
- Podkreśla, że nie istnieje jeden uniwersalny szablon systemu — każdy system jest unikalny dla danej osoby, firmy czy branży, i namawia do budowania własnego w oparciu o przedstawiony model.
Redakcyjne tłumaczenie
Wprowadzenie: dlaczego „agentic OS” wydaje się skomplikowany, a nie jest
Budowanie „agentic OS” — systemu operacyjnego opartego na agentach AI — to jeden z najbardziej niepotrzebnie skomplikowanych tematów, jakie widzę dziś w świecie AI. Wiele osób nadmiernie skupia się na rzeczach w rodzaju finalnego dashboardu, który spina wszystko w całość, albo na fantazji o stworzeniu jednego „centrum dowodzenia”, gdzie wszystko po prostu działa. W rzeczywistości sam dashboard jest bez znaczenia i bezużyteczny bez całej hydrauliki, która działa pod spodem. To właśnie to, co dzieje się „pod maską”, jest sednem budowania dobrego systemu.
Nauczyłem tego modelu myślowego tak wiele firm na całym świecie, że w końcu znalazłem najprostszy sposób, żeby wytłumaczyć tę koncepcję za pomocą kilku warstw. Podobnie jak Ziemia ma wiele warstw w swojej skorupie, system AIOS ma wiele warstw. Gdy zrozumiesz, jak te warstwy działają i jakie są między nimi niuanse, już nigdy się w tym nie pogubisz.
Ten model myślowy sprawdzi się niezależnie od tego, czy budujesz coś na użytek osobisty, biznesowy, czy jedno i drugie.
Pięć warstw — szybki przegląd
Żeby było to jak najbardziej klarowne, przejdziemy przez każdą warstwę od środka na zewnątrz. Zobaczycie dużo podobieństw do budowy Ziemi — od jądra, przez kolejne warstwy, aż po powierzchnię, gdzie jądro jest bardziej stabilne i statyczne, a zewnętrzna część bardziej podatna na zmienne czynniki, takie jak „pogoda”, różne wzorce czy prognozy, które mogą wpływać na sposób prowadzenia biznesu.
Pierwsza warstwa to tożsamość. Tożsamość to tzw. „soul file” (plik duszy) w wielu frameworkach agentowych, takich jak OpenClaw czy Hermes (Informacja dodatkowa: to nazwy konkretnych narzędzi/frameworków do budowy agentów AI, o których autor mówi w dalszej części nagrania) i podobnych.
Druga warstwa to reguły i hooki. To paradygmaty obecne w Claude Code, Codexie i praktycznie każdym modelu językowym działającym w ramach jakiegoś „harnessu” (środowiska uruchomieniowego). Ich celem jest dawanie modelowi bardzo mocnych sugestii co do tego, co powinien, a czego nie powinien robić w danych scenariuszach. Hooki natomiast są deterministyczne — to technicznie jedyny w pełni deterministyczny element systemu AIOS, uruchamiany w reakcji na konkretne zdarzenia.
Trzecia warstwa to umiejętności (skills) — ta, którą większość ludzi rozumie najlepiej. Mamy tu do czynienia z jakimś procesem lub przepływem pracy. Jeśli wykonujesz dokładnie ten sam workflow w podobny sposób wielokrotnie, ale wciąż nie jest on w pełni zdeterminowany, zasługuje na to, by stać się komendą slash i umiejętnością.
Czwarta warstwa to zmaterializowani (skrystalizowani) agenci. Gdy poczujesz, że opanowałeś umiejętności i wciąż je udoskonalasz, możesz zdecydować się na zatrudnienie agenta z określonym zestawem reguł i odpowiedzialności — dla zadań, które wyrosły poza poziom pojedynczych skilli.
Piąta, ostatnia warstwa to narzędzia, MCP i CLI (Informacja dodatkowa: MCP, czyli Model Context Protocol, to standard łączenia modeli AI z zewnętrznymi narzędziami i danymi; CLI to interfejs wiersza poleceń). Na tym etapie masz już cały system: masz sprecyzowany kontekst, tożsamość systemu — czy jest do księgowości, do praktyki prawniczej, czy do prywatnych podatków. Może to być cokolwiek. Ja sam mam obecnie 20 różnych „centrów dowodzenia”, z których każde ma stanowić specjalistyczną wiedzę domenową złożoną z tych pięciu warstw.
Rot rate — tempo dezaktualizacji
Jest jeszcze jeden element, o którym dotąd nie wspomniałem — coś, co nazywam „rot rate”, czyli tempem, w jakim dany fragment kontekstu traci ważność. Możesz zbudować dziś absolutnie idealny system AIOS dla dowolnej dziedziny, ale za miesiąc, 90 dni, 180 dni, nie mówiąc już o roku, może on być całkowicie przestarzały. Dlatego trzeba mieć systemy do wykrywania i naprawiania tych problemów.
Wyobraźcie sobie, że wasz system AIOS działa przez cały rok. Zauważycie, że rzeczy takie jak sposób korzystania z narzędzi, MCP, CLI, instrukcje dla agentów, używane umiejętności, a nawet sama tożsamość — będą wymagały aktualizacji z czasem, ponieważ staną się przestarzałe, nieaktualne, wyjdą z użycia. To wszystko będzie „zatruwać” okno kontekstowe wybranego modelu językowego.
Warstwa 1: tożsamość (soul)
Przejdźmy teraz szczegółowo przez każdą warstwę, wraz z przykładami systemów operacyjnych, które sam zbudowałem.
Tożsamość, czyli warstwa „duszy”, może przybrać formę fizycznego pliku duszy dla wybranego agenta, pliku agents.md albo pliku CLAUDE.md, jeśli korzystasz z Claude Code. Warstwa tożsamości jest z założenia jedną z najbardziej statycznych — nie aktualizujesz jej często i wiąże się ona z wyższym kosztem początkowym niż pozostałe warstwy. Ale dzięki temu wyższemu kosztowi na starcie, w kolejnych etapach wystarczą już tylko drobne modyfikacje.
Taki plik może się nazywać soul.md — w narzędziach takich jak Hermes czy OpenClaw — albo agents.md, albo CLAUDE.md w przypadku Claude Code. We wszystkich tych przypadkach pliki te mają zwykle podobną zawartość:
Po pierwsze — tożsamość, osobowość, sposób pracy, sposób upraszczania lub komplikowania całej sesji z użytkownikiem. Jeśli na przykład rozmawiacie o skomplikowanych zagadnieniach prawnych i zawsze chcecie, żeby agent tłumaczył je w prosty sposób, możecie zapisać to jako jedno zdanie: „wyjaśniaj wszystkie złożone koncepcje, o które będę pytać, na poziomie zrozumiałym dla ucznia siódmej klasy”.
Ja sam korzystam z tej warstwy jako z warstwy inwentaryzacji i wskaźników. Mój plik CLAUDE.md wskazuje na wszystkie istotne reguły i umiejętności — to zaledwie krótkie zdania, może 20–30 zdań, mówiące: „gdy robimy X, Y, Z, sięgnij do tych dokumentów”. Ponieważ ładuję bardzo „chudy” plik CLAUDE.md do każdej sesji, mam pewność, że wszystkie kluczowe odniesienia, których agent potrzebuje, są dostępne i skuteczne, niezależnie od wybranego modelu — nawet jeśli byłby to model open source. Agent zawsze będzie wiedział, gdzie szukać.
Warstwa 2: reguły i hooki
Reguły i hooki to nie tylko jedna z najprostszych warstw, ale też taka, od której rzadko zaczynacie — bo na starcie zwykle nie znacie jeszcze dokładnych zachowań modelu, które trzeba ograniczyć albo wokół których trzeba zbudować procedury (SOP), dopóki nie napotkacie konkretnego problemu.
Przykład: budujecie sobie coacha biznesowego, wytrenowanego na zbiorze materiałów od różnych influencerów, którzy pomagają rozwijać biznes. Dopiero gdy zaczniecie z nim rozmawiać i okaże się, że daje wam skrajnie ogólnikowe porady albo takie, które nie są dopasowane do specyfiki waszej firmy, zrozumiecie: „aha, powinniśmy dodać regułę mówiącą, żeby dawał feedback tylko w taki sposób, na taki temat, na takim poziomie szczegółowości”.
I jeszcze coś: powiedzmy, że za każdym razem, gdy chcecie wypchnąć zmiany na GitHuba, chcecie mieć pewność, że nigdzie nie ma żadnych danych osobowych. Wtedy stosuje się hooka — element deterministyczny, przypięty i powiązany z konkretnym zdarzeniem, w tym wypadku z operacją wypchnięcia zmian (push) przy użyciu GitHuba.
Warstwa 3: umiejętności (skills)
Ludzie uwielbiają budować umiejętności, ale nienawidzą ich utrzymywać. Podstawowa zasada: traktujcie umiejętność jako konkretny workflow, który wykonaliście może 5, 10, 15 razy w nieco różny, ale podobny sposób — zwykle z jakimś elementem udziału człowieka w procesie (human in the loop). Nazywam to „umiejętnościami procesowymi” — w odróżnieniu od innych rodzajów umiejętności.
Przykładem umiejętności innego typu byłoby stworzenie połączenia z Fathom albo Fireflies (Informacja dodatkowa: to narzędzia do automatycznej transkrypcji spotkań) w celu pobrania najnowszej transkrypcji ze spotkań. To byłaby raczej umiejętność „funkcjonalna” — łącząca się z istniejącym API, bez większych niuansów w działaniu.
Ta warstwa ma umiarkowane tempo dezaktualizacji — powinniście aktualizować umiejętności niemal co tydzień, nawet jeśli macie je od miesięcy. Ja do dziś zmieniam niektóre umiejętności nieco każdego dnia, zwłaszcza gdy zaczynam je stosować w przypadkach brzegowych, niezależnie od tego, nad czym akurat pracuję.
Jednym z powodów, dla których ta warstwa się dezaktualizuje, jest to, że wraz z pojawianiem się coraz mądrzejszych modeli, niektóre z nich potrzebują znacznie mniej instrukcji, żeby osiągnąć ten sam efekt przy znacznie mniejszej liczbie tokenów. Jednocześnie, jeśli zaczynacie przechodzić na modele open source i stosować podejście hybrydowe — z orkiestratorem opartym na modelu zamkniętym (np. Opus albo Fable, jeśli kiedyś wróci) i agentami wykonawczymi opartymi na modelach open source, jak GLM czy DeepSeek — te ostatnie mogą wciąż potrzebować dużo bardziej rozbudowanych instrukcji, żeby wykonać te same umiejętności. W efekcie możecie mieć różne wersje tej samej umiejętności, dopasowane do różnych wersji modeli.
Jedna praktyczna wskazówka: jeśli chcecie efektywnie i systematycznie doskonalić swoje umiejętności, możecie użyć komendy /goal i polecić: „chcę zoptymalizować tę umiejętność zgodnie z najnowszymi i najlepszymi praktykami”. W terminalu wyglądałoby to mniej więcej tak: /goal chcę, żebyś zoptymalizował(a) umiejętność X w sposób Y, zgodnie z aktualnymi najlepszymi praktykami. Jeśli korzystacie z Claude Code, lubię jeszcze dodać coś w stylu „CC” (jak przy kopiowaniu kogoś w mailu) i „oznaczyć” agenta-przewodnika Claude Code — wtedy pobierze on wszystkie istotne dokumenty, żeby upewnić się, że umiejętność jest maksymalnie zoptymalizowana.
Można pójść o krok dalej i skonfigurować /schedule, żeby co tydzień, nawet bez waszego udziału, proces lekko przycinał i optymalizował każdą waszą umiejętność — z określonym zestawem kryteriów decydujących, co warto zaktualizować, a co zostawić bez zmian. Warto też prowadzić logi tych zmian, na wypadek gdyby jakaś automatyczna aktualizacja sprawiła, że dana umiejętność zaczęła działać gorzej niż wcześniej.
Warstwa 4: zmaterializowani agenci
Podobnie jak umiejętność odpowiada czasownikowi, agent odpowiada roli. Gdy wasze umiejętności zaczynają tworzyć zbiorczy odpowiednik jakiejś roli, sensowne staje się „zatrudnienie” agenta.
Jeśli chcecie tworzyć zmaterializowanych, dopracowanych agentów, które utrzymujecie w czasie, myślcie jak założyciel startupu bootstrapowanego, bez pieniędzy od inwestorów venture capital: jaki jest absolutnie najlepszy pierwszy „pracownik”, jakiego możecie mieć? I jak daleko możecie pociągnąć tego pierwszego „pracownika-agenta”, zanim sensowne stanie się dodanie kolejnej roli?
Wiele osób ekscytuje się koncepcją i fantazją posiadania całej armii agentów, ale nie zdaje sobie sprawy, że armia agentów to bardziej koszmar utrzymaniowy niż błogosławieństwo.
Przykład: tworzycie agenta zorientowanego na podatki, nazwijmy go „optymalizator podatkowy”, którego rolą jest senior strateg podatkowy. Każecie mu przeskanować wszystkie transakcje w firmie, sprawdzić, w jakim regionie działacie, gdzie faktycznie można legalnie zaoszczędzić na podatkach i obniżyć podstawę kosztową. Skoro macie już zbudowaną infrastrukturę umiejętności, mówicie mu: „chcę, żebyś pełnił te role i obowiązki, a w kwestii księgowości i sprawdzania mojej struktury podatkowej używaj tych właśnie umiejętności w taki a taki sposób”.
Ten przykład pokazuje, że podejście to jest addytywne — buduje się na wcześniejszych warstwach. Gdybyście zbudowali agentów bez infrastruktury umiejętności czy tożsamości, byliby oni znacznie bardziej kruchi i zawodni.
Jeszcze jedna uwaga: ta warstwa dezaktualizuje się najszybciej ze wszystkich. Powód jest prosty — wraz z każdą nową wersją modelu otrzymujemy nieco (albo bardzo) inne zachowanie. Różne zachowanie oznacza, że sposób promptowania, który dziś prowadzi do konkretnego wyniku, może stać się przestarzały, gdy tylko pojawi się nowa wersja używanego modelu. Jeśli korzystacie zamiennie z Codexa i Claude Code, tak jak ja, musicie stworzyć zestaw instrukcji jak najbardziej neutralny — swoista „Szwajcaria” między zachowaniami obu modeli — żeby działał podobnie w obu przypadkach.
Warstwa 5: narzędzia, API, MCP i CLI
Ostatnia warstwa to narzędzia, API, MCP i CLI. Wiem, że to dużo skrótów, ale wszystkie odnoszą się do tego samego — to warstwa danych. Tutaj wzbogacacie proces o żywy dostęp do informacji, co może oznaczać dostęp do baz danych, z których pobieracie i do których zapisujecie informacje — na przykład CRM, HubSpot, QuickBooks.
Wracając do wcześniejszego przykładu z podatkami: potrzebowalibyście czegoś w rodzaju QuickBooks, żeby pobrać wszystkie faktury i dane księgowe. Może połączylibyście to z rozmowami z klientami z Fathom albo Fireflies, żeby wychwycić fakt, że trzeba napisać ofertę. Trzeba tę ofertę udokumentować. To staje się systemem, który wymaga logiki, tożsamości, zestawu umiejętności, może agentów, i wreszcie tej ostatniej warstwy, która spina wszystko razem i zapisuje efekty w wybranym CRM-ie.
Jednym z powodów, dla których nie przypisałbym tej warstwie koniecznie najwyższego tempa dezaktualizacji, jest fakt, że wraz ze zmianami API, gdy stają się one przestarzałe, będziecie musieli szybko dostosować cały system do najlepszego sposobu pobierania danych. Czasem struktura danych, sposób ich pobierania zmienia się nieznacznie — może dostawca oferuje bardziej efektywne rozwiązania pod względem opóźnień czy płynności działania. Trzeba więc na bieżąco obserwować, co się dzieje w tej warstwie.
Dobrym przykładem jest sytuacja z MCP. Jeszcze kilka lat temu MCP było ulubieńcem branży AI — wszyscy o nim mówili. Jeśli nie mieliście MCP, nie liczyliście się w rozmowie. Teraz wygląda na to, że MCP zaczyna odchodzić do lamusa. Niektórzy dostawcy nie pokazują już swojego API, udostępniając wyłącznie warstwę MCP, z różnych powodów, ale w większości przypadków to interfejsy wiersza poleceń (CLI) stały się jednym z popularniejszych narzędzi — po prostu dlatego, że są „opakowaniem” wokół API, ale opakowaniem bardzo przyjaznym dla CLI, biorąc pod uwagę, że Codex i Claude Code świetnie sprawdzają się właśnie w tej domenie.
Przykład praktyczny 1: system biznesowy (pseudo-CFO)
Żeby przejść od teorii do konkretu, spójrzmy na dwa namacalne przykłady. Pierwszy to mój system „My OS”, którego celem jest pełnienie funkcji pseudo mini-CFO dla mojej firmy.
Dla ułatwienia — jako „kółka treningowe” — można ponumerować i nazwać każdy folder zgodnie z nazwą danej warstwy w waszym systemie AIOS. W praktyce reguły i hooki powinny i będą znajdować się w czymś w rodzaju Claude, gdzie hostowane są hooki, workflowy i cała reszta. Ale jeśli pomaga wam to na początku uprościć model myślowy, możecie umieścić je w osobnych folderach, a potem, gdy zostaną już dopracowane i sfinalizowane, „przenieść je na wyższy poziom” — do głównego folderu core.claude, gdzie macie pełną inwentaryzację wszystkich tych zasobów.
Mamy tu sporo zasobów, więc doprecyzujmy, co dzieje się pod spodem. W ogólnej strukturze widać foldery wymienione wcześniej, a także plik substrate.wiki. Powstał on w oparciu o pracę Andreja Karpathy’ego (Informacja dodatkowa: znany badacz AI, współzałożyciel OpenAI, twórca koncepcji „drugiego mózgu” wspieranego przez AI), który zbudował bibliotekę pełniącą funkcję „drugiego mózgu”. Mam też folder prompts, w którym znajdują się dwie opcje promptów pozwalające przeprowadzić z wami „wywiad” i zbudować podobną strukturę oraz podejście do tworzenia każdej z tych warstw.
Plik CLAUDE stanowi jądro całego systemu i zawiera m.in. rolę i odpowiedzialność (solo fractional CFO — samodzielny CFO na część etatu), punkt widzenia skupiony na przepływach gotówki i rachunku zysków i strat, zasadę, że nigdy nie należy mieszać ani porównywać dwóch klientów z folderów klienckich, a także wskazuje na różne pliki „playbooków” — dodatkowe pliki kontekstu, których nie chcę przeładowywać do głównego okna kontekstowego ani do pliku CLAUDE.md.
Następnie mamy warstwę reguł i hooków — plik always.md, zawierający dziewięć zasad dotyczących obsługi finansów, oraz plik never.md — osiem rzeczy, których należy unikać i nigdy nie robić (nazewnictwo upraszczam dla jasności). Na przykład: nigdy nie mieszać danych klientów i nigdy nie przekazywać na zewnątrz liczb, które nie zostały w pełni zweryfikowane. Przykładowe hooki to m.in. podwójna weryfikacja, przed wysłaniem jakiejkolwiek pracy do klienta, że dane pochodzą dokładnie z bazy danego klienta i nie ma pomyłki, a także pewna forma zabezpieczenia PII (Informacja dodatkowa: PII, personally identifiable information — dane pozwalające zidentyfikować osobę, np. imię, e-mail), żeby upewnić się, że w żadnym mailu, repozytorium GitHub itd. nie wyciekają imiona, adresy e-mail itp.
Jeśli chodzi o umiejętności, mam np. „monthly close” (miesięczne zamknięcie), które przechodzi przez wszystkich obsługiwanych klientów jako fractional CFO, zamyka ich rachunki zysków i strat, przepływy pieniężne za dany miesiąc i tworzy dla nich raport. Mam też jednego agenta — plik client-portfolio.md — pełniącego funkcję ogólnego stratega. Zaczynam też szkicować, kim mógłby być kolejny agent, wraz z kryteriami wskazującymi, kiedy warto go „zatrudnić” w zależności od okoliczności.
Jednym z plików, których ludzie prawie nigdy nie tworzą, a który polecam — to plik „rot” (dezaktualizacji). Otwierając go w Sublime Text, widać, jak jest zbudowany — pokazuje Claude Code (i można go umieścić jako wskaźnik w pliku CLAUDE.md), w jakim tempie spodziewacie się dezaktualizacji każdej warstwy. Dużo łatwiej jest go stworzyć zaraz po zbudowaniu wersji „80%” czy „V0”, niż kilka miesięcy później, gdy już się „rozgościcie” w systemie i możecie być mniej proaktywni w utrzymywaniu go w dobrym stanie.
Jedna rzecz, o której nie mówiłem w tym nagraniu: te warstwy będą się dezaktualizować w różnym tempie w zależności od firmy i branży. Sami musicie ocenić, jak często musi się zmieniać wasza tożsamość, jak często trzeba aktualizować lub przeglądać połączenie z danym systemem czy usługą.
Mam jeszcze zestaw plików w folderze prompts, który udostępnię w drugim linku poniżej, razem z kilkoma innymi materiałami, żeby pomóc wam wystartować z tą podróżą albo ulepszyć to, co już macie. Mamy prompt A, prostszy, oraz prompt B, bardziej dopasowany do pracy z workflowami. W prompcie A — nie będę czytał go w całości, AI pomogło mi go wygenerować na bazie wielu lekcji, których uczę i które sam wyciągnąłem — napisano w skrócie: „jesteś architektem systemu agentic OS. Chcę skonfigurować prosty osobisty system operacyjny oparty na agentach wewnątrz Claude Code (lub innego modelu językowego, z którego korzystasz) w tym folderze, i chcę, żebyś przeprowadził(a) mnie przez cały proces od początku do końca. Przeczytaj te instrukcje” — po czym prompt rozkłada wszystkie omówione tu warstwy i wyjaśnia dokładnie, jak się ze sobą łączą. Jeśli chcecie dodać wiki, drugi mózg w Obsidianie, też można to uwzględnić.
Prompt zapyta, w jakiej ścieżce plików budujemy system operacyjny, a potem przeprowadzi z wami wywiad: jaka jest wasza rola, komu służycie, jaki jest wasz punkt widzenia — i powinien być jak najbardziej dopasowany do waszej konkretnej działalności. W drugim kroku zaproponuje dwie różne ścieżki budowy systemu operacyjnego i stworzy plik „blueprint” (schemat) systemu operacyjnego. Taki plik pokazuje m.in., kiedy wrócić do wprowadzonych zmian w konkretnej dacie, bo może być on powiązany z plikiem .wiki. Dalej krok po kroku rozkłada, co powinno znaleźć się w każdej warstwie. Gdy przekażecie taki blueprint Claude Code w nowej sesji, powinien on być w stanie stworzyć wersję roboczą całego systemu od początku do końca.
Czy zbuduje go idealnie i zachwyci was za pierwszym razem? Absolutnie nie. Ale sens tych systemów polega na tym, że są to gry nieskończone — rzeczy, które ciągle iterujecie. Podobnie jak ostrzy się miecz, tak w momencie zbudowania systemu operacyjnego bierzecie na siebie odpowiedzialność za jego utrzymanie i aktualność.
Przykład praktyczny 2: system osobisty (zdrowie)
To był przykład biznesowy. Pokażę teraz przykład osobisty, żeby jeszcze mocniej podkreślić ten punkt. To mój system operacyjny do spraw zdrowia, który budowałem publicznie, na oczach mojej społeczności, przez 15 dni. Celem było stworzenie własnego, jak to nazywam, „agenta claw” — czegoś w rodzaju Hermesa, ale lepszego, korzystającego z mojej subskrypcji Claude — dostosowanego do roli osobistego trenera zdrowia.
System zna moją strukturę DNA, wszystkie moje badania krwi, moje tendencje, dawne problemy zdrowotne — wszystko, czego potrzebuje, żeby pomóc mi skupić się na idealnej diecie, idealnym planie ćwiczeń itd.
Zauważcie, że tutaj nie mam ponumerowanych i nazwanych folderów tak jak w przykładzie biznesowym — bo gdy już się to opanuje, „kółka treningowe” można zdjąć i budować systemy operacyjne, mając w głowie ogólną strukturę. Mamy tu dane wyekstrahowane z surowych dokumentów — surowe dokumenty to moje PDF-y z badaniami krwi, wynikami analiz DNA itd. Potem mamy etap ekstrakcji, który przekształca te PDF-y w pliki markdown łatwe do odczytania dla LLM-a.
Następnie mamy warstwę danych — bazę Supabase, w której przechowywane jest absolutnie wszystko, co jem. Co rano synchronizowane są też moje dane z zegarka Whoop (Informacja dodatkowa: Whoop to opaska monitorująca aktywność fizyczną, sen i regenerację) przez API. Wszystko, co można sobie wyobrazić, jest przechowywane w tej bazie, żeby wspierać i „wstrzykiwać” pamięć do systemu. Dzięki temu mogę prowadzić rozmowy z pseudo-osobistym trenerem.
Efekt: mogę robić zdjęcia jedzenia, które spożywam, nagrywać notatki głosowe o wykonanych ćwiczeniach, nagrywać wideo tego, co zamierzam zjeść lub zrobić, albo tego, co widzę w alejce sklepowej — a system udzieli mi w pełni dopasowanej porady, uwzględniającej wszystko, co mnie dotyczy, w tym moje wyniki z ostatnich siedmiu dni, sen. Jeśli zajrzeć do mojego małego dashboardu, ponad samym systemem operacyjnym mam swoje cele dotyczące wagi, snu, struktury posiłków, stosunku białka do sodu i węglowodanów.
Te systemy operacyjne można uczynić bardzo skutecznymi, mając zaledwie kilka folderów. Jedyne, czego potrzeba, żeby czynić je coraz bardziej wyrafinowanymi, to model myślowy pozwalający zrozumieć: co właściwie rozwiązujemy? Jaka wiedza specjalistyczna jest potrzebna, żeby uczynić tego agenta — czerpiącego z uśrednionych danych treningowych — ekspertem w jednej konkretnej dziedzinie?
Ten sam model działa wszędzie
Ostatnia rzecz: niezależnie od tego, czy mówimy o zastosowaniu osobistym, czy nawet korporacyjnym, ten „globus” wygląda bardzo podobnie. Może nie nazywać się tożsamością, tylko „krajobrazem danych”. Może nie nazywać się regułami i hookami, tylko „dostępem do narzędzi” w ogólności — zwłaszcza jeśli w grę wchodzą jakieś ograniczenia działu IT. Potem mamy systemy agentowe w ogóle, w odróżnieniu od zwykłego pliku markdown. Wreszcie — konkretne oprogramowanie klienckie i ogólne systemy operacyjne.
Ten sam paradygmat różnych warstw i „skorup” systemu operacyjnego sprawdza się w różnych kontekstach — osobistym, małej firmy czy przedsiębiorstwa. Mam nadzieję, że ta analiza wraz z wizualizacją i przykładami pokazała wam, że to wcale nie jest takie skomplikowane. To nie jest rocket science. To raczej sztuka z barierkami bezpieczeństwa w postaci nauki — czyli zrozumienie: czego właściwie potrzebujecie? Jak stworzyć dany zasób? Jak upewnić się, że go optymalizujecie?
Nie istnieje jednak jeden konkretny schemat, który pasuje do każdego systemu operacyjnego — wbrew temu, co reklamuje wielu innych twórców. Mój system operacyjny do spraw zdrowia, finansów czy podatków będzie inny niż wasz, ponieważ sposób, w jaki robimy różne rzeczy, sposób, w jaki strukturyzujemy nasze firmy, systemy, z którymi się komunikujemy, i sposób, w jaki chcemy, żeby dostarczały efekty — to wszystko wyjątkowe, niepowtarzalne zasoby.
Podsumowanie
Jeśli ten materiał pomógł wam przełamać jakieś ograniczające przekonania i uwierzyć, że sami możecie to zrobić — mogę wam powiedzieć, że w jeden weekend da się zbudować 80% takiego systemu, a potem przez kolejne tygodnie, może parę miesięcy, dopracowywać go, aż stanie się na tyle wartościowy, że realnie pomoże i przyniesie namacalne efekty.
10 najważniejszych takeaways — z kontekstem zastosowania
1.System pięciu warstw jako uniwersalny szkielet
Na czym polega: Każdy system agentowy AI można opisać pięcioma warstwami: tożsamość (soul file/CLAUDE.md), reguły i hooki, umiejętności (skills), zmaterializowani agenci oraz narzędzia/API/MCP/CLI.
Jak stosować: Zanim zaczniecie budować własny „agentic OS”, rozrysujcie te pięć warstw jako foldery lub sekcje dokumentacji — nawet jeśli na początku część z nich będzie pusta, to pomaga uporządkować myślenie o systemie.
Na co uważać: Nie próbujcie od razu budować wszystkich pięciu warstw naraz w pełnej rozbudowie — autor podkreśla, że np. reguł i hooków zwykle nie da się przewidzieć z góry, tylko odkrywa się je w praktyce.
2.Tożsamość jako punkt odniesienia, nie encyklopedia
Na czym polega: Plik tożsamości (CLAUDE.md, agents.md, soul.md) powinien być „chudy” — pełnić funkcję wskaźnika do innych dokumentów, a nie zawierać wszystkiego w jednym miejscu.
Jak stosować: Zamiast upychać całą wiedzę domenową w jednym pliku, twórzcie krótkie odniesienia typu „gdy robimy X, sięgnij do dokumentu Y” i trzymajcie szczegóły w osobnych plikach playbooków.
Na co uważać: Zbyt rozbudowany plik tożsamości „zaśmieca” okno kontekstowe modelu przy każdej sesji, zwiększając koszty i obniżając jakość odpowiedzi.
3.Hooki są deterministyczne, reguły — nie
Na czym polega: Hooki to jedyny w pełni deterministyczny element systemu, uruchamiany automatycznie w reakcji na konkretne zdarzenie (np. push do GitHuba). Reguły to jedynie silne sugestie dla modelu, które może, ale nie musi, w pełni respektować.
Jak stosować: Krytyczne zabezpieczenia (np. blokada wycieku danych osobowych przy pushu do repozytorium) implementujcie jako hooki, a nie jako zwykłe instrukcje tekstowe w promptach.
Na co uważać: Poleganie wyłącznie na regułach tam, gdzie potrzebna jest twarda gwarancja, może zawieść — model może zignorować regułę w rzadkim przypadku brzegowym.
4.Umiejętności trzeba pielęgnować, nie tylko tworzyć
Na czym polega: Umiejętności (skills) mają umiarkowane, ale stałe tempo dezaktualizacji — wymagają regularnych, cotygodniowych korekt, m.in. dlatego że nowsze modele potrzebują mniej instrukcji do osiągnięcia tego samego efektu.
Jak stosować: Wprowadźcie cykliczny przegląd umiejętności, np. za pomocą zaplanowanego zadania (/schedule) uruchamianego co tydzień, które przycina i optymalizuje umiejętności według ustalonych kryteriów.
Na co uważać: Automatyczne aktualizacje umiejętności mogą pogorszyć ich działanie — prowadźcie logi zmian, żeby móc cofnąć niekorzystną modyfikację.
5.Osobne wersje umiejętności dla różnych modeli
Na czym polega: Przy pracy hybrydowej (model zamknięty jako orkiestrator + modele open source jako wykonawcy) ta sama umiejętność może wymagać różnego poziomu szczegółowości instrukcji w zależności od użytego modelu.
Jak stosować: Jeśli korzystacie z wielu modeli zamiennie (np. Claude Code i Codex, albo modeli zamkniętych i open source), rozważcie utrzymywanie kilku wariantów tej samej umiejętności, dopasowanych do specyfiki każdego modelu.
Na co uważać: Utrzymywanie wielu wersji tej samej umiejętności zwiększa nakład pracy administracyjnej — róbcie to tylko tam, gdzie różnice w zachowaniu modeli faktycznie na to wskazują.
6.Agent to „pierwszy pracownik”, nie armia botów
Na czym polega: Agenta warto tworzyć dopiero wtedy, gdy zbiór umiejętności zaczyna składać się na spójną rolę (odpowiednik stanowiska pracy). Autor poleca myślenie jak bootstrapowany founder: jaki jest najlepszy możliwy „pierwszy hire”?
Jak stosować: Zanim dodacie kolejnego agenta, sprawdźcie, jak daleko można rozciągnąć zakres obowiązków istniejącego agenta, opierając się na już zbudowanej infrastrukturze umiejętności i reguł.
Na co uważać: Mnożenie liczby agentów bez realnej potrzeby tworzy „koszmar utrzymaniowy” — każdy dodatkowy agent to kolejny element wymagający aktualizacji i nadzoru.
7.Warstwa agentów dezaktualizuje się najszybciej
Na czym polega: Ponieważ nowe wersje modeli językowych zmieniają swoje zachowanie, prompty i instrukcje napisane dla agentów tracą aktualność najszybciej ze wszystkich pięciu warstw.
Jak stosować: Jeśli korzystacie zamiennie z kilku dostawców modeli, twórzcie instrukcje możliwie neutralne względem konkretnego modelu, żeby ograniczyć konieczność ciągłego przepisywania promptów.
Na co uważać: Zakładajcie z góry, że instrukcje dla agentów będą wymagać najczęstszych korekt spośród wszystkich warstw — planujcie na to czas i budżet.
8.Warstwa narzędzi/API/MCP wymaga czujności na zmiany rynkowe
Na czym polega: Warstwa narzędzi (API, MCP, CLI) jest „warstwą danych” łączącą system z realnymi źródłami informacji. Zmienia się nie tylko z powodu deprecjacji API, ale też ze względu na zmieniające się trendy technologiczne — jak spadek popularności MCP na rzecz CLI.
Jak stosować: Śledźcie zmiany w API i narzędziach, z których korzysta wasz system, i bądźcie gotowi szybko przełączyć integrację, gdy dostawca zmieni sposób udostępniania danych.
Na co uważać: Nie wiążcie się sztywno z jedną technologią integracyjną (np. wyłącznie MCP) — rynek narzędzi AI zmienia się szybko, a to, co dziś jest standardem, jutro może zostać zastąpione.
9.Plik „rot” jako narzędzie planowania utrzymania
Na czym polega: Warto stworzyć osobny plik (np. rot.md), który określa oczekiwane tempo dezaktualizacji dla każdej warstwy systemu i służy jako wskaźnik w głównym pliku tożsamości.
Jak stosować: Twórzcie taki plik od razu po zbudowaniu wersji roboczej systemu („80%” lub „V0”), a nie kilka miesięcy później, gdy łatwiej o rutynę i mniejszą czujność.
Na co uważać: Tempo dezaktualizacji różni się między branżami i firmami — nie kopiujcie cudzych ustaleń bez dostosowania do własnej sytuacji.
10.Nie ma jednego uniwersalnego szablonu systemu
Na czym polega: Mimo wspólnej struktury pięciu warstw, konkretny system operacyjny (biznesowy, zdrowotny, podatkowy) będzie zawsze unikalny dla danej osoby lub firmy — zależnie od sposobu pracy, struktury organizacyjnej i używanych narzędzi.
Jak stosować: Traktujcie model pięciu warstw jako punkt wyjścia do zbudowania własnego systemu od zera (np. 80% w jeden weekend), a nie jako gotowy szablon do skopiowania 1:1.
Na co uważać: Bądźcie sceptyczni wobec twórców obiecujących „jeden uniwersalny blueprint” pasujący do każdego przypadku — zgodnie z materiałem, taki system zawsze wymaga dopasowania do specyfiki konkretnego zastosowania.