Долгая сессия с coding‑агентом даёт больше, чем код. Вы заметили баг, но сейчас нет времени им заниматься. Вам пришла идея для новой фичи. «Надо бы ещё…», с которым агент согласился. Потом сессия уезжает вверх, контекст сжимается или терминал закрывается, и идея пропадает. «Потом» не наступает, потому что его никто не помнит.

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

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

Проскроллить назад

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

Файл заметок в репозитории

NOTES.md, CLAUDE.md или собственная память агента. Хорошо для фактов, связанных с проектом: описания флагов, с которыми собирается билд, особеннсоти в скрипте деплоя. Для задач файл не годится: у строки нет статуса, нет срока, и никто её не закрывает.

Я попробовала пойти дальше с ai‑tree — это дерево идей на каждую сессию, которое рисуется на локальной странице. В CLAUDE.md я попросила агента держать его в актуальном состоянии. В длинных сессиях он забывал. Версия, которая более‑менее работает, читает лог сессии наблюдателем снаружи агента. Просить агента «помни сам» в длинной сессии бесполезно, я проверила.

ai-tree: дерево идей одной сессии, с краткой сводкой и ветками, которые из неё выросли; у каждой статус: не тронута, в работе, сделана
ai‑tree: дерево идей одной сессии, с краткой сводкой и ветками, которые из неё выросли; у каждой статус: не тронута, в работе, сделана

Встроенный список задач агента

У Claude Code он есть. Я включила его (CLAUDE_CODE_ENABLE_TODO_TOOLS=1), посмотрела, где он всё хранит (~/.claude/tasks/<session>/, по одному JSON на задачу, новая сессия видит старый список), и больше не возвращалась. Список живёт внутри агента. Я не ищу свои планы внутри агента, а никто другой туда заглянуть вообще не может.

Jira, когда это работа в компании

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

GitHub Issues плюс доска Projects

Это мой личный вариант, и он заслужил отдельную картинку. В проекте, который я делаю вместе с агентом, каждое «потом» становится issue, а issues лежат на доске GitHub Projects с двумя исполнителями: owner:you для того, что могу сделать только я (зарегистрировать приложение, принять решение, опубликовать), и owner:claude для кода и документации. Агент на этой доске секретарь. Он заводит карточку, даёт мне ссылку, двигает статус через gh project item‑edit, а закрытое issue означает «сделано». Я только закрываю. Если хотите настроить себе также (с метками и командами gh), можно скормить вашему агенту вот эту историю: The Relay Board: my agent runs the GitHub kanban, I just close my cards.

Relay Board: одна доска GitHub Projects
Relay Board: одна доска GitHub Projects

В чём плюсы? Доска может быть публичной, в моём случае другой пользователь нашёл issue про перенос моего MCP‑сервера на новую ревизию спецификации и оставил три подробных комментария, включая поправку по опыту собственного проекта. В Jira такого случиться не может в принципе. Агент читает доску в следующей сессии через gh, так что «потом» переживает сессию без того, чтобы я его куда‑то вставляла.

А теперь минусы. Вот маркетинговая доска того же проекта шесть недель спустя, нарисованная по живым данным.

Такая же доска шесть недель спустя: просроченные карточки, закрытая issue, которую никто не передвинул, карточки, не тронутые 42 дня
Такая же доска шесть недель спустя: просроченные карточки, закрытая issue, которую никто не передвинул, карточки, не тронутые 42 дня

Карточка статьи, которая вышла вчера, до сих пор «In Progress». Закрытое issue стоит в «waiting». Восемь карточек по рассылке просрочены на две недели. Девять карточек не трогали больше месяца. Никто не сделал ничего плохого. Агент завёл каждую карточку, которую просили завести, а я закрыла то, что вспомнила закрыть. Просто у доски нет никого, кто отвечает за её актуальность.

