Cztery składniki każdego skutecznego drugiego mózgu AI

2026-10-29 • Cole Medin • AI zagraniczne •tutorial •waga 4/5 •20 min czytania

Przewodnik po drugim mózgu AI według reguły czterech C — kontekst, połączenia, umiejętności, rytm — wraz z testami do audytu własnego systemu. Dla każdego, kto chce delegować pracę agentowi AI.

Robocza publikacja redakcyjna na podstawie publicznego transkryptu YouTube. Źródło: YouTube.

Oryginalny tytuł filmu

The 4 Components of Every Successful AI Second Brain

O czym jest ten film

  1. Cole Medin prowadzi na co dzień całą firmę wspólnie z „drugim mózgiem” — agentem AI z osobną bazą wiedzy — który oszczędza mu 25–30 godzin tygodniowo.
  2. To jego pierwszy materiał zbierający fundamenty w jedną całość: ramę czterech C, czyli kontekst, połączenia, umiejętności i rytm pracy.
  3. Rama pochodzi od Nate’a Hurka, innego edukatora AI na YouTube; Medin prezentował ją także na jego wirtualnej konferencji.
  4. Największa pułapka, przed którą przestrzega autor: nadmierne komplikowanie systemu. Jego w pełni rozwinięty drugi mózg to wciąż kilka narzędzi i folder plików markdown.
  5. Stos narzędzi: Claude Code jako silnik, Obsidian jako skarbiec wiedzy, wtyczka Excalidraw do diagramów, OpenRouter do generowania obrazów, tani serwer w chmurze do pracy zdalnej.
  6. Kontekst opiera się na dwóch warstwach: trzy pliki (soul.md, user.md, memory.md) ładowane do każdej sesji oraz wiki z podsumowaniami wszystkich rozmów i osobnymi notatkami na każdy projekt.
  7. Połączenia to integracje z platformami pracy — Gmail, Asana, GitHub, Slack, Dysk Google — zakładane przez gotowe serwery MCP/API albo własne małe narzędzia pisane z pomocą samego agenta.
  8. Umiejętności to zapisane raz procedury wywoływane komendą (np. montaż wideo); reguła kciuka: proces tłumaczony agentowi więcej niż trzy razy trzeba zamienić w skill.
  9. Rytm to praca proaktywna: „tętno” uruchamiane co 30 minut, które samo zdejmuje zadania (np. szkicuje odpowiedzi na maile) i rozlicza się krótkim raportem na Slacku.
  10. Każde C ma własny test do samodzielnego audytu, drugi mózg potrafi sam siebie ulepszać, a kod całego systemu autor oddaje za darmo w repozytorium na GitHubie.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Liczy się kontekst, nie model

Na czym polega: Autor przestawiał cały system między różnymi modelami Claude’a (Haiku, Sonnet, Opus), Codexem i Kimi K3.1 — za każdym razem działał bez zarzutu. O jakości drugiego mózgu decyduje to, ile agent wie o twojej firmie, a nie dobór konkretnego modelu.

Jak stosować: Zainwestuj czas w warstwę kontekstu, a nie w polowanie na „idealny model”. Jeśli już zmieniasz model, przepuść przez system listę testowych zadań (patrz wniosek 8).

Na co uważać: Ciągła rotacja modeli to najprostszy sposób, żeby zajmować się narzędziami zamiast faktyczną pracą.

2.Test świeżej sesji dla kontekstu

Na czym polega: Otwórz nową rozmowę z agentem i zapytaj, czym zajmuje się twoja firma i kto w niej pracuje. Odpowiedź ma brzmieć jak odpowiedź kolegi z zespołu — bez dłubania w bazie pamięci czy platformach.

Jak stosować: Rób ten test po każdej większej zmianie w systemie. Jeśli odpowiedź wymaga grzebania, kontekst wymaga wzmocnienia.

Na co uważać: Nie ruszaj od razu do ręcznych poprawek — najpierw powiedz agentowi wprost, że nie zna twojej firmy na wylot, i rozwiążcie problem razem.

3.Trzy pliki plus wiki: dwie warstwy pamięci

