Yet Another AI Memory: только 2 из 222 диалогов потребовали пересказать прошлый контекст в проекте на 250 тыс. строк кода

Как я перестал пересказывать AI-агенту историю проекта при каждом новом диалоге — и что показал разбор 170 дней работы.

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

Например, один из диалогов начинался с такого сообщения:

В запросе всего два предложения. Я не объяснял, как устроена авторизация, почему для новой роли нельзя создавать отдельную систему входа и что у нас есть шаблон личного кабинета, который нужно развернуть. Агент сам прочитал сохранённые правила и использовал их в работе. Правило общей авторизации появилось в памяти 3 февраля. До того, как агент прочитал его 23 апреля, прошло 154 независимых диалога и 78 дней.

Проект к тому моменту был немаленьким: ERP на TypeScript с React, Next.js, NestJS и Prisma, тремя приложениями, CRM-интеграциями, генератором конструкторов смет, онлайн-подписанием документов с миниблокчейном и 11 личными кабинетами. В исходниках — почти 250 тысяч строк кода.

Позже я решил проверить своё впечатление по истории работы. В выборку вошли 222 диалога с рабочими задачами. Только в двух из них я начинал с подробного напоминания о прошлом. А в логах нашлось 1 451 чтение памяти, которую обновляли в других диалогах.

Ниже расскажу, что это изменило в работе, как была устроена память и откуда взялись цифры.

Старый диалог путался, новый не знал предыстории

У долгой работы с AI-агентом есть известная проблема: старый диалог постепенно переполняется контекстом, а новый начинает работу без истории проекта. Поэтому обычно приходится выбирать между двумя неудобными вариантами:

• Продолжать старый диалог. Расход токенов растёт, агент начинает забывать часть контекста, путаться и ошибаться.
• Открыть новый. Агент может прочитать код, но не знает истории проекта и прежних договорённостей об архитектуре, ограничениях и подходе к работе.

Продолжить работу над проектом

Старый диалог

Растёт расход токенов. Агент путается и забывает часть переписки.

Новый диалог

Код доступен, но договорённости приходится переносить.

Особенно раздражало заново обсуждать уже принятые решения. Почему авторизация общая для всех ролей? Какой компонент нужно использовать? Почему мы отказались от другого варианта?

Код показывал, что мы сделали, но далеко не всегда объяснял, почему выбрали именно такое решение. Эти объяснения оставались в старой переписке. Приходилось вспоминать их самому и пересказывать агенту.

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

Три случая, когда понадобилась история проекта

Разделить систему между компаниями и учесть прежние решения по CRM

В мае я попросил агента изучить план мультиарендности и поддоменов, затем реализовать первые два этапа. Мультиарендность здесь означает, что в одной системе работают разные компании, каждая со своими данными и пользователями.

Я дал ссылку на план и короткую команду. Заново объяснять, как работают CRM-интеграции, не стал. А там уже были важные договорённости:

• У одной компании могло быть несколько CRM-интеграций — по одной на воронку продаж. Прежнее ограничение «одна компания — одна интеграция» отменили.
• У каждой интеграции должны были быть имя и ответственный руководитель отдела продаж.
• Имя должно было быть уникальным внутри компании, а уникальность воронки проверялась отдельно в сервисе.

При разделении данных между компаниями эти правила важны. От них зависит, кому принадлежит каждая запись и как пользователь получает к ней доступ.

Агент прочитал запись о том, как устроены интеграции и какое ограничение мы отменили. Затем открыл схему базы данных Prisma и стал сверяться с кодом.

Первые два этапа успешно внедрили. Переделывать архитектуру после этого не пришлось.

В разборе кейса можно посмотреть сам запрос, прочитанную агентом запись и его следующие действия. У него также был план с требованиями к задаче, а из памяти он узнал о прежних решениях.

Запустить проверку планов и вспомнить старую проблему Cursor

В другом диалоге я хотел, чтобы субагенты проверяли каждый новый план. У каждого должна была быть своя часть:

• одному субагенту поручить базу данных;
• другому — бизнес-логику;
• затем добавить проверки интерфейса и других частей проекта.

Нужно было сделать так, чтобы эти проверки запускались при подготовке каждого нового плана.

Ранее при внедрении новых правил Cursor не всегда автоматически подключал их. Тогда мы решили временно перенести короткие команды запуска в User Rule — пользовательские правила редактора.

В новом запросе я эту историю не пересказывал. Агент нашёл прежнее решение и сам напомнил о баге Cursor с alwaysApply. Обсуждая, где разместить команду запуска новых проверок, он предложил в том числе добавить её в User Rule.

