Częściowe wykonanie: agent AI zmienił dwa systemy z trzech

Rekord powstał. Termin jest zarezerwowany. Dostęp do materiałów nie został nadany. Agent podsumowuje: „Nie udało się wykonać zadania”. To zdanie jest prawdziwe tylko w bardzo szerokim sensie. Dwie z trzech zmian już wpływają na pracę ludzi, więc samo ponowienie całego polecenia może powiększyć bałagan.

Częściowe wykonanie wymaga odpowiedzi na kilka konkretnych pytań: co zaszło w każdym systemie, co nadal może nastąpić, jaki stan chcemy uzyskać i kto wybiera drogę naprawy. AI może pomagać w planowaniu czy opisie przebiegu, ale nie nadaje niezależnym usługom wspólnego przycisku cofania. Taką obsługę trzeba zaprojektować i sprawdzić dla rzeczywistych operacji.

Posłużmy się fikcyjną firmą organizującą płatne konsultacje eksperckie. Po uzgodnieniu terminu asystent ma utworzyć sprawę w CRM, czyli systemie obsługi relacji z klientami, zarezerwować pokój w kalendarzu i nadać konsultantowi dostęp do folderu roboczego. Dwa pierwsze kroki się udały. Przy trzecim integracja straciła uprawnienie. Nie wykonujemy tutaj operacji na prawdziwych kontach; układ służy przygotowaniu odbioru.

Co dokładnie zostało po przerwanym zadaniu?

Zacznij od mapy skutków, a nie od opisu zamiaru. Przy każdej usłudze zapisz identyfikator obiektu, ostatni potwierdzony stan, czas potwierdzenia i możliwość dalszego działania. Oddziel zapis planu agenta od dowodu po stronie systemu docelowego. Zdanie „utworzyłem sprawę” powinno dać się powiązać z rzeczywiście odczytywalną sprawą.

W naszym przykładzie CRM pokazuje rekord konsultacji, kalendarz potwierdza rezerwację, a folder nie zawiera nowego uprawnienia. To trzy różne dowody. Jeżeli jedna odpowiedź zaginęła, przy tej pozycji zapisz stan nierozstrzygnięty i metodę sprawdzenia. Brak odpowiedzi nie powinien zmienić się w założenie, że operacji nie wykonano.

Microsoft opisuje wzorzec transakcji kompensującej: odwrócenie skutków może wymagać reguł właściwych dla procesu i uwzględnienia późniejszych zmian. Nie musi przywracać dokładnego stanu sprzed rozpoczęcia. To ważne ograniczenie obietnicy „wycofamy wszystko”.

Do mapy dodaj odbiorców skutku. Rezerwację mógł już zobaczyć recepcjonista, a rekord mógł uruchomić pracę opiekuna. Samo usunięcie dwóch obiektów nie wymazuje tych informacji z pamięci zespołu. Trzeba ustalić, czy ktoś podjął działanie oraz jak dowie się o zmienionym stanie konsultacji.

Przydatnym punktem odniesienia są ponowienia bez podwójnego skutku. Ten mechanizm rozpoznaje powtórzenie jednej operacji. Mapa częściowego wykonania obejmuje dodatkowo zależności między kilkoma różnymi operacjami. Nawet idealne rozpoznawanie duplikatów nie odpowie, czy rezerwacja pokoju nadal ma sens bez dostępu do materiałów.

Właściciel procesu powinien móc przeczytać mapę bez rekonstruowania całej rozmowy z agentem. Dla naszej konsultacji wystarczy krótki zapis trzech pozycji i ich związku z jednym zleceniem. Rozbudowany dziennik techniczny może pozostać dostępny do analizy. Widok operacyjny ma prowadzić do następnej decyzji, nie urządzać wycieczkę po wszystkich żądaniach integracji.

Dokończyć, skompensować czy przekazać człowiekowi?

Nie każda awaria trzeciego kroku uzasadnia anulowanie dwóch wcześniejszych. Konsultacja może się odbyć, jeżeli uprawniona osoba nada dostęp inną uzgodnioną drogą. Może też wymagać przesunięcia, gdy folder zawiera materiały niegotowe do udostępnienia. Najpierw wybierz pożądany stan biznesowy, a dopiero potem zestaw czynności prowadzących do niego.

Rozważ trzy drogi. Dokończenie zachowuje poprawne skutki i realizuje brakujący etap po usunięciu przeszkody. Kompensacja wykonuje uzgodnione czynności naprawcze wobec już dokonanych zmian. Ręczne rozstrzygnięcie zatrzymuje dalsze działanie, dopóki człowiek nie ustali właściwego zakończenia. Każda droga wymaga warunków wejścia oraz dowodu osiągnięcia wyniku.

