Claude Code v2.1.318 dodaje kontrolę delegowanej pracy i działania bez nadzoru

Claude Code v2.1.318 od Anthropic dodaje mechanizmy kontroli delegowanej pracy, jednocześnie rozwiązując problemy przerywające sesje programowania bez nadzoru. Główne napięcie tej aktualizacji ma charakter operacyjny: powierzenie agentowi większej odpowiedzialności zwiększa także znaczenie poświadczeń, uprawnień i stanu możliwego do odzyskania.

Dla deweloperów oznacza to, że ocena wykracza poza pytanie, czy asystent potrafi stworzyć użyteczny patch. Agent programistyczny musi także zachowywać instrukcje, rzetelnie zgłaszać błędy i zatrzymywać się po wygaśnięciu autoryzacji. Wymagania te trudniej nadzorować, gdy praca trwa poza aktywnym terminalem.

GitHub Copilot stanowi istotne porównanie, ponieważ jego udokumentowane środowisko chmurowe również podkreśla kontynuowanie sesji agenta między klientami. Szersze pytanie dotyczy tego, jak niezawodnie delegowana praca przetrwa przejścia między ludźmi, procesami i środowiskami. To wydanie oferuje konkretne zmiany do przeanalizowania, choć same informacje o wydaniu nie mogą potwierdzić ich skuteczności.

Co zmienia Claude Code v2.1.318

Wydanie koncentruje się na kontrolach otaczających wykonywanie zadań przez agenta, a także na poprawkach niezawodności sesji.

Informacje o wydaniu Anthropic wskazują kilka dodatków. Claude Code zapisuje teraz odpowiedzi na pytania dotyczące włączania modów zapisywanych w sesji, czyli jego programistycznych rozszerzeń. $.model.fork moda otrzymuje opcję effort, umożliwiając delegowanej pracy korzystanie z innego ustawienia nakładu pracy.

Przechowywane wygaśnięcie logowania jest teraz widoczne przez loginExpiresAt w stanie uwierzytelnienia oraz credential_expires_at w programistycznych wynikach JSON. Dane tekstowe otrzymują ostrzeżenie zaczynające się 10 dni przed wygaśnięciem.

Brama zyskuje również obsługę assume_role dla źródeł nadrzędnych mantle, przeznaczoną dla ról AWS między kontami i przypisywania kosztów na poziomie dewelopera. Anthropic informuje ponadto o poprawkach dotyczących kontynuacji rozmów, monitów o uprawnienia, trwałości konfiguracji oraz błędnie raportowanego powodzenia. GitHub datuje wydanie na 4 listopada.

Zmiany te dotyczą różnych komponentów, ale łączy je praktyczny motyw. Ujawniają więcej warunków operacyjnych agenta. Deweloper może sprawdzić datę wygaśnięcia, przypisać nakład pracy do delegowanego zadania albo przeanalizować, czy decyzja o zatwierdzeniu została zapisana.

Ta widoczność ma znaczenie, ponieważ delegowanie tworzy dystans między instrukcją a jej ostatecznym wykonaniem. Osoba może zatwierdzić pracę podczas obserwowania terminala, a następnie wrócić po wznowieniu jej przez inny proces. Pierwotny zamiar musi pozostać zrozumiały przez cały ten czas.

Rozważmy hipotetyczny zespół inżynieryjny korzystający z asystenta do zbadania nieudanego testu w nocy. Oczekiwanym rezultatem jest diagnoza lub proponowany patch. Jednak przepływ pracy zależy także od prawidłowej tożsamości, użytecznych ustawień projektu i dokładnego sygnału ukończenia.

Wiarygodna odpowiedź nie zrekompensuje procesu, który po cichu utracił kontekst operacyjny. Podobnie nienaruszony zapis rozmowy nie potwierdza poprawności wynikowego kodu. Jakość wyniku i integralność wykonania wymagają odrębnej oceny.

To rozróżnienie nadaje aktualizacji wartość informacyjną. Jej dodatki dotyczą okoliczności, w których praca postępuje, zamiast dostarczać nowej podstawy do oceny umiejętności programistycznych. Czytelnicy nie powinni traktować kontroli operacyjnych jako dowodu poprawy inteligencji modelu.

Istnieje także różnica między udostępnianiem informacji a działaniem na ich podstawie. Pole wygaśnięcia staje się użyteczne dopiero wtedy, gdy otaczający system je sprawdza. Zapisana decyzja staje się użyteczna tylko wtedy, gdy ktoś może powiązać ją z odpowiednim działaniem.