Спустя полтора месяца агент вспомнил, почему мы настраивали запуск правил именно так, и учёл эту причину, когда понадобилось настроить новые проверки.

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

Создать ещё один кабинет без очередного дубля авторизации

Третий случай — запрос из начала статьи: создать личный кабинет руководителя отдела продаж управляющей компании.

Для разных ролей в ERP уже была общая система авторизации. Но при создании первых кабинетов агент дважды обходил её: делал отдельные модули входа и дублировал существующее решение.

Мы зафиксировали в памяти правило использовать общую авторизацию. После этого такие случаи больше не повторялись.

Когда понадобился кабинет руководителя, агент прочитал это правило и использовал общую авторизацию. Напоминать о ней в запросе мне не пришлось.

Кабинет запустили без ошибок. Проблем после запуска тоже не возникло.

В материалах кейса есть исходный запрос и правила, которые прочитал агент. После этого он продолжал работать над задачей: в логах осталось ещё 133 вызова инструментов.

При разборе всех трёх случаев проверяли, что именно прочитал агент и что я успел написать ему до этого. Это позволяет увидеть, какие детали он узнал из памяти.

Что изменилось в повседневной работе

Важно понимать: сейчас я описываю кейсы выше как что-то важное, но в процессе работы с агентом я об этом даже не задумывался. Это происходило где-то на фоне, без моего погружения. Так я работал месяцами, и, как выяснилось в процессе исследования, таких запросов к памяти в итоге набралось больше 1 400.

В исследование вошли 272 диалога Cursor с 3 февраля по 22 июля 2026 года — 170 календарных дней. Из них 222 были рабочими, а 50 относились к информационным и служебным задачам.

Самыми полезными для меня оказались три изменения:

1. Можно было спокойно закрыть перегруженный диалог. Следующий подхватывал работу. Не нужно было держаться за старую переписку из страха потерять контекст.
2. Не приходилось заново договариваться об одном и том же. Агент мог прочитать, какую архитектуру мы выбрали, какие ограничения учитываем и как договорились работать.
3. Агент узнавал о прежних ошибках. В следующем диалоге он мог прочитать, что уже пошло не так, почему и как мы это исправили.

В итоге стало практически неважно, в каком диалоге продолжать работу. В новом или старом агент подхватывал сохранённые наработки и продолжал с того места, где мы остановились.

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

В активный день я мог открывать до 20 новых диалогов

Чтобы проверить это по истории работы, я посчитал только новые рабочие диалоги, начатые в каждый день. Диалоги, открытые раньше и использованные повторно, в эту статистику не входят.

В расчёт вошли 222 новых рабочих диалога, распределённых по 45 активным дням. В среднем я начинал 4,93 новых диалога за активный день. Медиана — 3 диалога. Разница между этими числами появилась из-за нескольких особенно насыщенных дней.

В 37 из 45 активных дней (82,2%) начиналось два и более новых диалога. В 25 днях (55,6%) — три и более. В 16 днях (35,6%) — пять и более. Максимум составил 20 новых диалогов за один день.

В эти же дни я мог возвращаться в старые диалоги. Текущий набор данных не позволяет посчитать такие возвращения, поэтому приведённые значения показывают только нижнюю границу реального числа диалогов, в которых шла работа.

Источник: распределение новых рабочих диалогов по активным дням.

Именно этого мне хотелось от памяти. Сэкономленные часы и токены я отдельно не считал. Зато по истории работы можно проверить, как часто приходилось пересказывать прошлое и к каким записям обращался агент в следующих диалогах.

Память стала принадлежать проекту, а не диалогу.

Как это работало: протокол, Markdown и Git

Система состояла из четырёх частей:

• Протокол — инструкции, когда читать память и что сохранять после работы.
• Markdown-файлы — состояние проекта, решения, ошибки и история задач.
• Обычные файловые инструменты — агент читал и редактировал память так же, как остальные файлы проекта.
• Git — версии записей и история изменений.

Отдельный сервер, векторная база или специальный API для памяти не понадобились.

Для меня эта простота — одно из главных преимуществ. Память легко встроить в работу с репозиторием. Любую запись можно открыть, прочитать, исправить и сравнить с предыдущей версией.

Если контекст терялся, я мог проверить конкретные вещи:

• Сохранили ли нужный факт?
• В какой файл он попал и можно ли найти этот файл по карте проекта?
• Прочитал ли его агент?
• Актуальна ли запись?

