5 Hacks to Instantly Level Up Your AI OS

O czym jest ten film

1. Jak zorganizować własny „system operacyjny AI” (AIOS) oparty na plikach i folderach, żeby agent nie halucynował.
2. Cztery tryby awarii kontekstu: zatrucie, przeładowanie, dezorientacja i sprzeczność.
3. Dwa typy kontekstu: ekspercki (zawsze potrzebny) i sytuacyjny (ładowany na żądanie).
4. Autorska umiejętność (skill) „OS audit”, która sprawdza spójność projektu i wypisuje listę napraw bez ich wykonywania.
5. Hack 1: traktuj główny CLAUDE.md jak router, a nie jak system prompt.
6. Hack 2: pozwól AI regularnie audytować samego siebie i sugerować zmiany.
7. Hack 3: buduj automatyzacje (crony) do samoczynnego wciągania danych.
8. Hack 4: segmentuj wiedzę na wyraźnie różne, rosnące „węzły”.
9. Hack 5: przy błędzie każ agentowi prześledzić własne kroki i naprawić przyczynę.
10. Refleksja: synchronizacja drugich mózgów na poziomie zespołu to problem ludzi i nawyków, nie technologii.

Redakcyjne tłumaczenie

Dlaczego organizacja AIOS jest najważniejsza

Ostatnio najczęściej dostaję jedno pytanie: jak mam poukładany swój system operacyjny AI? Ludzie pytają, jak kierować plikami, jak organizować wiki, jak układać foldery, gdzie trzymać projekty klientów — mnóstwo pytań o samą organizację. Problem polega na tym, że jeśli nie masz tego uporządkowanego, twój agent zaczyna halucynować — nie tylko w rozmowie z tobą, ale też w twoich umiejętnościach (skills) czy przy budowaniu automatyzacji. A to potrafi być naprawdę groźne.

Dlatego dziś pokażę pięć trików, których używam, żeby utrzymać swój AIOS w maksymalnej dokładności i aktualności — tak, żebym mógł co tydzień dokładać kolejne dane bez utraty jakości i pamięci.

(Informacja dodatkowa: „AIOS” — AI Operating System — to autorskie określenie autora na osobisty „drugi mózg” zbudowany z plików i folderów, po których porusza się agent AI, na przykład Claude Code.)

Umiejętność „OS audit”

Na starszej wersji swojego projektu „Herk” uruchamiam umiejętność o nazwie OS audit. Przechodzi ona przez cały projekt, czyta wszystko, analizuje reguły routingu i wskazuje słabe miejsca: gdzie trzeba poprawić, gdzie zaktualizować dane. Efektem końcowym jest sam audyt — raport w stylu: „Oto 10 rzeczy, które zauważyłem, oto 10 poprawek. Zrobić je? Tak czy nie”. Na tym etapie narzędzie niczego jeszcze nie zmienia — to faza czysto rozpoznawcza. Tworzy też w katalogu głównym folder audits (jeśli go nie masz) i wrzuca tam plik Markdown z ustaleniami i propozycjami napraw.

(Informacja dodatkowa: autor udostępnia tę umiejętność bezpłatnie w swojej społeczności na platformie School — link znajduje się w opisie filmu.)

Cztery tryby awarii kontekstu

Zanim przejdę do pięciu wskazówek, wyjaśnię sześć pojęć: cztery tryby awarii kontekstu oraz dwa typy kontekstu. Zrozumienie ich sprawi, że audyt nabierze sensu, i realnie pomoże w codziennej pracy.

Cztery tryby awarii to: zatrucie, przeładowanie, dezorientacja i sprzeczność. Kiedy agent mówi ci coś błędnego, przyczyna leży zwykle w jednym z nich.