To samo dotyczy wyboru nakładu pracy. Jawne ustawienie daje deweloperom dodatkową kontrolę, ale nie wybiera za nich właściwego ustawienia. Zespoły nadal potrzebują uzasadnionej relacji między wagą zadania, wymaganiami dotyczącymi przeglądu a przydzielonymi zasobami.

Odczytywane łącznie zmiany wspierają węższy wniosek niż szeroka deklaracja wzrostu produktywności. Anthropic zajmuje się konkretnymi granicami operacyjnymi wokół delegowanego programowania. To, czy zmiany te ograniczają przerwy lub pracę przeglądową, pozostaje empirycznym pytaniem dla wdrożeń.

Praca bez nadzoru wywiera presję na otaczający system

Bezpośrednia presja spada na deweloperów, którzy przekształcają interaktywnego asystenta w powtarzalną zależność operacyjną.

Interaktywna sesja zapewnia nieformalny system monitorowania: osobę, która ją obserwuje. Może ona zauważyć wahanie, sprawdzić nieoczekiwany monit lub rozpoznać, że odpowiedź zakończyła się przedwcześnie. Wykonywanie bez nadzoru usuwa znaczną część tego kontekstu.

Dokumentacja Anthropic dotycząca wykonywania programistycznego opisuje claude -p jako sposób uruchamiania Claude Code bez interaktywnego wejścia. Obsługuje on dane ustrukturyzowane i statusy zakończenia procesu, umożliwiając skryptom korzystanie z wyników i reagowanie na błędy.

Interfejsy te tworzą istotną odpowiedzialność dla właścicieli integracji. Skrypt potrzebuje jawnej definicji sukcesu. Otrzymanie czytelnego tekstu nie wystarcza, jeśli oczekiwany patch, analiza lub weryfikacja nigdy nie zostały ukończone.

Wyobraźmy sobie zaplanowane zadanie, które przegląda zmiany i generuje poranny raport. To scenariusz ilustracyjny, a nie udokumentowane wdrożenie u klienta. Jego użyteczność zależy od odróżnienia rzetelnego przeglądu od nieukończonego badania.

Jeśli oba wyniki tworzą podobnie pewny siebie tekst, odbiorca raportu ponosi ukryty koszt weryfikacji. Ktoś musi odtworzyć, czy agent zbadał zamierzony materiał i osiągnął wymagany punkt końcowy. Automatyzacja przesunęła pracę, zamiast ją usunąć.

Widoczność poświadczeń rozwiązuje inną część tego problemu. Znana data wygaśnięcia daje operatorowi coś, wokół czego może planować. Tworzy możliwość odnowienia dostępu przed przydzieleniem pracy, która od niego zależy.

Jednak utrzymanie tożsamości nadal wymaga właściciela. Ktoś musi otrzymać ostrzeżenie, zrozumieć, którego przepływu pracy dotyczy, i zorganizować autoryzowaną reakcję. Wyświetlenie ostrzeżenia nie dowodzi, że organizacja ma taki proces.

Jest to szczególnie istotne, gdy odpowiedzialność jest podzielona między dewelopera a zespół infrastruktury. Deweloper rozumie zadanie, podczas gdy administrator kontroluje dostęp. Bez jasnego przekazania obowiązków każda strona może rozsądnie zakładać, że za przerwę odpowiada druga.

Konsekwencją operacyjną jest potrzeba lepszych kontraktów przepływu pracy. Powtarzalne zadanie agenta powinno mieć rozpoznawalnego właściciela, oczekiwany wynik i zdefiniowaną reakcję na niepełne wykonanie. To wybory zarządcze, a nie możliwości modelu.

Odpowiada temu obciążenie recenzentów. Potrzebują wystarczającego kontekstu wykonania, aby ocenić rezultat bez odtwarzania każdej interakcji. Dokładny zapis ukończenia pomaga im zdecydować, gdzie skupić uwagę.

Zespoły powinny również odróżniać błędy uzasadniające ponowienie próby od błędów wymagających interwencji. W niektórych okolicznościach ponowienie przerwanego żądania może być właściwe. Powtarzanie działania, którego autoryzacja jest niejasna, tworzy inny problem.

