Od ponad roku buduję agentów AI, którzy działają realnie w firmach: własne skille, harness do pracy, systemy, w których jeden model planuje, drugi wykonuje, a trzeci sprawdza wynik. Im dłużej to robię, tym częściej mam wrażenie déjà vu. Problemy, które rozwiązuję, wyglądają jak żywcem wyjęte z podręcznika do zarządzania.
Nie mówię tu o agencie, którego ktoś odpala sobie na własnym laptopie do drobnych zadań. Mam na myśli systemy agentowe, które pracują w firmie na produkcji i są dostępne dla całej organizacji. Część z nich działa w pełni autonomicznie, część pod nadzorem człowieka (human in the loop). A to zupełnie inna skala niż pojedyncze narzędzie dla jednej osoby. Taki agent staje się pełnoprawnym wykonawcą, któremu firma powierza prawdziwe zadania, dostęp do danych i systemów oraz odpowiedzialność za wynik.
Podobny temat opisałem już trochę w tekście Architektura agentowego AI została rozwiązana w 1949. Od tamtej pory mam więcej doświadczenia i więcej przemyśleń, pojawiły się też “loops”, dlatego chcę opisać to na nowo.
W tym wpisie pokażę, że to nie przypadek. Większość pojęć z agent engineeringu ma swój starszy odpowiednik w teorii zarządzania, cybernetyce i zarządzaniu jakością. Opiszę najmocniejsze analogie, a na koniec to, co w agentach jest naprawdę nowe.
Jaka jest główna teza?
Postawię ją wprost:
Agent engineering to w dużej części zarządzanie organizacją, w której wykonawcą nie jest człowiek, tylko model językowy.
Gdy program był deterministyczny, wystarczał kod. Gdy “program” sam planuje, wybiera narzędzia, popełnia błędy i wymaga nadzoru, zaczynamy potrzebować tego samego, czego firmy potrzebują do zarządzania ludźmi: celów, ról, uprawnień, kontroli, raportowania, oceny i pętli poprawy.
Najkrócej całość można zapisać tak:
- model jest wykonawcą,
- prompt jest poleceniem,
- context jest informacją,
- narzędzia są zasobami i uprawnieniami,
- harness jest systemem zarządzania,
- evals są kontrolą jakości,
- system wieloagentowy jest organizacją.
Skąd wzięło się słowo “agent”?
To jest moja ulubiona część, bo pokazuje, że branża AI nie wymyśliła nowej nazwy, tylko sięgnęła po pojęcie, które teoria opisała 50 lat temu.
Teoria agencji (Jensen i Meckling, 1976) opisuje relację principal-agent. Powierzam zadanie komuś, kto wie o swojej pracy więcej niż ja (asymetria informacji), kto może optymalizować pod siebie zamiast pod mój cel (hazard moralny), więc muszę projektować bodźce, monitoring i kontrakty. Branża AI odkrywa dziś dokładnie te same koszty agencji, tylko nazywa je “alignment tax” i “oversight”.
Jest tu jedna ważna różnica, do której wrócę na końcu. Człowiek może świadomie działać we własnym interesie. Agent AI częściej zawodzi przez źle opisany cel, brak informacji, błędną interpretację instrukcji albo przez to, że do danego zadania dobrano zły model.
Warto dodać dwa inne korzenie:
- reward hacking, czyli agent optymalizujący benchmark zamiast realnego celu, to prawo Goodharta i klasyczna patologia KPI. Pracownik grający system premiowy robi dokładnie to samo,
- orchestration i systemy wieloagentowe mają korzeń w cybernetyce zarządzania. Stafford Beer już w latach 70. rozpisał architekturę z jednostkami operacyjnymi, koordynacją, kontrolą i sygnałami eskalacji. To niemal jeden do jednego dzisiejsze diagramy orkiestratorów z sub-agentami.
Czym prowadzenie agenta przypomina prowadzenie pracownika?
Kiedy zamienisz w głowie słowo “agent” na słowo “pracownik”, większość pojęć nagle staje się oczywista. Poniżej najmocniejsze pary.
| Pojęcie w AI | Po zamianie na człowieka | Znane pojęcie |
|---|---|---|
| System prompt | Stałe zasady roli | Opis stanowiska, zakres obowiązków, regulamin |
| User prompt / task | Konkretne zlecenie | Brief, polecenie służbowe, work order |
| Context engineering | Dobór informacji do zadania | Briefing i przepływ informacji |
| RAG / knowledge base | Dostęp do dokumentacji podczas pracy | Baza wiedzy, procedury, instrukcje |
| Tool access | Dostęp do systemów i pieniędzy | Przydzielenie zasobów i uprawnień |
| Fine-tuning | Trwała zmiana zachowań | Szkolenie i rozwój kompetencji |
Zwróć uwagę na jedną rzecz. “Lepszy prompt” rzadko jest odpowiednikiem bardziej motywującej przemowy. Częściej jest odpowiednikiem lepszego briefu, dokładniejszej instrukcji, łatwiejszego dostępu do wiedzy i jaśniejszego standardu wyniku. To jest praca menedżera, a nie mówcy motywacyjnego.
Osobny przykład to skille. Agent skill to gotowy zestaw instrukcji, narzędzi i przykładów pod konkretny typ pracy. W firmie nazwalibyśmy to procedurą operacyjną, playbookiem albo pakietem kompetencji.
Jak wygląda nadzór i kontrola nad agentem?
To obszar, w którym IT dopiero układa reguły, które bankowość i audyt mają rozpisane od dekad.
- human-in-the-loop to zasada czterech oczu i matryca uprawnień. Ktoś od dawna ustalił, które decyzje wymagają kontrasygnaty, a które nie. My dopiero układamy, które wywołania narzędzi wymagają zatwierdzenia,
- eskalacja agenta do człowieka to zarządzanie przez wyjątki. Podwładny działa autonomicznie w ramach norm i raportuje tylko odchylenia,
- guardrails to kontrola wewnętrzna, segregacja obowiązków i poka-yoke z lean, czyli takie zbudowanie stanowiska, żeby błąd był niemożliwy albo od razu widoczny,
- observability i tracing to controlling, ścieżka audytowa i raportowanie zarządcze,
- poziomy autonomii agenta to kontinuum delegowania i przywództwo sytuacyjne. Skala “tell, sell, consult, delegate” jest gotowa: od “agent proponuje, człowiek zatwierdza” aż po pełną autonomię, dobieraną do dojrzałości wykonawcy.
Wraca tu też znana myśl Deminga. Kontrola jakości na końcu procesu jest gorsza niż jakość wbudowana w sam proces. W języku agentów: lepszy prompt zwykle bije walidator na wyjściu.
Dlaczego zespół agentów to projekt organizacji?
Kiedy budujesz system wieloagentowy, nie piszesz tylko kodu. Podejmujesz klasyczne decyzje organizacyjne.
| Pojęcie w AI | Po zamianie na człowieka | Znane pojęcie |
|---|---|---|
| Multi-agent system | Zespół specjalistów | Struktura organizacyjna |
| Orchestrator / router | Osoba przydzielająca zadania | Kierownik, dyspozytor, koordynator |
| Handoff | Przekazanie zadania dalej | Przekazanie między działami lub etapami |
| Planner-worker-reviewer | Rozdzielone role | Rozdział obowiązków, maker-checker |
| Specialized agent | Specjalista od jednego typu pracy | Podział pracy Adama Smitha |
| Agent swarm | Grupa dzieląca się zadaniami | Zespół samoorganizujący się |
Tworząc taki system, odpowiadasz na te same pytania, co przy projektowaniu firmy:
- które role wydzielić,
- kto komu przekazuje pracę,
- kto odpowiada za wynik,
- kto może podejmować decyzje,
- kto sprawdza jakość,
- kiedy problem ma trafić wyżej,
- ilu wykonawców może nadzorować jeden koordynator (klasyczny spór o rozpiętość kierowania).
Sam widzę to w praktyce. Zespół agentów bez podziału ról i odpowiedzialności zachowuje się jak zespół ludzi w takiej samej sytuacji. Dubluje pracę, wchodzi sobie w drogę i gubi wynik. Dlatego role Belbina, fazy Tuckmana i macierz RACI nagle stają się przydatne przy projektowaniu systemów agentowych.
Jak agenci uczą się i doskonalą?
Tu najciekawsza jest relacja z uczeniem dwupętlowym, które Chris Argyris opisał w 1977 roku.
- single-loop: agent źle wykonał zadanie, więc poprawiamy prompt,
- double-loop: być może samo zadanie, KPI albo reguła były źle zdefiniowane, więc zmieniamy założenia całego systemu.
Branża AI dochodzi do tego przez “eval-driven harness improvement”, czyli poprawianie nie tylko instrukcji, ale i całej struktury pracy. Kilka innych par z tego obszaru:
- reflection agenta to after-action review, metoda przeglądu po działaniu,
- evals z błędów produkcyjnych to lessons learned,
- red-team agent to advocatus diaboli, audyt wewnętrzny i war-gaming,
- retry i error recovery to działania korygujące i procedury awaryjne.
Jedna ważna uwaga o evalach. Eval nie sprawdza samego modelu. Sprawdza cały układ: model, instrukcje, narzędzia i sposób pracy. Dlatego bliżej mu do audytu całego procesu niż do oceny jednego pracownika.
Co w agentach jest naprawdę nowe?
Nie chcę przesadzić z tezą, że to tylko odkrywanie koła na nowo. Kilka rzeczy jest realnie nowych:
- można zapisać całą strukturę zarządzania w kodzie,
- można kopiować “pracowników” prawie bez kosztu,
- można uruchomić wiele kopii równolegle,
- można błyskawicznie zmieniać role i strukturę zespołu,
- można zapisać niemal każdą czynność, co przy ludziach jest niemożliwe,
- dochodzą problemy wynikające z probabilistycznego działania modeli oraz ataki przez instrukcje, takie jak prompt injection.
Natomiast problemy nadrzędne są stare. Jak określić dobry cel, jak delegować, jak mierzyć wynik, jak kontrolować ryzyko, jak przekazywać wiedzę, jak podzielić role, jak wykrywać błędy i jak poprawiać proces. To wszystko teoria zarządzania rozpisała dawno temu.
Jest jeszcze jedna obserwacja, która mnie samego zaskoczyła. Branża AI nie odtwarza losowych fragmentów historii, tylko całą jej sekwencję. Najpierw taylorowski nadzór nad każdym krokiem (approval na każde wywołanie narzędzia), potem odkrycie, że to się nie skaluje, i przejście do zarządzania przez cele i wyjątki. Agenci przechodzą przyspieszony kurs XX-wiecznej teorii organizacji.
Podsumowanie
Jeśli budujesz dziś systemy agentowe, warto patrzeć na nie szerzej niż tylko przez kod i modele. Pomagają w tym starsze dziedziny:
- teorię zarządzania i teorię organizacji,
- cybernetykę i teorię sterowania,
- zarządzanie jakością, lean i PDCA,
- teorię principal-agent i corporate governance,
- zarządzanie procesami i projektami,
- zarządzanie wiedzą i human factors.
Moim zdaniem to praktyczna wskazówka, a nie ciekawostka. Zamiast wymyślać od zera reguły eskalacji, uprawnień czy podziału ról, możesz sięgnąć po rozwiązania, które sprawdzały się w organizacjach od dekad. Model jest wykonawcą, harness jest systemem zarządzania, a system wieloagentowy jest organizacją. Reszta to znane problemy w nowym przebraniu.
