Poradnik OpenRouter Agent SDK pokazuje, jak zaplanowani agenci obsługują pamięć i akceptację człowieka

OpenRouter opublikował 31 października poradnik wykorzystujący Agent SDK w wersji 0.11.0 do monitorowania Hacker News, w którym akceptacja człowieka oddziela obserwację od działania zewnętrznego. Poradnik OpenRouter Agent SDK opisuje zaplanowanego asystenta, który wybiera istotne historie i tworzy zestawienie. Jego znaczenie wynika ze sposobu podziału odpowiedzialności między model, kod aplikacji i operatora.

Stale działający agent to oprogramowanie, które sprawdza, czy pojawiła się praca do wykonania, bez oczekiwania na nową wiadomość użytkownika. Nie wymaga to nieprzerwanej rozmowy ani nieograniczonych uprawnień. Kluczowe pytanie projektowe brzmi, które decyzje zasługują na osąd modelu, a które obowiązki powinny pozostać przewidywalnym zachowaniem oprogramowania.

Anthropic oferuje użyteczny punkt odniesienia, rozróżniając zdefiniowane wcześniej przepływy pracy i agentów samodzielnie kierujących użyciem narzędzi. Przykład OpenRouter znajduje się na granicy tych dwóch podejść: oprogramowanie kontroluje moment rozpoczęcia pracy, a model ocenia, co zasługuje na uwagę. Dla deweloperów wynikająca z tego presja ma praktyczny charakter. Przekonujący nienadzorowany asystent potrzebuje czegoś więcej niż czytelnego podsumowania; potrzebuje zrozumiałego opisu tego, co dzieje się między kolejnymi podsumowaniami.

Poradnik OpenRouter Agent SDK konkretyzuje trwałość

Poradnik dotyczący stale działającego agenta łączy TypeScript, język programowania dodający sprawdzanie typów do JavaScript, z cyklicznym sprawdzaniem Hacker News. OpenRouter określa domyślny interwał na 15 minut. Jego przykład zachowuje identyfikatory wcześniej napotkanych historii, rozpoczyna nowe rozmowy dla kolejnych kontroli i prosi o akceptację przed proponowanym powiadomieniem zespołu.

Istotna zmiana polega na przedstawieniu działającego wzorca aplikacji, a nie na wynalezieniu zaplanowanej automatyzacji.

Deweloperzy już wiedzą, jak uruchamiać programy cyklicznie. Trudniejsze pytanie produktowe dotyczy tego, jak wprowadzić osąd modelu, nie czyniąc wszystkich otaczających go obowiązków równie niepewnymi. Obserwator wiadomości stanowi użyteczny przykład, ponieważ pokazuje to rozróżnienie w zrozumiałej formie.

Znalezienie historii jest obserwowalnym zdarzeniem. Decyzja, czy ma ona znaczenie dla konkretnego czytelnika, wymaga interpretacji. Zapisanie, że historia została przetworzona, to kolejne obserwowalne zdarzenie. Łączenie tych obowiązków w jednej, nierozróżnionej rozmowie utrudnia wyjaśnianie błędów.

Przykład ma też ważną granicę dotyczącą dostarczania: jego funkcja powiadamiania zespołu zapisuje komunikat w logu zamiast integrować się z rzeczywistą usługą komunikacyjną. Czytelnicy powinni zatem odróżniać zilustrowaną ścieżkę akceptacji od ukończonego produktu komunikacyjnego.

Ta granica ma znaczenie przy ogólnej ocenie poradników programistycznych. Nazwa funkcji może sugerować gotową możliwość, nawet gdy implementacja jedynie pokazuje, gdzie powinno znaleźć się zachowanie specyficzne dla aplikacji. Integracja produkcyjna nadal wymagałaby uwierzytelniania, obsługi dostarczania oraz sposobu rozumienia awarii.

Konsekwencją biznesową jest to, że elementy rozwiązania stają się łatwiejsze do zbadania. Zespoły mogą pytać, które części otrzymują z biblioteki, a które muszą obsługiwać samodzielnie. To bardziej użyteczne pytanie zakupowe niż to, czy produkt nazywa siebie autonomicznym.

Dla czytelnika technicznego wiadomość jest więc konkretna. OpenRouter dostarczył praktyczny punkt odniesienia dla cyklicznej obserwacji z selektywnym raportowaniem. Daje on deweloperom coś, co mogą ocenić, zmodyfikować i zakwestionować, jednocześnie pozostawiając widoczne obowiązki operacyjne.