Ta analiza nie potwierdza, że aktualizacja rozwiązuje te kwestie organizacyjne. Pokazuje, dlaczego dotknięte nią interfejsy mają znaczenie, gdy Claude Code staje się częścią powtarzalnej pracy. Małe sygnały nabierają znaczenia, gdy oprogramowanie wykorzystuje je do podejmowania dalszych decyzji.

Dla nabywców korporacyjnych istotne pytanie jest zatem konkretne: czy ich istniejące procesy monitorowania i dostępu potrafią interpretować sygnały agenta? Sama lista funkcji nie może na to odpowiedzieć. Reprezentatywny przepływ pracy może ujawnić, czy integracja zamyka pętlę.

Delegowana praca potrzebuje granic, które pozostają zrozumiałe

Większa delegacja zwiększa wartość jasnych granic dotyczących nakładu pracy, tożsamości i uprawnień.

Kontrole nakładu pracy ilustrują pierwszą granicę. Delegowane zadanie może być wąskim wyodrębnieniem danych albo trudnym dochodzeniem. Traktowanie obu identycznie czyni decyzję o przydziale domyślną, nawet jeśli ich wymagania znacząco się różnią.

Użyteczne pytanie analityczne brzmi, czy deweloperzy mogą przydzielać zasoby zgodnie z konsekwencją błędu. Krótkie zadanie nadal może być wrażliwe. Długie zadanie nadal może być rutynowe. Sama długość stanowi słabą podstawę wyboru nakładu pracy.

Na przykład zbieranie nazw plików i ocena zmiany wrażliwej z punktu widzenia bezpieczeństwa wymagają różnych oczekiwań dotyczących przeglądu. To hipotetyczne porównanie nie dowodzi żadnej różnicy w wydajności między ustawieniami nakładu pracy. Wyjaśnia, dlaczego jawne ustawienie potrzebuje uzasadnienia właściwego dla zadania.

Zwrócone ustawienie służy też innemu celowi niż pomiar wyniku. Może pokazać, jaka konfiguracja została wysłana. Nie może potwierdzić, że odpowiedź osiągnęła akceptowalny próg jakości ani że wybrany przydział był efektywny.

Tożsamość wprowadza kolejną granicę. AWS dokumentuje role między kontami jako sposób, w jaki autoryzowani użytkownicy mogą uzyskać dostęp do zasobów na innym koncie. Uprawnienia roli regulują dostęp, a polityki zaufania i uprawnień kontrolują, kto może ją przyjąć.

To tło ma znaczenie przy ocenie każdej integracji aplikacji zbudowanej wokół przejmowania ról. Obsługa tego mechanizmu nie determinuje projektu uprawnień organizacji. Administratorzy nadal muszą zdecydować, które tożsamości mogą dotrzeć do których zasobów.

Przypisywanie kosztów jest podobnie odrębne od kontroli kosztów. Przypisanie aktywności do dewelopera może pomóc wyjaśnić wykorzystanie. Nie określa, czy praca była potrzebna, czy wynik był użyteczny ani czy wystarczyłby tańszy przydział.

Istnieje też pytanie dotyczące zarządzania wspólną pracą. Agent może wykonać zadanie zlecone przez jedną osobę, które przynosi korzyść całemu zespołowi. Przypisanie zużycia do jednostki nie oddaje automatycznie tej szerszej wartości.

Uprawnienia są trzecią granicą. System uprawnień Anthropic rozróżnia reguły dostępu, zachowanie zatwierdzeń i zarządzane polityki. Dokumentacja wyjaśnia, że niektóre zatwierdzenia są trwałe, podczas gdy inne obowiązują wyłącznie w ramach sesji.

To rozróżnienie ma praktyczną konsekwencję: zapamiętana preferencja i autoryzacja konkretnego działania są różnymi zapisami. Recenzent musi rozumieć, który z nich uzasadniał wykonanie. W przeciwnym razie pozornie pomocna trwałość może stać się niejednoznacznym uprawnieniem.

Właściwym standardem jest zrozumiała ciągłość. Gdy praca zostaje wznowiona lub deleguje podzadanie, odpowiednie ograniczenia powinny pozostać jasne dla osób odpowiedzialnych. Zdolność agenta do kontynuowania pracy jest wartościowa tylko w ramach tych ograniczeń.

