Pulse: system operacyjny agencji zbudowany w Claude Code

W skrócie

Pulse zamienia każde spotkanie w agencji — z klientem, wewnętrzne, sprzedażowe, telefon do prospekta — w konkretną informację dostarczoną właściwej osobie we właściwym miejscu. Nie w raport, który ktoś kiedyś otworzy. W komentarz pod zadaniem, post na kanale projektu, prywatną wiadomość do konkretnego człowieka.

Powstał między lutym a sierpniem 2026 i przez cały ten czas był rozwijany na działającej produkcji, nie obok niej. Powstał w Claude Code — nie „z pomocą AI”, ale w Claude Code jako środowisku inżynieryjnym, z własnymi narzędziami, własnym procesem kontroli jakości i własną pamięcią projektu.

To case study jest o tej drugiej części. O tym, jak wygląda praca, w której jedna osoba utrzymuje system tej wielkości, i dlaczego wychodzi z tego kod, który przechodzi przegląd, a nie kod, który wygląda na gotowy.

Punkt wyjścia

Agencja marketingowa spotyka się dużo. Z klientami, na standupach, na spotkaniach działowych, na rozmowach sprzedażowych. Z każdego z nich zostaje transkrypcja, notatka albo nic.

Problem nie polega na tym, że nikt nie robi notatek. Polega na tym, że notatka trafia w miejsce, do którego nikt nie wraca. Team Leader nie wie, że klient trzeci raz z rzędu mówi o tym samym problemie. Project Manager dowiaduje się o ustaleniu tydzień później. Handlowiec nie wie, że klient dzwonił i nie dodzwonił się, bo powiadomienie poszło mailem do menedżera.

Do tego dochodzi rzecz trudniejsza: nikt nie ma obrazu całości. Ile projektów jest w kiepskiej kondycji? Kto prowadzi spotkania dobrze, a kto zamienia je w monolog? Czego klienci nie mówią wprost, ale powtarzają co miesiąc?

Odpowiedź „przeanalizujmy transkrypcje modelem językowym” jest w tym miejscu banalna i sama z siebie nic nie daje. Trudność nie leży w analizie. Leży w tym, co dzieje się wokół niej: skąd bierzesz transkrypcję, jak rozpoznajesz typ spotkania, do którego zadania przypinasz wynik, komu wysyłasz wiadomość, co robisz, gdy model zwróci uszkodzoną odpowiedź, i jak sprawić, żeby błąd był głośny zamiast cichy.

To jest problem inżynierski, nie problem promptowania. I dokładnie tam pracuje Claude Code.

Co robi Pulse

Krótko, bo to nie jest sedno tego dokumentu.

System skanuje kalendarze zespołu i sam dołącza do spotkań pasujących do wzorca. Po spotkaniu pobiera transkrypcję, rozpoznaje typ po tytule i kieruje do właściwego modułu. Warstwa analizy — model językowy pracujący na promptach trzymanych poza kodem, w edytowalnych dokumentach — zwraca ustrukturyzowany wynik: ustalenia, ryzyka, cele, sentyment, zadania.

Model jest tu wymienialny: prompty żyją w dokumentach, nazwa modelu to wpis w konfiguracji, a poszczególne moduły mogą pracować na różnych modelach. Analiza spotkań, chatbot i moduł informacji zwrotnej mają dziś trzy niezależne ustawienia. To założenie z pierwszego dnia, nie późniejsza łatka.

Dalej wynik rozchodzi się do ludzi: komentarz pod zadaniem projektu, dla Team Leadera. Post na kanale projektu, dla Project Managera. Prywatna wiadomość do konkretnej osoby — indywidualny feedback, metryki udziału w spotkaniu, draft posta na LinkedIn, ostrzeżenie o ryzyku w omawianym procesie. Wpis do bazy, żeby dało się o to zapytać za pół roku.