Wyznacza też właściwe oczekiwanie wobec czytelnika. To przykład, który należy ocenić pod kątem rzeczywistej potrzeby informacyjnej. Jego istnienie nie dowodzi, że każde cykliczne zadanie czytelnicze korzysta na podejmowaniu decyzji przez model.

Presja spada na zespoły, które muszą odpowiadać za obserwatora

Wcześniejszy przegląd przepływu pracy agentów OpenRouter opisuje callModel, funkcję zarządzającą wymianami między modelem a narzędziami aplikacji. Narzędzie to wywoływalna funkcja, za pośrednictwem której model żąda informacji lub działania. Firma przedstawia swój SDK, zestaw narzędzi do tworzenia oprogramowania, jako sposób na pakowanie tej powtarzalnej interakcji.

Ograniczenie kodu zarządzającego pętlą przesuwa uwagę w stronę odpowiedzialności za aplikację, jakości i utrzymania.

Ta zmiana wywiera presję na zespół budujący obserwatora. Biblioteka może uprościć sposób, w jaki model żąda wyszukiwania. Nie może zdecydować, co organizacja uznaje za istotne, kto powinien otrzymać alert ani jak duża liczba przerw jest akceptowalna.

Rozważmy grupę inżynierską śledzącą zmiany w narzędziach dla deweloperów. Historia o nowo wydanym asystencie programistycznym może zasługiwać na natychmiastową uwagę. Popularny wątek opinii o asystentach programistycznych może nadawać się do cotygodniowej listy lektur. Podobne słownictwo nie oznacza podobnej pilności.

Produkt musi gdzieś zakodować tę różnicę. Może wykorzystywać instrukcje, jawne filtry, przykłady użytecznych historii lub opinie recenzentów. Niezależnie od mechanizmu, ktoś odpowiada za definicję sukcesu.

W tym miejscu niewielka demonstracja staje się decyzją organizacyjną. Osobiste zestawienie może tolerować niejednoznaczność, ponieważ jego czytelnik interpretuje wynik prywatnie. Powiadomienie zespołowe ma inne znaczenie społeczne. Współpracownicy zasadnie zakładają, że coś zasłużyło na ich uwagę.

Obciążenie rośnie, gdy asystent staje się częścią rutyny. Czytelnicy przestają traktować każdy wynik jak eksperyment. Zaczynają polegać zarówno na jego braku, jak i obecności, zakładając, że cisza oznacza brak istotnych wydarzeń.

To założenie zasługuje na analizę. Cisza może oznaczać skuteczne filtrowanie, niedostępne źródło, nieudane uruchomienie lub nierozwiązane żądanie. Z perspektywy pustej listy lektur warunki te wyglądają podobnie, ale wymagają różnych reakcji.

Bezpośrednia presja operacyjna spada na osobę utrzymującą aplikację. Potrzebuje ona wystarczającej widoczności, by odróżnić spokojny sukces od przerwanej pracy. W przeciwnym razie użytkownik musi ręcznie kontrolować system, co osłabia wartość nienadzorowanego monitorowania.

Powiązana presja dotyczy dostawców frameworków. Deweloperzy potrzebują jasnych wyjaśnień odpowiedzialności na granicy biblioteki. Co SDK waliduje? Co zapisuje? Które decyzje pozostają polityką aplikacji? Niejasne odpowiedzi utrudniają zaufanie do integracji.

Dla kupujących sugeruje to bardziej konkretny proces oceny. Poproś dostawcę o wyjaśnienie zwykłego pustego wyniku, nieudanego wyszukiwania i opóźnionej akceptacji. Odpowiedzi ujawniają więcej o dojrzałości operacyjnej niż dopracowane zestawienie.

Moment publikacji przykładu OpenRouter jest istotny w tym węższym sensie. Jego publikacja umieszcza cykliczne działanie w widocznym scenariuszu aplikacyjnym. Kolejna decyzja należy do deweloperów określających, czy ten scenariusz odpowiada pracy, której rzeczywiście potrzebują ich użytkownicy.

Zaplanowana praca i osąd modelu służą różnym zadaniom

Wskazówki dotyczące architektury agentów Anthropic rozróżniają przepływy pracy o zdefiniowanych wcześniej ścieżkach od agentów dynamicznie kierujących własnymi procesami. Zalecają też rozpoczęcie od najprostszego odpowiedniego rozwiązania. Ta perspektywa stanowi użyteczną przeciwwagę dla traktowania każdego cyklicznego zadania jako problemu agentowego.