Dlatego też możliwość audytu należy oceniać przez konkretne pytania. Kto zlecił zadanie? Która tożsamość je wykonała? Jaki zakres został autoryzowany? Który wynik dotarł do recenzenta? Każde pytanie dotyczy innej odpowiedzialności.

Żadne z nich nie wymaga zakładania złośliwego zachowania. Zwykłe nieporozumienia wystarczą, by słabe granice stały się kosztowne. Deweloper może zatwierdzić właściwe działanie w jednym kontekście, a później mieć trudność z ustaleniem, dlaczego powiązane działanie nastąpiło gdzie indziej.

W przypadku Claude Code v2.1.318 wniosek jest wyważony. Dodatkowe mechanizmy kontroli tworzą możliwości bardziej świadomego delegowania. Ich użyteczność zależy od tego, czy otaczające narzędzia zachowują te rozróżnienia i czynią je dostępnymi podczas przeglądu.

Trwałe sesje stają się wymogiem konkurencyjnym

Konkurencja coraz częściej obejmuje ciągłość pracy między środowiskami, obok jakości poszczególnych odpowiedzi.

Udokumentowane przez GitHub sesje chmurowe stanowią użyteczny punkt odniesienia. Nowsza wersja Copilot opisuje kontynuowanie pracy między obsługiwanymi klientami, z rozmowami połączonymi ze środowiskami, w których wykonywane są zadania agentów.

GitHub rozróżnia również klienta, sesję i środowisko wykonawcze. Klient to interfejs używany przez człowieka. Sesja zawiera rozmowę i aktywność. Środowisko to miejsce, w którym odbywa się praca.

To słownictwo pomaga wyjaśnić stawkę konkurencji bez sugerowania równoważnych implementacji. Rozmowa może pozostać widoczna, podczas gdy zmienia się jej środowisko wykonawcze. Znajomy interfejs może ukrywać inną maszynę, kontekst poświadczeń lub dostępny zestaw narzędzi.

Dla nabywców ciągłość powinna zatem oznaczać coś więcej niż odnalezienie starego czatu. Istotne pytanie brzmi, czy po przejściu praca pozostaje zrozumiała i możliwa do kontrolowania. Transkrypcja dostarcza dowodów, lecz jest tylko częścią tej oceny.

Rozważmy programistę, który rozpoczyna analizę lokalnie, a później sprawdza jej postęp przez inny interfejs. Przekazanie jest użyteczne, jeśli programista potrafi zrozumieć bieżący stan i odpowiednio interweniować. Wygoda zależy od przejrzystości operacyjnej.

To porównanie nie dowodzi, że którykolwiek produkt lepiej obsługuje przejścia. Dokumentacja opisuje zamierzone działanie, a nie wspólny, niezależny test. Każdy ranking wymagałby dopasowanych zadań, porównywalnych uprawnień i jasno zdefiniowanych warunków awarii.

Ustanawia jednak istotną kategorię oceny. Trwała praca agentów wymaga od oprogramowania przenoszenia intencji przez granice, które wcześniej ludzie nadzorowali samodzielnie. Nabywcy powinni badać to zachowanie bezpośrednio, zamiast wyciągać wnioski z dopracowanego interfejsu.

Przekonująca demonstracja może pokazać agenta kończącego proste zadanie. Ocena operacyjna pyta, co dzieje się po przerwaniu, zmianie dostępu lub niedostępności zależności. Te warunki ujawniają, czy przepływ pracy pozostaje zrozumiały.

Presja na dostawców polega na precyzyjnym wyjaśnianiu tych przejść. Użytkownicy muszą wiedzieć, co przetrwa, co zostanie ponownie sprawdzone i co wymaga ponownej autoryzacji. Mgliste obietnice ciągłości pozostawiają zespołom integracyjnym konieczność samodzielnego odkrywania zasad działania.

Presja dotyczy również zespołów zakupowych. Lista kontrolna skupiona wyłącznie na obsługiwanych modelach lub integracjach z edytorami pomija zachowanie operacyjne. Ocena powinna odzwierciedlać sposób, w jaki organizacja faktycznie planuje delegować pracę.

Dla zespołu wykonującego okazjonalne wspomagane edycje zachowanie podczas odzyskiwania może być kwestią drugorzędną. Dla zespołu zlecającego cykliczne zadania w tle staje się ono kluczowe. Ta sama funkcja może mieć różne znaczenie w różnych modelach operacyjnych.

