Autonomiczna firma nie zaczyna się od armii agentów

Gdy jeden agent przestał wystarczać do pracy nad moimi aplikacjami, zbudowałem Paperclipa: system wielu agentów, którzy mają zachowywać się jak pracownicy organizacji. Programista powinien być dokładny, tester sceptyczny, grafik kreatywny, a project manager odpowiedzialny za koordynację zamiast pisania kodu czy tworzenia grafik. Każdy dostaje rolę, instrukcje i kontekst potrzebny do pracy.

To brzmi jak zalążek autonomicznej firmy. Praktyka szybko pokazała jednak, że zbiór agentów nie staje się firmą tylko dlatego, że nadam im stanowiska. Paperclip potrafił wykonywać wiele zadań, tworzyć dokumentację i rozbudowywać własne procedury, a jednocześnie nie wprowadzać zmian widocznych w aplikacjach. System był aktywny, ale jego aktywność nie była jeszcze dowodem autonomii.

Samo AI jest tylko jedną warstwą. Firma potrzebuje jeszcze podziału odpowiedzialności, procesów, pamięci, kryteriów odbioru, przepływu decyzji, dowodów wykonania oraz granic wyznaczanych przez człowieka. Bez tego wielu agentów może jedynie szybciej produkować więcej pracy pośredniej.

W tym tekście Paperclip oznacza system organizujący pracę wielu agentów. Sprawdzam go na trzech rozwijanych przeze mnie aplikacjach. Featherly jest CMS-em przeznaczonym do budowania stron także z udziałem agentów. Soar jest aplikacją do automatycznego tradingu, którą może skonfigurować człowiek, agent AI albo oboje wspólnie. Roost ma być organizatorem biznesowym. Czytelnik nie musi znać ich architektury — są tutaj trzema różnymi środowiskami testującymi, czy Paperclip potrafi doprowadzić złożoną zmianę do działającego rezultatu.

Pipeline wykonuje proces. Firma musi umieć nim zarządzać

Pojedyncza automatyzacja przypomina linię produkcyjną: dostaje wejście, przechodzi przez opisane kroki i zwraca wynik. To wystarcza, gdy zadanie jest powtarzalne, a jego przebieg został wcześniej zaprojektowany. Nie wystarcza, gdy system ma sam rozpoznać nowy problem, podzielić go, dobrać wykonawców, zweryfikować zależności i poprawić sposób pracy po zakończeniu.

Autonomiczna organizacja powinna nie tylko wykonywać procesy, lecz także tworzyć je wtedy, gdy pojawia się nowy rodzaj pracy. Po każdej iteracji może korzystać z pętli PDCA: zaplanować zmianę, wykonać ją, sprawdzić wynik i poprawić proces na podstawie tego, co rzeczywiście się wydarzyło. Nie chodzi jednak o ciągłe przepisywanie procedur. Poprawa ma wynikać z konkretnego problemu ujawnionego podczas dostarczania produktu.

Dlatego instrukcje przechowuję w plikach Markdown. Agent ma wiedzieć, za co odpowiada, według jakich standardów działa i komu przekazuje wynik. Dobrze opisana rola zmniejsza konieczność wymyślania koła od nowa przy każdym zadaniu. Nie jest jednak cyfrową osobowością pracownika ani gwarancją eksperckości. To konfiguracja odpowiedzialności, kontekstu, dostępu i kryteriów działania.

Z góry zadanie, z dołu dowód wykonania

Zmiana w aplikacji może obejmować wiele miejsc i warstw jednocześnie. Funkcja może mieć część w interfejsie, logikę na backendzie, zapis danych i zależności z innymi przepływami. Gdy prosiłem pojedynczego agenta o lokalną poprawkę, potrafił zmienić wskazany fragment, ale nie zawsze rozpoznawał, co ta zmiana psuje albo czego wymaga w pozostałych warstwach.

Paperclip ma rozwiązać ten problem przez przepływ pracy w dwóch kierunkach. Manager rozbija cel z góry na mniejsze zadania i przekazuje je wyspecjalizowanym agentom. Wykonawcy raportują z dołu do góry nie tylko informację „zrobione”, lecz także dowody: co zmienili, jak sprawdzili rezultat, jakie zależności znaleźli i co nadal blokuje całość. Wyższy poziom zamyka zadanie dopiero wtedy, gdy części składają się w działający przepływ.

Do tego potrzebna jest pamięć stanu. Manager musi wiedzieć, na jakim etapie jest wdrożenie, jakie decyzje już podjęto i które testy zaliczono. Bez pamięci może trzy razy zlecić tę samą pracę albo uznać dokumentację za rezultat, mimo że aplikacja się nie zmieniła. Pamięć nie jest więc magazynem całej możliwej wiedzy. Ma przechowywać stan, dowody i wnioski potrzebne do następnej decyzji.

Dokumentacja nie jest zmianą w produkcie

