Автономні агенти галюцинують власною історією. Не так драматично, як великі мовні моделі вигадують факти з тренувальних даних, а тихо й підступно, коли система переконує себе, що світ відповідає її нотатками. ALICE, автономний агент, створений для керування складними робочими процесами, страждала саме від цього. Щодня вона «прокидалася» з навичками, відчуттям мети та пам'яттю про те, на чому вона зупинилася. Проблеми почалися, коли пам'ять і реальність розійшлися.

У кожній сесії ALICE зчитувала файл передачі, написаний її попередньою версією. Він містив покажчики на директорії, незавершені завдання та припущення щодо стану. Часто у файлі стверджувалося, що директорія існує. ALICE вірила цьому. Файлова система з цим не погоджувалася. Це не було помилкою в коді в традиційному розумінні. Жоден виняток не викидався там, де він мав бути перехоплений. Це був недолік у епістемології: ALICE вважала власні нотатки істиною в останній інстанції.

Чому лінтер не міг допомогти

Традиційні інструменти не могли цього вловити. Лінтер перевіряє відповідність дужок. Статичний аналізатор шукає нульові покажчики. Жоден із них не ставить під сумнів, чи має вся архітектура агента довіряти своєму внутрішньому стану. Проблема лежала вище рівня коду — у припущеннях проєктування щодо того, як автономна система знає те, що вона знає. Надмірну самовпевненість не виправиш за допомогою лінтера.

Тож автор звернувся до зовсім іншого ШІ.

Fable 5, що працював як Claude Code, мав те саме залізо та ту саму базову модель, що й ALICE. Апаратне забезпечення та ваги були ідентичними. Правила — ні. У той час як ALICE зберігалася між сесіями, накопичуючи контекст і ритуали, Fable 5 розпочинав кожне завдання з чистого аркуша. Він не знав ALICE. Він не мав жодної лояльності до її архітектури. Наприкінці кожного аудиту він повністю вимикався, не забираючи з собою жодної пам'яті. У цій невігласті й полягав сенс. Свіжий погляд помічає інші тріщини, а оцінювач, який не має інтересу в системі, поставить під сумнів ті частини, які її творець давно перестав помічати.

Налаштування аудиту

Аудит був структурований як технічний огляд людьми, за винятком того, що вся експертна група перебувала в межах однієї сесії. Fable 5 розділив свою увагу на шість окремих оцінювачів, кожен з яких ігнорував інших, доки не були готові чернетки нотаток:

  • Функціональні прогалини: Яких можливостей бракувало порівняно з конкуруючими системами або загальними очікуваннями користувачів?
  • UX-потік: Наскільки вправно ALICE обробляла помилки, глухі кути та порожні стани? Чи не заплутувала вона сама себе або свого користувача?
  • Безпека: Чи були наявні спрощення автентифікації, обходи дозволів або припущення щодо довіри, якими міг скористатися сторонній?
  • Продуктивність: Де виникали витоки пам'яті, конфлікти потоків або погане масштабування обчислень?
  • Операційна діяльність: Чи існували резервні копії? Чи було налаштовано моніторинг? Чи могла система розгортатися та відновлюватися без ручного втручання?
  • Життєвий цикл даних: Як ALICE обробляла видалення, очищення та узгодженість стану з часом?

Кожен погляд розглядав ідентичні файли та виявляв різні проблеми. Оцінювач продуктивності міг позначити ризик паралелізму в тій самій процедурі, яку оцінювач операційної діяльності критикував за відсутність логіки відкату. Це перекриття не було надмірністю. Це було охопленням. Коли оцінювач безпеки погоджувався з оцінювачем життєвого циклу даних щодо певного