Organizacje inżynieryjne potrzebują również trwałej dokumentacji własnych decyzji. Przeszukiwalna baza wiedzy może zachowywać założenia integracyjne, raporty awarii i oceny aktualizacji. Pomaga to recenzentom odróżnić zamierzone działanie od lokalnie nagromadzonego obejścia problemu.

Konsekwencja konkurencyjna jest praktyczna, a nie dramatyczna. Dostawcy wspierający kontynuowanie pracy muszą uczynić kontynuowanie odpowiedzialności możliwym do zarządzania. Nabywcy uzyskają bardziej użyteczne dowody, testując tę relację, niż traktując trwałość sesji jako prostą funkcję typu tak lub nie.

Informacje o Wydaniu Pozostawiają Otwarte Ważne Pytania Dotyczące Niezawodności

Udokumentowana poprawka wskazuje rozwiązany problem; nie mierzy pozostałego prawdopodobieństwa awarii.

Informacje o wydaniu przedstawiają opis zmian z perspektywy dostawcy. Rzadko dostarczają dowodów na poziomie wdrożenia, niezbędnych do oszacowania niezawodności w każdej obsługiwanej konfiguracji. To ograniczenie powinno wpływać na sposób, w jaki czytelnicy interpretują tę aktualizację.

Zweryfikowany materiał nie ustala wskaźnika awarii przed instalacją ani po niej. Nie zapewnia też niezależnego pomiaru produktywności. Twierdzenia o mniejszej liczbie przerw lub niższych kosztach operacyjnych wymagałyby dodatkowych dowodów.

Przydatne jest rozróżnienie między odtwarzalną korektą a szerokim wnioskiem dotyczącym niezawodności. Wykazanie, że znana awaria już nie występuje, wspiera pierwsze stwierdzenie. Ustalenie drugiego wymaga reprezentatywnych obciążeń roboczych i obserwacji w czasie.

Złożoność konfiguracji sprawia, że to rozróżnienie jest ważne. Lokalna stacja robocza i współdzielone środowisko wykonawcze mogą ujawniać różne założenia. Testowanie czystej instalacji nie może potwierdzić, jak zachowuje się każda istniejąca integracja.

Organizacje powinny również unikać traktowania braku skarg jako potwierdzenia. Nieudane zadanie w tle może nigdy nie dotrzeć do osoby czytającej publiczne zgłoszenia problemów. Z kolei widoczna skarga może opisywać nietypową konfigurację, a nie powszechną wadę.

Nie ma potrzeby tworzyć kontrowersji wokół tej niepewności. Właściwe sceptyczne podejście jest metodologiczne: należy sprawdzić dowody wymagane dla zamierzonego twierdzenia. Wydanie konserwacyjne może być użyteczne, nie uzasadniając przy tym szeroko zakrojonej oceny.

Alokacja wysiłku wymaga tej samej dyscypliny. Niższe ustawienie może być odpowiednie dla ograniczonego zadania, ale sam wybór zasobów niewiele mówi o całkowitej efektywności przepływu pracy. W ocenie należy uwzględnić również wysiłek związany z przeglądem i pracą korygującą.

Załóżmy, że niedroga wstępna analiza wymaga później intensywnego sprawdzania. Jej bezpośrednie zużycie zasobów może wyglądać atrakcyjnie, podczas gdy jej praktyczna wartość pozostaje ograniczona. To ilustracyjna możliwość, a nie zaobserwowany wynik tego wydania.

Atrybucja ma powiązane ograniczenie. Wyraźniejszy zapis tego, kto zainicjował pracę, może poprawić rozliczalność, lecz nie ustala, kto odniósł korzyść. Organizacje muszą interpretować wykorzystanie w kontekście wspólnych rezultatów inżynieryjnych.

Rejestry uprawnień również potrzebują kontekstu, aby były znaczące. Zapisana odpowiedź może wyjaśniać decyzję tylko wtedy, gdy recenzenci rozumieją działanie i okoliczności, których dotyczyła. Zachowanie wyłącznie odpowiedzi „tak” lub „nie” nie rozstrzyga każdego pytania o autoryzację.

Na szczególną uwagę zasługuje jakość raportowania awarii. Operatorzy muszą rozróżniać pełną odpowiedź, częściowo użyteczną odpowiedź i nieudane wykonanie. Łączenie tych wyników pod jedną etykietą sukcesu osłabia późniejszą ocenę.