Na czym polega: soul.md (zachowanie agenta), user.md (fakty o tobie i firmie) i memory.md (kluczowe cele) ładują się do każdej sesji. Pod spodem działa wiki z dziennymi podsumowaniami rozmów i osobnym plikiem na każdy film, klienta czy współpracownika.

Jak stosować: Zacznij od dwóch pierwszych plików, wiki rozbudowuj stopniowo, zasypując ją podsumowaniami codziennych rozmów.

Na co uważać: Nie przeładowuj górnej warstwy — do sesji trafiają tylko rzeczy, które agent musi znać natychmiast; resztę ma samodzielnie wyszukiwać.

4.Drugi mózg naprawia sam siebie — wystarczy mu powiedzieć

Na czym polega: Autor codziennie rozmawia z agentem o tym, co działa, a co nie, i wspólnie wprowadzają poprawki. Dzięki temu system przeszedł z 10 oszczędzonych godzin tygodniowo do ponad 30.

Jak stosować: Po każdym nieudanym zadaniu opisz agentowi problem i zapytaj, co poprawić w kontekście lub umiejętnościach — zmiany to zwykle edycja plików markdown.

Na co uważać: Metoda brzmi banalnie, więc łatwo ją zaniedbać. Robi różnicę regularność tych rozmów, a nie pojedyncza sesja.

5.Połączenia: agent ma pracować tam, gdzie ty pracujesz

Na czym polega: Bez integracji z pocztą, zadaniami, repozytoriami i komunikatorem agent jest tylko „bardzo sprytnym chatbotem”. U autora drugi mózg sięga do Gmaila, Asany, GitHuba, Drive’a i Slacka.

Jak stosować: Test „poniedziałkowego poranka”: poproś o przegląd priorytetów, rzeczy czekających na odpowiedź i osób wymagających uwagi. Ma to zebrać w kilka chwil z każdej platformy, na której pracujesz.

Na co uważać: Tam, gdzie nie ma gotowej integracji, zbuduj własne małe narzędzie — i rób to z pomocą samego drugiego mózgu, bez osobnego agenta programistycznego.

6.Nakładka na integracje daje kontrolę nad uprawnieniami

Na czym polega: Autor otacza API i serwery MCP cienką warstwą własnych skryptów, która decyduje, do jakich narzędzi agent ma dostęp w ramach każdej integracji — na przykład może szkicować maile, ale nie wysyłać ich bez przeglądu.

Jak stosować: Zanim podłączysz cały serwer MCP, wypisz, które z jego funkcji naprawdę chcesz delegować, i odsłoń tylko te.

Na co uważać: Pełny serwer MCP daje agentowi wszystkie narzędzia naraz — wygodne, ale tracisz precyzję kontroli i płacisz dodatkowymi tokenami.

7.Reguła trzech wyjaśnień

Na czym polega: Każdy proces tłumaczony agentowi więcej niż trzy razy trzeba zamienić w umiejętność — wywoływaną komendą typu „/edit video”, z dopiskiem kontekstu (który film montujemy, co ma pokazywać diagram).

Jak stosować: Test: krótkie zlecenie zadania wykonywanego co tydzień ma zwrócić konkretny efekt, bez lawiny pytań doprecyzowujących i bez wymyślania procesu od nowa. Jeśli któryś warunów pada — brakuje skilla.

Na co uważać: Bez zapisanych umiejętności agent wynajduje koło na nowo przy każdym zleceniu — płacisz za to czasem i jakością wyniku.

8.Lista testowa po każdej dużej zmianie

Na czym polega: Autor prowadzi stale aktualizowaną listę zadań obejmujących wszystkie umiejętności (montaż wideo, diagramy, scenariusze, newsy) i przepuszcza ją przez system po każdej istotnej zmianie — np. po przejściu z Opusa 5 na 5.5 montuje krótkie, nagrane na zapas wideo.

Jak stosować: Zbuduj własny zestaw kilku powtarzalnych zadań i uruchamiaj go w całości przed tygodniem pracy, ilekroć coś zmienisz w systemie.

Na co uważać: Bez takiej listy duże zmiany psują system niezauważenie — wykryjesz to dopiero w trakcie prawdziwej pracy, w najgorszym możliwym momencie.

9.Rytm: automatyzuj dopiero po zdobyciu zaufania

