Контекст AI-агента деградирует. Вот как это лечить.

Есть момент который происходит со всеми кто работает с AI-агентами больше пары недель. Агент начинает ошибаться не потому что модель стала хуже - а потому что его картина мира устарела. Он отвечает на основе того что знал месяц назад. Метрики поменялись, решения приняты, задачи закрыты - а агент этого не знает.

Это называется деградация контекста. И это не техническая проблема - это организационная.

Почему это происходит

Большинство людей начинают работу с агентом так: объясняют контекст в начале разговора, потом ещё раз, потом ещё. Каждая новая сессия - это пересказ. Через месяц это бесит. Через три - от агента отказываются.

Проблема в том что нет единой точки истины. Нет файла который представляет собой "текущее состояние" - актуальное, точное, поддерживаемое. Агент работает с тем что дают каждый раз заново, а не с тем что есть постоянно.

Решение которое работает - не умнее промпты, а другая архитектура.

Единая точка истины

В моей системе каждый проект имеет один файл - я называю его UFC (можно называть как угодно: product brief, context file, living doc). Суть одна: это не история проекта и не архив. Это снимок текущего состояния.

Что там живёт:

  • Главная метрика и где она сейчас
  • Активные инициативы и их статус
  • Ключевые решения которые приняты и закрыты с результатом (с датой и коротким почему)
  • Что работает, а что нет
  • Правила и ограничения
  • Следующие шаги

Всё. Без бэкграунда, без истории, без "как мы до этого дошли". Агент читает этот файл в начале каждой сессии - и сразу в контексте. Не нужно объяснять. Не нужно пересказывать.

Агент с чистой сессией читает это за 10 секунд и знает где проект, что важно, что открыто. Без вводных.

Когда обновлять

Это не "раз в неделю обновляй файл". Это событийная логика.

Файл обновляется когда что-то меняется по существу: приняли решение, закрыли задачу, получили новые данные, поменяли приоритет. Не по расписанию - по событию.

На практике это выглядит так: завершил сессию с агентом где что-то произошло - обновил UFC. Провёл синк с клиентом, поменялся приоритет - обновил. Пришли метрики за неделю - обновил.

Правило которое помогает не забывать: "если бы ты объяснял коллеге состояние проекта с нуля - что бы ты сказал?" То что сказал - должно быть в UFC.

Что туда не надо писать: переписку, детали обсуждений, почему три недели назад выбрали вот этот подход. Это архив. UFC - это не архив, это настоящее.

Проблема которая всё ломает: файл перестаёт обновляться

Самое частое что происходит: несколько недель всё хорошо, потом файл перестаёт обновляться. Не специально - просто некогда, потом забыл, потом уже всё равно.

Через месяц агент снова работает с устаревшей картиной. Снова ошибается. Снова раздражает.

Это точно такая же проблема как техдолг в разработке. Не возникает резко - накапливается незаметно.

Решение которое помогает: не правило "обновляй UFC", а механизм который замечает что UFC не обновлялся. Скрипт который раз в неделю проверяет дату последнего изменения каждого файла и отправляет алерт если прошло >14 дней. Не "я должен помнить" - а "система скажет когда забыл".

Разница в том что правила ломаются. Алерты - нет.

Треды как рабочий журнал

Есть ещё один слой который помогает: треды. Это файлы для каждой темы или задачи - живой журнал что происходит.

Тред - не замена UFC. Тред - это сырой материал из которого UFC собирается.

Схема: провёл работу → записал в тред (что сделано, что решено, что открыто) → ключевые вещи из треда перенёс в UFC. UFC остаётся компактным и актуальным, треды сохраняют детали.

Важный момент: треды тоже деградируют. Задача закрылась - тред висит с статусом ACTIVE. Набирается десяток таких тредов - и уже непонятно что реально открыто, что давно закрыто. Поэтому тот же принцип: скрипт раз в неделю смотрит на треды которые не обновлялись >2 недель и показывает список. Не удаляет, не закрывает - просто показывает. Решение принимает человек.

Как это выглядит как система

Итого рабочий фреймворк выглядит так:

Структура хранения:

  • Один UFC-файл на проект (снимок текущего состояния)
  • Треды для активных задач (рабочий журнал)
  • Архив не нужен - история в git или просто не нужна

Правила обновления:

  • UFC: после каждого события которое меняет состояние проекта
  • Треды: после каждой сессии где что-то произошло
  • Не по расписанию - по событию

Мониторинг свежести:

  • Проверка UFC раз в неделю (автоматически): если не обновлялся >14 дней - алерт
  • Проверка тредов раз в неделю: ACTIVE треды >2 недель без обновления - показать список
  • Не нужно помнить - система напомнит

Как агент использует:

  • Начало любой сессии: читает UFC нужного проекта
  • Новая задача: читает соответствующий тред
  • Всё остальное объяснять не нужно

Что происходит без этого

У меня недавно был аудит всей системы. Нашли: 4 из 7 UFC-файлов отсутствовали (удалились при синхронизации), 15 тредов с статусом ACTIVE не обновлялись 2-6 недель.

Система работала. Агент отвечал. Задачи выполнялись.

Просто каждый раз когда агент обращался к этим проектам - работал с неполной или устаревшей картиной. Не критично в момент. Накапливается в ошибки через несколько недель.

Готовность к работе нового агента с чистой сессии по итогам аудита: 5 из 10. Не катастрофа. Но это честная цифра.

Это фреймворк который работает потому что он простой: одна точка истины на проект, событийное обновление, автоматическая проверка свежести. Не нужна сложная инфраструктура. Нужна дисциплина - и механизм который за ней следит.

Можно начать с одного проекта и одного файла. Посмотреть что изменится через месяц.

Я пока так это вижу.

В канале показываю как эти системы устроены изнутри - живые примеры из текущих проектов