Model zasługuje na swoje miejsce, gdy interpretacja poprawia wynik na tyle, by uzasadnić dodatkową niepewność.

W przypadku obserwatora wiadomości niektóre decyzje są z natury mechaniczne. Ustalenie, czy rekord ma identyfikator, nie wymaga interpretacji. To, czy wcześniej przetworzony identyfikator odpowiada bieżącemu rekordowi, jest równie proste. Operacje te powinny dawać przewidywalne odpowiedzi.

Istotność jest czymś innym. Czytelnik zainteresowany niezawodnością wdrożeń może zwrócić uwagę na analizę awarii, która nigdy nie używa jego preferowanych słów kluczowych. Inny czytelnik może odrzucić szeroko dyskutowane ogłoszenie dotyczące modelu, ponieważ nie ma ono znaczenia dla jego pracy.

Model może pomóc wypełnić lukę między dosłownym dopasowaniem a zainteresowaniem wynikającym z kontekstu. Pytanie analityczne brzmi, czy robi to wystarczająco konsekwentnie. Atrakcyjne wyjaśnienie, dlaczego dana historia ma znaczenie, jest dowodem płynności, ale nie automatycznie dowodem użytecznej selekcji.

Porównanie powinno zatem obejmować prostszą alternatywę. Cykliczne wyszukiwanie ze stałymi filtrami może spełniać potrzeby czytelnika. Stały proces pobierania, po którym następuje etap podsumowania, może zapewnić wystarczającą interpretację bez oddawania modelowi kontroli nad wyszukiwaniami.

Żadna z alternatyw nie jest z natury gorsza. Inaczej rozkładają niepewność. Stały proces ułatwia zrozumienie zakresu, podczas gdy proces kierowany przez model oferuje większą elastyczność, gdy istotne słownictwo się zmienia.

To główne napięcie architektoniczne stojące za ogłoszeniem. Deweloperzy zyskują elastyczność, pozwalając modelowi wybierać części pracy. Dziedziczą też odpowiedzialność za wyjaśnianie pominięć, niepotrzebnych działań i zmieniającego się zachowania.

Użyteczna ocena uwzględniałaby historie odrzucone przez system obok tych, które wybrał. Przeglądanie wyłącznie końcowego zestawienia ukrywa pominięty materiał. Nagradza też jakość pisania, nawet gdy podstawowa selekcja była słaba.

Dla hipotetycznej grupy inżynierskiej pominięte ostrzeżenie dotyczące bezpieczeństwa może mieć większe znaczenie niż niezręczne podsumowanie. Zestawienie pełne interesujących, lecz nieistotnych dyskusji może być przyjemne w lekturze, jednocześnie nie spełniając swojego rzeczywistego celu.

To samo rozumowanie dotyczy pamięci. Prowadzenie rejestru przetworzonych materiałów wspiera ciągłość. Przechowywanie każdej wymiany w rozmowie służy innemu celowi. Traktowanie tych form przechowywania jako zamiennych utrudnia zrozumienie aplikacji.

Deweloperzy powinni pytać, czego przyszłe decyzje potrzebują z przeszłości. Przetworzony identyfikator wspiera zapobieganie duplikatom. Zapisane wyjaśnienie wspiera audyt. Preferencja użytkownika wspiera ocenę istotności. Każdy element należy umieścić w rejestrze o jasnym przeznaczeniu.

To rozróżnienie ma znaczenie również po zebraniu materiału. Zestawienie staje się bardziej użyteczne, gdy czytelnicy mogą połączyć je z wcześniejszymi decyzjami lub badaniami technicznymi. Przeszukiwalna baza wiedzy odpowiada na tę późniejszą potrzebę informacyjną, odrębną od wyboru nowych historii.

Przykład OpenRouter jest użyteczny jako punkt wyjścia do rozmowy o architekturze, ponieważ obowiązki te można omawiać osobno. Najsilniejsza implementacja będzie tą, której złożoność odpowiada zadaniu czytelnika.

Limity wykonania wymagają interpretacji operacyjnej

Mechanizmy kontroli warunków zatrzymania OpenRouter pozwalają deweloperom zakończyć wykonanie zgodnie z liczbą kroków, użyciem tokenów, wydatkami lub niestandardowymi warunkami. Token to jednostka tekstu przetwarzana przez model językowy. Dokumentacja wskazuje, że tablica warunków zatrzymuje wykonanie po spełnieniu dowolnego warunku.