Больше всего внимания потребовала организация информации: что считать текущим состоянием, где хранить историю и как не смешивать их.

Сначала карта проекта, затем нужные подробности

В начале диалога агент читал короткую сводку: что сейчас делаем, что мешает двигаться дальше и где искать подробности. Рядом был список принятых решений со ссылками на их описание. Несколько последних журналов диалогов помогали понять, что происходило недавно.

После этого агент переходил к материалам по своей задаче.

Файлы были разложены так:

docs/memory/
├── PROJECT_STATUS.md
├── DECISIONS.md
├── TECH_DEBT.md
├── status/
├── decisions/
├── errors/
└── dialogs/

Эти записи нужно обновлять по-разному. Статус должен описывать проект сегодня, поэтому он меняется вместе с работой. Решение может действовать долго, а история ошибки — понадобиться через несколько месяцев. В журнале при этом остаются все этапы, в том числе шаги, от которых мы уже отказались.

Я старался хранить каждый факт в одном основном месте. Например, подробно описать решение в отдельном файле, а в общем списке оставить короткую запись со ссылкой. Если мы пересматривали решение, править нужно было этот файл.

Так агент мог выбирать записи по своей задаче. Для CRM — открыть статус интеграций и связанные решения. Для входа в систему — правила авторизации и известные ошибки. Из памяти он также мог перейти по ссылке к нужному плану или исходнику.

Чтение и обновление стали частью работы

Цикл был простым:

1. В начале нового диалога короткая команда направляла агента к протоколу.
2. Агент читал общий статус, реестр решений и три последних журнала диалогов.
3. Открывал подробности по теме задачи и приступал к работе.
4. В конце итерации фиксировал запрос, выполненную работу и результат.
5. Проверял, что изменилось, и обновлял нужные записи: статус работы, решение, ошибку, отложенную задачу или препятствие, которое мешало двигаться дальше.

Новая сессияПоставить задачу

→

Чтение нужной памятиОткрыть контекст

Статус, решения и материалы по задаче.

→

Работа и проверка результатаВыполнить и проверить

Сверить результат с требованиями проекта.

↓

Запись результатаОбновить нужный слой

Зафиксировать результат, решение, ошибку или отложенную задачу.

←

Версия в GitСохранить изменения

Память и материалы проекта остаются в истории.

←

Следующая задачаПродолжить работу

↑

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

Что показала история работы

Чтобы проверить работу памяти, сравнили историю Cursor с версиями файлов в Git: что агент сохранял, что потом читал и какой текст получал. Скрипты посчитали диалоги, записи и чтения. Первые запросы распределял по категориям ChatGPT. В выбранных кейсах дополнительно разбирали содержание записей и дальнейшие действия агента.

Здесь — основные результаты. Подробные правила подсчёта собраны в методике.

Почти каждый рабочий диалог начинался без пересказа прошлого

В исследовании 272 независимых диалога: 222 с рабочими задачами и 50 информационных или служебных. Первые сообщения всех 272 диалогов начинались с запроса человека; рабочие и остальные запросы разделены по содержанию.

Память читали и там, и там:

Память использовалась и в рабочих диалогах, и в информационных или служебных. Для подсчёта того, как часто приходилось вручную восстанавливать прошлое состояние, важна рабочая часть выборки — 222 диалога.

Распределение получилось таким:

• 113 запросов — без явной передачи прошлого контекста. Это 50,90% рабочих запросов.
• 88 — со ссылкой на план или другой документ.
• 19 — с коротким упоминанием предыдущей работы.
• 2 — с подробным напоминанием о прежних решениях или состоянии проекта.

В сумме первые три группы — 220 из 222 запросов, или 99,10%. В этих диалогах не понадобилось подробно пересказывать прошлое.

Ссылка на план, конечно, тоже передаёт контекст. Но написать «реализуй следующие этапы этого плана» намного проще, чем заново объяснять историю работы. На графике эти случаи показаны отдельно.

Эта доля показывает, как часто я начинал рабочий диалог без подробного напоминания о прошлом. Долю успешно выполненных задач здесь не считали. В работе агент мог пользоваться и памятью, и планами, и кодом.

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

Память выросла до 300 файлов

Постепенно в памяти накопился большой архив:

Общий объём на финальном срезе — 1 140 450 символов.

Большая часть этого объёма приходилась на журналы диалогов: 263 файла и 996 507 символов. В остальных 37 файлах хранились статусы, решения, ошибки, правила, архитектура и другие рабочие разделы. Вместе они занимали 143 943 символа.

