Nadzór człowieka w agentic engineering: gdzie osadzić punkt kontroli

Najczęstszy błąd we wdrożeniach agentowych nie polega na braku nadzoru. Polega na tym, gdzie ten nadzór postawiono. Zespół buduje agenta, który planuje, korzysta z narzędzi i wykonuje wieloetapowe zadania, a na sam koniec dokleja przycisk „zatwierdź“ albo „zatrzymaj awaryjnie“ — i nazywa to nadzorem człowieka. Problem w tym, że w chwili, gdy ktoś sięga po ten przycisk, agent zwykle już zrobił to, co miało być kontrolowane: wysłał wiadomość do klienta, zapisał rekord w bazie, zainicjował transakcję. Kontrola na końcu chroni najwyżej przed kontynuacją błędu. Nie chroni przed jego popełnieniem.

Ten tekst jest o tym, jak postawić nadzór wewnątrz procesu inżynierskiego budowy agenta, a nie obok niego. Agentic engineering — dyscyplina projektowania, budowy, ewaluacji i utrzymania agentów działających niezawodnie w produkcji — ma swój własny cykl: cel, kontekst, harness (środowisko wykonania i narzędzia), pamięć i ewaluacja. Pokażę, gdzie w każdej z tych warstw umieścić punkt, w którym człowiek naprawdę decyduje, jak zaprojektować próg pewności decydujący o eskalacji, i jak to wszystko spina się z obowiązkiem nadzoru z artykułu 14 AI Act oraz prawem z artykułu 22 RODO.

Gdzie w cyklu agentic engineering umieścić punkt nadzoru człowieka?

Krótka odpowiedź: nadzór nad agentem nie jest jednym punktem, tylko rozproszonym zestawem checkpointów wbudowanych w każdą warstwę cyklu inżynierskiego — w definicję celu i granic, w dobór kontekstu, w bramki harnessu przed działaniami nieodwracalnymi, w zapis do pamięci długoterminowej i w pętlę ewaluacji — z jednym dodatkowym mechanizmem spinającym całość: progiem pewności, który decyduje, kiedy konkretna sprawa ma trafić do człowieka zamiast zostać rozwiązana automatycznie.

Z tego wynika reguła przewodnia całego tekstu: im wcześniej w cyklu budowy agenta osadzisz punkt kontroli, tym tańszy w skutkach jest błąd, który ten punkt wyłapie. Checkpoint przy definicji celu kosztuje jedną rozmowę przed startem projektu. Checkpoint przy harnessu kosztuje jedno kliknięcie zgody przed operacją. Przycisk awaryjny na samym końcu kosztuje już naprawianie szkody, która się wydarzyła. To nie jest różnica kosmetyczna — to różnica między nadzorem, który zapobiega, a nadzorem, który tylko rejestruje.

Czym właściwie jest agentic engineering — i czym nie jest?

Zanim rozłożymy nadzór na warstwy, warto uczciwie nazwać przedmiot tego tekstu, bo wokół „agentic“ narosło sporo pojęciowego bałaganu. Agentic engineering to dyscyplina inżynierska projektowania, budowania, ewaluowania i operowania agentami AI niezawodnie w środowisku produkcyjnym — nie pojedynczy prompt, tylko cały cykl życia systemu, który działa wobec wyznaczonego celu, a nie tylko odpowiada na jedno polecenie.

To rozróżnienie pojęć jest tu kluczowe, bo bez niego łatwo pomylić warstwy i wsadzić nadzór w niewłaściwe miejsce. Prompt engineering to praca nad pojedynczą wiadomością do modelu — zachowaniem w jednej turze. Inżynieria kontekstu to już coś szerszego: cała architektura informacji, którą model widzi — pobrane dokumenty, wyniki narzędzi, historia rozmowy, schematy danych. Orkiestracja agentów to warstwa narzędziowa, frameworki koordynujące wielu agentów w układzie orchestrator-worker, gdzie jeden agent dzieli cel na podzadania i syntetyzuje wyniki — to narzędzia, nie samodzielna dyscyplina. Agentic engineering spina to wszystko w jeden proces inżynierski: cel, kontekst, harness (wykonanie, narzędzia, obserwowalność, weryfikację), pamięć i ewaluację — od prototypu do agenta, któremu można zaufać w produkcji.

