Agent kończy sprawę o 2:14, zatwierdzający wchodzi o 8:30. W tym okienku wolno mu tylko akcje odwracalne

Agent pocztowy zamknął analizę sprawy o 2:14. Akcja, którą do niej zaplanował, czekała na zatwierdzenie do 8:37, bo operator zaczyna o 8:30 i najpierw odsłuchuje pocztę głosową. Sześć godzin i dwadzieścia trzy minuty opóźnienia nie wyszło z architektury — wyszło z grafiku zespołu, który przepływ odziedziczył razem z bramką.

Grafik da się policzyć przed wdrożeniem i da się na nim oprzeć projekt. Pytanie, które rozstrzyga, nie brzmi „czy człowiek zatwierdza”, bo odpowiedź jest zawsze twierdząca. Brzmi: które akcje agent może wykonać w godzinach, gdy nikogo nie ma, a które muszą poczekać na zmianę. Odpowiedź jest inna dla każdej akcji i czyta się ją z dokumentacji dostawcy.

Grafik operatora jest częścią architektury, nie organizacji pracy

Agent chodzi w trybie ciągłym, a zatwierdzający pracuje na zmianie. Z tego rozjazdu bierze się jedyna liczba, od której zależy sensowny projekt nadzoru: czas do powrotu operatora, liczony od momentu, w którym agent zgłasza gotową akcję. Dla sprawy z 2:14 i zmiany zaczynającej się o 8:30 ten czas wynosi ponad sześć godzin, a dla sprawy z 11:00 — kilka minut.

Tę wielkość wyciąga się z logu zgłoszeń, nie z regulaminu pracy. Potrzebne są dwa przebiegi: mediana czasu od zgłoszenia do decyzji w podziale na godziny doby oraz 90. percentyl tego samego rozkładu. Mediana mówi, jak przepływ zachowuje się normalnie, a 90. percentyl mówi, czego przepływ musi wytrzymać bez interwencji — i to on jest progiem projektowym, bo bramka ustawiona na medianę zatrzyma się przy pierwszym dniu z urlopem.

Dalszy krok jest już mechaniczny. Akcja może wykonać się bez nadzoru wtedy, gdy czas, w którym da się ją odwrócić, jest dłuższy niż czas do powrotu operatora przy 90. percentylu. Jeżeli jest krótszy, akcja czeka. Nie ma tu miejsca na ocenę, jak groźna jest akcja, bo oba czynniki są mierzalne i oba są własnością systemu, nie opinią.

Okno cofnięcia dla akcji, które agenci wykonują najczęściej

Poniższe wartości pochodzą od dostawców usług; stan na 3 listopada 2026. Kolumna trzecia jest ważniejsza, niż wygląda, bo decyduje, czy cofnięcie o 8:30 jest jeszcze cofnięciem, czy już tylko porządkowaniem skutków.

Po nałożeniu tej tabeli na ośmiogodzinną zmianę rozkład wychodzi nierówny. Akcji z oknem dłuższym niż jedna doba jest w typowym przepływie najwięcej i one mogą chodzić nocą bez żadnego nadzoru. Akcji z oknem zerowym jest zwykle kilka i wszystkie dotyczą tego samego: pieniędzy, rejestrów publicznych oraz komunikacji wychodzącej poza firmę. Pomiędzy nimi nie ma prawie nic — okna liczone w minutach praktycznie nie występują, więc decyzja jest dwustanowa, a nie ciągła.

Agent wysyła maila w nocy: granica organizacji wyznacza granicę autonomii

Dwa mechanizmy, które przy mailu łatwo pomylić, zachowują się nocą zupełnie inaczej. Okres anulowania w Gmailu to opóźnienie po stronie nadawcy — wiadomość jeszcze nie wyszła, więc da się ją zatrzymać bez śladu, ale maksymalnie 30 sekund, czyli o 2:14 ten mechanizm nie istnieje. Cofanie w Exchange Online działa na wiadomości już dostarczonej: Microsoft podaje, że próba chodzi do 24 godzin, obejmuje dowolny folder i radzi sobie również z wiadomościami przeczytanymi.