Отсюда правило, к которому я пришла: доске, на которую пишет агент, нужна рутина, которую агент выполняет каждый день, без моей просьбы. По сути это агент в роли менеджера проекта, только работу он при этом не делает, он следит за доской. Утром открыть доску, написать мне, что подходит к сроку и что просрочено, закрыть карточки, которые эта сессия уже закрыла сама (такое бывает чаще, чем я думала), и спросить про всё, что не трогали три недели, ещё нужно или нет. У меня уже есть короткий утренний брифинг, который по расписанию присылает headless‑агент; проверка доски должна жить в нём, отдельным «уборщиком», который ничего не трогает, не сказав об этом. Эту часть я ещё не отполировала, поэтому картинка выглядит так, как выглядит. Кажется, я просто прихожу к стандартной команде с её ритуалами утреннего дэйлика, но на дэйлике присутствуют только агенты.

Miro: красивее, но та же устаревшая доска

Я ещё пробовала скопировать ту же доску в Miro: как mind map, как таймлайн и как матрицу «влияние / усилия», потому что агент умеет рисовать там через MCP, а виды красивее. Копии воспроизвели устаревшие статусы доски GitHub. Так что основной смысл не меняется, а красивые виды для меня не стоят того, чтобы переносить работу в другую среду.

Два вида «потом»

Идеи из сессии бывают двух видов, и, мне кажется, им нужны разные места. Задачам («сделай это») нужен статус, владелец и дата закрытия. Issues, доски, Jira и встроенный список задач сделаны под них. Отчётам о брейншторме («можно пойти вот так») нужна карта: что из чего выросло, и что отложили. Под них сделаны ai‑tree и mind map. ai‑tree у меня, впрочем, живёт только пока я о нём помню. Большинство инструментов покрывают только первый вид, а я продолжаю терять второй.

Вопросы для обсуждения

  • Куда уходят «потом» вашего агента? Переживает ли это место сессию, и может ли агент прочитать это в следующий раз?

  • Если вы работаете с Linear или Jira через MCP: остаётся ли доска актуальной без вас или превращается в свалку как моя?

  • Давал ли кто‑нибудь агенту ежедневную задачу наведения порядка? Хочу посмотреть на чужую, прежде чем строить свою.