Warto tu od razu rozbroić popularny mit: zespoły, które faktycznie odnoszą sukces we wdrożeniach produkcyjnych, inwestują więcej w prompt i inżynierię kontekstu niż w złożoność samej orkiestracji. Orkiestracja jest narzędziem do koordynacji pracy, nie celem samym w sobie — i nadzór człowieka nie powinien być traktowany jak jeszcze jeden węzeł w grafie orkiestracji, tylko jak warunek brzegowy całego procesu.

Skala tego zjawiska w 2026 roku jest spora, choć warto podawać ją z zastrzeżeniem, bo to szacunki branżowe, a nie dane audytowane. Według raportów sektorowych z tego roku nawet 40% aplikacji korporacyjnych ma mieć wbudowane wyspecjalizowane agenty AI do końca 2026 roku, wobec mniej niż 5% jeszcze rok wcześniej — to tempo wzrostu, przy którym łatwo o pośpiech kosztem jakości nadzoru. Około 31% przedsiębiorstw deklaruje już co najmniej jednego agenta w produkcji, z bankowością i ubezpieczeniami na czele z udziałem sięgającym blisko połowy organizacji w branży. Jednocześnie 62% firm eksperymentuje z agentami, ale tylko 23% realnie skaluje wdrożenie w choćby jednej funkcji biznesowej — reszta utyka między pilotażem a produkcją. Część analiz branżowych, cytowanych szeroko jako prognoza w stylu Gartnera, wskazuje nawet, że ponad 40% projektów agentowych może zostać anulowanych do końca 2027 roku z powodu rosnących kosztów, niejasnej wartości biznesowej lub niedostatecznej kontroli ryzyka. Ten ostatni punkt — niedostateczna kontrola ryzyka — jest wprost o tym, co dalej opisuję: o nadzorze, który nie nadąża za tempem budowy.

Dlaczego przycisk awaryjny na końcu nie jest nadzorem?

Wyobraź sobie typowy projekt: zespół buduje agenta obsługi zwrotów, agenta triage’ującego zgłoszenia albo agenta zarządzającego zapasami. Model działa, testy przechodzą, a na końcu ktoś dodaje panel administracyjny z przyciskiem „zatrzymaj agenta“ i polem do ręcznego cofnięcia decyzji. Zespół prezentuje to jako „człowieka w pętli“. W rzeczywistości to jest coś innego: nadzór dołożony post factum, projektowany jako ostatnia linia obrony, a nie jako część procesu podejmowania decyzji.

Problem ma dwa wymiary. Pierwszy jest czasowy: przycisk działa dopiero po tym, jak agent już wykonał działanie. Jeśli agent ma uprawnienia do wysłania e-maila, zmiany rekordu w systemie CRM albo zainicjowania zwrotu środków, to w chwili, gdy człowiek zauważa problem, skutek często już zaistniał. Nadzór, który reaguje po fakcie, jest w najlepszym razie mechanizmem ograniczania szkód, a nie mechanizmem ich zapobiegania — to zupełnie inna kategoria kontroli, choć w dokumentacji projektu obie bywają nazywane tym samym słowem.

Drugi wymiar jest behawioralny i dobrze znany z ogólnego projektowania współpracy człowiek–AI: przycisk dołożony na końcu procesu, bez wbudowanego kontekstu i bez regularnego kontaktu operatora ze sprawą, szybko zamienia się w teatr nadzoru — jest, ale nikt go realnie nie używa, bo nikt nie ma czasu ani danych, by ocenić, kiedy warto go nacisnąć. To dokładnie ten sam mechanizm, który opisałem szerzej przy okazji rzeczywistego nadzoru człowieka nad AI: obecność człowieka obok systemu niczego nie gwarantuje, jeśli interfejs i proces nie dają mu realnej szansy na ocenę.

Wniosek stąd jest prosty, choć wymaga zmiany nawyku projektowego: nadzór trzeba projektować razem z architekturą agenta, od pierwszego dnia, a nie doklejać po zbudowaniu. To oznacza pytanie nie „gdzie wstawić przycisk stop“, tylko „w których miejscach cyklu inżynierskiego agent w ogóle powinien czekać na człowieka, zanim zrobi kolejny krok“.

Pięć miejsc w cyklu inżynierskim, gdzie osadzić checkpoint