Zatrucie (poisoning) to obecność fałszywego faktu w kontekście. Wyobraź sobie jeden zły fakt wrzucony między poprawne. Agent go widzi i podaje dalej — wyświetla ci go albo wpisuje do maila do klienta — bo był w kontekście. Agent nie kłamie celowo; po prostu chwyta dane, które zostały zatrute błędem. To na szczęście najłatwiejszy tryb do naprawienia: wystarczy weryfikacja — kontrola faktów przez wyszukiwarkę (jedno lub dwa wyszukania), sprawdzenie względem żywej bazy danych, a przy braku stuprocentowej pewności — włączenie człowieka do pętli.

Przeładowanie (bloat) to nadmiar danych. To właśnie odczuwa wiele osób w miarę rozrastania się AIOS. Znamy problem „gnicia kontekstu” (context rot) w oknie oraz problem „igły w stogu siana”: agent podejmuje decyzję na podstawie tego, co ma aktualnie załadowane, a jeśli danych jest za dużo, trudno mu wyłuskać to, co istotne. Coś nieistotnego zawsze się przemyci. Ten tryb jest trudniejszy do naprawienia — pomoże tu rozróżnienie kontekstu eksperckiego i sytuacyjnego (o tym za chwilę).

Dezorientacja (confusion) przypomina po trochu i zatrucie, i przeładowanie. Chodzi o fakt nieistotny albo o coś zupełnie brakującego. To klasyczna halucynacja: agent próbuje uzupełnić brakujące lub błędne dane własnym wymysłem. Różnica względem zatrucia: przy zatruciu agent chwyta fakt z gruntu fałszywy i pewnie go podaje; przy dezorientacji gubi się z powodu tego, co widzi i czego mu brakuje, i po prostu sam sobie odpowiada.

Sprzeczność (clash) to stare dane albo dwa źródła z kłócącymi się informacjami — agent nie wie, któremu ufać. Prosty przykład: w marcu polityką był zawsze zwrot pieniędzy, w czerwcu — nigdy zwrotu. Gdy pojawia się pytanie o zwrot, agent nie wie, którego źródła słuchać. Czasem zaufa staremu, czasem nowemu, a czasem wymyśli coś zupełnie od siebie.

Kontekst ekspercki kontra sytuacyjny

To rozróżnienie jest równie ważne i wiąże się bezpośrednio z czterema trybami awarii. Jeśli korzystasz z mojego frameworka budowy AIOS — czterech „C”: context, connections, capabilities, cadence (kontekst, połączenia, możliwości, rytm) — to kontekst i połączenia stanowią część „drugiego mózgu”. Kontekst utożsamiam z ekspertyzą, a połączenia z sytuacyjnością.

Kontekst ekspercki to rzeczy potrzebne cały czas: kim jesteś, jakie masz cele, czym zajmuje się twoja firma. To rulebook — zasady, polityki, informacje wstępnie załadowane, które muszą być obecne w każdym uruchomieniu, trochę jak system prompt.

Lubię analogię dyrektora i nauczyciela układających plan rozsadzenia klasy. Dyrektor wie, jak powinny działać sale — gdzie jest tablica, gdzie drzwi, jak zbudować dobry plan miejsc. Ale to nauczyciel ma kontekst sytuacyjny każdego ucznia: który słabo widzi i musi siedzieć bliżej, którzy dwaj będą chichotać przez całą lekcję, jeśli usiądą razem. Tę wiedzę ładuje się dokładnie na czas (just in time).

Przykład: interesuje cię zgłoszenie z obsługi klienta, które wpłynęło wczoraj. Nie ma powodu, żeby to zgłoszenie na stałe siedziało w kontekście — dołożyłoby tylko przeładowania, dezorientacji, może i sprzeczności. Zamiast tego, gdy w czwartek o 14:00 musisz odpowiedzieć na pytanie o tego klienta, sięgasz po dane na żywo, wciągasz je, bo właśnie są potrzebne, i wzbogacasz odpowiedź agenta realnym kontekstem sytuacyjnym.

Wszystkie te sześć pojęć składa się na sens audytu i pomaga myśleć o tym, jak promptować i organizować agenta oraz jakie dane powinien mieć zawsze, a jakie pobierać tylko od czasu do czasu.