Dokumentacja AWS dotycząca orkiestracji sagi opisuje koordynowanie lokalnych operacji i czynności kompensujących. Wskazuje także złożoność ponowień, potrzebę obserwacji oraz brak izolacji całego przebiegu. Sama nazwa wzorca nie stanowi gwarancji poprawności konkretnego połączenia usług.

Dla konsultacji uzgodnijmy, że opiekun sprawdza brakujący dostęp, a do tego czasu rezerwacja pozostaje oznaczona jako oczekująca na przygotowanie. Jeżeli przygotowanie nie będzie możliwe, opiekun wybiera zmianę terminu albo zakończenie sprawy. Agent nie powinien sam wymyślać innego konsultanta tylko dlatego, że ma możliwość wyszukania go w katalogu.

Granice tej decyzji warto powiązać z zatwierdzaniem konkretnego działania AI. Zgoda na utworzenie konsultacji w uzgodnionym terminie nie musi obejmować jej odwołania, zmiany osoby czy udostępnienia innego folderu. Czynność naprawcza ma własny skutek, który również potrzebuje odpowiedniej podstawy.

Przy braku decyzji sprawa trafia do kolejki wyjątków w automatyzacji. Wpis powinien zawierać skutki już dokonane, niepewności i dostępne drogi zakończenia. Ogólny błąd z przyciskiem „ponów” zostawia operatorowi zadanie odgadnięcia, czy kliknięcie zarezerwuje drugi pokój.

Wybór drogi zapisz przy sprawie razem z osobą decydującą. Dla konsultacji może to być „utrzymujemy rezerwację, opiekun sprawdzi dostęp przed potwierdzeniem gotowości”. Mechanizm kierujący dalszą pracą powinien respektować tę decyzję i zatrzymać sprzeczną czynność naprawczą; sama notatka nie zapewnia takiej ochrony. Jeśli ktoś wybierze później anulowanie, potrzebny jest czytelny moment zmiany decyzji. W przeciwnym razie dwie osoby mogą jednocześnie uważać, że realizują właściwe zakończenie tej samej sprawy.

Ustal także termin następnego sprawdzenia i osobę odpowiedzialną. Nie chodzi o dopisywanie automatycznego zegara do każdej awarii. Rezerwacja zbliżająca się do terminu konsultacji wymaga innej reakcji niż roboczy rekord na przyszły miesiąc. Priorytet powinien wynikać z następstw pozostawienia sprawy w obecnym stanie.

Dlaczego cofnięcie zapisu nie odwraca czasu?

Załóżmy, że po utworzeniu rekordu opiekun dopisał uzgodnienie z klientem. Automatyczne przywrócenie całej starej wersji CRM usunęłoby również tę późniejszą pracę. Zamiast odtwarzać bez namysłu dawny obraz, określ zmianę właściwą dla rozliczanej operacji. Może nią być oznaczenie odwołania z zachowaniem notatki oraz powiązania z rezerwacją.

Opis wzorca Saga w Azure rozdziela lokalne transakcje i koordynowanie ich między usługami. Omawia też konflikty współbieżnych zmian oraz ograniczenia kompensacji. Jest to odniesienie architektoniczne, nie instrukcja, że każdy system firmowy obsługuje taki sam sposób odwracania skutków.

W kalendarzu sprawdź, czy nadal istnieje ta sama rezerwacja i czy ktoś jej nie zmienił. W folderze ustal, czy uprawnienie faktycznie nie powstało. W CRM zachowaj potrzebny związek między konsultacją a czynnością naprawczą. Te kontrole powinny poprzedzać działanie w używanym rozwiązaniu, zgodnie z jego możliwościami i zasadami dostępu.

Szczególnie ostrożnie traktuj skutki wychodzące poza wewnętrzny zapis. Usunięcie wydarzenia z jednego kalendarza nie daje samo w sobie dowodu, że wszystkie powiadomione osoby poznały zmianę. Wysłanej treści nie odzyskuje się przez usunięcie jej lokalnej kopii. Zakończenie technicznego kroku trzeba odróżnić od uporządkowania sytuacji odbiorców.

Sprawdź także punkt, po którym automatyczna kompensacja traci sens dla tego procesu. Gdy konsultacja już się rozpoczęła, anulowanie roboczego rekordu jest inną decyzją niż przed potwierdzeniem terminu. Warunek powinien być czytelny dla operatora. Nie ukrywaj go w samym porządku wykonywania instrukcji, którego nikt poza autorem integracji nie potrafi wyjaśnić.

