Gdzie powinna zostać wprowadzona poprawka?

Dwie drużyny, takie samo napięcie, inna kwarta

Obie drużyny rozpoczynają rejestrowanie przeszkód, na jakie napotykają ich agenci AI: niejasne zapytania, nieaktualna dokumentacja, zawodne narzędzia, konieczność ponownego uruchamiania zadań.

Pierwszy zespół rozwiązuje wszystkie problemy na najbliższym poziomie. Każda powtarzająca się niedogodność staje się okazją do drobnej poprawki lub notatki przypominającej; wszystko, co wykracza poza ten zakres, staje się kolejnym akapitem w pliku kontekstowym. Trzy miesiące później agenci działają w oparciu o rozbudowane instrukcje, których nikt nie czyta od początku do końca, a istotne utrudnienia — krótki szablon, który nie określa zakresu zadań, czy konto reklamowe, którego struktura utrudnia każdą sesję — nadal istnieją, ponieważ żadna doraźna poprawka nie jest w stanie ich rozwiązać.

Drugi zespół zadaje jedno dodatkowe pytanie dotyczące każdego wzorca: gdzie właściwie należy umieścić to rozwiązanie? Klaster „agenci wciąż próbują odgadnąć, kim jest nasza grupa docelowa” przekształca się w zmianę sposobu przekazywania wytycznych dotyczących pracy: rozwiązanie procesowe, uzgodnione podczas sesji zespołowej. Klaster „przestarzały podręcznik operacyjny” przekształca się w poprawkę dotyczącą dokumentacji, za którą odpowiada konkretna osoba. Jednorazowa osobliwość staje się jedynie notatką przypominającą i niczym więcej. Trzy miesiące później ich pliki instruktażowe są krótsze niż na początku, a liczba kategorii utrudnień, które udało się wyeliminować, wykazuje tendencję spadkową.

Różnica nie polega na dyscyplinie w prowadzeniu dziennika. Obie drużyny prowadziły dzienniki. Różnica dotyczy kwestii wytyczenia trasy, o którą pierwsza drużyna nigdy nie zapytała.

Kluczowy manewr: punkty tarcia na wysokości

Gdy sesja wspomagana przez sztuczną inteligencję napotyka przeszkodę, jej pierwotna przyczyna wskazuje na poziom, na którym znajduje się trwałe rozwiązanie. Nazywamy to poziomem rozwiązania; dostępne poziomy obejmują zarówno rozwiązania doraźne, jak i strukturalne:

pamięć → umiejętności/wskazówki → otoczenie i konfiguracja → dokumentacja → sam materiał roboczy → proces/przebieg pracy → produkt lub dostawca wyższego szczebla

Określenie przyczyny pozwala przekształcić zgłoszenie w konkretne zadanie, które można przydzielić. „Agent ponownie błędnie ustalił strategię ustalania stawek” to zgłoszenie. „Decyzja dotycząca strategii ustalania stawek nie została nigdzie zapisana w sposób dostępny dla agenta: należy poprawić dokumentację, a oto podręcznik operacyjny, w którym należy ją umieścić” to zadanie z jasno określonym zakresem działania.

Błędne określenie zakresu ma negatywne skutki w dwóch kierunkach. Zbyt wąski zakres – prywatna notatka służąca jako zastępstwo faktycznie brakującego dokumentu zespołowego – oznacza, że problem ten powraca dla wszystkich oprócz Państwa: stanowi to obciążenie związane z powtarzaniem się tego problemu dla reszty zespołu. Nadmierne ukierunkowanie (nowa umiejętność wprowadzona jednorazowo, kolejny akapit w i tak już rozbudowanym pliku kontekstowym) stanowi obciążenie związane z utrzymaniem artefaktu; środowisko fachowe precyzyjnie nazwało te antywzory: rozrost umiejętności (16→48 umiejętności w ciągu 15 dni: „Dodawanie umiejętności jest łatwe. … Trudnością jest zarządzanie nimi.”) oraz nadmierne rozbudowanie pliku kontekstowego („plik pamięci, który przestał być czytany”, zgodnie z tą notatką terenową). Dostawcy zbliżyli się do tego samego podejścia, wychodząc z przeciwnej strony — ograniczają znaczenie pamięci efemerycznej, promując trwałe uczenie się w ramach kontroli wersji: Windsurf/Devin („zapisz to jako regułę lub dodaj do pliku AGENTS.md… zamiast polegać na automatycznie generowanych wspomnieniach”, dokumentacja), OpenAI Codex („gdy Codex popełni ten sam błąd dwukrotnie, należy poprosić go o retrospektywę i zaktualizować plik AGENTS.md”, najlepsze praktyki), celowe 28-dniowe wygaśnięcie pamięci Copilot.