Na czym polega: Ostatnie C to praca proaktywna: „tętno” odpala się co 30 minut na serwerze w chmurze za ok. 20 dolarów miesięcznie, przegląda Asanę i Gmaila i samo zdejmuje zadania. Największe z nich — szkicowanie odpowiedzi na wszystkie maile — oszczędza autorowi 30–60 minut dziennie.

Jak stosować: Wstaw na harmonogram jeden przepływ pracy, który sprawdził się w trybie ręcznym. Sekwencja jest stała: zbuduj umiejętność, przepracuj z nią w duecie, zyskaj zaufanie, dopiero wtedy automatyzuj.

Na co uważać: Agent nie może działać po cichu — po każdym cyklu ma wrócić z krótkim raportem (u autora: wiadomość na Slacku) i listą rzeczy wymagających decyzji.

10.Zacznij od minimum, które odda ci kilka godzin tygodniowo

Na czym polega: Cała filozofia materiału to prostota. Start to dwa pliki, kilka serwerów MCP i jeden skill — bez rozbudowanej autonomii. Potem system pracuje na sobie sam, bo zna twoje priorytety i wie, co chcesz delegować.

Jak stosować: Ustal cel na start: odzyskać kilka godzin tygodniowo. Umiejętności i automatyzacje dokładaj tam, gdzie realnie boli.

Na co uważać: Najczęstszy błąd to przekombinowanie — piętrzenie narzędzi i warstw. Rozwinięty system autora to wciąż kilka narzędzi i folder markdownów.

Redakcyjne tłumaczenie

Cała firma działa na drugim mózgu

Mój drugi mózg pomaga mi prowadzić całą firmę. Nie dlatego, że wszystko zautomatyzowałem, ale dlatego, że w czymkolwiek aktualnie pracuję, on odgrywa w tym sporą rolę. Śledzenie nowości ze świata AI, przygotowywanie materiałów, tworzenie diagramów i prezentacji, doskonalenie systemów agentowych, których uczę i które wdrażam u firm — gdziekolwiek działam, non stop rozmawiam z moim drugim mózgiem i ciągle z niego korzystam.

Jestem dziś głęboko przekonany, że taki system jest potrzebny każdemu — niezależnie od roli zawodowej i od tego, czym się zajmujesz. To już nie fanaberia, tylko konieczność. A przy tym zbudowanie go i wplecenie w życie jest dziś zdumiewająco proste.

Mówiłem o moim drugim mózgu na kanale już wiele razy, ale nigdy nie zebrałem fundamentów w jednym filmie. Jakie ramy sprawiają, że drugi mózg po prostu „się spina”? Właśnie temu poświęcam ten materiał. Pomoże ci ruszyć z budową, jeśli jeszcze nie zacząłeś, a jeśli już prowadzisz własny system, posłuży jako lista kontrolna — sprawdzisz, czy pracuje dla ciebie tak dobrze, jak tylko potrafi.

Cel jest prosty: agent ma znać twoją firmę na wylot

Bo widziałem już mnóstwo osób, które — czy to na starcie, czy z czasem, przy rozwijaniu systemu — kompletnie go przekombinowały. To jest rzecz numer jeden, przed którą chcę cię uchronić.

Zadajmy sobie podstawowe pytanie: po co nam w ogóle drugi mózg? Ma znać naszą firmę na wylot, bez zaglądania w notatki. Przecież po to nazywamy go drugim mózgiem — to w gruncie rzeczy przedłużenie nas samych. A żeby to działało dobrze, wcale nie trzeba budować wielu elementów. W tym filmie pokazuję tylko cztery. Jeśli dopiero stawiasz system — one są twoim fundamentem. Jeśli już go masz — to lista kontrolna do audytu. Zajmę się oboma przypadkami.

Od razu dodam: wszystko, o czym mówię, obowiązuje niezależnie od tego, jak zbudowałeś swój system. Może skleciłeś go od zera w Claude Code jak ja, a może używasz botów Groka, Hermesa czy Open Claude. To dosłownie bez znaczenia. Te cztery podstawowe składniki musisz zbudować, sprawdzać i z czasem ulepszać sam — nieważne, na czym stoi twój drugi mózg.