Poniżej rozkładam cykl agentic engineering na pięć warstw i pokazuję, jaki konkretnie checkpoint pasuje do każdej z nich. To nie jest lista opcjonalna — pominięcie jednej warstwy zwykle oznacza, że nadzór w pozostałych czterech i tak zawiedzie, bo błąd wejdzie do systemu tam, gdzie nikt go nie pilnował.

Cel: co agent w ogóle ma robić i czego mu nie wolno

Pierwszy checkpoint nie dotyczy pojedynczej decyzji agenta, tylko samego zakresu jego działania. Zanim agent zacznie pracować, człowiek powinien zatwierdzić trzy rzeczy: cel w mierzalnej formie, twarde granice tego, czego agent nigdy nie może zrobić bez zgody, oraz kryteria sukcesu, wobec których będzie oceniana jego praca. To jest warstwa człowieka w dowodzeniu (in-command) z klasycznego podziału modeli nadzoru — decyzja o tym, czy dany agent w ogóle powinien zostać uruchomiony i w jakim zakresie, a nie ocena pojedynczego wyniku.

W praktyce ten checkpoint najczęściej ginie, bo zespoły techniczne traktują go jako etap planowania projektu, a nie jako element nadzoru — a to błąd. Granica typu „agent nie inicjuje zwrotów powyżej 500 zł bez zgody człowieka“ albo „agent nie wysyła wiadomości do klientów oznaczonych jako spór prawny“ to realny mechanizm kontroli, tyle że osadzony na starcie, nie w locie. Im precyzyjniej te granice są zapisane — najlepiej w formie, którą da się potem zaimplementować jako twardą regułę w harnessu, a nie tylko jako wytyczną w dokumencie — tym mniej sytuacji w ogóle dotrze do etapu, w którym trzeba by je łapać później.

Kontekst: co agent widzi i skąd to bierze

Druga warstwa to inżynieria kontekstu — cała architektura informacji, którą agent dostaje: dokumenty źródłowe, wyniki wywołań narzędzi, historia poprzednich interakcji, dostęp do baz danych. Checkpoint na tym poziomie odpowiada na pytanie: czy człowiek zatwierdził, jakie źródła danych i jaki zakres uprawnień dostępu agent w ogóle otrzymuje, zanim zacznie z nich korzystać?

To miejsce jest łatwe do przeoczenia, bo wygląda jak decyzja czysto techniczna — „podłączamy agenta do tej bazy danych“ — a w rzeczywistości jest decyzją o ryzyku. Agent, który dostaje szerszy dostęp do danych niż potrzebuje do realizacji celu, zwiększa powierzchnię błędu bez żadnej korzyści biznesowej. Dobra praktyka to zasada najmniejszego niezbędnego zakresu: kontekst agenta obejmuje dokładnie te źródła i te uprawnienia, które są potrzebne do konkretnego zadania, a rozszerzenie tego zakresu wymaga osobnej zgody człowieka, a nie dzieje się przy okazji kolejnej iteracji rozwoju produktu. Ten sam mechanizm chroni też przed cichym dryfem: agent, który miał dostęp tylko do odczytu, z czasem „dostaje“ też zapis, bo ktoś to uprościł dla wygody wdrożenia — a to jest dokładnie ten typ zmiany, który powinien przechodzić przez punkt kontroli, nie obok niego.

Harness: bramka zgody przed działaniem nieodwracalnym

Trzecia warstwa to harness — środowisko wykonania, narzędzia, którymi agent dysponuje, oraz mechanizmy obserwowalności i weryfikacji jego działań. To tutaj znajduje się najważniejszy z pięciu checkpointów, bo to jedyne miejsce w cyklu, w którym kontrola działa dokładnie w momencie, w którym można jeszcze zapobiec skutkowi, a nie wcześniej (planowanie) ani później (ewaluacja po fakcie).

Praktyczny wzorzec: każde działanie agenta, które jest kosztowne do cofnięcia — płatność, wysyłka wiadomości na zewnątrz organizacji, zmiana uprawnień, usunięcie danych — przechodzi przez bramkę zatwierdzenia wbudowaną w sam harness, a nie w interfejs administracyjny dołożony obok. Różnica jest fundamentalna: bramka w harnessu oznacza, że agent technicznie nie może wykonać operacji bez zgody, bo wywołanie narzędzia jest zablokowane na poziomie uprawnień, a nie że ktoś powinien to sprawdzić, zanim agent zadziała. Pierwsze jest architekturą; drugie jest nadzieją.