W branży znane są zatem oba rodzaje awarii. Brakowało dotychczas urządzenia do wyznaczania tras.

Stały zestaw słów, który kieruje

Nasza propozycja robocza: przypisanie do każdego zidentyfikowanego utrudnienia dokładnie jednej przyczyny źródłowej z ustalonego zestawu dziesięciu etykiet podzielonych na pięć grup: zestaw ten jest na tyle niewielki, że można go zapamiętać; etykiety odnoszą się raczej do przyczyn niż do objawów; a ponadto są celowo niezależne od konkretnych narzędzi i dyscyplin:

• Odprawa: ambiguous-instruction, missing-context, incorrect-context, changed-requirements
• Dokumentacja: missing-documentation, incorrect-documentation
• Materiały robocze: work-material-friction
• Oprzyrządowanie: missing-access-or-tool, environment-friction
• Agent: agent-error

Grupa stanowi klucz routingu. W momencie, gdy wynik zostanie oznaczony, jest on już w połowie skierowany:

Dominacja w grupie	Poprawka zazwyczaj znajduje się w	Typowe artefakty
Odprawa	proces (sposób przekazywania wytycznych dotyczących pracy) lub pamięć trwała	szablon briefu, lista kontrolna na rozpoczęcie projektu, plik z materiałami
Dokumentacja	dokumenty	Plik README, instrukcja postępowania/procedura operacyjna, plik kontekstowy, specyfikacja
Materiały robocze	sam materiał	kod: refaktoryzacja, na którą nieustannie wskazuje „friction”; elementy inne niż kod: restrukturyzacja konta, tablicy lub szablonu
Oprzyrządowanie	środowisko/konfiguracja lub źródło	ustawienia, konfiguracja MCP, zezwolenie na dostęp, zgłoszenie dostawcy
Agent	komenda, umiejętność lub zabezpieczenie	edycja umiejętności, hook, eval

Na wstępie jedna uwaga dotycząca rzetelności: grupy zostały nazwane na cześć miejsc docelowych pomiarów, więc stwierdzenie, że „etykieta w połowie wyznacza trasę pomiaru”, jest prawdziwe z samej natury rzeczy — jest to wybór projektowy, a nie odkrycie empiryczne. Leżącym u podstaw twierdzeniem empirycznym jest to, że etykiety z czasem przechwycenia są dokładne i spójne, a właśnie tego jeszcze nie zmierzyliśmy (więcej poniżej).

Zwróćcie uwagę na to,work-material-frictionco obejmuje to pojęcie, ponieważ właśnie w tym zakresie słownictwo to zasługuje na miano niezależnego od konkretnej dziedziny. W kodzie jest to dług techniczny: moduł, o który potyka się każda sesja. Poza kodem jest to równie realne. Wyobraźcie sobie zespół marketingowy, którego pracownik przeprowadza audyt konta Google Ads, które rozrosło się w wyniku stopniowego gromadzenia elementów: trzy generacje konwencji nazewniczych, wstrzymane kampanie, których nikt nie ma odwagi usunąć, oraz słowa kluczowe powielone w nakładających się grupach reklam. Podczas każdej sesji konsultant poświęca początkowy czas na ustalenie, która kampania jest odpowiedzialna za co, a każda rekomendacja zawiera zastrzeżenie. Żadne doraźne rozwiązanie nie rozwiązuje tego problemu; żadna notatka nie ułatwi zadania kolejnej osobie. Etykietą jest work-material-friction, zawsze powiązana z konkretnym materiałem, na który wskazuje (to konto), a sednem sprawy jest sam materiał: ta restrukturyzacja, na którą nieustannie wskazuje to utrudnienie. Ten sam schemat występuje w splątanych arkuszach kalkulacyjnych, chaosie szablonów CMS oraz bibliotekach makr wsparcia; pętla w postaci specjalisty ds. kodowania nie ma gdzie tego umieścić.