Dlaczego akurat teraz: prostota i absurdalny zwrot z inwestycji

Jedno zauważysz w trakcie: mój drugi mózg to dosłownie kilka narzędzi i folder z plikami markdown. Choć z czasem dorzuciłem do niego mnóstwo możliwości — na tyle, że oszczędza mi dziś 25–30 godzin tygodniowo — nigdy nie musiałem tworzyć rozrośniętej konstrukcji z piętrzącymi się narzędziami. Głównie dlatego, że agenty programistyczne zrobiły się aż tak dobre.

Pod maską całym systemem steruje Claude Code. Nie płacę za osobne usługi do montażu wideo ani do tworzenia diagramów czy prezentacji — wystarczą komendy uruchamiane bezpośrednio na moim komputerze i drugi mózg ogarnia to wszystko. To właśnie moc dużych modeli językowych pozwala utrzymać taką prostotę.

I to jest właściwie najważniejszy powód, żeby budować drugi mózg właśnie teraz: zwrot z inwestycji jest absurdalny. Zbudowanie takiego systemu nie zajmuje już tyle czasu co kiedyś, a poprawianie — tym mniej. Zwłaszcza że po postawieniu fundamentów możesz używać drugiego mózgu do ulepszania jego samego.

Rama czterech C — fundament i lista kontrolna

Skoro mowa o fundamentach, przechodzimy do czterech C: kontekst, połączenia, umiejętności i rytm. To wszystko, co sprawia, że drugi mózg naprawdę działa. Dobrze wdrożysz każdą z nich — i masz podstawy sukcesu.

Sama rama pochodzi od Nate’a Hurka, innego edukatora AI na YouTube, którego bardzo cenię. Kilka tygodni temu wystąpiłem na jego wirtualnej konferencji z bardzo podobną prezentacją. Przynoszę tu jego cztery C, bo to po prostu solidne ujęcie pytania: czego naszemu drugiemu mózgowi naprawdę potrzeba. Według tej listy będziesz budować — albo audytować — swój system.

Narzędzia: cały mój stos mieści się na jednym slajdzie

Jak wspominałem, trzymam się maksymalnej prostoty. Agentem, który wszystko obsługuje pod spodem, jest Claude Code. Przez pewien czas używałem do wszystkiego także Codexa. Przełączenie zarówno środowiska, jak i modelu jest banalne, kiedy poczujesz potrzebę — nie rób tego często, ale jak najbardziej się da.

Do pamięci — całego skarbca wiedzy agenta — używam Obsidiana. Równie dobrze może to być Notion. Ja wolę Obsidiana, bo cała baza wiedzy to pliki markdown na moim komputerze, synchronizowane między urządzeniami. Stylizuję ją na wiki w duchu Karpathy’ego, o którym nagrywałem osobny film — link zostawiam obok. (Informacja dodatkowa: Andrej Karpathy — znany badacz AI; chodzi o promowany przez niego format bazy wiedzy: zwykłe pliki markdown, z którymi model językowy radzi sobie znakomicie.) To układ, który trzyma wszystko w prostocie, a agentowi pozwala bardzo sprawnie przeszukiwać całość: podstawowe wspomnienia i historię rozmów o naszej firmie.

Wszystkie diagramy, które często pokazuję na kanale, robię wtyczką Excalidraw bezpośrednio w Obsidianie. Dzięki temu nawet diagramy to pliki markdown. Cudo. Do obrazów i pozostałych modeli używam OpenRouter — gdy porównuję modele w testach albo generuję miniatury, wszystko idzie przez tę jedną bramkę.

Drugi mózg jest u mnie podpięty dosłownie wszędzie tam, gdzie pracuję: do Kalendarza Google i Gmaila, do Asany, w której ogarniam zadania, do repozytoriów GitHub, do Dysku Google z plikami, do Slacka — przez niego rozmawiam z systemem zdalnie z telefonu i przy jego pomocy koordynuję kontakt z zespołem. System jest wpleciony wszędzie, a to jedno z C, do których zaraz dojdziemy: możliwość pracy tam, gdzie realnie pracujemy.