To miejsce jest też naturalnym punktem, w którym osadza się próg pewności decydujący o eskalacji — omawiam go osobno w kolejnej sekcji, bo zasługuje na własne, dokładniejsze rozwinięcie.

Pamięć: co staje się precedensem na przyszłość

Czwarta warstwa bywa pomijana najczęściej, a jest szczególnie niebezpieczna, bo błąd popełniony tutaj się powiela. Agent z pamięcią długoterminową — czy to w formie zapisanych podsumowań poprzednich spraw, czy w formie danych trafiających z powrotem do dostrajania modelu — uczy się na podstawie tego, co wcześniej zrobił. Jeśli błędna decyzja albo błędna korekta trafi bez przeglądu do pamięci, staje się nie jednorazową pomyłką, tylko wzorcem, który agent będzie powielał w kolejnych, podobnych sprawach.

Checkpoint w tej warstwie oznacza: człowiek przegląda, co konkretnie zapisuje się jako trwała wiedza agenta, zanim to się stanie, a przynajmniej regularnie audytuje próbkę tego, co już zostało zapisane. Dotyczy to zwłaszcza sytuacji, w których agent „uczy się“ na poprawkach człowieka — jeśli ktoś raz zaakceptuje skrót myślowy albo wyjątek od reguły pod presją czasu, a system zapamięta to jako nowy standard, powstaje cichy dryf, który trudno wykryć inaczej niż przez systematyczny przegląd pamięci. To jest też miejsce, w którym granica z warstwy „cel“ powinna działać jako filtr: nic, co narusza zdefiniowane wcześniej granice działania, nie powinno móc zostać zapisane jako precedens, niezależnie od tego, kto i w jakim pośpiechu to zaakceptował.

Ewaluacja: pętla, która wyłapuje dryf, a nie tylko pojedynczy błąd

Piąta warstwa różni się od poprzednich tym, że nie dotyczy pojedynczej decyzji, tylko zachowania systemu w czasie. Ewaluacja w agentic engineering to nie jednorazowy test przed wdrożeniem, tylko ciągła pętla: regularne próbkowanie decyzji agenta, sprawdzanie, czy jego pewność jest nadal rzetelnie skalibrowana, i wychwytywanie sytuacji, w których zachowanie zaczyna odbiegać od tego, co zakładano na starcie.

Checkpoint w tej warstwie to człowiek recenzujący próbkę wyników agenta regularnie, a nie tylko wtedy, gdy coś już poszło źle. W praktyce oznacza to zestaw eval, w którym część przypadków jest oceniana przez ludzi, porównanie odsetka eskalacji i odrzuceń w czasie, oraz alarmowanie, gdy rozkład pewności agenta zaczyna się przesuwać — na przykład agent zaczyna być „pewny“ w sytuacjach, w których wcześniej prawidłowo się wahał. To jest bezpośrednie przeniesienie na poziom inżynierski tego, co w AI Act nazywa się świadomością ryzyka nadmiernego zaufania automatowi: tu problem nie dotyczy jednego operatora ufającego zbyt mocno agentowi, tylko całego systemu, który z czasem może zacząć ufać sam sobie bardziej, niż na to zasługuje.

Jak zaprojektować próg pewności decydujący o eskalacji?

Wszystkie pięć checkpointów opisanych wyżej to punkty stałe, wbudowane w architekturę. Próg pewności (confidence threshold) jest inny — to mechanizm dynamiczny, który na bieżąco decyduje, czy konkretna sprawa zostaje przy agencie, czy trafia do człowieka. To jest serce warstwy harnessu i jednocześnie najczęściej źle projektowany element całego układu.

Pierwsza zasada: próg nie powinien być jedną liczbą dla całego systemu. Agent obsługujący dziesiątki typów zadań o bardzo różnej stawce potrzebuje progów dopasowanych do konkretnego zadania, nie globalnego ustawienia „eskaluj poniżej 80% pewności“. Zwrot towaru za 50 zł i zmiana limitu kredytowego mają zupełnie inny profil ryzyka, nawet jeśli model deklaruje dla obu identyczną pewność. Praktyczna heurystyka: im trudniej cofnąć skutek decyzji i im wyższa stawka dla osoby po drugiej stronie, tym wyższy próg pewności potrzebny, by agent w ogóle mógł działać samodzielnie — a dla decyzji nieodwracalnych i wysokiej stawki checkpoint powinien być obowiązkowy niezależnie od deklarowanej pewności modelu.