Dokumentacja opisuje także opcjonalną końcową odpowiedź po tym, jak warunek zatrzymania przerwie sekwencję wywołań narzędzi. To zachowanie ma znaczenie przy interpretacji limitu. Zakończenie dalszej eksploracji i utworzenie czytelnej odpowiedzi to odrębne operacje.

Reguła zatrzymania definiuje zachowanie wykonania; nie oznacza, że aplikacja ukończyła zamierzone zadanie.

Wyobraź sobie watchera, który zatrzymuje się, zanim oceni wszystkie dostępne materiały. Uruchomienie mogło przestrzegać skonfigurowanej polityki, a mimo to zapewnić niepełne pokrycie. Użytkownik potrzebuje sposobu, by odróżnić taki wynik od ukończonej kontroli.

Samo podsumowanie może ukrywać tę różnicę. Język naturalny często brzmi tak, jakby zadanie zostało zakończone, zwłaszcza gdy jest prezentowany bez otaczających go informacji o stanie. Aplikacja nie powinna pozwalać, by dopracowany tekst sugerował pracę, której zapis wykonania nie potwierdza.

To kwestia interfejsu w równym stopniu co inżynierii. Czytelnik nie powinien musieć rozumieć wewnętrznej wymiany komunikatów modelu, aby rozpoznać niekompletne zestawienie. System może prostym językiem poinformować, że zakończył działanie przedwcześnie.

Ograniczenia wpływają też na to, co deweloperzy mogą twierdzić o wydajności. Krótkie uruchomienie może oznaczać zdyscyplinowane wykonanie, łatwe dane wejściowe albo przedwczesne zakończenie. Te wyjaśnienia mają odmienne konsekwencje dla użyteczności.

Porównania między konfiguracjami powinny więc utrzymywać stałą potrzebę informacyjną. Konfiguracja, która tworzy krótsze odpowiedzi przez pomijanie istotnych historii, niekoniecznie ulepszyła produkt. Zmieniła zakres dostarczanej pracy.

Rozliczenia operacyjne powinny uwzględniać ludzki wysiłek wokół uruchomienia. Ktoś może potrzebować przejrzeć niepewne wybory, naprawić uszkodzoną integrację lub zatwierdzić proponowane powiadomienia. Działania te wpływają na to, czy watcher rzeczywiście oszczędza uwagę.

Nie podważa to monitorowania opartego na modelu. Zmienia podstawę jego oceny. Użyteczne pytanie brzmi, czy połączony system ogranicza powtarzalną pracę, zachowując jednocześnie informacje, które czytelnik uznaje za ważne.

Samouczek OpenRouter Agent SDK należy czytać z uwzględnieniem tego rozróżnienia. Jego mechanizmy kontroli wykonania są istotne, lecz rezultat biznesowy pozostaje zależny od konkretnej aplikacji. Deweloperzy nadal potrzebują dowodów z własnych tematów, warunków operacyjnych i od własnych czytelników.

Kolejna kwestia dotyczy tego, jak awarie ujawniają się z upływem czasu. Ograniczone uruchomienie, które wielokrotnie zawodzi na tym samym etapie, może pozostawać indywidualnie kontrolowane, a jednocześnie zapewniać niewielką trwałą wartość. Powtarzalne wykonywanie wymaga powtarzalnych dowodów skutecznej pracy.

Dowody te nie muszą przytłaczać czytelnika. Zwięzły zapis operacyjny może wyjaśnić, czy pobieranie się powiodło, czy przetwarzanie zostało ukończone oraz czy nadal potrzebna jest interwencja. Szczegółowe zapisy techniczne mogą pozostać dostępne do analizy.

Chodzi o połączenie ograniczeń ze znaczeniem. Deweloperzy muszą wiedzieć, co się zatrzymało, użytkownicy muszą wiedzieć, co zostało osiągnięte, a operatorzy muszą wiedzieć, co wydarzy się dalej.

Zatwierdzenie przez człowieka zmienia znaczenie pracy bez nadzoru

Dokumentacja OpenRouter dotycząca zatwierdzania i trwałości opisuje requireApproval, które może wstrzymać wywołanie wrażliwego narzędzia. Opisuje również StateAccessor, interfejs do ładowania i zapisywania stanu rozmowy. Aplikacje mogą wznawiać zapisaną pracę, korzystając z decyzji zatwierdzenia lub odrzucenia powiązanych z konkretnymi wywołaniami narzędzi.