Najbardziej użyteczna porażka Paperclipa przypomina popularne streszczenie prawa Goodharta: kiedy wskaźnik staje się celem, przestaje być dobrym wskaźnikiem. System miał rozwijać aplikacje, ale znalazł łatwiejszy produkt pośredni — dokumentację. Tworzył opisy aplikacji i własnego działania, ponieważ były czytelnym śladem pracy. Tymczasem w samych aplikacjach niewiele się zmieniało.

Dokumentacja jest potrzebna, jeśli pozwala następnemu agentowi poprawnie wykonać zadanie albo stanowi dowód decyzji. Staje się problemem, gdy jej przyrost zastępuje rezultat. Sto opisanych funkcji nie jest równoważne jednej naprawionej funkcji. Tak samo liczba agentów, zadań i komunikatów nie mówi jeszcze, czy organizacja dostarczyła wartość.

Praktyczny test autonomii musi kończyć się w produkcie. W Featherly takim testem jest usunięcie problemu niestabilnego logowania i sprawdzenie całego przepływu sesji. W Soar funkcja DCA przecina tryby live i paper trading, wiele giełd oraz backtesty, więc lokalna poprawka nie wystarczy. W Roost potrzebne są przekrojowe zmiany UX/UI. Paperclip powinien sam rozpoznać zakres problemu, skoordynować wykonanie i wykazać, że wszystkie istotne ścieżki nadal działają.

System poprawnie zmienił logo Roost na dostarczone SVG. To mały sukces wykonawczy: polecenie zostało zrealizowane. Nie jest jednak jeszcze dowodem autonomicznej organizacji, ponieważ zadanie wskazałem bezpośrednio, a jego zakres był prosty i lokalny. Właściwy test zaczyna się wtedy, gdy system musi wyprowadzić zadania z celu produktu, znaleźć zależności i domknąć zmianę bez ręcznego prowadzenia każdego kroku.

Więcej agentów może oznaczać mniej rezultatu

Wielu agentów ma sens, gdy problem da się podzielić, role wnoszą różne kompetencje, a korzyść z równoległej pracy przewyższa koszt komunikacji. Przy małym zadaniu samo organizowanie niezorganizowanych agentów może trwać dłużej niż bezpośrednie wykonanie pracy.