Druga zasada dotyczy samej liczby, nie tylko jej progu: pewność musi być rzetelnie skalibrowana, inaczej cały mechanizm jest fasadą. Jeśli agent zwraca „92% pewności“, to wśród takich przypadków realnie około 92% powinno okazywać się trafnych. Modele bywają pewne siebie i jednocześnie w błędzie, zwłaszcza w sytuacjach odstających od danych, na których się uczyły — dlatego dobra architektura eskalacji nie polega wyłącznie na progu liczbowym, tylko łączy go z wykrywaniem nowości: sytuacja, która wygląda inaczej niż większość przypadków w danych treningowych, powinna eskalować niezależnie od tego, jak pewny brzmi model.

Trzecia zasada to monitorowanie progu w czasie, nie ustawienie go raz na zawsze. Odsetek eskalacji i odsetek przypadków, w których człowiek zmienia decyzję agenta po eskalacji, to dwa najważniejsze sygnały zdrowia progu. Jeśli eskalacji jest bardzo mało, a jednocześnie zdarzają się głośne błędy, próg jest ustawiony zbyt nisko — agent zatrzymuje dla siebie sprawy, których nie powinien. Jeśli człowiek regularnie zatwierdza to, co agent i tak by zrobił, bez żadnych korekt, próg może być zbyt wysoki i tylko marnuje czas ludzi na sprawy, które faktycznie są rutynowe. Ten sam wzorzec pomiaru — odsetek edycji i odrzuceń jako sygnał zdrowia nadzoru, a nie tylko czas obsługi — opisałem szerzej przy projektowaniu współpracy człowiek–AI; tu stosuje się go nie do pojedynczego ekranu, tylko do całego mechanizmu eskalacji agenta.

Ostatnia zasada, łatwa do przeoczenia: eskalacja bez kontekstu jest bezużyteczna. Sprawa, która trafia do człowieka, powinna nieść ze sobą to, co agent już ustalił, czego nie jest pewien i dlaczego akurat ta sprawa przekroczyła próg — nie gołą prośbę o decyzję. Człowiek, który dostaje sprawę bez tła, w praktyce zaczyna od zera, co unieważnia całą wcześniejszą pracę agenta i sprawia, że eskalacja jest droższa, niż powinna być.

Co na to AI Act art. 14 i RODO art. 22?

Podejście opisane w tym tekście — checkpointy wbudowane w cykl inżynierski, a nie doklejone na końcu — nie jest wymysłem stylistycznym. To praktyczna realizacja wymogów prawa, które akurat w tym punkcie jest zaskakująco zgodne z dobrą inżynierią.

Artykuł 14 AI Act wymaga, by systemy wysokiego ryzyka dało się skutecznie nadzorować, i sprowadza to do czterech zdolności: zrozumieć system, monitorować jego działanie, nadpisać jego wynik oraz go zatrzymać. Rozłożone na cykl agentic engineering, te cztery zdolności mapują się wprost na warstwy opisane wyżej. Zrozumienie wynika z przejrzystości warstwy celu i kontekstu — człowiek wie, po co agent działa i na jakich danych. Monitorowanie to warstwa ewaluacji — ciągła pętla, a nie jednorazowy test. Nadpisanie to próg pewności i eskalacja — realna, tania droga, by sprawa trafiła do człowieka, zanim zapadnie decyzja. Zatrzymanie to bramka w harnessu — techniczna niemożność wykonania działania bez zgody, nie tylko formalna możliwość interwencji.

Ta zgodność nie jest przypadkowa: artykuł 14 opisuje, jak ma wyglądać system, który daje się nadzorować — a system agentowy zbudowany z checkpointami wbudowanymi w każdą warstwę cyklu jest właśnie takim systemem, niezależnie od tego, czy projektowano go z myślą o zgodności prawnej, czy wyłącznie o niezawodności. Warto pamiętać o harmonogramie: obowiązki przejrzystości z artykułu 50 obowiązują od 2 sierpnia 2026 roku, a pełne wymogi dla systemów wysokiego ryzyka z artykułu 14, w ramach pakietu Digital Omnibus, przesunięto na 2 grudnia 2027 roku dla samodzielnych systemów z załącznika III. To nie powód, by odkładać projektowanie checkpointów — agentic engineering i tak wymaga ich do niezawodności w produkcji, prawo tylko czyni je obowiązkiem tam, gdzie stawka jest najwyższa.