Dlaczego „ustalona”, a nie „wyłaniająca się”? Ponieważ dla zespołu taksonomia stanowi narzędzie koordynacji, a nie ćwiczenie z klasyfikacji. Stwierdzenie, że „takie same trudności występujące w ośmiu sesjach stanowią problem procesowy”, ma sens tylko wtedy, gdy wszystkie osiem sesji zostało oznaczonych w ten sam sposób; twierdzenia dotyczące rozkładu wymagają stabilnego mianownika; a linie trendów („czy trudności związane z briefowaniem zmniejszyły się od czasu ustalenia szablonu briefu?”) mają sens tylko wtedy, gdy dana etykieta oznacza to samo zarówno w marcu, jak i w lipcu. Kategorie wyłaniające się, w których każda osoba samodzielnie przypisuje etykiety, są właściwym rozwiązaniem w przypadku pracy indywidualnej, jednak w ramach zespołu ulegają one rozbieżności w zależności od osoby, a żadne dane nie mogą zostać zagregowane bez etapu uzgadniania, za który nikt nie ponosi odpowiedzialności. Utrzymujemy działanie tego mechanizmu w dwóch miejscach: w postaci notatki opartej na dowodach umieszczonej pod każdą etykietą oraz poprzez okresowy przegląd słownictwa, podczas którego zgromadzone notatki poddają etykiety testom wytrzymałościowym. Słownictwo jest wersjonowane; zostało zaprojektowane tak, by zmieniać się w oparciu o dowody, a nie by być bronione.

To, co już istnieje – rzetelne porównanie

To nie my stworzyliśmy klasyfikacje niepowodzeń, a te istniejące dobrze spełniają swoje zadanie.

MAST (arXiv 2503.13657) stanowi referencyjną, stałą taksonomię: 14 rodzajów awarii w 3 kategoriach, wyodrębnionych na podstawie 150 śladów zweryfikowanych przez ekspertów i zweryfikowanych w korpusie obejmującym ponad 1600 przypadków, przy wysokim stopniu zgodności między anotatorami (κ = 0,88). Klasyfikuje ona sposoby, w jakie systemy wieloagentowe ulegają awarii; została stworzona na potrzeby badań naukowych i testów porównawczych — jest najbliższa naszej pod względem dyscypliny, ale różni się przedmiotem badań: my klasyfikujemy przyczyny wystąpienia tarć w współpracy między ludźmi a agentami.

Szkoła analizy błędów, metodologia ewaluacji autorstwa Husaina i Shankara (FAQ dotyczące ewaluacji, styczeń 2026 r.), opowiada się za podejściem przeciwnym do stosowania stałej listy: kategorie „powinny wynikać z zaobserwowanych wzorców niepowodzeń… a nie z z góry ustalonych klasyfikacji zapytań”, a swobodna interpretacja własnych śladów stanowi „najważniejsze działanie w ramach ewaluacji”.” Uważamy, że mają rację w przypadku pracy indywidualnej, natomiast w skali zespołowej sytuacja ulega odwróceniu ze względu na wspomniane powyżej kwestie związane z agregacją. Ich dyscyplina analizy stanowi w naszej propozycji podstawę niezależnie od sytuacji; na tym właśnie polegają notatki dowodowe.