To daje regułę, którą da się zapisać w jednym warunku narzędzia. Mail wyłącznie do adresatów z własnej organizacji ma okno dłuższe niż każda zmiana, więc agent może go wysłać o 2:14, a operator rano dostaje listę do przejrzenia i realną możliwość wycofania. Mail z choćby jedną obcą domeną na liście ma okno zerowe i czeka do zmiany — albo wychodzi z kolejki wyjściowej z czasem nadania ustawionym na początek godzin pracy, co jest tym samym rozwiązaniem widzianym z drugiej strony.

Kolejka wyjściowa z przesuniętym czasem nadania jest w ogóle najtańszym sposobem dorobienia okna tam, gdzie dostawca go nie daje. Opóźnienie jest parametrem, który przepływ ustawia sam, a nie prosi o nie dostawcy.

Agent rusza pieniądze w nocy: autoryzacja tak, przejęcie środków nie

W płatnościach okno cofnięcia ma gotową nazwę techniczną i pokrywa się dokładnie z podziałem na zmiany. Dokumentacja Stripe’a wylicza statusy, w których płatność da się anulować, a przy requires_capture nieprzejęta kwota wraca automatycznie. Po przejęciu środków zostaje wyłącznie zwrot, którego — jak w tabeli — przy karcie nie odwraca się wcale.

Rozdzielenie tych dwóch operacji między zmianę nocną i dzienną nie odbiera agentowi ani jednej funkcji. Agent autoryzuje o 2:14, składa cały wniosek, sprawdza kwotę i dopina dokumenty; operator przejmuje środki po 8:30, widząc gotowy komplet. Przepustowość nie spada, bo klient i tak dostaje potwierdzenie autoryzacji od razu, a firma zyskuje okno liczone w godzinach zamiast w sekundach. Ustawienie odwrotne, czyli pełne obciążenie w nocy i zatwierdzanie rano, daje ten sam komplet dokumentów i zero możliwości działania.

Okno bywa zapisane nie w API, lecz w regulaminie, i wtedy zamyka się równie skutecznie: po stronie zakupów subskrypcyjnych zgoda na natychmiastowy dostęp kasuje ustawowe 14 dni na odstąpienie. Agent, który nocą kupuje dostępy albo akceptuje regulaminy, zamyka takie okna w imieniu firmy i nikt tego do rana nie zobaczy.

Agent wystawia fakturę: stan roboczy wolno, przesłanie nie

Faktura jest w tym podziale przypadkiem najprostszym, bo okno wynosi zero od chwili przyjęcia dokumentu. Analiza w serwisie Prawo.pl stwierdza, że KSeF nie przewiduje anulowania, usunięcia ani edytowania wprowadzonej faktury, a jedyną drogą wyeliminowania dokumentu przesłanego omyłkowo jest korekta do zera z numerem KSeF faktury pierwotnej; autor powołuje się na interpretację indywidualną dyrektora KIS z 23 czerwca 2026 r.

Skutek dla podziału zmian jest jednoznaczny, a jego konsekwencje księgowe warto potwierdzić u własnej księgowości, zanim agent dostanie prawo wysyłki. Nocą agent może złożyć dokument w stanie roboczym, bo taki plik wolno usunąć bez śladu. Przesłanie czeka na zmianę, ponieważ odwrócenie błędu nie jest cofnięciem, lecz drugim dokumentem, który również wchodzi do rejestru i również podlega rozliczeniu w okresie. Przepływ, w którym agent wysyła faktury o 2:14, kupuje sobie każdy fałszywy alarm po cenie dwóch dokumentów zamiast zera.

Agent usuwa pliki: wariant miękki chodzi nocą, trwały nie chodzi wcale