Tak wygląda układ wiadomości coachingowej, którą po spotkaniu dostaje jedna osoba — prywatnie, nie na kanale zespołu. Cel jest rozwojowy: człowiek dostaje konkret, co następnym razem zrobić lepiej. Wnioski o osobie widzi ograniczone grono; materiał projektowy widzą osoby pracujące nad danym projektem, żeby znały historię i przebieg współpracy. Przykład jest zanonimizowany; każdy prawdziwy nosi nazwisko.

Spotkanie: [EXT] klient.pl | przegląd kampanii
👋 Cześć! Kilka obserwacji z wczorajszego przeglądu z klientem.
🚀 MOCNE
— Kiedy klient powiedział „to nie są wyniki, których się spodziewaliśmy”, nie tłumaczyłaś/eś się od razu — najpierw dopytałaś/eś, do czego je porównuje. Okazało się, że do zeszłego Q4, czyli sezonu. To ustawiło całą dalszą rozmowę.
— Zamknęłaś/zamknąłeś spotkanie konkretem: kto, co, do kiedy. Klient powtórzył to własnymi słowami, więc wiadomo, że się zgadzacie.
🔧 CO POPRAWIĆ U SIEBIE
— Temat budżetu na przyszły kwartał wszedł w 47. minucie, przy zbieraniu się. Następnym razem postaw go w pierwszej połowie — wtedy jest czas na reakcję, a nie tylko na odnotowanie.
💡 POMYSŁ DLA AGENCJI (nie zadanie dla Ciebie)
To trzecie spotkanie w tym miesiącu, na którym klient porównuje wyniki do niewłaściwego okresu. Może warto, żeby raport miał porównanie rok do roku ustawione domyślnie, zamiast liczyć na to, że każdy PM to za każdym razem wyprostuje.

Wiadomość jest zakotwiczona w konkretnych momentach spotkania — bez tego byłaby zbiorem ogólników, których nikt nie czyta drugi raz.

Na tym samym fundamencie stoi reszta: cotygodniowy przegląd kondycji projektów z oceną punktową, informacja zwrotna dla prowadzących spotkania — co następnym razem zrobić inaczej, obsługa prospectingu telefonicznego z automatycznym powiadomieniem osoby prowadzącej kontakt, przekazanie ustaleń sprzedażowych do zespołu projektowego w momencie wygrania leada, wtyczka streszczająca wątek mailowy do naszego systemu pracy i chatbot, który odpowiada na pytania o historię spotkań.

Zabezpieczenia, o które pytają najpierw

Na każdym spotkaniu bot odzywa się na czacie — wewnętrznym i zewnętrznym — i to uczestnicy decydują, czy ma nagrywać. Przykład wyżej jest przepisany i zanonimizowany; zrzutów prawdziwych wiadomości nie publikujemy, bo każda nosi nazwisko. Dane przetwarzamy zgodnie z naszą polityką prywatności i umowami.

Jak to powstało

Tutaj zaczyna się właściwe case study.

Claude Code jako środowisko, nie jako podpowiadacz

Standardowe użycie asystenta kodu wygląda tak: człowiek pisze, asystent podpowiada linijkę. Tutaj układ jest odwrotny. Claude Code dostaje zadanie sformułowane po ludzku — „klient zgłosił, że w podsumowaniach nagłówki zamieniły się miejscami z treścią” — i prowadzi je od diagnozy do wdrożenia.

Żeby to działało powtarzalnie, a nie od przypadku do przypadku, zbudowaliśmy w repozytorium czternaście własnych narzędzi opisujących konkretne obszary systemu i konkretne procedury. Każde to dokument mówiący: kiedy tego użyć, jakie są zasady, jakie są znane pułapki, co zwrócić na końcu.

Nad nimi stoi orkiestrator — narzędzie, które nie pisze kodu. Rozpoznaje intencję, planuje, deleguje do właściwego narzędzia i pilnuje, żeby praca przeszła przez bramki jakości.

Bramki jakości, które faktycznie zatrzymują pracę

To jest fragment, z którego jesteśmy najbardziej zadowoleni, bo rozwiązuje realny problem pracy z modelem: kod, który wygląda na gotowy, nie jest gotowy.