No i kwestia wdrożenia. Skoro rozmawiam z systemem z telefonu nawet przy wyłączonym komputerze, całość działa na prostym serwerze w chmurze. Płacę jakieś 20 dolarów miesięcznie, cały system tam żyje, a skarbiec pamięci synchronizuje się z moimi lokalnymi urządzeniami. Używam DigitalOcean; Hostinger to również dobry i tani wybór. Nie ma to większego znaczenia — trzymaj się prostoty. Wcale nie musisz trzymać systemu w chmurze, a na początku, budując lokalnie, w ogóle się tym nie przejmujesz. Wspominam o tym dla kompletności, bo pokazuję ci mój cały stos. Mówiłem, że jest prosty — mieści się na jednym slajdzie.

Model nie ma znaczenia, o ile dostaniesz cztery C

Najważniejsza rzecz o czterech C: jeśli dobrze je ogarniesz, nie ma nawet znaczenia, na jakim modelu językowym stoi twój system. Będziesz ustawiony. Cały mój system przestawiałem między Claude’em — do części rzeczy nawet na Haiku, do większości na Sonnecie i Opusie — a potem na Codexa. Przenosiłem całość na Kimi wyłącznie dla testu, jest już model Kimi K3.1. Za każdym razem drugi mózg działał znakomicie, bo to naprawdę nie leży po stronie modelu. Liczy się kontekst — to, jak dobrze system zna twoją firmę. I to jest nasz główny cel.

Segment sponsorowany: Arcade — uprawnienia dla agentów i dobór narzędzi

Sponsorem dzisiejszego filmu jest Arcade, środowisko uruchomieniowe MCP dla agentów AI. (Informacja dodatkowa: MCP, czyli Model Context Protocol, to otwarty standard łączenia agentów z zewnętrznymi narzędziami i danymi.) Łączenie agentów z platformami, w których pracujemy — pocztą, systemem zgłoszeń — jest dziś banalnie proste. Prawdziwy problem leży gdzie indziej: w uprawnieniach. Arcade staje pomiędzy agentem a systemami, w których ten działa. Każda osoba loguje się na własne konto, więc agent działa w jej imieniu i nigdy nie wychodzi poza swoje uprawnienia. Dane logowania w ogóle nie trafiają do modelu, a zasady bezpieczeństwa są egzekwowane poza modelem — żaden prompt ich nie obejdzie.

Arcade wprowadziło właśnie rekomendację narzędzi. To spora sprawa, bo samo Arcade wystawia ponad osiem tysięcy narzędzi dla agentów — jest tam każda platforma, do której chciałbyś się podpiąć. Gdyby jednak załadować je wszystkie agentowi z góry, kosztowałoby go to 1,75 miliona tokenów, zanim przeczyta choć jedną wiadomość. Rekomendacja narzędzi rozwiązuje dokładnie ten problem: system na bieżąco dobiera te, których agent faktycznie potrzebuje.

W mojej sesji Claude Code jestem podłączony do Arcade przez serwer MCP. Wystarczy, że opiszę zadanie — agent wysyła opis do Arcade, dostaje rekomendacje, ładuje tylko potrzebne narzędzia i wywołuje je. Dostaję finalną odpowiedź, nie przeładowując kontekstu na starcie. Arcade można testować za darmo, bez podawania karty; link jest w opisie filmu.

Pierwsze C: kontekst — znaj firmę jak własną kieszeń

Sposobów na dobre ustawienie kontekstu jest tysiąc i jeden; swoją strategię pokażę za chwilę w zarysie. Chodzi o jedno: drugi mózg ma mieć poczucie, że zna twoją firmę na wylot. Bez gruntownego kopania w notatkach powinien wiedzieć, nad czym pracujesz i jakie są twoje główne cele.

Audyt: świeża sesja. Test jest prosty. Otwórz nową rozmowę i zapytaj, czym zajmuje się twoja firma i kto w niej pracuje. Odpowiedź ma brzmieć jak odpowiedź kolegi z zespołu — bez dłubania w systemie pamięci czy platformach. Agent po prostu ma wiedzieć.