Odczytanie wyników audytu

Audyt skończył się po około dwóch minutach. Wiedza w systemie jest aktualna do 29 czerwca — czyli sprawie sprzed prawie miesiąca. Wyniki są oznaczone kolorami (czerwony — źle, zielony — dobrze):

• Integralność routingu — czerwony: błędne kierowanie i nieaktualne wpisy.
• Prawdziwość indeksu — czerwony: indeks mówi o 55 folderach, a na dysku jest 79; indeks ma 52 wiersze.
• Świeżość — czerwony.
• Przeładowanie / duplikaty — żółty.
• Higiena — czerwony.
• Rozmieszczenie kontekstu — czerwony.

Audyt tłumaczy też, „co dałoby ci dziś błędną odpowiedź”: każde pytanie o stan biznesu po 29 czerwca zwróciłoby pewną, ale nieaktualną czerwcową odpowiedź; pytanie o postępy pewnych zadań w Q3 trafiłoby w złe miejsce; pytanie o zawartość projektów dałoby przeterminowane dane.

Następnie pojawia się lista napraw ze statusem „czeka na zatwierdzenie”. Można wskazać: „OK, zrób A, B, C i D”. Rekomendacje obejmują: dokończenie rozgrzebanych zmian i zatwierdzenie decyzji o sprzątaniu, naprawę routingu i prawdziwości indeksu, nadrobienie danych (wciągnięcie wiki z sesji Q&A i spotkań) oraz trwałość — cotygodniowy cron dla transkryptów spotkań, ankiet z YouTube, sprzątania archiwum i kwartalnych ponownych przebiegów.

W samej umiejętności (SKILL.md) opis brzmi mniej więcej tak: „OS audit — czy twój AIOS wciąż jest prawdziwy? To twój podręcznik obsługi. Indeksy i wiki to twierdzenia o tym, co istnieje i co jest aktualne. Audyt sprawdza każde twierdzenie względem rzeczywistości. Tylko do odczytu, nigdy nie naprawiaj, nie zmieniaj nazw, nie usuwaj — po prostu daj raport”. Działa na dowolnym projekcie Claude Code.

Umiejętność najpierw szuka wcześniejszych raportów w folderze audits (a jeśli go nie ma — tworzy go). Przy dużym projekcie (ponad 100 folderów) rozdziela pracę: uruchamia po jednym podagencie „Explore” na każdą kontrolę, daje mu instrukcje słowo w słowo plus ścieżkę routingu, po czym scala raporty. Kolejne kontrole to: integralność routingu (czy wszystko, na co wskazuje, istnieje — czyta CLAUDE.md, pliki lokalne i pliki routingu będące spisem treści, także w drugą stronę, szukając błędnie skierowanych rzeczy), prawdziwość indeksu (czy indeksy zgadzają się z dyskiem), świeżość (czy źródła danych są aktualne — świeże, dryfujące, zamrożone, wycofane czy „na żądanie”), a także pamięć, przeładowanie, duplikaty i organizacja.

Hack 1: CLAUDE.md jako router

Wielu z was, budując konkretne projekty, używa CLAUDE.md jak system promptu — „oto twoje tło, oto co robisz”. W większości przypadków to poprawne. Ale mój AIOS „Herk 2” mam ułożony pod jednym wielkim folderem: w środku mnóstwo folderów, część z nich ma własne foldery, a te jeszcze kolejne. Robię tak, bo mogę po prostu wypchnąć główny folder na GitHub i wszystko się backupuje. Każdy z podfolderów ma własny CLAUDE.md, więc mogę wejść (cd) do konkretnego katalogu i tam ustawić bardziej szczegółowy, projektowy „system prompt”.