Источник: итоговые показатели роста памяти.

Агент читал небольшую часть архива

За один диалог агент обычно читал лишь небольшую часть памяти. Медиана — 1,99% доступных файлов памяти: в половине диалогов, для которых удалось сделать расчёт, он читал не больше этой доли.

• В 90% диалогов она не превышала 12,82%.
• Максимальная доля — 44,44%: в 19-м диалоге агент прочитал 8 из 18 доступных файлов.
• Во всех диалогах, где было известно, сколько файлов доступно на старте, агент обходился частью архива.

Максимум пришёлся на самое начало работы, когда память только накапливалась. Сохранённых файлов было мало, поэтому для очередной задачи требовалась заметная часть уже записанного опыта. На стартах диалогов со 2-го по 20-й медианная доля составляла 27,78%.

По мере роста архива доля быстро снижалась. В последних 30 диалогах медианный размер памяти составлял 289 файлов, а агент читал медианно четыре файла — 1,38%. Накопленный опыт рос, но для каждой отдельной задачи требовалась лишь небольшая его часть. Это хорошо видно на графике.

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

Поэтому я отдельно рассмотрел только основные разделы памяти — без docs/memory/dialogs/**. Их объём вырос с 14 539 до 143 943 символов, то есть почти в десять раз.

В начале, со 2-го по 20-й диалог, медианный объём этих разделов составлял 20,8 тысячи символов. Агент обращался к ним лишь в 5 из 19 диалогов. Когда чтение происходило, медианный объём составлял 4,4 тысячи символов — около 21% от медианного доступного объёма.

В последних 30 диалогах основные разделы занимали уже медианные 136 тысяч символов. Агент читал их в 22 диалогах из 30, но медианный объём чтения по всему периоду составил 4,26 тысячи символов. Это около 2,96% доступного объёма. Если считать только диалоги с чтением, медиана получилась 5,4 тысячи символов — около 4,0% от доступного объёма.

Связь между размером основных разделов и объёмом чтения была слабой: коэффициент корреляции Пирсона — 0,26, ранговая корреляция Спирмена — 0,27. Объём памяти рос, но объём прочитанного не рос вместе с ним: для конкретной задачи агент выбирал нужные записи.

Для задачи по интеграциям можно было открыть нужные записи и не загружать всю историю интерфейсов и инфраструктуры. Карта проекта помогала выбрать, что читать.

Доля файлов не равна экономии токенов: у файлов разная длина. Полного расхода токенов в снимке истории нет.

Источники: доля прочитанных файлов и объём памяти и чтения без журналов диалогов. Для первого диалога нет стартового Git-среза, поэтому долю чтения удалось рассчитать для 271 диалога.

Записи возвращались в работу спустя месяцы

В логах нашлась 1 451 запись о чтении памяти, которую до этого обновили в другом диалоге. Такие чтения произошли в 240 диалогах.

Чаще требовались недавние записи. Но часть знаний возвращалась намного позже:

• медианная дистанция — 4 диалога;
• 90-й перцентиль — 50 диалогов;
• максимальная дистанция — 191 диалог.

Для большинства чтений промежуток был небольшим: в 90% случаев, где удалось его определить, с последнего изменения файла прошло не более 20 полных дней. Максимум — 81 день. Иногда агенту требовалось вернуться почти на три месяца назад.

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

Источник: расчёт чтений и расстояний между диалогами. Для 1 384 из 1 451 чтений удалось определить расстояние в диалогах.

Исправленные ошибки перестали возвращаться

По моим наблюдениям, повторяющихся ошибок стало кратно меньше. Я не могу вспомнить случая, когда ошибка, корректно зафиксированная в памяти, потом повторилась.

Случалось другое: после моей корректировки агент не распознавал проблему как ошибку и не сохранял её. Тогда она могла вернуться. После прямой просьбы добавить правило в память такие повторы прекращались.

История с дублями авторизации — конкретный пример этого поведения.

Процент снижения ошибок я отдельно не измерял.

По истории работы можно проверить и то, как часто агент читал записи об ошибках и решениях:

В журнале чтений есть отдельная строка на каждое обращение к файлу. По нему построен следующий график:

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

Источник графика: журнал междиалоговых чтений Cursor.

Ещё несколько задач из той же истории

В семи рабочих эпизодах агент прочитал прежнюю запись, которая относилась к новой задаче. Важные детали из неё я перед чтением не пересказывал.

В последнем столбце показано, что произошло дальше. Часть продолжений видна в логах. Результаты внедрения мультиарендности, проверок планов, кабинета руководителя и PDF-подписания я подтвердил по своей работе над проектом.

Подробные разборы первых трёх эпизодов приведены в соответствующих материалах по кейсам выше.

Где всё-таки приходилось вмешиваться

Два диалога, в начале которых мне пришлось подробно напомнить о прошлом, касались одной задачи: переименовать «Регионы» в «Города».

В диалоге 227 я напомнил, что мы уже договорились о названии и меняли его в административном интерфейсе. В диалоге 249 снова сообщил, что название страницы и элементов осталось прежним, и попросил исправить.

Мне явно пришлось напомнить о договорённости дважды. По самим сообщениям нельзя понять причину: агент мог не сохранить решение, не прочитать его или оставить старое название на части экранов.

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

Всего получилось 149 замечаний. Из них 18 просто сообщали о повторе решения в реестре и карточке, а ещё 131 замечание требовало проверки. Например, давно не обновлявшийся статус мог оставаться верным, а путь — вести к файлу, который намеренно не хранится в Git. В списке замечаний можно посмотреть каждый случай.

Память нужно поддерживать в порядке. Если договорённость осталась только в переписке, следующий агент может о ней не узнать. А если в статус записали ошибочный вывод, он может повлиять и на следующие задачи. Такой регулярный аудит памяти считаю необходимым внедрить в будущих решениях.

Что я повторил бы в следующем проекте

1. Хранил бы память рядом с проектом. Тогда следующий агент или другой исполнитель получит и сами файлы, и объяснение того, что с ними происходило.
2. Разделял бы статус, решения и историю. Следующему диалогу должно быть понятно, что действует сейчас, а что описывает прошлое.
3. Начинал бы с короткой карты. Она помогает найти нужные подробности, когда архив уже большой.
4. Записывал бы результат сразу после работы. Пока легко вспомнить, почему приняли решение, как исправили ошибку и на чём остановились.
5. Подсказывал бы агенту, что сохранить. Если он сам не зафиксировал важное решение, ошибку или другую значимую для проекта вещь, я бы прямо попросил добавить это в память. Агент не всегда понимает, что важно именно мне и в конкретном проекте.

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

Подводя итог: работа продолжается с того места, где остановилась

Главное изменение я заметил ещё до подсчётов: новый диалог перестал требовать подготовки. Можно закончить один диалог, открыть следующий и продолжить проект.

В истории работы нашлись и короткие запросы без пересказа прошлого, и возвращения к решениям спустя месяцы. Для этого хватило файлов, понятной структуры и правил чтения и записи.

Это решение стало отправной точкой и первым слоем моей работы в рамках публичного эксперимента 0→AGI. Дальше мне интересно решить следующую задачу: как организовать работу агентов так, чтобы человеку вообще не приходилось самому управлять её продолжением через окна чатов.

Следующие слои 0→AGI

Layer 01 — Yet Another AI Memory → Next: Work-Centric AI → Then: Accumulating Experience

Следить за продолжением

Я уже собрал этот подход в отдельный skill — Memomy. Публичную alpha-версию планирую выпустить через несколько дней вместе со следующим материалом о новом слое гипотезы 0→AGI — о том, как перестать менеджерить диалоги и сосредоточиться на задачах.

Я создал отдельный Telegram-чат для обсуждения этой статьи и будущих наработок. Там же будут выходить релизы Memomy и других материалов. Если вам интересен эксперимент — присоединяйтесь, чтобы не пропустить новости.

Подробности исследования

Эта часть нужна, чтобы проверить, что именно стоит за числами.

Данные и протокол

Материалы для проверки и воспроизведения

Материалы для проверки собраны рядом со статьёй:

• Первые запросы: корпус 272 диалогов, сводка категорий.
• Память и чтения: показатели роста памяти, чтение по диалогам, доля прочитанных файлов, объём основных разделов и чтения, междиалоговые чтения и расстояния.
• Новые диалоги по дням: активность по датам, распределение за активные дни и сводка.
• Воспроизводимость: скрипт пересборки реестра расстояний кейсов и контрольные суммы пакета.

Все числа в статье получены на том протоколе, с которым я работал в Cursor. Как себя покажет более универсальная версия на других площадках, ещё предстоит проверить.

Публичная обезличенная копия материалов приложена к статье; состав, способ редактуры и ограничения описаны в README пакета. Скрипт полного пересчёта корпуса не входит в пакет: для него нужны закрытые исходные данные.