Poprawki rób razem z agentem. A jeśli nie wie? Jeśli odkrywasz, że kontekst w twoim systemie kuleje, rozwiązanie jest banalne: powiedz mu o tym. Wprost: „Nie mam wrażenia, że znasz moją firmę na wylot. Co możemy z tym zrobić?”. I szukacie pomysłu razem. W zasadzie od samego początku możesz używać drugiego mózgu do tego, żeby zrobił się lepszy. Nie zdałeś któregokolwiek z testów opisywanych w tym filmie? Powiedz o tym systemowi i wspólnie zaprojektujcie rozwiązanie.

Wiem, że brzmi to zbyt prosto, prawie ckliwie — ale po prostu działa. Właśnie tak przeszedłem z dziesięciu oszczędzonych godzin tygodniowo przy pierwszej wersji do ponad trzydziestu dziś, co brzmi szaleńczo, nawet gdy mówię to na głos. Mam cały system pomiaru tego efektu, o którym opowiem w kolejnych materiałach. Spora część mojego dnia to dziś rozmowa z drugim mózgiem: „to działa, to nie działa, co poprawimy w kontekście albo w umiejętnościach?”. System nie ulepsza się w pełni sam — ale codziennie mocno na nim polegam przy wprowadzaniu zmian.

Dwie warstwy wiedzy. Mój kontekst składa się dziś z dwóch warstw. Pierwsza to podstawowe pliki markdown, ładowane do każdej sesji — to one sprawiają, że agent wie o firmie od ręki. Jest soul.md, swoista dusza systemu: zapis tego, jak ma się zachowywać. Jest user.md: wiedza o mnie i o mojej firmie, wszystkie kluczowe fakty. I memory.md: najważniejsze rzeczy, które wyławiam z niższej warstwy bazy wiedzy — na przykład główne cele firmy, które agent ma znać natychmiast, bez szukania. To jest ta górna warstwa: to, o czym drugi mózg wie zawsze.

Pod nią działa wiki w stylu Karpathy’ego, obejmujące całość mojej działalności. Po każdej rozmowie z systemem powstaje podsumowanie, które trafia do dzienników — to one codziennie odświeżają wiedzę o tym, nad czym pracuję. W bazie jest osobny plik na każdy element mojego biznesu: każdy film, każdą firmę-klienta, każdą osobę z zespołu, projekty open source i nie tylko. Wszystko to jest zapisywane i pielęgnowane w czasie.

Hook, który wszystko ładuje. Górną warstwę wiedzy ładuję do sesji przez mechanizm hook w Claude Code — skrypt odpalający się przy starcie rozmowy. Agent czyta globalne zasady, jak mój Claude.md, a oprócz tego dostaje soul.md, user.md i memory.md. Te pliki opisują zresztą także strukturę niższej bazy, więc agent wie, jak ją sprawnie przeszukiwać.

Audyt dla całego tego C: możesz swobodnie porozmawiać o samym sednie twojej firmy, a agent nie musi grzebać głęboko, żeby podać właściwe odpowiedzi.

Drugie C: połączenia — agent pracuje tam, gdzie ty pracujesz

Można dyskutować, czy kontekst to najważniejszy element drugiego mózgu — ja bym powiedział, że tak. Ale sam kontekst nie jest specjalnie użyteczny, bo agent nie może nam pomóc tam, gdzie realnie pracujemy. Bez integracji mamy po prostu bardzo sprytnego chatbota. Jeśli nie sięga do zarządzania zadaniami, nie pomoże napisać odpowiedzi na maile ani nie wrzuci plików na Dysk Google — nie wykorzystuje ani ułamka swojego potencjału.

Audyt: przegląd poniedziałkowego poranka. Poproś o poranny przegląd na start tygodnia — priorytety, rzeczy czekające na twoją odpowiedź, osoby wymagające uwagi. Jeśli agent nie zbierze tego szybko, audyt oblał. I masz kolejny punkt do poprawy. Powinien czerpać z każdej platformy, w której pracujesz. U mnie: poczta, zadania, repozytoria GitHub, Slack — system jest wszędzie. Zwykle wystarcza zwykłe API albo serwer MCP, więc podpięcie kolejnej platformy niewiele kosztuje. A gdy czegoś nie da się łatwo podłączyć, buduję małe narzędzie wiersza poleceń — przy czym robię to z pomocą samego drugiego mózgu. Nie potrzebuję osobnego agenta programistycznego do konfigurowania systemu. On konfiguruje sam siebie.

