Gdzie powinna trafić ta poprawka?
Oznaczcie każdy przypadek tarcia agenta jego pierwotną przyczyną, a wskaże to poziom (pamięć, dokumentacja, proces lub elementy wyższego rzędu), na którym należy wprowadzić trwałe rozwiązanie.
Dwie drużyny, takie samo napięcie, inna kwarta
Obie drużyny rozpoczynają rejestrowanie trudności, z jakimi borykają się ich agenci AI: niejednoznaczne 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 korekty lub notatki przypominającej; wszystko, co wykracza poza ten zakres, staje się kolejnym akapitem w pliku kontekstowym. Trzy miesiące później ich agenci działają w oparciu o rozbudowane instrukcje, których nikt nie czyta od początku do końca, a istotne utrudnienia (szablon briefu, który nie określa zakresu zadań, 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 nieustannie próbują odgadnąć, kim jest nasza grupa docelowa” przekształca się w zmianę sposobu przekazywania wytycznych dotyczących pracy: rozwiązanie procesowe, uzgodnione podczas spotkania zespołu. 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 im się wyeliminować, wykazuje tendencję spadkową.
Różnica nie polega na dyscyplinie w prowadzeniu dziennika. Obie drużyny prowadziły dzienniki. Różnica polega na 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 trudności, przyczyna leży na poziomie, na którym można znaleźć 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 zakresu problemu pozwala przekształcić skargę w zadanie, które można przyporządkować konkretnej osobie. „Agent ponownie błędnie zastosował strategię ustalania stawek” to skarga. „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 powinna się znaleźć” to zadanie z jasno określonym adresatem.
Błędne określenie zakresu powoduje problemy w dwóch kierunkach. Zbyt wąski zakres – prywatna notatka w pamięci, która w rzeczywistości zastępuje brakujący dokument zespołowy – oznacza, że trudności powtarzają się dla wszystkich oprócz Państwa: jest to „koszt powtarzalności” ponoszony przez resztę 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 rozrost pliku kontekstowego („plik pamięci, który przestał być czytany”, zgodnie z tą notatką z branży). Dostawcy zbliżyli się do tego samego trendu, 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 pamięciach”, dokumentacja), OpenAI Codex („gdy Codex popełni ten sam błąd dwukrotnie, proszę 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 jedynie 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; są one celowo niezależne od konkretnych narzędzi i dyscyplin:
- Informacja:
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 oznaczenia wyniku jako „znalezionego” jest on już w połowie skierowany:
| Dominacja w grupie | Poprawka zazwyczaj znajduje się pod adresem | Typowe artefakty |
|---|---|---|
| Odprawa | proces (sposób przekazywania wytycznych dotyczących pracy) lub pamięć trwała | szablon krótkiego dokumentu, lista kontrolna na rozpoczęcie projektu, plik z materiałami pamiątkowymi |
| Dokumentacja | dokumenty | Plik README, instrukcja postępowania/procedura operacyjna, plik kontekstowy, specyfikacja |
| Materiał roboczy | 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ść swoich miejsc docelowych, więc stwierdzenie, że „etykieta w połowie wyznacza trasę do celu”, 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).
Proszę zwrócić uwagę na to, co obejmujework-material-friction 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 agent przeprowadza audyt konta Google Ads, które rozrosło się w wyniku stopniowego gromadzenia się 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, do której kampanii co należy, a każda rekomendacja zawiera zastrzeżenie. Żadne doraźne rozwiązanie tego nie naprawi; żadna notatka nie ułatwi zadania kolejnej osobie. Etykieta to [dług techniczny]work-material-friction, zawsze powiązana z konkretnym materiałem, którym jest [to konto], a sednem problemu jest sam materiał: 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 samo tarcie występujące w ośmiu sesjach stanowi problem procesowy”, ma sens tylko wtedy, gdy wszystkie osiem sesji zostało oznaczone w ten sam sposób; twierdzenia dotyczące rozkładu wymagają stabilnego mianownika; a linie trendów („czy tarcie związane z briefingiem zmniejszyło 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 pracy indywidualnej, jednak w skali 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 bierze odpowiedzialności. Utrzymujemy ten mechanizm w dwóch miejscach: w postaci notatki opartej na dowodach 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 je bronić.
To, co już istnieje – rzetelne porównanie
To nie my stworzyliśmy taksonomie 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 zbadanych przez ekspertów i zweryfikowanych w oparciu o korpus liczący ponad 1600 przypadków, przy wysokim stopniu zgodności między anotatorami (κ = 0,88). Klasyfikuje ona sposoby awarii systemów wieloagentowych; została stworzona na potrzeby badań naukowych i testów porównawczych, jest najbliższa naszej dziedzinie, ale różni się przedmiotem badań: my klasyfikujemy przyczyny wystąpienia tarć w współpracy między człowiekiem a agentem.
Szkoła analizy błędów, metodologia ocen Husaina i Shankara (FAQ dotyczące ocen, styczeń 2026 r.), prezentuje stanowisko przeciwne do koncepcji stałej listy: kategorie „powinny wynikać z zaobserwowanych wzorców błędów… a nie z z góry ustalonych klasyfikacji zapytań”, a swobodna interpretacja własnych śladów stanowi „najważniejsze działanie w ramach ocen”.” Uważamy, że mają rację w przypadku pracy indywidualnej, natomiast w przypadku pracy 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 osprzętem (osprzęt stanowi szkielet otaczający model), dlatego nasza agent-erroretykieta ma charakter rezydualny i jest stosowana wyłącznie w przypadku, gdy dane wejściowe były adekwatne (szkoła inżynierii osprzętu agentów wyraźnie odrzuca domyślne obarczanie winą agenta, skupiając się na naprawie osprzętu, a nie samego 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 odpraw i dokumentacji; jego „ramie awarii” odpowiada to, co rozkłada nasza taksonomia. Factory Signals klasyfikuje objawy sesji w automatycznie utworzone zgłoszenia; Braintrust Topics to produktowa forma tej 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, co sprawia, że etykieta staje się kluczem routingu, i to właśnie stanowi rzeczywisty argument na rzecz nowatorskiego charakteru tego 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 naszych dziesięciu etykiet nie została zmierzona, a traktujemy to jako warunek wstępny, a nie tylko przypis: eksperyment (niezależni oceniający dokonujący ślepej klasyfikacji tych samych rzeczywistych wpisów, przy czym zgoda jest raportowana niezależnie od jej 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 κ = 0,88 uzyskany przez MAST. Dopóki nie zostaną opublikowane jego wyniki, niniejsza taksonomia stanowi roboczą propozycję z etykietami o określonych 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 cykle: 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 istniejących obecnie pętli: niemal wszystkie z nich mają charakter jednoosobowy (jeden programista i jego agent lub jeden dostawca i jego flota). Z danych branżowych wynika, że kosztownym etapem nie jest monitorowanie: około 90% zespołów wdraża śledzenie działania agentów, ale tylko 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ć perspektywa, z dwóch powodów.
Agregacja zmienia priorytety. Dziesięciominutowa niedogodność dla jednej osoby to tylko szum; nikt rozsądnie nie podejmuje działań, by to naprawić. 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 poziomy decyzyjne należą do zespołu. Poszczególne osoby mogą samodzielnie dostosowywać swoje ustawienia pamięci, podpowiedzi i konfigurację. Jednak zmiany procesów, decyzje wymagające oceny w kontekście wielu narzędzi, budżet na oprogramowanie, eskalacje do wyższych szczebli – czyli poziomy decyzyjne, 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ż spotkania poświęcone ciągłemu doskonaleniu, ta procedura idealnie się w nie wpisuje: pojawia się zbiorczy obraz oporów, zespół zadaje pytanie „gdzie należy wprowadzić poszczególne poprawki?”, a każdy wzorzec opuszcza spotkanie z przypisanym poziomem ważności oraz osobą odpowiedzialną. Nie jest to nowy rytuał, a jedynie retrospektywa z lepszymi danymi wejściowymi. Inżynierowie uczenia maszynowego nazywają to analizą błędów odczytu; zespoły nazywają to spotkaniem retrospektywnym.
Co mogłoby nas przekonać?
Ponieważ jest to dokument do dyskusji, poniżej przedstawiamy kwestie, co do których naprawdę nie mamy pewności:
- Wiarygodność. Jeżeli wyniki eksperymentu porównawczego między oceniającymi wskazują na 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 podczas przekazywania między podagentami, awarie koordynacji) są obecnie klasyfikowane w kategorii
environment-friction; rzeczywiste przypadki mogą wymagać utworzenia odrębnej kategorii. - Zakres przeglądów nieobejmujących kodu. Zakres przeglądów określamy na podstawie miejsca, w którym wprowadzane są poprawki: w repozytorium w przypadku większości prac programistycznych; poza nim – w ramach „konta”, „środowiska pracy” lub „projektu”. 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ż należy to zrobić dopiero podczas przeglądu? Zespoły, które to wypróbują, rozstrzygną tę kwestię szybciej niż nasze teoretyczne rozważania.
Jeśli korzystają Państwo z jakiejkolwiek 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 utrudnień, który w ogóle nie wskazuje na wysokość: ai-discussion@teamretro.com.
Następny rozdział: Raport istnieje. Pomieszczenie nie.: dlaczego kierowanie poprawkami jest decyzją zespołową oraz jak zespół reaguje na otrzymanie raportu dotyczącego tarć. Fragment przewodnika po retrospektywach agentów AI.