W oparciu o te filary: taksonomia czterowarstwowa (Greyling, maj 2026 r.) klasyfikuje, która warstwa stosu uległa awarii, przypisując jedynie około 9,9% awarii rozumowaniu modelu: większość awarii wynika z problemów związanych z harnessem (harness to szkielet otaczający model), dlatego naszaagent-error etykieta ma charakter rezydualny i jest stosowana wyłącznie w przypadku, gdy dane wejściowe były adekwatne (szkoła inżynierii harnessu wyraźnie odrzuca domyślne obarczanie winą agenta — należy naprawić harness, a nie agenta: Osmani, Agent Harness Engineering). TraceProbe klasyfikuje działania związane z obsługą błędów w śladach. Garg’s Feedback Flywheel gromadzi cztery rodzaje sygnałów w artefaktach zespołowych, w ramach których funkcjonuje nasza struktura: jego kontekst ≈ nasze grupy briefingowe i dokumentacyjne; jego „ramie awarii” odpowiada to, co rozkłada nasza taksonomia. Factory Signals klasyfikuje objawy sesji do automatycznie tworzonych zgłoszeń; Braintrust Topics to produktowa forma tej nowej szkoły, codziennie dokonująca ponownego grupowania Państwa śladów.

Dwie rzetelne interpretacje tego porównania. Po pierwsze, większość z nich klasyfikuje objawy, warstwy lub miejsca docelowe; nasza klasyfikacja dotyczy przyczyn — to właśnie sprawia, że etykieta pełni rolę klucza routingu i stanowi rzeczywisty argument przemawiający za nowatorskim charakterem rozwiązania, w takim właśnie rozumieniu. Po drugie, co ważniejsze: MAST dokonał pomiaru rzetelności etykietowania, a my nie. Rzetelność międzyoceniająca w odniesieniu do naszych dziesięciu etykiet nie została zmierzona, a traktujemy to jako warunek wstępny, a nie jedynie przypis: eksperyment (polegający na ślepym przypisywaniu etykiet przez niezależnych oceniających do tych samych rzeczywistych wpisów, z podaniem stopnia zgodności niezależnie od jego wyniku) jest obecnie prowadzony na podstawie wpisów z naszego własnego badania w warunkach rzeczywistych, przy czym za punkt odniesienia przyjęto współczynnik κ wynoszący 0,88 uzyskany przez MAST. Dopóki nie zostaną opublikowane wyniki tego badania, niniejsza taksonomia stanowi roboczą propozycję z etykietami w różnych wersjach, a nie zatwierdzone narzędzie. Wolimy poinformować Państwa o tym, niż pozwolić, by sami Państwo to odkryli.

Popieramy również wszystkie już działające pętle: Loop Engineering, Compound Engineering, agent-retro, retrospektywy AGENTS.md, systemy pamięci dostawców oraz zautomatyzowane raporty z sesji. Prosimy zachować je wszystkie; żadne z wymienionych tutaj rozwiązań nie zastępuje ich.

Dlaczego wysokość nad poziomem morza jest kwestią dotyczącą całego zespołu

Oto wspólna cecha tych istniejących pętli: niemal wszystkie z nich mają charakter indywidualny (jeden programista i jego agent lub jeden dostawca i jego flota). Z danych branżowych wynika, że najkosztowniejszym etapem nie jest monitorowanie: około 90% zespołów wdraża śledzenie działania agentów, ale jedynie około 37–52% systematycznie je ocenia (LangChain State of Agent Engineering, czerwiec 2026 r.). Niewykorzystaną warstwą jest synteza na poziomie zespołu i właśnie w tym miejscu znaczenie zaczyna nabierać szersza perspektywa, z dwóch powodów.

Agregacja zmienia priorytety. Dziesięciominutowa niedogodność dla jednej osoby to tylko szum; nikt rozsądny nie zajmie się jej usunięciem. Ta sama etykieta pojawiająca się w ośmiu sesjach i u pięciu osób stanowi jeden z największych kosztów zespołu, a dostrzec to można jedynie w ujęciu zbiorczym. Agregacja jest również tym, co zapewnia ustalone słownictwo: liczby sumują się tylko wtedy, gdy wszyscy używali tych samych etykiet.