Nakładka dająca kontrolę. Dodatkowo napisałem cienką warstwę własnych skryptów na wszystkie używane API i serwery MCP. Dzięki temu sam decyduję, do jakich dokładnie narzędzi agent ma dostęp w ramach każdej integracji. Przykład: chcę, żeby szkicował maile w moim imieniu, ale nie wysyłał ich — najpierw je przejrzę. Zamiast podłączać cały serwer MCP z Gmaila i dawać dostęp do wszystkich jego funkcji, mam pełną kontrolę. Nakładka pozwala też dodać przewidywalności w skryptach — nie będę teraz wchodził w szczegóły. Chodzi o to, że taka warstwa pośrednia otwiera mnóstwo możliwości dostosowania.

Trzecie C: umiejętności — naucz raz, deleguj potem

Mamy wiedzę (kontekst) i dostęp do platform (połączenia). Brakuje trzeciego elementu: agent nie wie, jak konkretnie pracujesz. I właśnie to są umiejętności — tu zapisujemy przepływy pracy i procedury, żeby móc je oddelegować.

Bo nie chcemy, żeby drugi mózg za każdym razem wynajdował koło na nowo. Nie chcemy, żeby przy każdym zleceniu uczył się od zera montować wideo albo rysować diagram. Chcemy to rozpracować z nim raz — a potem zamienić w umiejętność (w ekosystemie mówi się o „skillach”).

Audyt: cotygodniowe zadanie. Daj agentowi krótkie zlecenie dotyczące zadania, które robisz co tydzień. Po drugiej stronie powinien wyjść konkretny rezultat — bez lawiny pytań doprecyzowujących i bez wymyślania procesu od zera. Jeśli którykolwiek z tych warunków pada, potrzebujesz skilla. Uczysz agenta, jak pracujesz, a potem po prostu delegujesz i ufasz — tym bardziej po kilku iteracjach, gdy umiejętność się wykluje.

Kiedy mówię, że mój system oszczędza mi coraz więcej czasu, mam głównie na myśli dokładanie i poprawianie właśnie umiejętności. Codzienne rozmowy w stylu „to działa, to nie” najczęściej kończą się korektami skilli — a że to zwykłe pliki markdown, przeglądanie i zmiany są dziecinnie proste. Jak cały mój drugi mózg, zresztą: w dużej mierze markdown, i właśnie dlatego tak łatwo go z czasem formować.

Reguła trzech wyjaśnień. Moja reguła kciuka: jeśli tłumaczysz agentowi jakiś proces — choćby najmniejszy — więcej niż trzy razy, zamień go w umiejętność. Zamiast za każdym razem rozpisywać „zrób to, potem to, potem tamto i zwróć wynik w takim formacie”, wołasz „/edit video” albo „/create diagram” i dorzucasz tylko kontekst: który film montujemy, co ma pokazywać diagram.

Mam dziś pokaźny zbiór takich procedur: montaż wideo, diagramy, prezentacje, research w sieci, filtrowanie nowości ze świata AI, pomoc przy scenariuszach, ogarnianie skrzynki mailowej. Sporo z nich uczy drugi mózg, jak korzystać z połączeń. I to wszystkie C faktycznie się przenikają: kontekst podpowiada, kiedy sięgnąć po integracje, a umiejętności wciągają je do siebie — na przykład „w tym kroku ta procedura odpytuje integrację z moją społecznością Dynamis”. Wszystko się zazębia, ale umiejętności to w gruncie rzeczy zapis wszystkich procesów, które agent ma wykonywać.

Testy regresji: lista zadań po każdej dużej zmianie. To najważniejsza część całego filmu dla tych, którzy drugi mózg już mają. Właśnie tak dbam o to, żeby zmiany czegoś nie zepsuły. Kiedy ruszam coś dużego — sposób delegowania pracy albo sam model językowy — prowadzę stale aktualizowaną listę zadań, które system wykonuje na wszystkich swoich umiejętnościach: montaż wideo, diagramy, pomoc przy scenariuszach, codzienny przegląd wiadomości AI. Po każdej dużej zmianie przepuszczam przez system całą listę jak zestaw testów i sprawdzam, czy wciąż działa dobrze — a najlepiej jeszcze lepiej.