Ale główny CLAUDE.md na górze traktuję niemal wyłącznie jako router. Zaczyna się od zdania „Jesteś systemem operacyjnym AI Nate’a Herka, twoim zadaniem jest…”, a potem to już właściwie tablica routingu: gdzie żyją dane, gdzie iść po konkretną rzecz. Dalej baza wiedzy — ścieżka do wiki, gorący cache, indeks, fallback, system pamięci, narzędzia, gdzie są klucze API, gdzie skille i agenci, gdzie decyzje, szablony, referencje, projekty i „inne światy”. (Informacja dodatkowa: „inne światy” to duże, samodzielne repozytoria, każde z własnym repo GitHub, żeby wszystko było zsynchronizowane.)

Struktura folderu obejmuje m.in.: .claude z globalnymi skillami, podagentami i ustawieniami; folder brainstormów (zapisy sesji „grill me”); „herk brain” (pierwsze, ogólne wiki); „inne światy”; największy folder projects, gdzie ląduje niemal wszystko, co powstaje (w tym podfolder YouTube videos z transkryptami, scenariuszami, testami, badaniami i skryptami Pythona dla każdego filmu); oraz brand assets z wytycznymi marki, logo i zdjęciami.

Pamiętaj: budujemy tu wyłącznie pliki i foldery, więc możesz podłączyć Hermes, Codex czy cokolwiek innego — nie tylko Claude. To nie musi być najbardziej optymalny układ — ważne jest tylko, żeby mieć właściwe reguły routingu, dzięki którym i ty, i twoi agenci wszystko znajdziecie. Nieważne, czy masz strukturę bardzo płaską, czy jeden wielki folder, do którego schodzisz coraz głębiej.

Hack 2: pozwól AI audytować samego siebie

Dokładnie to, co pokazał audyt — po prostu to rób. Zbudowałem wokół tego skill, ale wcześniej robiłem to rozmową: na koniec każdego tygodnia albo miesiąca mówiłem: „Przejrzyj wszystko, otwórz każdy plik, sprawdź reguły routingu, upewnij się, że nadal są trafne. A jeśli coś ci się nie podoba w świetle dobrych praktyk albo tego, jak ze mną rozmawiasz — zaproponuj zmiany i iterujmy dalej”.

Świetny przykład: mam kilka wiki. Dwa główne — jedno na transkrypty z YouTube, drugie na transkrypty ze spotkań. Początkowo trzymałem wszystko w jednym master-wiki. To sam Claude Code zasugerował: „Zauważyłem, że co tydzień w stałym rytmie wrzucasz dwa konkretne typy danych — rozdziel je, żeby łatwiej mi było szukać”. Efekt: mniej przeładowania, mniej dezorientacji, szybsze i dokładniejsze odpowiedzi, a przy tym taniej, bo agent nie spala tylu tokenów na przekopywanie się przez wszystko.

Ważna zmiana nastawienia: każdy buduje swój drugi mózg trochę inaczej i nie ma jednej właściwej drogi. Jedyny sposób, żeby robić to źle, to stale dostawać błędne odpowiedzi i nic z tym nie robić. Nie stresuj się, że ktoś zrobił to inaczej. Dobry test: otwórz eksplorator plików, pomyśl o czymś, co niedawno zrobiłeś, i spróbuj to znaleźć bez wyszukiwarki i bez pytania Claude’a — po samych folderach. Jeśli trafisz ścieżką sam, to układ jest intuicyjny również dla agenta (zwłaszcza z regułami routingu).

Hack 3: buduj automatyzacje do aktualizacji danych

W audycie pojawiła się „trwałość — cotygodniowy cron”. Im więcej używasz systemu, tym częściej mówisz mu „idź pobierz te dane”. Jeśli okazuje się, że to nie jest kontekst sytuacyjny na żądanie, tylko coś stałego — zautomatyzuj. Dla mojego wiki: co poniedziałek mam Q&A i chcę to mieć w środku; co wtorek spotkanie z zespołem liderów — też chcę to mieć. Po co więc na tym polegać na pamięci? Ustawiam crona, który sam wciągnie te dane, żeby przy następnej rozmowie już tam były, nawet jeśli zapomnę je dodać po spotkaniu.

