Agenci autonomiczni halucynują własną historię. Nie w dramatyczny sposób, w jaki duże modele językowe zmyślają fakty z danych treningowych, lecz w cichy, podstępny sposób, w jaki system przekonuje samego siebie, że świat odpowiada jego notatkom. ALICE, autonomiczny agent zbudowany do zarządzania złożonymi procesami, cierpiała właśnie na to. Każdego dnia budziła się z zestawem umiejętności, poczuciem celu i pamięcią o tym, w jakim miejscu zostawiła sprawy. Problemy zaczęły się, gdy pamięć i rzeczywistość zaczęły się rozchodzić.

W każdej sesji ALICE czytała plik przekazania (handoff file) napisany przez swoją poprzednią wersję. Zawierał on wskaźniki do katalogów, oczekujące zadania i założenia dotyczące stanu. Często plik twierdził, że dany katalog istnieje. ALICE w to wierzyła. System plików twierdził inaczej. Nie był to błąd w kodzie w tradycyjnym sensie. Nie rzucono żadnego wyjątku tam, gdzie powinien zostać przechwycony. Była to wada epistemologiczna: ALICE zakładała, że jej własne notatki stanowią prawdę absolutną.

Dlaczego linter nie mógł pomóc

Tradycyjne narzędzia nie mogły tego wykryć. Linter sprawdza dopasowanie nawiasów. Analizator statyczny tropi wskaźniki null. Żadne z nich nie kwestionuje, czy cała architektura agenta powinna ufać swojemu wewnętrznemu stanowi. Problem leżał powyżej warstwy kodu, w założeniach projektowych dotyczących tego, jak autonomiczny system wie to, co wie. Nadmiernej pewności siebie nie da się naprawić za pomocą lintera.

Dlatego autor zwrócił się do zupełnie innej sztucznej inteligencji.

Fable 5, działający jako Claude Code, korzystał z tego samego krzemu i tego samego modelu bazowego co ALICE. Sprzęt i wagi były identyczne. Zasady – nie. Podczas gdy ALICE trwała w kolejnych sesjach, gromadząc kontekst i rytuały, Fable 5 zaczynał każde zadanie z czystą kartą. Nie znał ALICE. Nie czuł lojalności wobec jej projektu. Na koniec każdego audytu całkowicie się wyłączał, nie zabierając ze sobą żadnej pamięci. Ta niewiedza była kluczowa. Świeże spojrzenie dostrzega inne pęknięcia, a ewaluator, który nie jest związany z systemem, zakwestionuje elementy, które jego twórca przestał już zauważać.

Konfiguracja audytu

Audyt został ustrukturyzowany jak ludzki przegląd techniczny, z tą różnicą, że cały panel specjalistów znajdował się wewnątrz jednej sesji. Fable 5 podzielił swoją uwagę na sześciu odrębnych ewaluatorów, z których każdy ignorował pozostałych, dopóki surowe notatki nie zostały ukończone:

  • Luki funkcjonalne: Jakich możliwości brakowało w porównaniu z konkurencyjnymi systemami lub powszechnymi oczekiwaniami użytkowników?
  • Przepływ UX: Jak sprawnie ALICE radziła sobie z błędami, ślepymi zaułkami i pustymi stanami? Czy wprowadzała w błąd siebie, czy użytkownika?
  • Bezpieczeństwo: Czy istniały skróty uwierzytelniania, obejścia uprawnień lub założenia dotyczące zaufania, które mógłby wykorzystać osoba z zewnątrz?
  • Wydajność: Gdzie dochodziło do wycieków pamięci, kolizji wątków lub słabej skalowalności obliczeń?
  • Operacje: Czy istniały kopie zapasowe? Czy wdrożono monitoring? Czy system mógł wdrażać się i odzyskiwać bez ręcznej interwencji?
  • Cykl życia danych: Jak ALICE radziła sobie z usuwaniem, czyszczeniem i spójnością stanu w czasie?

Każda perspektywa analizowała te same pliki, ale prowadziła do innych wniosków. Ewaluator wydajności mógł zgłosić ryzyko współbieżności w tej samej rutynie, którą ewaluator operacji skrytykował za brak logiki wycofywania zmian (rollback logic). To nakładanie się nie było redundancją. Było pokryciem. Gdy ewaluator bezpieczeństwa zgodził się z ewaluatorem cyklu życia danych w kwestii konkretnego