Bardzo do tego zachęcam, po co drugi mózg używasz. Przykład: przy każdej zmianie modelu — choćby z Opusa 5 na Opusa 5.5 — montuję skillem krótkie, trzyminutowe wideo nagrane kiedyś na zapas. Robię to razem z resztą zadań z listy i dopiero potem ruszam w tydzień pracy. Nie chcę wykrywać problemów w trakcie prawdziwych zadań tylko dlatego, że dzień wcześniej coś przerobiłem w systemie.

Czwarte C: rytm — praca, o którą nie prosisz

Ostatnie C dotyczy tego, żeby drugi mózg pracował także wtedy, kiedy o to nie prosisz. Proaktywność. Nawet w dobrze rozwiniętym systemie większość pracy to wciąż bezpośrednie delegowanie. Ale im bardziej ufasz agentowi, tym więcej warto zautomatyzować — żeby robił coś sam, bez naszego pytania.

U mnie ten rytm nazywam tętnem. Odpala się co pół godziny na tym serwerze w chmurze, zagląda do Asany i Gmaila i wyłapuje rzeczy, które może po prostu zdjąć mi z głowy. Największy filar: szkicowanie odpowiedzi na wszystkie maile — a dostaję ich mnóstwo. Ta jedna rzecz oszczędza mi od pół godziny do godziny dziennie.

Rytm jest ostatnim C nieprzypadkowo. Automatyzujesz dopiero wtedy, gdy ufasz, że agent zrobi to dobrze. Najpierw budujesz umiejętność, potem pracujesz z nią w duecie, a kiedy zyskujesz zaufanie — dopiero wtedy włączasz automat.

Test: wstaw jeden przepływ pracy na harmonogram, gdy sprawdza się uruchamiany ręcznie. Agent ma się z tego rozliczać — nie może odhaczać pracy po cichu. Musi wrócić choćby z krótkim podsumowaniem tego, co zrobił. Moje tętno po każdym cyklu wysyła mi na Slacku zwięzłą informację: co zrobiło i co wymaga mojej uwagi.

Jak zacząć: prosto, jeszcze prościej

Mamy więc cztery C w pigułce. Najważniejsza rada dla startujących: trzymaj się maksymalnej prostoty. Nawet moja rozwinięta wersja jest nadal prosta. Przy kontekście zacznij choćby od kilku podstawowych plików — soul.md i user.md — i dopiero potem buduj wiki. Przy połączeniach podepnij kilka serwerów MCP do narzędzi, z którymi chcesz pracować najpierw. Przy umiejętnościach — jeden skill albo kilka, do najbardziej powtarzalnych rzeczy, które chcesz oddelegować. Rytm zostaw na później, gdy zdobędziesz zaufanie: zbuduj tętno, coś uruchamianego z harmonogramu — na początek choćby szkicowanie odpowiedzi na maile.

Nie musisz budować wszystkich umiejętności naraz ani od razu dopracowywać autonomii agenta. Zrób cokolwiek, co zdejmie ci kilka godzin tygodniowo na start — a system zacznie sam na sobie pracować. Jak mówiłem: drugi mózg będzie ulepszał drugi mózg, bo zna twoje priorytety i wie, co z czasem chcesz delegować.

Jeśli chcesz postawić dokładnie ten system, którego używam codziennie — w opisie zostawiam link do repozytorium na GitHubie ze skillem, który pomoże ci go odtworzyć. Oddaję to za darmo. Nagrywałem też o tym osobny film, podlinkuję go tutaj. Nie musisz kopiować mojego systemu jeden w jeden; jeśli chcesz się tylko zainspirować przedstawionymi pomysłami — bardzo zachęcam. Liczy się solidny fundament i bieżący audyt w miarę rozwoju. Dlatego wszystko, o czym mówiliśmy, działa tak samo dla zaczynających i dla tych, którzy system już mają.

To wszystko, co chciałem dziś przekazać. Jeśli doceniasz materiał i czekasz na więcej o budowaniu drugich mózgów i inżynierii agentów — polub film i zasubskrybuj kanał. Do zobaczenia w następnym.