Brzmi banalnie, ale mnóstwo osób tego nie robi. Wystarczy klucz API i polecenie w naturalnym języku: „Claude, ustaw mi tego crona / tę rutynę” albo „pomóż mi wypchnąć ten skrypt na Modal”. (Informacja dodatkowa: Modal to platforma chmurowa do uruchamiania kodu i zadań w tle, np. właśnie zaplanowanych cronów.)

Hack 4: segmentuj wiedzę

Mam dwa wiki — jedno na YouTube, drugie na transkrypty spotkań — i rozdzieliłem je, bo oba zaczęły rosnąć i planuję je dalej rozbudowywać. Im więcej potrafisz posegmentować, tym lepiej. Jeśli masz wyraźnie odrębne „węzły wiedzy”, które będą się rozrastać, rozdziel je: agent od razu wie, że informacji o jakimś narzędziu ma szukać w wiki z transkryptami YouTube, zamiast przekopywać się przez pięć czy dziesięć razy więcej plików. Rzecz w tym, jak zawęzić kontekst, przez który agent musi się przeszukać.

Częste pytanie: gdzie umieścić projekty klientów i czy wszystko wrzucać do jednego folderu? Ja wewnątrz swojego AIOS trzymałbym informacje segmentowane po kliencie — folder clients, a w nim client A, client B, client C, z plikami opisującymi, nad czym pracuję. Ale zastrzeżenie: konkretny deliverable dla klienta budowałbym w osobnym, „zewnętrznym” repo klienta (np. C:\Users\...\client A), które mógłbym udostępnić klientowi jako współpracownikowi albo wypchnąć do jakiegoś środowiska. W AIOS trzymam wtedy wiedzę wewnętrzną: kiedy zaczęliśmy współpracę, kiedy podpisano umowę, cena projektu, rozmowy rozpoznawcze, zakres prac. Zewnętrzne, właściwe deliverables trzymam nieco na uboczu od wewnętrznego AIOS — ale mój AIOS i tak dostaje kontekst tego zaangażowania, bo musi o nim wiedzieć; po prostu nie musi być właścicielem wszystkiego w środku, gdy wypycham całe repo.

Hack 5: każ agentowi się cofnąć

Podkreślałem, jak ważne jest reagowanie, gdy coś jest nie tak — gdy agent szukał pięć minut czegoś, co powinien znaleźć od razu, albo powiedział „nie mam do tego dostępu”, choć wiesz, że plik tam jest. Trzeba go poprawić: „Masz do tego dostęp, dopilnuj, żeby to się nie powtórzyło, sprawdzaj najpierw”.

Ale ważniejsze jest kazać mu prześledzić własne kroki (backtrack). Mówię: „Powiedziałeś, że nie masz dostępu, ale wiem, że masz. Przejrzyj, co zrobiłeś i gdzie szukałeś, i pomóż mi ustalić, czemu nie znalazłeś tych danych od razu”. Agent wtedy przyznaje: „Zrobiłem błąd, oto co zrobiłem, oto gdzie powinienem był zajrzeć — wtedy znalazłbym to dużo szybciej”. Skoro sam udowodnił swój błąd i powiedział, co zrobił źle, każ mu to naprawić: zaktualizować routing, może przenieść lub przeorganizować pliki na podstawie tego, co odkrył przy cofaniu. To działa znacznie lepiej niż samo „nie popełniaj błędów”.

Refleksja: synchronizacja na poziomie zespołu

Drugie mózgi i systemy AI to teraz bardzo gorący temat — słusznie. Duży problem, który widzimy w rozmowach z firmami: gdy ludzie zbudują już własne drugie mózgi, jak zsynchronizować wszystkie dane na poziomie zespołu czy działu? Aktywnie się tym zajmuję, ale nie mam jeszcze dobrej odpowiedzi. Uważam natomiast, że to nie jest problem technologiczny, tylko ludzki. Da się to zrobić na Google Drive, w Notion czy na GitHubie — trudność leży w zmianie nawyków: w synchronizowaniu danych, wiedzy o tym, co wciągać, zmuszaniu agentów do czytania, w uprawnieniach. To problem nawyków, który musimy rozwiązać, zanim ogłosimy „jedyny słuszny sposób”.