Każda zmiana przechodzi przez trzy niezależne przeglądy, każdy zadający inne pytanie.

Test sprawdza, czy to w ogóle działa — scenariusz normalny, przypadki brzegowe, złe dane wejściowe. Tester niczego nie naprawia; zwraca raport.

Przegląd użytkowy ocenia z perspektywy człowieka, który tego używa, w skali 1–10. Nie ocenia elegancji kodu — ocenia, czy Team Leader zrozumie tę wiadomość bez instrukcji i czy dostanie sensowny komunikat, gdy coś pójdzie nie tak. Próg akceptacji to 9/10. Poniżej wracamy do poprawek, bez pytania „czy iterować”.

Przegląd kodu pyta o coś jeszcze innego: czy kod robi to, co obiecuje. Bo zmiana może dostać 10/10 za użyteczność i wciąż gubić dane na pustej tablicy.

Dopiero czysty wynik z trzech bramek pozwala na commit. Commita zatwierdza człowiek — Claude Code nigdy nie robi tego sam. To zasada zapisana w konfiguracji projektu i przestrzegana.

System, który się sam poprawia

W repozytorium leży log zadań: jedna linia na zakończone zadanie. Cel użytkownika, rezultat, użyte narzędzia, pomysł na nowe narzędzie.

Na starcie każdej sesji Claude Code przegląda ostatnie wpisy i szuka powtórzeń. Gdy ta sama procedura wraca trzeci raz i ma ustabilizowany przebieg — proponuje zrobienie z niej narzędzia. Nie tworzy go sam; proponuje, z dowodem z logu.

Tak powstało nasze narzędzie do publikowania treści. Dwa razy z rzędu zadanie skończyło się ręcznym wklejaniem treści na stronę. Za trzecim razem Claude Code to zauważył, zaproponował narzędzie i — po zgodzie — napisał je razem ze skryptem pomocniczym.

Narzędzie ma jedną cechę, o którą poprosiliśmy wprost i która pokazuje, o co w tym wszystkim chodzi: domyślnie niczego nie zapisuje. Najpierw porównuje treść lokalną z tym, co jest na stronie, pokazuje linia po linii, co zniknie, i czeka na decyzję człowieka. Powód: prompty bywają poprawiane wprost w panelu, repozytorium o tym nie wie, a nadpisanie skasowałoby te poprawki bez śladu.

To nie jest ostrożność wpisana do promptu jako ogólnik. To ostrożność wynikająca z konkretnego, przeżytego problemu, zapisana w narzędziu tak, żeby nie dało się jej pominąć.

Tydzień z sierpnia

Teoria brzmi ładnie. Poniżej to, co wydarzyło się naprawdę — pięć zadań z jednego tygodnia, każde pokazujące inny rodzaj pracy. To nie jest wybór najlepszych momentów z półrocza. Tak wygląda zwykły tydzień w logu zadań.

Model zgubił jeden nawias

24 sierpnia. Analiza spotkania z klientem przewróciła się na parsowaniu odpowiedzi. Przyczyna: model zgubił jedną klamrę otwierającą w liście zadań. Treść była kompletna — przepadła całość.

Naprawa oczywistej przyczyny zajęłaby kwadrans. Zamiast tego Claude Code napisał test własnościowy: weź cztery kształty odpowiedzi, usuń po kolei każdy znak strukturalny i sprawdź, czy naprawa odzyska treść co do znaku albo uczciwie odmówi.

Test wykrył trzy wady starsze niż zmiana, która go wywołała. Każda z nich w określonych warunkach po cichu sklejała dwa zadania w jedno albo zakopywała całą sekcję raportu — i publikowała to jako sukces. Nikt o nich nie wiedział, bo nie generowały błędów.