Najwyższe szczeble decyzyjne należą do zespołu. Poszczególne osoby mogą samodzielnie dostosowywać swoje zasoby pamięci, podpowiedzi i ustawienia. Jednak zmiany procesowe, decyzje wymagające oceny w kontekście wielu narzędzi, budżet na oprogramowanie, eskalacje do wyższych szczebli — czyli te szczeble, na których zazwyczaj pojawiają się największe powtarzające się tarcia — to decyzje, których żadna osoba nie może podjąć samodzielnie. To właśnie dlatego uważamy, że udział człowieka w procesie syntezy pozostaje niezbędny, niezależnie od tego, jak dobre będą modele: poprawki trafiają do artefaktów, za które odpowiadają ludzie i za które ponoszą odpowiedzialność: briefy, procesy, budżety, porozumienia zespołowe. Jest to stwierdzenie dotyczące autorytetu organizacyjnego, a nie możliwości modeli. Jest to miejsce w pętli decyzyjnej, a nie punkt kontrolny w procesie: agenci powinni swobodnie wykrywać, rejestrować, grupować i tworzyć projekty; ludzie natomiast dodają osąd dotyczący dalszego kierunku działań i ponoszą odpowiedzialność.

Jeśli Państwa zespół organizuje już spotkanie poświęcone ciągłemu doskonaleniu, można to w nim uwzględnić: pojawia się zbiorczy obraz tarcia, zespół zadaje pytanie „gdzie trafia każda poprawka?”, a każdy wzorzec opuszcza spotkanie z przypisanym poziomem ważności oraz osobą odpowiedzialną. Nie jest to nowy rytuał — to retrospektywa z lepszymi danymi wejściowymi. Inżynierowie ML nazywają to analizą błędów odczytu; zespoły nazywają to spotkaniem retrospektywnym.

Co mogłoby skłonić nas do zmiany zdania?

Ponieważ jest to dokument do dyskusji, poniżej przedstawiamy kwestie, co do których naprawdę nie mamy pewności:

• Wiarygodność. Jeśli w eksperymencie międzyoceniającym stwierdzono niską zgodność, oznacza to, że reguły wyznaczania granic (lub same etykiety) są błędne i dokonamy ich korekty w ramach danej wersji, zamiast ich bronić.
• Rozmiar. Liczba dziesięciu etykiet jest wartością odziedziczoną, a nie wyprowadzoną. W modelu MAST jest ich 14, a w modelu Four-Layer – 4. Rozkład naszych etykiet po przetworzeniu jednej czwartej rzeczywistych wpisów stanowi dowód, który potwierdza lub zmienia tę wartość.
• Brakujące tryby. Tarcia między agentami (utrata kontroli nad podagentami, awarie koordynacji) są obecnie klasyfikowane w kategorii environment-friction; rzeczywiste przypadki mogą wymagać utworzenia odrębnej kategorii.
• Zakres przeglądów niedotyczących kodu. Zakres przeglądów określamy na podstawie miejsca, w którym wprowadzone zostaną poprawki: w repozytorium w przypadku większości prac programistycznych; w obszarach „konto”, „środowisko pracy” lub „zlecenie” poza nim. Te granice dotyczące elementów innych niż kod stanowią propozycje, które chcemy przetestować w praktyce z udziałem rzeczywistych zespołów.
• Wykonalność w momencie rejestracji. Czy zapracowane zespoły są w stanie przypisywać przyczyny od razu, czy też przypisywanie to musi nastąpić podczas przeglądu? Zespoły, które spróbują tego rozwiązania, rozstrzygną tę kwestię szybciej niż nasze teoretyczne rozważania.

Jeśli korzystają Państwo z dowolnej wersji tego cyklu (kategorie wyłaniające się, proces dostawczy, zwykły arkusz kalkulacyjny), chcielibyśmy dowiedzieć się, w którym miejscu tabela routingu zawodzi. Szczególnie jeśli mogą Państwo pokazać nam schemat oporu, który w ogóle nie wskazuje na wysokość: ai-discussion@teamretro.com.

---

Następny rozdział: Raport istnieje. Pomieszczenie nie. — dlaczego przydzielanie zadań związanych z usunięciem problemów jest decyzją zespołową oraz jak zespół postępuje po otrzymaniu raportu dotyczącego tarć. Fragment przewodnika po retrospektywach agentów AI.