Przy plikach kosz wygląda na uniwersalne zabezpieczenie i w interfejsie nim jest. Dysk Google trzyma usunięty plik 30 dni, a dokumentacja Microsoftu opisuje dla SharePointa i OneDrive’a 93-dniowy okres obejmujący oba etapy kosza, przy czym drugi etap widzi i przywraca wyłącznie administrator kolekcji witryn. Oba okna z łatwością przekraczają każdą zmianę, więc porządkowanie plików jest kandydatem na pracę nocną.

Warunkiem jest to, którą metodą agent usuwa. Wywołanie files.delete w API Dysku usuwa plik trwale, bez przeniesienia do kosza, a ustawienie znacznika trashed przez aktualizację pliku zostawia pełne 30 dni. Nocny agent z pierwszym wariantem narzędzia nie ma okna wcale, z drugim ma miesiąc — różnica siedzi w jednej linii definicji narzędzia i nie wychodzi w żadnym teście, w którym sprzątanie zakończyło się poprawnie.

Przegląd, który to wyłapuje, zajmuje kwadrans: wypisać wywołania dostępne agentowi i zaznaczyć, które mają wariant miękki. Narzędzie bez wariantu miękkiego nie wchodzi do zestawu nocnego, choćby akcja wydawała się niegroźna.

Przepływ z kolejką poranną: co agent odkłada, a czego nie

Różnica wobec typowego schematu jest w jednym miejscu: na zmianę przechodzi wywołanie przygotowane, a nie wykonane. Kolejność kroków wygląda tak:

• 1. Wejście. Zdarzenie wchodzi do kolejki zadań z kluczem sprawy i znacznikiem czasu.
• 2. Plan. Agent ustala listę wywołań wraz z pełnymi argumentami.
• 3. Dwa odczyty. Dla każdego wywołania przepływ bierze okno cofnięcia ze słownika akcji oraz czas do powrotu operatora z grafiku. Oba są liczbami w sekundach, żadnej z nich nie szacuje model.
• 4. Okno dłuższe niż czas do zmiany. Wykonanie od razu, wpis do logu, pozycja na liście do porannego przeglądu.
• 5. Okno krótsze. Wywołanie zostaje zserializowane i zapisane w stanie „do zatwierdzenia”. Nic nie opuszcza firmy, a sprawa czeka w kolejce porannej.
• 6. Zmiana. Operator widzi argumenty, które polecą: kwotę, adresatów, numer dokumentu, ścieżkę pliku. Podgląd streszczony przez model nie jest podglądem wywołania.
• 7. Wykonanie. Payload leci z kluczem idempotencji zbudowanym z identyfikatora sprawy, żeby ponowienie po timeoucie nie wykonało akcji drugi raz.
• 8. Zapis. Do logu idzie odpowiedź dostawcy z identyfikatorem operacji — jedyny punkt zaczepienia, jeśli cofanie okaże się potrzebne.

Krok piąty jest tym, którego najczęściej brakuje w przepływie działającym już na produkcji, bo w pierwszej wersji narzędzie wykonuje akcję natychmiast, a zatwierdzenie dokleja się obok jako powiadomienie. Przebudowa dotyka warstwy narzędzi, nie promptu, i nie wymaga przepisywania agenta — także wtedy, gdy robi ją zespół wdrażający takie przepływy na zlecenie, bo zmiana jest po stronie integracji, a nie wiedzy o firmie.

Rachunek miesięczny dla trzech ustawień zmiany

Liczby poniżej są arytmetyką na jawnych założeniach, nie pomiarem: 1200 spraw miesięcznie, jedna akcja zewnętrzna na sprawę, 456 spraw wpływających poza godzinami pracy operatora, 40 sekund na jedno zatwierdzenie wraz z przeczytaniem argumentów, stawka 90 zł za godzinę. Udział akcji z oknem krótszym niż zmiana przyjęty na 9 proc., a odsetek akcji odwracalnych wymagających naprawy po fakcie na 3 proc.; obie wartości wylicza się z własnego logu za miesiąc, zliczając wywołania po typie.