Najlepsze, co możesz teraz robić, to opanować i zrozumieć własny system, żeby przejście na poziom zespołu było łatwiejsze — bo już przeszedłeś tę drogę.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Nazwij tryb awarii kontekstu, zanim zaczniesz naprawiać

Na czym polega: Błędne odpowiedzi agenta niemal zawsze mają jedną z czterech przyczyn — zatrucie (fałszywy fakt w danych), przeładowanie (za dużo danych), dezorientacja (brak/nieistotny fakt uzupełniany zmyśleniem), sprzeczność (kłócące się źródła).

Jak stosować: Przy każdym błędzie zapytaj najpierw „który to tryb?” — dopasuj lek do choroby: zatrucie → weryfikacja i fact-checking; przeładowanie i sprzeczność → segmentacja i usuwanie starych danych; dezorientacja → uzupełnienie brakujących faktów.

Na co uważać: Zatrucie i dezorientacja bywają mylone. Zatrucie to pewnie podany, wprost fałszywy fakt; dezorientacja to zgadywanie przy brakach. Diagnoza determinuje naprawę.

2.Traktuj główny CLAUDE.md jak router, nie jak system prompt

Na czym polega: Nadrzędny plik konfiguracyjny AIOS powinien być tablicą routingu — „co gdzie żyje i kiedy tam iść” — a nie długim opisem osobowości agenta.

Jak stosować: W głównym pliku zostaw krótkie wprowadzenie i mapę ścieżek (wiki, indeks, cache, narzędzia, klucze, projekty). Szczegółowe „system prompty” umieszczaj w podfolderach z własnym CLAUDE.md, do których agent wchodzi przez cd.

Na co uważać: Router musi odpowiadać rzeczywistości na dysku — nieaktualny routing to gwarantowane błędne kierowanie. To najczęstsze czerwone pole w audycie.

3.Rozdzielaj kontekst ekspercki od sytuacyjnego

Na czym polega: Kontekst ekspercki (kim jesteś, cele, polityki) musi być w każdym uruchomieniu; kontekst sytuacyjny (konkretne zgłoszenie, wczorajsza sprawa) pobiera się na żądanie.

Jak stosować: Do stałego promptu wrzucaj tylko rulebook. Dane jednorazowe trzymaj poza kontekstem i sięgaj po nie „just in time” przez wyszukanie na żywo dokładnie wtedy, gdy są potrzebne.

Na co uważać: Wrzucanie danych sytuacyjnych na stałe do kontekstu to prosta droga do przeładowania i dezorientacji. Zadaj sobie pytanie: „czy potrzebuję tego w każdym uruchomieniu?“.

4.Zbuduj (lub wypożycz) rutynę audytu OS

Na czym polega: Regularny audyt sprawdza, czy twierdzenia indeksów i wiki nadal zgadzają się z rzeczywistością, i zwraca listę napraw — bez ich wykonywania.

Jak stosować: Uruchamiaj audyt tylko do odczytu, przeglądaj raport, a dopiero potem zatwierdzaj wybrane naprawy. Przy dużych projektach (100+ folderów) rozdziel kontrole na podagentów i scal raporty.

Na co uważać: Kluczowa zasada bezpieczeństwa — faza rozpoznania niczego nie zmienia, nie usuwa i nie zmienia nazw. Nie pozwól narzędziu automatycznie „naprawiać” przed twoją akceptacją.

5.Pozwól AI regularnie audytować samego siebie i sugerować zmiany

Na czym polega: Sam agent często dostrzega wzorce w twoich danych i proponuje reorganizację (np. rozdzielenie jednego wiki na dwa według rytmu wrzucania danych).

Jak stosować: Na koniec tygodnia lub miesiąca poproś: „przejrzyj routing i strukturę, i zaproponuj usprawnienia w świetle dobrych praktyk i tego, jak ze mną pracujesz”. Nie musisz mieć skilla — wystarczy rozmowa.