Комментарии (29)


  1. kozliq
    27.10.2026 20:09

    Актуально как никогда, я своего попросил все папки на диске как окрщик разложить и он сам ведет дневник в Обсидиан


  1. Ka463
    27.10.2026 20:09

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


    1. Yahhi Автор
      27.10.2026 20:09

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


      1. Ka463
        27.10.2026 20:09

        У меня там все не совсем просто....
        Посмотрел код, я чуток ошибся, у меня сделано наоборот, заряд весов падает во времени, примерно за трое суток, чем дальше тем реже агент напоминает, но если тема всплывает в разговоре, или я к примеру игнорирую напоминание агента, то тема получает заряд к весам, и тем самым она не когда по сути не умирает полностью, заряд есть всегда, и так же это завязано на производственный календарь, агент может поставить себе постоянный циклический будильник, который так же влияет на заряд весов =)
        Снять тему я могу только сам, то-есть агент ее без моей отмашки сам не снимает некогда, но тут есть нюанс, как вы и сказали если тема решена агент просто уточняет, закрыть ? я даю отмашку и тема уходит в историю. а так как память у него постоянная можно всегда спросить что мы обсуждали полгода назад, и он дословно проецирует если нужно и чем это было закрыто


        1. Yahhi Автор
          27.10.2026 20:09

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

          «Закрыть?» с отмашкой это мои пожелания к агенту-проект менеджеру. А вот «чем это было закрыто» через полгода у меня размазано: у карточек из кода ответ в коммите, у маркетинговых в ссылке на публикацию, и спросить одним вопросом «что мы решили в апреле» некого. Трёхдневный спад вы подбирали руками или просто первое число прижилось? И не копится ли внизу слой тем, которые никогда не всплывают, но и не умирают?


          1. Ka463
            27.10.2026 20:09

            Даже не знаю, будет ли работать такая схема незакрытых тем как отдельный механизм, так как появилась она по мере развития агента и все это связанно с его памятью от части.
            Трехдневный спад появился эмпирически, и прижился, а веса заряда калибровались, и подобраны таким образом что бы не захватывать проходные темы, и концентрироваться на том что важно.
            Накопление тем не происходит, от части из за того, что у моего агента память ассоциативная и многоуровневая с несколькими механизмами, хеббиан, матричная факторизация графа, механизм (tip-of-the-tongue): “знаю, что знаю, но не могу вспомнить” и т.д.
            При этом время встроено в саму память, с дословным архивом.
            То-есть в отличии от RAG или тем более стандартного подхода с .md файлами, память работает как накопление опыта, а тот же rag как поиск по смыслу.
            Таким образом когда он вспоминает какую-то горячую незакрытую тему он так же может подтянуть и остальные незакрытые темы которые могли потеряться, и напомнить о них или перечислить, либо использовать инструмент и просто посмотреть что там висит =)
            И на счет вашего "размазано" как раз по этому я и строил ассоциативную память, она связывает факты которые встречались вместе, и могут быть разнесены во времени.
            Записи связываются по сущностям и совместным всплытиям независимо от того, насколько далеко они разнесены, поэтому "что мы решили в апреле" агенту не нужен расклад по датам, достаточно вопроса, ассоциация сама подтянет и решение, и чем оно закончилось в октябре, а агент залезет в память и прочитает все события дословно если нужно


            1. Yahhi Автор
              27.10.2026 20:09

              Спасибо за подробный ответ, это уже не «агент с напоминалкой», а своя память. Тогда у меня один вопрос по существу. У нас с коллегами есть наблюдение, что устаревший текст в досягаемости агента ему скорее вредит, чем помогает: старая инструкция или уже отменённое решение подхватываются с той же уверенностью, что и свежие. У вас спад заряда работает только на незакрытые темы или на факты тоже? То есть если в апреле решили одно, а в октябре переиграли, ассоциация подтянет оба, и кто из них побеждает: более позднее, более «заряженное», или агент отдаёт оба и спрашивает? И есть ли это где-то описано или в коде, почитать? Я бы попробовала для себя такое применить


              1. Ka463
                27.10.2026 20:09

                Тут схема с несколькими механиками. Спад заряда работает только на незакрытые темы. Факты стареют другим механизмом, календарным уменьшение веса записи : вес записи = результат × 0.5^(возраст/период) × частота использования.
                Решение, которым полгода не пользовались, тонет само, без всякого конфликта.
                Ретривер подтягивает по релевантности запроса с приоритетом, записи в памяти резонируют не на саму фразу пользователя а на весь контекст текущей беседы который в данный момент в окне, но имеется ранжирование. и Top N что бы не тащить все.
                Вот тут я приведу цитату из свое статьи которую я все не как не допишу =) один из механизмов памяти конфликтные ребера.

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

                Как работает этот механизм. Агент получил задание, активация разошлась по графу и подняла какие-то записи. Это повлияло на то, как он построил ход: что сделал, какие инструменты вызвал, что сказал. Ход закончился провалом. Система учится по результатам ходов: раз ход провалился, значит, связи, которые в нём участвовали, получают штраф.

                Обучение связи и её старение:

                w(n, m) ← w(n, m) + η · r w(n, m) ← w(n, m) · 2^(−Δt / T½)

                w(n, m) — вес связи; η — скорость обучения, насколько один ход меняет вес; r — результат хода: +1 успех, −1 провал; Δt — время с последнего использования связи; T½ — период полураспада, за время, равное T½, невостребованная связь теряет половину веса.

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

                Решается это через отдельный фоновый контур который разбирает накопившиеся конфликтные пары записей. Контур читает обе записи, вес ребра, историю использования и дает одно из трех заключений.

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

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

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

                В ситуации если к примеру обе записи доехали вместе, ретривер не выбирает, он клеит пометку DISAGREE («обе оставлены: применимы при разных условиях»). Агент видит противоречие и решает сам: разобраться по контексту или спросить пользователя.
                Так же, каждая запись в [RELEVANT MEMORY] рендерится с датой yyyy-MM-dd, модель сама видит «апрель» и «октябрь» рядом и решает, опираясь на видимую причину.


                1. Yahhi Автор
                  27.10.2026 20:09

                  Спасибо, это самый подробный ответ из всех, что я получала под статьями. Два места совпали с тем, к чему я пришла с другой стороны. Дата рядом с каждой записью, чтобы модель сама видела «апрель» и «октябрь»: у меня в историях на worklore так же, дата и пометка «может быть устаревшим» видны агенту, и решает он, а не фильтр. И «обе верны при разных условиях» с пометкой DISAGREE: у меня это называется исправлением с примечанием, старая версия не удаляется, а читателю видно, почему появилась новая.

                  Про фоновый контур вопрос: кто выносит одно из трёх заключений, модель, которая читает обе записи и историю рёбра, или правило? И когда агент при DISAGREE спрашивает пользователя, ответ записывается обратно как условие, или пара так и остаётся спорной до следующего прохода?

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


                  1. Ka463
                    27.10.2026 20:09

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

                    При DISAGREE ответ уходит стандартным каналом в память, далее его обрабатывает фоновый вызов LLM, так же агент сразу может себе записать в заметки нужный вариант ответа от пользовался, тем самым выбрав правильную стратегию.
                    Потому что когда агент спрашивает пользователя, вопрос обычно не «кто прав», а «какое из двух условий сейчас действует».


                  1. Ka463
                    27.10.2026 20:09

                    Так же, главное, не переборщить с контекстом, как вы выше правильно заметили, старые и разнородные записи сильно путают модель, отсюда релевантность запросу дедупликация, и ограничение выдачи играет одну из ключевых ролей в том насколько агент будет адекватен, я на это потратил довольно много времени что бы добиться правильной работы ретривера, контекстное окно у меня пересобирается каждый ход, и не просто абы как, а по весу и релевантности записей ранжируется.
                    Отсюда есть и негативные технические моменты, kv кеш сильно страдает, по замерам его эффективность порядка 60% по этому я и ввел разделение на оркерстратора и воркера,
                    У них совершенно разный подход к памяти и контекстному окну, если первый играет роль мозга, и работает реже, то воркер решает задачи которые требуют множества вызовов( к примеру работа с кодом) и его контур лоялен к кешу и достигает 90% эффективности.


    1. Varowlord4
      27.10.2026 20:09

      Идея с угасанием веса за трое суток звучит круто, чистый аналог человеческой памяти. Если тема не всплыла в работе, значит туда ей и дорога)


      1. Ka463
        27.10.2026 20:09

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


  1. rengel_system
    27.10.2026 20:09

    Агенту говорю добавь этот вопрос, задачу в todo.md с выставленным приоритетом, раз в час скрипт обходит все todo.md и plan.md, добавляет на доску в gitea, того что нет, помечает закрыто если задачу сделали или переместили на доске. Раз в сутки проверочный скрипт проверяет на коллизии и ошибки (так как синхронизация двунаправленная). От захломления пока спасает дисциплина.


    1. Yahhi Автор
      27.10.2026 20:09

      Это почти моя доска, только источник правды перевёрнут: у вас todo.md в репозитории, а доска в Gitea его отражение, у меня наоборот, и именно поэтому доска и захламилась: файл агент видит каждую сессию, а посмотреть на доску его надо попросить. Два вопроса. Что чаще всего ловит суточная проверка: одну и ту же задачу, переименованную с двух сторон, или закрытое в файле и живое на доске? И «дисциплина» это что конкретно: вы перечитываете todo.md перед сессией, или просто не даёте агенту писать туда без приоритета?


    1. Varowlord4
      27.10.2026 20:09

      Если агент умеет сам выставлять приоритеты по контексту разговора, это здорово экономит силы

      Останется только не забывать раз в неделю чистить выполненные пункты, чтобы файл не разрастался до мегабайта)


  1. dpyzhov
    27.10.2026 20:09

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

    И главное — жёсткая резня идей. Их один фиг будет больше, чем реально воплотить, а в большом количестве часть протухает, часть теряется. Идеи сейчас безумно дёшевы, плодятся как тараканы. Если появляются сомнения — удаляю. Они тормозят и мешают сфокусироваться на чём-то важном, создавая лишь иллюзию полезного изобилия.


    1. Yahhi Автор
      27.10.2026 20:09

      С «идеи дешевы» полностью согласна, за шесть недель моя доска это и доказала. Вопрос про резню: вы режете в момент, когда идея появилась, или проходом раз в какое-то время? У меня в момент появления рука не поднимается, все кажутся хорошими. Они и через месяц не так уж плохи и вполне могут пойти в дело, просто к тому времени находятся идеи ещё лучше, и старые на их фоне уже не такие. Так что удалять приходится не плохое, а то, на что времени не хватило. И папку с идеями читаете только вы, или агент тоже в неё заглядывает, когда предлагает, что делать дальше?


  1. AppCrafter
    27.10.2026 20:09

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


  1. AndreyDmitriev
    27.10.2026 20:09

    Я от Обсидиана подустал немножко, вот Tolaria пробую вторую неделю — https://tolaria.md, в принципе норм, там достаточно разумно всё (особенно если с GTD знакомы), хотя и не без багов.


    1. Yahhi Автор
      27.10.2026 20:09

      Спасибо за наводку, не знала. Посмотрела: каждый vault это git-репозиторий и в комплекте AGENTS-файл для Claude Code и Codex, то есть та схема, о которой выше пишут про Обсидиан, только из коробки. Из-за чего от Обсидиана устали, если не секрет: от плагинов или от того, что агент в него не заглядывает? И как в Tolaria с устарешими заметками: там есть что-то, кроме дисциплины, чтобы старое не попадалось агенту наравне с новым?


      1. AndreyDmitriev
        27.10.2026 20:09

        В обсидиане, пожалуй, чуть больше "информационного шума" и да, плагины нужны, он в общем более навроченный. Тут более минималистично. Мне понравилась система фильтров-видов, когда на заметки можно посмотреть под разными "углами", легко сделать систему контекстов (я вообще люблю GTD). Старые заметки можно архивировать, в контектном меню есть такой пункт, там при этом просто в заголовке проставляется _archived: true, ну и можно агента просить в такие на лазить. Очень зашла интеграция с гитхабом - настроил и забыл, в статусе всё показано, автокоммитит прямо в мастер - всё как мы любим, настоящиим джедаям бранчи не нужны ;). Типы и папки норм, в общем больше ничего не надо. В Обсидиане я темплейтами пользуюсь, тут тоже есть, хоть и примитивно. Опять же никто не запрещает то же самое хранилище и обсидианом открыть - они на маркдауне практически совместимы. Но тут надо просто попробовать - оно или приживётся или нет.


    1. Varowlord4
      27.10.2026 20:09

      Тоже поглядывал на Tolaria из-за прямой интеграции с репозиториями, для кода и документации концепция отличная, но для быстрых мыслей на ходу телефон все равно удобнее


      1. Yahhi Автор
        27.10.2026 20:09

        я бы просто с агентом на компе через remote-control на ходу разговаривала


  1. Dims_SPb
    27.10.2026 20:09

    Напрашивается необходимость какого-то личного классификатора и маркировки мета-данными. С тех точек зрения, по которым потом намереваешься поискать. Но при этом коассификация и маркировка не должны превращаться в самостоятельную трудоемкую и напряженную задачу. Как бы разрешить это противоречие? ))


    1. AndreyDmitriev
      27.10.2026 20:09

      Ну вот посмотрите Tolaria, что комментом выше, я только что попробовал запустить в хранилище OpenCode, у меня накопилось там в инбоксе куча скриншотов, я попросил их классифицировать как мне надо, она проанализировала их содержимое, создала заголовки заметок, всё разумно. В принципе это с Обсидианом можно сделать, но там довольно удобно, что это дело с ИИ в одном флаконе и с гитхабом уже интегрировано, она сама комитит, если что не так, всегда можно откатиться.


      1. Yahhi Автор
        27.10.2026 20:09

        Разметка помогает найти, но как понять, что найденное уже неактуально? И что на что-то надо обратить внимание сейчас?


    1. Yahhi Автор
      27.10.2026 20:09

      Противоречие у меня разрешилось тем, что размечает не человек. Идея рождается в сессии, и агент в этот момент знает про неё больше, чем я вспомню через месяц, так что теги, проект и «откуда взялось» он ставит сам. Я могу только добавить что-то дополнительное, когда что-то ищу.


  1. Varowlord4
    27.10.2026 20:09

    Я пришел к тому, что держу один локальный файл TODO.md в корне репозитория строго для текущей итерации. Все что не попало в ближайший спринт или коммит - удаляется прям во время сессии с агентом. Если идея действительно стоящая, она всплывет в голове еще раз во время тестов