Weryfikacja przez człowieka staje się użyteczna, gdy reguluje konkretne proponowane działanie i zapewnia wystarczający kontekst do jego oceny.

Prośba o „zezwolenie na powiadomienia” pozostawia znaczną niejednoznaczność. Prośba pokazująca proponowaną wiadomość, jej miejsce docelowe oraz wspierające ją dowody daje recenzentowi realną decyzję do podjęcia. Różnica wpływa zarówno na bezpieczeństwo, jak i użyteczność.

Recenzent musi rozumieć, dlaczego wiadomość zasługuje na uwagę. Tytuł i pewne siebie wyjaśnienie mogą być niewystarczające, jeśli leżące u ich podstaw twierdzenie pozostaje niepewne. Zatwierdzenie nie powinno po cichu przenosić odpowiedzialności za brakujące badania na osobę naciskającą przycisk.

Tworzy to obowiązek projektowy dotyczący dowodów. Aplikacja powinna zachować wystarczający kontekst, aby recenzent mógł odróżnić potwierdzone ogłoszenie od spekulacji. W przeciwnym razie interfejs zatwierdzania może stać się czynnością czysto ceremonialną.

Ta sama kwestia dotyczy pilności. Jeśli asystent oznacza zwykłe wydarzenia jako pilne, recenzenci uczą się ignorować jego prośby. Osłabia to znaczenie bramki zatwierdzania, nawet gdy techniczne wstrzymanie działa poprawnie.

Istnieje również kompromis związany z dostępnością. W przykładzie OpenRouter prośba o zatwierdzenie bez odpowiedzi wstrzymuje dalsze monitorowanie. Projekt czyni nierozwiązaną pracę widoczną, ale wiąże obserwację z dostępnością recenzenta.

Dla osobistego asystenta do czytania może to być akceptowalne. Dla zespołu zależnego od ciągłego pokrycia tworzy to decyzję polityczną. Organizacja musi zdecydować, czy oczekujące komunikaty powinny blokować świeżą obserwację.

Rozdzielenie tych działań wprowadza własne obowiązki. Nowa praca potrzebuje wyraźnej tożsamości, oczekujące prośby potrzebują trwałego przechowywania, a decyzje muszą dotrzeć do zamierzonego działania. Dodatkowa współbieżność jest użyteczna tylko wtedy, gdy jej zachowanie pozostaje zrozumiałe.

Wymiar bezpieczeństwa opiera się na tej samej zasadzie. Prompt injection to próba sprawienia, by instrukcje osadzone w zewnętrznych treściach przekierowały system AI. Watcher wiadomości konsumuje materiały pisane przez osoby spoza kontroli operatora.

Złośliwy nagłówek powinien pozostać materiałem do oceny. Nie powinien zyskiwać autorytetu wyłącznie dlatego, że pojawia się w wyniku wyszukiwania. Ograniczenie dostępnych działań i wymaganie weryfikacji zmniejszają skutki błędnej interpretacji.

Ograniczenia te nadal wymagają odpowiedniego zakresu. Prywatne wyniki mogą zawierać wprowadzające w błąd materiały, nawet gdy zewnętrzna komunikacja pozostaje zablokowana. Bramki weryfikacyjne chronią określoną granicę działania; nie poświadczają wszystkiego, co powstało przed tą granicą.

Mechanizm zatwierdzania pozostawia też bez odpowiedzi pytania organizacyjne. Kto weryfikuje prośby podczas nieobecności? Kiedy prośba staje się nieaktualna? Czy stare powiadomienie powinno nadal kwalifikować się po zmianie leżącej u jego podstaw historii?

To zwyczajne pytania produktowe o bezpośrednich konsekwencjach dla pracy bez nadzoru. Najsilniejsze systemy czynią swoje odpowiedzi widocznymi, zanim użytkownicy zaczną na nich polegać.

Następnie obserwuj pokrycie, odzyskiwanie działania i obciążenie weryfikacją

API wyszukiwania Hacker News przypomina, że monitorowanie zaczyna się od powierzchni pobierania danych. API, czyli interfejs programowania aplikacji, udostępnia informacje poprzez zdefiniowane żądania. Każdy watcher zbudowany wokół takiej powierzchni zależy od tego, co zwracają jego żądania.

Kolejne dowody powinny dotyczyć użytecznego pokrycia, niezawodnego odzyskiwania działania i zrównoważonej ludzkiej uwagi.