Te kwestie wspierają ukierunkowaną ocenę, a nie powszechną nieufność. Zespoły mogą wybrać reprezentatywne zadania sprawdzające ich rzeczywiste granice. Celem jest poznanie, gdzie nadal konieczny jest ludzki przegląd, a gdzie automatyzacja może przebiegać przewidywalnie.

W przypadku Claude Code v2.1.318 możliwa do obrony ocena pozostaje uzależniona od tych dowodów. Wydanie opisuje konkretne ulepszenia warte zbadania. Nie eliminuje potrzeby oceny otaczającego przepływu pracy ani weryfikacji powstałego kodu.

Na Co Zwracać Uwagę Po Aktualizacji

Kolejne użyteczne sygnały to dowody odzyskiwania, mierzalne wyniki delegowania i jaśniejsze zasady działania między środowiskami.

Po pierwsze, warto obserwować, czy użytkownicy i opiekunowie publikują odtwarzalne wyniki dotyczące przerwanych przepływów pracy. Mocne dowody obejmują warunki, które wywołały awarię, oraz zaobserwowane zachowanie po aktualizacji. Proste stwierdzenie, że wszystko wydaje się lepsze, ma mniejszą wartość diagnostyczną.

Udane odtworzenie, po którym następuje sprawne odzyskanie, wzmocniłoby argument za odpowiednią poprawką. Zgłoszenia tej samej awarii w dopasowanych warunkach osłabiłyby go. Zgłoszenia dotyczące innych konfiguracji wymagałyby zbadania przed poparciem któregokolwiek wniosku.

Po drugie, warto obserwować oceny wyboru poziomu wysiłku, które uwzględniają pełny wynik zadania. Znaczące porównanie bada akceptowalne rezultaty, potrzeby przeglądu i pracę korygującą. Pomiar wyłącznie alokacji zasobów pozostawia centralne pytanie o produktywność bez odpowiedzi.

Jeśli ograniczone zadania zachowują akceptowalną jakość przy mniejszym przydzielonym wysiłku, celowe delegowanie staje się łatwiejsze do uzasadnienia. Jeśli rośnie obciążenie związane z przeglądem, pozorna korzyść maleje. Każdy z tych wyników byłby bardziej informacyjny niż założenie, że każde małe zadanie zasługuje na minimalną alokację.

Po trzecie, warto obserwować, jak Anthropic i konkurujący dostawcy dokumentują przejścia między środowiskami wykonawczymi. Jasne zasady powinny pomagać użytkownikom zrozumieć obowiązującą tożsamość, uprawnienia i stan zadania. Ogłoszenia produktów podkreślające ciągłość bez tych szczegółów pozostawiają ważne kwestie operacyjne nierozstrzygnięte.

Dokładniejsza dokumentacja zwiększyłaby pewność, że organizacje mogą odpowiedzialnie integrować trwałe sesje. Powtarzająca się niejednoznaczność sugerowałaby, że nabywcy nadal potrzebują znacznej lokalnej infrastruktury wspierającej. Istotnym sygnałem są użyteczne szczegóły, a nie liczba obsługiwanych interfejsów.

Te obserwacje powinny uwzględniać rzeczywisty wzorzec wdrożenia zespołu. Użytkownik stacji roboczej i właściciel infrastruktury będą priorytetowo traktować różne dowody. Oboje skorzystają na ocenianiu aktualizacji względem zdefiniowanego przepływu pracy, a nie abstrakcyjnego oczekiwania lepszej AI.

Przed rozszerzeniem nienadzorowanego użycia wybierz reprezentatywny przepływ pracy i udokumentuj, co oznacza ukończenie. Uwzględnij oczekiwany artefakt, granicę przeglądu oraz osobę odpowiedzialną, gdy wykonanie się zatrzyma. Po zainstalowaniu Claude Code v2.1.318 porównaj zaobserwowany wynik z tą umową.

Powiąż ocenę z pracą, którą wspiera. Zapisuj, gdzie agent wymagał interwencji i czy końcowy rezultat pozostał zrozumiały. Podziel się tymi ustaleniami z osobami utrzymującymi poświadczenia, uprawnienia i integracje. Następnie wykorzystaj dowody, aby zdecydować, które zadania zasługują na dalsze delegowanie. Która granica obecnie powoduje największą niepewność w Twoim przepływie pracy: sama praca, jej autoryzacja czy sygnał informujący o jej zakończeniu?