Osobną, starszą podstawą jest artykuł 22 RODO, który daje osobie prawo, by nie podlegać decyzji opartej wyłącznie na zautomatyzowanym przetwarzaniu, jeśli wywołuje ona skutki prawne lub podobnie istotnie na nią wpływa. Dla agenta, który na przykład ocenia wnioski klientów albo ustala warunki umowy, oznacza to konkret: checkpoint w warstwie harnessu przy decyzjach o istotnym skutku nie jest opcjonalnym usprawnieniem architektury, tylko warunkiem, by decyzja w ogóle mogła zostać uznana za nieautomatyczną. Mechaniczne zatwierdzenie przez człowieka bez realnej możliwości zmiany wyniku tego warunku nie spełnia — a to jest dokładnie ta sama granica między augmentacją a cichym zastąpieniem, którą opisałem przy okazji projektowania punktu decyzji.

Wzorce i antywzorce osadzania nadzoru w cyklu inżynierskim

Warstwa cyklu	Wzorzec (rób tak)	Antywzorzec (unikaj)
Cel	Granice i kryteria sukcesu zatwierdzone przed startem, zapisane jako reguły do wdrożenia	Cel opisany ogólnikowo, granice ustalane w locie przez zespół deweloperski
Kontekst	Najmniejszy niezbędny zakres dostępu, rozszerzenie wymaga osobnej zgody	Szeroki dostęp „na zapas“, bo tak wygodniej wdrożyć
Harness	Techniczna bramka zgody przed działaniem nieodwracalnym, wbudowana w uprawnienia	Panel administracyjny z przyciskiem stop dołożony po zbudowaniu agenta
Pamięć	Przegląd tego, co staje się trwałym precedensem, przed zapisem	Agent uczy się cicho na każdej akceptowanej poprawce, bez audytu
Ewaluacja	Ciągła pętla z próbkowaniem przez ludzi i monitorowaniem kalibracji pewności	Test jednorazowy przed wdrożeniem, potem brak systematycznej kontroli
Próg eskalacji	Zróżnicowany wg stawki zadania, monitorowany, przekazuje pełny kontekst sprawy	Jedna globalna liczba procentowa, ustawiona raz i zapomniana

Najgroźniejszy antywzorzec nie mieści się w jednym wierszu tabeli, bo dotyczy całości: traktowanie nadzoru jako etapu projektu, a nie jako części architektury. Zespół, który najpierw buduje agenta, a dopiero potem „dodaje nadzór“, nieuchronnie doda go tam, gdzie jest najłatwiej — czyli na końcu, w formie przycisku. Zespół, który od pierwszego szkicu architektury pyta, gdzie w cyklu cel–kontekst–harness–pamięć–ewaluacja siedzi punkt kontroli, buduje system, w którym nadzór jest strukturalny, a nie kosmetyczny.

Co z tego wynika w praktyce?

Nadzór człowieka nad agentem AI nie jest funkcją, którą dokłada się na końcu listy zadań sprintu. Jest właściwością architektury, którą trzeba zaprojektować razem z celem, kontekstem, harnessem, pamięcią i ewaluacją agenta — od pierwszego dnia, nie po incydencie. Pięć checkpointów opisanych w tym tekście to nie lista życzeń, tylko minimalny zestaw miejsc, w których błąd jest tani do złapania, zanim stanie się kosztowną szkodą albo, gorzej, trwałym wzorcem zapisanym w pamięci systemu.

Najprostszy test, czy Twój projekt agenta jest po właściwej stronie tego podziału, brzmi: czy potrafisz wskazać, w którym miejscu cyklu inżynierskiego konkretna decyzja została zatrzymana, zanim wywołała skutek — czy dopiero po? Jeśli odpowiedź to „po“, masz przycisk awaryjny, nie nadzór. Jeśli potrafisz wskazać punkt wcześniej — w celu, w kontekście, w bramce harnessu — budujesz agenta, którym naprawdę da się zarządzać, a nie takiego, którego można tylko obserwować, jak działa, i mieć nadzieję, że nikt nie będzie musiał nacisnąć czerwonego przycisku.