Kolumna trzecia jest w tabeli po to, żeby ją odrzucić z rachunkiem w ręku: dyżur kupuje kilka godzin na sprawach nocnych za kilkunastokrotność kosztu kolumny drugiej i nie zmniejsza liczby akcji nieodwracalnych, które i tak wymagają decyzji. Kolumna druga wychodzi najtaniej nie dlatego, że obniża poprzeczkę, lecz dlatego, że przestaje zatrudniać człowieka do zatwierdzania rzeczy, które da się odwrócić przez trzydzieści dni.

Do rachunku dochodzi pozycja po stronie modelu, widoczna dopiero na fakturze za drugi miesiąc. Oczekiwanie na zatwierdzenie w środku jednego kontekstu wywraca pamięć podręczną promptu, więc wariant pierwszy podnosi nie tylko godziny, ale i tokeny — a nocą, przy przerwie liczonej w godzinach, traci cały prefiks każdej wstrzymanej sprawy.

Ostatni koszt wariantu pierwszego nie mieści się w żadnej z tych jednostek. Kolejka 1200 pozycji miesięcznie, w której 91 proc. wpisów jest nieszkodliwych, uczy operatora zatwierdzać bez czytania w ciągu kilku tygodni. Raport z bramki wygląda wtedy w panelu identycznie jak wcześniej, a to jest najgorszy możliwy stan: nadzór zniknął, a wskaźnik nadal go pokazuje.

Co wypisać, zanim agent dostanie zmianę nocną

• Mediana i 90. percentyl czasu od zgłoszenia do decyzji, w podziale na godziny doby — z logu, nie z grafiku.
• Wszystkie wywołania zewnętrzne dostępne agentowi w zestawie narzędzi, a nie te, które przewiduje dla niego instrukcja.
• Dla każdego wywołania: nazwa operacji odwracającej, warunek jej działania i data sprawdzenia w dokumentacji dostawcy.
• Czy wywołanie ma wariant miękki, który odkłada skutek, zamiast go utrwalać.
• Klucz idempotencji dla każdej akcji z oknem zerowym oraz test, czy dwa identyczne zatwierdzenia dają jeden skutek.
• Zgodność podglądu z payloadem: czy zatwierdzający rano widzi argumenty wywołania, czy ich streszczenie.
• Kto może odwrócić akcję i czy jest dostępny w czasie, w którym odwrócenie jest jeszcze możliwe — administrator kolekcji witryn o 3:00 nie jest.

Od czego zacząć w przepływie, który już chodzi

Pierwsze zadanie zajmuje jedno popołudnie i nie dotyka kodu: wypisać akcje agenta, dopisać do każdej okno cofnięcia z dokumentacji, obok postawić 90. percentyl czasu reakcji operatora dla godziny, w której akcja zwykle wypada, i porównać dwie kolumny. Wszystko, co ma okno krótsze, jest kandydatem do kolejki porannej. Jeśli w zestawieniu jest choć jedno wywołanie z oknem zerowym, które agent wykonuje dziś samodzielnie w nocy, to jest zadanie na ten tydzień.

Druga decyzja dotyczy uprawnień i jest trudniejsza, bo nie da się jej odłożyć na później bez konsekwencji. Agent, który ma w zestawie narzędzie wykonujące akcję z oknem zerowym, ma do niej prawo niezależnie od tego, co stoi w instrukcji — prompt nie jest mechanizmem kontroli dostępu i nie zmienia się w niego od dopisania zdania o ostrożności. Takie narzędzie albo wypada z zestawu nocnego, albo zostaje opakowane w wersję odkładającą wywołanie do kolejki porannej. Wybór między tymi dwiema możliwościami zapada przy projektowaniu grafiku, nie po pierwszym incydencie o 2:14.