Podobną ostrożność wobec przywracania wcześniejszego stanu rozwija próba odtworzenia przy migracji bazy. Kopia danych i operacyjnie poprawny stan całej usługi to różne zakresy. W częściowym wykonaniu kilku usług potrzebujesz sprawdzić każdy z nich we właściwym miejscu.

Co zrobić, gdy naprawa również się zatrzyma?

Kompensacja jest kolejnym przebiegiem działań. Może nie uzyskać dostępu, stracić połączenie albo spotkać zmieniony rekord. Dlatego opis naprawy powinien przechowywać własny postęp. W przeciwnym razie kolejne uruchomienie będzie jeszcze raz próbowało odwołać rezerwację, która już została odwołana, podczas gdy otwarta pozostaje inna część sprawy.

Połącz pierwotne zlecenie, jego poszczególne operacje i późniejsze działania naprawcze. Pracownik powinien rozpoznać, która zmiana dotyczy którego obiektu oraz jaki jest ostatni potwierdzony wynik. Nie musi widzieć wszystkich danych w jednym ekranie, ale powinien mieć do nich uprawniony dostęp. Sam zbiorczy napis „naprawianie” nie wystarczy do ręcznego przejęcia.

Przygotuj również sytuację, w której osoba przejmująca ma odczyt CRM i kalendarza, ale nie może sprawdzić folderu. Nie powinna oznaczać pełnego rozliczenia na podstawie dwóch dostępnych ekranów. Karta sprawy ma wskazywać, kto może potwierdzić brakującą część i jak dołączyć jego wynik. To ograniczenie dostępu może być prawidłowe dla jej roli. Nie rozwiązuj go automatycznym nadaniem szerokich uprawnień tylko po to, żeby wszystkie pola raportu zrobiły się zielone. Rozpoznana granica i właściwe przekazanie są częścią sprawnego procesu.

W próbie przerwij naprawę po zmianie rekordu CRM, zanim zostanie rozliczona rezerwacja. Następnie rozpocznij uzgodnione wznowienie. Oczekuj rozpoznania już wykonanej czynności i kontynuowania od właściwego miejsca. Jeśli używane usługi nie dają wystarczającego potwierdzenia, zapisz tę granicę i skieruj przypadek do sprawdzenia przez uprawnioną osobę.

Osobny przebieg powinien obejmować równoległą pracę człowieka. Opiekun może właśnie nadawać brakujący dostęp, kiedy agent rozpoczyna anulowanie. Ustal, jak koordynuje się te decyzje. Nie zakładaj, że dopisek „nie pracuj równolegle” w instrukcji wystarczy, jeśli ekran nadal oferuje obie czynności bez informacji o drugiej operacji.

Przy przerwanym strumieniu odpowiedzi AI tracimy potwierdzenie odbioru tekstu. Tutaj mogło już dojść do zmian w usługach. Rozróżnienie ma praktyczny skutek: przycisk regenerowania opisu nie powinien zarazem ponawiać wcześniejszych operacji. Odbiór obejmuje zarówno widok rozmowy, jak i miejsca wystąpienia skutków.

Po czym uznać sprawę za rozliczoną?

Przygotuj kontrolowane scenariusze dla awarii przed pierwszym skutkiem, po pierwszym i po drugim kroku. Dodaj utratę odpowiedzi po wykonaniu oraz przerwanie samej naprawy. Dla każdego zapisz oczekiwany stan końcowy w trzech usługach i informację dostępną dla opiekuna. Plan tych prób nie jest jeszcze dowodem ich przeprowadzenia.

Rozliczenie powinno odpowiadać wybranej drodze: konsultacja gotowa do realizacji, termin zmieniony albo sprawa zakończona z uporządkowaniem skutków. Sam brak pozycji w kolejce nie potwierdza żadnego z tych wyników. Operator mógł zamknąć wpis, mimo że pokój nadal pozostał zarezerwowany. Dlatego sprawdzaj stan docelowy, a nie tylko status zadania koordynującego.

Dla operacyjnego przeglądu Aeneia Audit przygotuj schemat trzech kroków, dostępne potwierdzenia i przykład zmiany dokonanej równolegle przez człowieka. Pozwoli to rozmawiać o rzeczywistym sposobie pracy. Lista nazw integracji nie mówi jeszcze, co stanie się po zatrzymaniu między nimi.

Na końcu poproś osobę nieuczestniczącą w konfiguracji o odczytanie jednej częściowo wykonanej sprawy. Czy potrafi wskazać aktualny stan, decyzję do podjęcia i granicę własnych uprawnień? Jeżeli potrzebuje telefonicznego tłumaczenia autora automatu, popraw opis i widok. Firma powinna umieć uporządkować skutki także wtedy, gdy twórca eleganckiego schematu właśnie wyszedł na obiad.