Nad zadaniem pracowało trzynaście równoległych agentów: inwentaryzacja wszystkich wywołań modelu w systemie, analiza ryzyka ponowień, trzy niezależne próby złamania naprawy, krytyk sprawdzający kompletność. Krytyk znalazł realną lukę w samym teście — jeden z przykładów testowych nie wykrywał, że zgubiony nawias zamykający chowa treść notatki wewnątrz listy zadań.

Przegląd użytkowy dał 8/10. Po dopisaniu wyraźnych granic zakresu — 9/10. Wtedy poszło do wdrożenia.

Polski cudzysłów

22 sierpnia. Wtyczka do Gmaila skasowała gotową notatkę. Przyczyna: model otworzył cytat polskim znakiem „, zamknął zwykłym ", co urwało treść w połowie — a odpowiedź była formalnie oznaczona jako kompletna.

Cztery warstwy naprawy, w tym jedna nieoczywista: okazało się, że wzorzec promptu pokazywał modelowi niepoprawny format do skopiowania. Dwie linijki obok siebie, jedna dobra, druga zła. Model kopiował złą.

To jest klasa błędu, której prawie się nie widzi. Prompt czyta się poprawnie — człowiek przegląda go i wszystko wygląda w porządku, bo poprawny przykład stoi tuż obok. Dopiero zachowanie modelu pokazuje, który z dwóch wzorców faktycznie skopiował. Winny nie jest ani kod, ani model: winna jest instrukcja, w której zostawiliśmy dwie sprzeczne odpowiedzi na to samo pytanie.

Przy okazji wyszło, że jeden z wcześniejszych kroków naprawczych gubił pola po cichu i meldował to jako sukces.

Kreska, która była nagłówkiem

26 sierpnia. Zgłoszenie od użytkownika: „asystent podmienił mi headingi z tekstem w podsumowaniach”. Akapity renderowały się większe niż tytuły sekcji.

Przyczyna: linia myślników postawiona bezpośrednio pod tekstem. W Markdownie to nie jest kreska pozioma — to podkreślenie nagłówka, które promuje akapit nad nią do nagłówka drugiego poziomu. Model wykonał prompt poprawnie. Prompt kazał mu zbudować pułapkę.

Ale najciekawsze wyszło obok. Weryfikacja poprawki wymagała wysłania wiadomości. Claude Code sprawdził, jak działa uruchamianie tego modułu, i zauważył, że lista odbiorców jest ustawiona na „wszyscy” — test na produkcji rozesłałby wiadomości po całym zespole. Zamiast tego wysłał dwie wiadomości testowe tym samym mechanizmem, ale poza produkcyjnym przebiegiem, i porównał render.

Przy okazji obalił założenie zapisane w prompcie miesiąc wcześniej — zakaz nagłówków uzasadniony tym, że wiadomości prywatne nie renderują nagłówków niezawodnie. Zrzut ekranu od użytkownika dowodził czegoś odwrotnego. Założenie nigdy nie zostało zmierzone; teraz zostało, i zakaz zniknął.

Telefon, o którym nie dowiedział się nikt

26 sierpnia. Klient zadzwonił na linię jednego z handlowców. Nikt nie odebrał, poszła poczta głosowa. System zapisał „brak właściciela” i nie powiadomił nikogo.

Diagnoza: mechanizm ustalania odbiorcy miał trzy poziomy i wszystkie trzy pytały o numer dzwoniącego albo o to, co przypisał operator. Żaden nie pytał o numer, na który dzwoniono. Ten numer był w arkuszu przez cały czas. Brakowało wyłącznie miejsca, w którym stoi, czyj to numer.

Nowy poziom został świadomie ustawiony pod istniejącym, nie nad nim — bo mapa numerów jest ręczna i się starzeje, a dane od operatora mówią, co faktycznie zadzwoniło. Dzięki temu zmiana nie rusza ani jednego powiadomienia, które dziś trafia dobrze. Odzywa się wyłącznie tam, gdzie dziś jest cisza.

Do tego mechanizm, który sam pilnuje, żeby mapa nie zwietrzała: przy każdym wierszu dopisuje się informacja o stanie numeru — także przy powiadomieniach, które zadziałały. Dziura ma być widoczna, zanim kosztuje leada.