Na co uważać: To sugestie, nie wyrocznia. Traktuj je jako punkt wyjścia do iteracji; ty decydujesz, co wdrożyć.

6.Zautomatyzuj wciąganie danych o stałym rytmie

Na czym polega: Dane pojawiające się cyklicznie (cotygodniowe Q&A, transkrypty spotkań) powinny trafiać do systemu automatycznie, a nie ręcznie.

Jak stosować: Ustaw crony/rutyny w naturalnym języku — wystarczy klucz API i polecenie „ustaw crona, który co poniedziałek wciągnie te dane”. Rozważ uruchomienie skryptów w chmurze (np. Modal).

Na co uważać: Automatyzuj tylko dane, które naprawdę mają żyć w systemie na stałe. Dane jednorazowe zostaw jako lookup na żądanie — inaczej cron sam wygeneruje przeładowanie.

7.Segmentuj rosnące węzły wiedzy

Na czym polega: Wyraźnie odrębne, rozrastające się zbiory (transkrypty YouTube vs. spotkania) lepiej trzymać w osobnych wiki, żeby zawęzić obszar przeszukiwania.

Jak stosować: Gdy zauważysz, że jeden zbiór puchnie i tematycznie różni się od reszty, wydziel go. Agent od razu skieruje się do właściwego węzła, zamiast przeszukiwać wielokrotnie więcej plików — szybciej, dokładniej i taniej (mniej tokenów).

Na co uważać: Nie segmentuj na siłę wszystkiego — dziel według realnych, trwałych granic tematycznych. Za drobne rozdrobnienie utrudnia routing tak samo jak brak podziału.

8.Projekty klientów: rozdziel wiedzę wewnętrzną od deliverables

Na czym polega: Wewnątrz AIOS trzymaj wiedzę wewnętrzną o kliencie (daty, umowa, cena, zakres), a właściwe deliverables buduj w osobnym, klienckim repo.

Jak stosować: Segmentuj klientów po folderach (clients/client A/…). Deliverables trzymaj w zewnętrznym repo, które można udostępnić klientowi jako współpracownikowi lub wypchnąć do środowiska — ale nadal dawaj AIOS kontekst zaangażowania.

Na co uważać: Nie wypychaj poufnych deliverables razem z całym repo AIOS. AIOS ma „wiedzieć” o zleceniu, ale nie musi być właścicielem całej jego zawartości.

9.Przy błędzie każ agentowi się cofnąć i naprawić przyczynę

Na czym polega: Zamiast mówić „nie popełniaj błędów”, zmuś agenta do prześledzenia własnych kroków, wskazania, gdzie powinien był szukać, a potem do naprawienia przyczyny (routingu, organizacji).

Jak stosować: Gdy agent twierdzi „nie mam dostępu”, a wiesz, że plik istnieje, powiedz: „prześledź, gdzie szukałeś, i ustal, czemu nie znalazłeś tego od razu” — po diagnozie każ zaktualizować routing lub przenieść pliki.

Na co uważać: Samo „nie rób tego więcej” nie działa. Wartość jest w samodiagnozie i trwałej poprawce struktury, a nie w obietnicy poprawy.

10.Opanuj własny system, zanim przejdziesz na poziom zespołu

Na czym polega: Synchronizacja drugich mózgów w zespole to dziś problem nierozwiązany — i według autora bardziej ludzki (nawyki, uprawnienia) niż technologiczny.

Jak stosować: Najpierw doprowadź do porządku i pełnego zrozumienia własny AIOS. Test intuicyjności: znajdź niedawny plik po samych folderach, bez wyszukiwarki i bez pytania agenta.

Na co uważać: Nie czekaj na „jedyne słuszne” narzędzie zespołowe — Google Drive, Notion czy GitHub wystarczą. Wąskim gardłem jest zmiana nawyków ludzi, nie wybór technologii.