Badanie 260 konfiguracji agentowych pokazało, że korzyść z wielu agentów zależy od charakteru zadania i architektury, a narzut komunikacyjny w badanych układach wynosił od 58% do 515% względem konfiguracji pojedynczego agenta ([Kim i in., 2026](https://www.nature.com/articles/s42256-026-01268-y)). Nie wynika z tego, że jeden agent jest zawsze lepszy. Wynika, że liczba agentów nie jest skalą dojrzałości.

Inna analiza ponad 1600 śladów wykonania systemów wieloagentowych wyróżniła problemy projektu i specyfikacji, niedopasowanie między agentami oraz błędy weryfikacji i zakończenia pracy. Same poprawki opisów ról i orkiestracji dawały ograniczone efekty ([Cemri i in., 2025](https://arxiv.org/abs/2503.13657)). To ważna granica mojego modelu: instrukcje, hierarchia i raportowanie są potrzebne, ale system musi jeszcze umieć sprawdzić wynik i przestać działać, gdy cel został osiągnięty.

Dobór architektury powinien więc wynikać z problemu. Zmianę logo może wykonać jeden agent. Przekrojowa naprawa funkcji DCA może wymagać managera, programistów odpowiedzialnych za różne warstwy i niezależnego testera. Organizacja jest kosztem, który musi się zwrócić w jakości, czasie albo zdolności objęcia zależności.

Pułapka organizacji, która pracuje nad sobą

Największym problemem Paperclipa nie jest obecnie brak pomysłów na usprawnienia. Jest nim ich nadmiar. Obserwowałem sytuacje, w których około 150 z 200 zadań dotyczyło własnego rozwoju systemu. Organizacja miała tworzyć aplikacje, lecz większość energii zużywała na poprawianie organizacji.

Autorozwój jest formą eksploracji: system szuka lepszych procesów, ról i narzędzi. Praca nad aplikacjami wykorzystuje już posiadane możliwości. James March opisał, że eksploracja i eksploatacja konkurują o te same ograniczone zasoby, choć ich korzyści pojawiają się w różnych momentach ([March, 1991](https://doi.org/10.1287/orsc.2.1.71)). Paperclip nie może więc traktować samodoskonalenia jako darmowego dodatku do pracy produktowej.

Każde usprawnienie organizacji powinno mieć właściciela, ograniczony budżet, hipotezę poprawy i warunek zatrzymania. Musi odpowiadać na wykryty problem: na przykład powtórne zlecanie tej samej pracy, brak testu zależności albo raport bez dowodu. Po wdrożeniu trzeba sprawdzić, czy problem rzeczywiście występuje rzadziej. Jeżeli nie, kolejny raport o autorozwoju tylko powiększa pętlę.

Organizacja nie musi być optymalna, zanim zacznie dostarczać. Ma być wystarczająco dobra, aby wykonać pracę, spełnić kryteria odbioru, nie pozostawić znanego błędu blokującego i pozwolić wrócić do konkretnego usprawnienia po dostarczeniu wartości. To nie jest zgoda na bylejakość. To praktyczne zastosowanie podejścia *satisficing*: przy ograniczonej informacji i zdolności obliczeniowej szuka się rozwiązania spełniającego jawny próg, zamiast niedostępnego optimum ([Simon, 1956](https://iiif.library.cmu.edu/file/Simon_box00063_fld04854_bdl0001_doc0001/Simon_box00063_fld04854_bdl0001_doc0001.pdf)).

Człowiek nadal wyznacza przedsiębiorstwo

Paperclip rozumiem jako zbiór cyfrowych pracowników działających w zaprojektowanym systemie. Nie chcę jednak oddawać mu decyzji o kierunku firmy, jej strategii ani o tym, jakie produkty i funkcjonalności powinny powstać. Te decyzje definiują przedsiębiorstwo i nadal należą do człowieka.

Agenci mają wdrażać ten kierunek jak eksperci: wykrywać niespójności, proponować rozwiązania, koordynować zależności i pokazywać dowody. Mogą usprawniać proces w granicach celu, ale nie powinni zamieniać własnego rozwoju w nową strategię firmy. Okresowy nadzór Codexa może analizować ich pracę i zapisywać wnioski, lecz wdrożenie zmian w organizacji powinno wynikać z jawnej oceny, a nie z automatycznego powiększania systemu.

Autonomia nie oznacza zatem braku człowieka. Oznacza zdolność systemu do domykania coraz większej części pracy bez prowadzenia każdego kroku, przy zachowaniu ustalonego kierunku, obserwowalnych kryteriów i możliwości zatrzymania lub cofnięcia działania.

Autonomię widać po zamkniętej pętli

Nie wiem jeszcze, w którym momencie Paperclip będzie można uczciwie nazwać autonomiczną firmą. Wiem natomiast, czego nie uznam za dowód: liczby agentów, wykonanych zadań, zapisanych tokenów ani stron dokumentacji.

Dowodem będzie zamknięta pętla. System bierze cel wynikający z założeń aplikacji, rozpoznaje pełny zakres zmiany, rozdziela pracę, pamięta stan, zbiera dowody, testuje zależności i zwraca działający rezultat. Dopiero po dostarczeniu wartości poprawia konkretny element własnego procesu, który podczas pracy okazał się niewystarczający.

Jeżeli organizacja potrafi tylko pracować nad sobą, nie jest autonomiczna — jest zapętlona. Jeżeli potrafi wykonywać wyłącznie ręcznie wskazane, lokalne zadania, jest narzędziem. Autonomiczna firma zaczyna się pomiędzy tymi skrajnościami: tam, gdzie wielu wyspecjalizowanych agentów potrafi zamienić kierunek wyznaczony przez człowieka w sprawdzalną zmianę w rzeczywistości.

Praktyczny próg autonomii

Aktywności agentów nie należy uznawać za postęp, dopóki system nie potrafi przedstawić sześciu elementów: jasno nazwanego problemu i oczekiwanego rezultatu, dowodu działania, kontroli zależnych funkcji i przepływów, jawnego bilansu między pracą trafiającą do produktu a dokumentacją i autorozwojem, warunku zatrzymania oraz uzasadnienia, że koszt koordynacji wielu agentów jest mniejszy niż wartość, którą ta koordynacja wnosi.

Te elementy nie tworzą uniwersalnej recepty na każdą organizację. Są minimalnym mechanizmem rozróżniającym system, który dostarcza rezultat, od systemu, który jedynie wytwarza ślady aktywności. Pozwalają też wybrać architekturę adekwatną do problemu: czasem będzie nią jeden agent, czasem wyspecjalizowany zespół, a czasem człowiek wspierany przez kilka narzędzi.

Jeżeli system nie potrafi pokazać wyniku, dowodów, granic i kosztu własnego działania, jego autonomia może być tylko nazwą. Jeżeli potrafi zamienić kierunek wyznaczony przez człowieka w działającą zmianę, sprawdzić jej konsekwencje i zatrzymać się po spełnieniu kryteriów, można oceniać go jak organizację — po tym, co zmienił w rzeczywistości.

Bibliografia

• Yubin Kim i in., „Capable language models can outgrow the benefits of collaboration”, *Nature Machine Intelligence* 8, 2026, [artykuł](https://www.nature.com/articles/s42256-026-01268-y), dostęp 2026-09-04.
• Mert Cemri i in., „Why Do Multi-Agent LLM Systems Fail?”, arXiv:2503.13657, wersja 3, 2025, [preprint](https://arxiv.org/abs/2503.13657), dostęp 2026-09-04.
• James G. March, „Exploration and Exploitation in Organizational Learning”, *Organization Science* 2(1), 1991, [DOI](https://doi.org/10.1287/orsc.2.1.71), dostęp 2026-09-04.
• Herbert A. Simon, „Rational Choice and the Structure of the Environment”, *Psychological Review* 63(2), 1956, [PDF](https://iiif.library.cmu.edu/file/Simon_box00063_fld04854_bdl0001_doc0001/Simon_box00063_fld04854_bdl0001_doc0001.pdf), dostęp 2026-09-04.