Test: 68 asercji, pierwszy test tego modułu w ogóle. Wśród nich cztery pilnujące nie kodu, tylko podjętych decyzji.

Operator, który się mylił

25 sierpnia. Webhook oznaczony jako „nieodebrane” przyniósł dziesięciominutową odebraną rozmowę. Pod zadaniem prospekta wylądował komentarz „nie udało się dodzwonić” — nieprawda, w miejscu, gdzie żyje praca nad leadem.

Tego samego poranka ten sam mechanizm zaklasyfikował poprawnie prawdziwą nieudaną próbę. Czyli nie dało się ani odrzucić sygnału, ani mu bezwarunkowo ufać.

Rozstrzygnięcie oparto na dwóch niezależnych sygnałach, bo z góry nie wiadomo, które dane przyjdą: obecność nagrania wraz z czasem rozmowy oraz odstęp czasu między początkiem rozmowy a przyjściem powiadomienia. Trzynaście sekund to nieudana próba. Sześćset dwadzieścia dwie — rozmowa.

Do notatki trafia długość rozmowy, i to nie jest ozdobnik. „Rozmowa odbyta” to wniosek, nie fakt odczytany wprost — a handlowiec jest jedyną osobą, która wie, jak było naprawdę. Bez podanej długości nie ma czego zweryfikować.

Mechanizm działa tylko w jedną stronę: brak dowodu zostawia dotychczasowe zachowanie. Pomyłka w stronę milczenia kosztuje brak komentarza. W drugą — kłamstwo na zadaniu klienta.

Co z tego wynika

Pięć historii, jeden wspólny wątek: żadna z nich nie jest o generowaniu kodu.

Każda jest o czymś trudniejszym — o zauważeniu, że problem leży gdzie indziej niż w zgłoszeniu. Że test na produkcji rozesłałby wiadomości po zespole. Że wzorzec promptu uczy model błędu. Że dane były w arkuszu przez cały czas. Że założenie sprzed miesiąca nigdy nie zostało zmierzone.

Właśnie to dostaliśmy z Claude Code — nie szybsze pisanie linijek, tylko utrzymanie systemu, na który normalnie potrzeba zespołu.

Dokumentacja to 5 885 linii w 30 plikach. Moduły produkcyjne obsługują pięć typów spotkań, siedem rodzajów wiadomości prywatnych, dwie wtyczki do przeglądarki i jednego chatbota. System jest w produkcji od lutego 2026. Zaoszczędzony czas to jedyna liczba, której tu nie mierzymy wprost — szacunek agencji mówi o setkach godzin miesięcznie i jest szacunkiem, nie odczytem.

Trzy rzeczy, które okazały się kluczowe

Zapisuj powody, nie tylko decyzje. Nasz plik zmian ma 1 595 linii i przy każdej zmianie odpowiada na pytanie „dlaczego”, nie tylko „co”. Dzięki temu Claude Code wchodzący w zadanie po miesiącu wie, że dany mechanizm stoi tam z powodu konkretnej awarii — i nie „naprawia” go z powrotem.

Bramka jakości musi mieć prawo zatrzymać pracę. Próg 9/10 działa tylko dlatego, że poniżej niego wracamy do poprawek automatycznie, bez pytania. Gdyby próg był miękki, byłby dekoracją.

Rozdziel „czy to jest dobre dla człowieka” od „czy kod robi to, co obiecuje”. To dwa różne pytania i jedno nie zastępuje drugiego. Zmiana bywa świetna w odbiorze i wciąż gubi dane na pustym wejściu.

Co dalej

Pulse rośnie dalej. Najbliższy kierunek to rozszerzenie chatbota o pytania, na które dziś trzeba szukać odpowiedzi ręcznie.

Sposób pracy zostaje ten sam. Człowiek stawia problem i zatwierdza wynik. Claude Code prowadzi wszystko pomiędzy — i zatrzymuje się, kiedy trzeba zapytać.