Pierwszym sygnałem do obserwowania jest jakość selekcji w realistycznych okresach czytania. Deweloperzy powinni analizować, co watcher znalazł, co odrzucił oraz jakie istotne materiały nigdy nie zostały wzięte pod uwagę. Dopracowane zestawienie samo w sobie nie może ujawnić pominiętej części.

W przypadku watchera dla deweloperów taka weryfikacja powinna odzwierciedlać rzeczywiste priorytety zamierzonego czytelnika. Znaczenie techniczne, istotność wydania i popularność dyskusji to powiązane, lecz odmienne oceny. Popularna historia nie zasługuje automatycznie na przerwanie pracy.

Dowody, że model wychwytuje użyteczne materiały pomijane przez prostsze filtrowanie, wzmocniłyby argument za monitorowaniem kierowanym przez model. Dowody, że głównie przepisuje już wystarczający wynik wyszukiwania, przemawiałyby za prostszą architekturą.

To również miejsce, w którym widoczne stają się ograniczenia źródeł. Lepsza ocena nie zrekompensuje materiału, który nigdy nie został pobrany. Ocena powinna oddzielać pokrycie wyszukiwania od decyzji modelu dotyczących otrzymanego materiału.

Drugim sygnałem jest odzyskiwanie działania przy realistycznych przerwaniach. OpenRouter informuje o ćwiczeniach dotyczących restartów i awarii, ale pozostają one demonstracjami zgłaszanymi przez firmę. Ustalają, co wydawca twierdzi, że przetestował, a nie niezależną ocenę niezawodności.

Dalsze dowody powinny pokazać, czy przerwana praca wznawia się bez wprowadzania użytkownika w błąd. Czy system zachowuje oczekującą decyzję? Czy operator może zrozumieć, czy zewnętrzne działanie nastąpiło? Czy odzyskiwanie zachowuje informacje potrzebne do zbadania błędu?

Ważnym rezultatem jest spójna historia. Czytelnik nie powinien otrzymywać sprzecznych wyjaśnień tego, co zrobił watcher. Operator nie powinien musieć zgadywać, czy powtórzenie uruchomienia powtórzy działanie o istotnych konsekwencjach.

Udane ćwiczenia odzyskiwania działania wzmocniłyby argument za cyklicznym użyciem. Awarie pozostawiające niejednoznaczne dostarczenie lub brakujące zapisy wskazywałyby, gdzie potrzebna jest dalsza inżynieria aplikacji.

Trzecim sygnałem jest obciążenie ludzką weryfikacją. Prośby o zatwierdzenie powinny zasługiwać na swoje miejsce w dniu czytelnika. System, który stale prosi o interwencję, przeniósł pracę do innego interfejsu, zamiast ją usunąć.

Użyteczne dowody pokazałyby, że recenzenci mogą podejmować świadome decyzje bez odtwarzania całego procesu badawczego. Powinny również pokazać, że ignorowane prośby nie tworzą niewidocznych problemów operacyjnych.

Sygnały te dają deweloperom ugruntowany sposób oceny kolejnych zmian SDK i raportów aplikacji. Więcej funkcji ma znaczenie wtedy, gdy ulepszają zidentyfikowaną słabość. Dodatkowa złożoność bez wyraźniejszych rezultatów utrudnia ocenę produktu.

Przed przyjęciem samouczka OpenRouter Agent SDK jako punktu wyjścia do produkcji wybierz zadanie monitorowania z jasno określonym czytelnikiem i celem. Opisz wydarzenia zasługujące na uwagę, błędy, które miałyby znaczenie, oraz działania wymagające weryfikacji. Następnie porównaj otrzymane zestawienie z tym, czego ów czytelnik rzeczywiście potrzebował podczas zwykłej pracy. Zachowaj dostęp do linków źródłowych, sprawdzaj odrzucone materiały i uwzględnij w ocenie spokojne okresy. Zapytaj, czy watcher ogranicza powtarzalne sprawdzanie, nie utrudniając jednocześnie zauważania ważnych pominięć. Jeśli odpowiedź brzmi tak, stopniowo rozszerzaj jego odpowiedzialność i zachowaj tę samą przejrzystość. Które powtarzalne zadanie informacyjne stałoby się wyraźnie łatwiejsze, gdyby obserwacja trwała nadal, a decyzje o istotnych konsekwencjach pozostawały możliwe do zweryfikowania?