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

У меня есть конкретный случай.

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

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

Разрежённые узлы переходят в плотную mesh-сеть

Как это работает

Память — это Markdown-файлы в Git. Никаких привязок к конкретному AI-инструменту. Одна и та же папка читается Claude, GPT, любым другим агентом с доступом к файлам — включая тот, которого я ещё не пробовал.

Система двухслойная.

Личная память — кто я, мой стиль, что меня раздражает в AI-ответах. Читается при первом входе в контур или когда нужен общий личный контекст; при продолжении уже известного проекта агент сразу работает с проектными файлами. Меняется редко. Тоже просто файлы, без магии:

personal-memory/
├── instructions.md          ← как со мной работать: роль, стиль, границы
├── index.md                 ← карта: какие темы где искать
└── identity/
    ├── index.md              ← кто я, коротко
    ├── tone-of-voice.md       ← как я пишу и говорю
    └── anti-ai-patterns.md   ← чего в текстах быть не должно

Идея та же: не абстрактная «настройка личности», а обычные текстовые файлы, которые агент открывает и читает, как любые другие.

Проектная память — по одной папке на проект. Что за проект, где остановились, какие решения приняты. Меняется каждую сессию.

Смена провайдера — не ноль, но близко: путь к папке вставляется один раз (шаблон промта — дальше в статье), дальше новый инструмент сам читает Markdown и входит в контекст. Никакого экспорта, никакого «это работает только в Claude».

В моём рабочем контуре разные агенты читают одну и ту же проектную память из Git-репозитория. При смене инструмента я передаю путь к ней, а не историю предыдущего чата.

Почему не Notion, не Wiki и не встроенная память AI

Три очевидные альтернативы — и у каждой один и тот же изъян.

Встроенная память провайдера (память ChatGPT, проекты Claude) — самый простой вариант и самый хрупкий: она существует только внутри чужого аккаунта, и её судьба целиком зависит от решений сервиса, а не от вас.

Notion и Wiki переносимы в смысле «данные мои», но агент не читает их напрямую — нужен коннектор под каждый инструмент отдельно. Новый AI-сервис — новая интеграция, новая точка отказа.

Markdown в Git не требует ни того, ни другого. Файл — это файл. Его открывает любой агент с доступом к файловой системе, без API и без коннектора.

Векторные базы и RAG-память вроде MemGPT — другой слой, не альтернатива: они помогают найти релевантный кусок в неструктурированном тексте. Этот стандарт фиксирует, что сейчас является правдой о проекте, в файлах, которые любой агент открывает без API и инфраструктуры; поиск можно навесить поверх тех же файлов, когда объём вырастет.

Три уровня — от простого к сложному

Не нужно создавать всё сразу. Структура растёт вместе с проектом.

Базовый уровень (без AI)

Три файла. Достаточно, даже если вы вообще не пользуетесь AI-агентами:

  • index.md — карта: что за проект, что где лежит, с чем связан. Максимум 60 строк.
  • state.md — где остановились: активная задача, следующий шаг, блокеры. Максимум 80 строк, обновляется в конце каждой сессии.
  • backlog.md — открытые задачи и идеи: что запланировано, что отложено.

Это фундамент. Если позже подключите агента — он начнёт читать те же файлы. Перестраивать ничего не нужно.

С AI-агентом

Добавляется, когда впервые даёте агенту доступ к проекту:

  • project.yaml — машинный паспорт проекта: статус, владелец. YAML — простой текстовый формат для структурированных данных, парсится мгновенно и при этом читается человеком.
  • instructions.md — ограничения: «архитектурные решения фиксировать отдельно, не менять по ходу дела», «код — через отдельную ветку с ревью, не напрямую».
  • logs/ — история существенных сессий: что делали, что решили.
  • decisions/ — история решений (ADR, Architecture Decision Record — короткая запись «что решили и почему»), чтобы агент не предлагал то, что уже отвергли.
  • prompts/implementation/ — задачи для агентов, которые не теряются в чате.

Расширенный

Когда проект вырос настолько, что первых двух уровней не хватает:

  • constitution.md — неизменные принципы.
  • links/ — связи с кодом, смежными проектами.
  • specs/ — формальные спецификации.

Наглядно — как это выглядит на диске для проекта с подключённым агентом (первые два уровня вместе):

my-project/
├── project.yaml
├── index.md
├── state.md
├── backlog.md
├── instructions.md
├── logs/
│   ├── index.md
│   └── log-2026-07-08-тема.md
├── decisions/
│   └── ADR-001-название-решения.md
└── prompts/
    └── implementation/
        └── 2026-07-08-задача-для-агента.md

Ничего лишнего сверху, ничего не спрятано на десять уровней вглубь.

Когда проектов становится много, они не сваливаются в одну кучу, а группируются по типу. У меня три категории — свои проекты, фриланс, рабочие задачи — плюс отдельная personal-memory/, которая одна на всё, а не на проект. Внутри каждой категории — обычные папки проектов с той же структурой, что выше. Агент всегда открывает один конкретный проект, а не пролистывает всё дерево целиком — масштаб не давит на контекст, потому что контекст не общий, он всегда по одному проекту за раз.

Почему файлы именно такой длины

Когда папка проекта уже подключена к сессии, агент на старте читает фиксированный набор:

project.yaml     (~15 строк)
index.md         (≤60 строк)
state.md         (≤80 строк)
instructions.md  (≤40 строк)
────────────────────────────
Итого:           ~150-200 строк

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

Если задача требует больше контекста — агент идёт по маршруту из index.md и догружает только нужное. Логи, старые решения, исследования — только когда реально понадобились.

Индекс заводится не для всего подряд, а только там, где рост без потолка. Какой проект открыт — решается снаружи, тем, какая папка подключена к сессии, а не перебором каталога, поэтому индекса над всеми проектами нет и не нужен — независимо от того, сколько их. А вот логи растут с каждой сессией без ограничения — через год плоский список в index.md их не выдержит. Поэтому внутри logs/ — свой index.md (таблица «дата → файл → о чём»), а верхний index.md указывает только на него, не на каждый лог по отдельности. Тот же приём годится для любой части проекта, которая растёт без потолка, а не для всего сразу. Принцип простой: маршрутизация должна быть дешёвой и точной, а не исчерпывающей.

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

Сессионный ритуал

«Продолжаем» — не обязательная команда, а просто моя привычка. На деле достаточно открыть новый чат и написать + или любое другое короткое сообщение: если к сессии уже подключена папка проекта, агент читает project.yaml, index.md, state.md и instructions.md. От меня нужен только сигнал, что диалог начался; остальное — работа агента.

Если следующий шаг один, ответ короткий: «Я в контексте. Остановились на X. Следующий шаг: Y.»

Старт новой сессии: агент читает проектные файлы и возвращается в контекст

Если в state.md осталось несколько рабочих направлений, агент не сжимает их в одно длинное предложение. Он показывает короткую развилку нумерованным списком вместо одной строки.

Пара секунд. Любой агент. Контекст не теряется между сессиями, между инструментами, между людьми: новый человек на проекте открывает state.md и понимает то же, что понял бы агент.

Триггера для сохранения два: агент сам замечает, что сессия разрослась, и предлагает сохраниться — я соглашаюсь сразу или прошу закончить текущий кусок работы; либо я говорю «сохраняйся» без повода со стороны агента, просто по своему ощущению. Дальше в обоих случаях один и тот же ритуал.

Конец сессии — агент обновляет:

  1. state.md — где остановились, что дальше.
  2. logs/log-YYYY-MM-DD-тема.md — если была существенная работа или изменения.
  3. decisions/ADR-*.md — если было важное решение.

Агент предлагает сохранить state, log и decisions в конце сессии

После сохранения агент повторно читает изменённые файлы и проверяет Git diff. Одного сообщения «сохранено» недостаточно. Локальные незакоммиченные изменения — ещё черновик, а не общая память проекта: прежде чем считать статус доступным другим людям и агентам, нужно проверить ветку, commit и его попадание в нужный remote. Для деплоя этого недостаточно — отдельно проверяется, какая версия реально работает.

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

Один яркий узел в разрежённой mesh-сети

Сокращённый пример из проекта

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

project.yaml:

id: mind-mesh
name: Mind & Mesh
status: active
owner: takeshi
summary: "Личный бренд, портфолио и лаборатория."
entrypoints:
  index: index.md
  state: state.md
  instructions: instructions.md

index.md того же проекта:

# Mind & Mesh
Личный бренд, портфолио и personal site.

## Read first
- state.md — текущее состояние
- instructions.md — как агенту работать

## Навигация
- Нужен статус → state.md
- Нужна история → logs/
- Нужно почему так решили → decisions/

## Связи
- Код: dev/personal/mind-mesh-site/

state.md того же проекта:

# State — Mind & Mesh
## Summary
Сайт доработан. Мониторинг: 10 источников.

## Current focus
- active_track: контент для Лаборатории
- next_step: дописать статью про проектную память

Этого сокращённого набора достаточно, чтобы увидеть принцип: контекст остаётся коротким и входит мгновенно.

Инфраструктура

Источник истины — Git-репозиторий. Где именно он живёт — вопрос второй: у меня сейчас self-hosted GitLab на сервере, но принцип не в этом. Git — открытая система с переносимым форматом репозитория, а не сервис одной компании: его можно клонировать на другой хостинг и отправить в приватный репозиторий на GitHub. Для всей описанной архитектуры достаточно Git на ноутбуке и удалённого приватного репозитория. Self-host — личный выбор, не требование системы: GitLab у меня заодно закрывает и другие задачи, не только хранение файлов, это отдельная тема.

Сам себе провайдер — тоже провайдер, если это единственная копия. Точка истины — GitLab на сервере. Зеркала независимы: внешний диск бэкапит весь сервер целиком, облако — приватные репозитории на GitHub, по одному на каждый. Если пропадёт сервер или любое зеркало, репозитории живы в оставшихся. Source of truth без независимого бэкапа — это просто более медленный способ повторить историю из начала статьи, только с собственным именем на табличке вместо чужого сервиса.

Стек — Git, Markdown, YAML. Ничего специфичного под один инструмент: если файл не открывается в обычном блокноте, в эту систему он не годится.

Сам я для удобства смотрю и редактирую эти файлы через Obsidian с плагином Git-синхронизации — но это моя личная привычка просмотра, не часть архитектуры. Агентам Obsidian не нужен вообще, они читают файлы напрямую.

Быстрый старт

Начать можно без скриптов и терминала: создать папку проекта и положить в неё один state.md.

# State — my-project

## Сейчас
Короткое описание текущего состояния.

## Следующий шаг
Одно конкретное действие.

## Блокеры
Нет.

Даже без AI такой файл уже сохраняет точку продолжения. Когда этого станет мало, рядом появятся index.md, backlog.md и остальные уровни структуры.

Новый агент, новый инструмент

Стартовый промт один и тот же для любого нового инструмента:

Твоя память и правила не здесь. Источник истины — GitLab, рабочая копия — локальный vault пользователя.
Сначала открой: memory/personal-memory/knowledge-rules/core/entrypoint.md — и следуй маршруту из него.
Не храни правила, личные факты, рабочую или проектную память в собственных настройках — только ссылки на GitLab/vault.

Ключевое — это пойнтер, а не копия правил. Соблазн вставить сами правила целиком в настройки инструмента (System Prompt, Custom Instructions, Project Instructions) есть всегда, и он неправильный: тогда придётся синхронизировать две копии вручную, и рано или поздно они разойдутся. В настройки идёт только этот короткий адрес — дальше агент читает актуальную версию сам, каждый раз заново. Если агент и внешний файл разошлись — например, агент «помнит» что-то не то, — побеждает файл.

Это правило относится к памяти, а не ко всей реальности. state.md отвечает на вопрос «где остановились», ADR — «что решили», а живая система — «что сейчас работает». При конфликте не нужно выбирать один файл наугад: сначала проверить, о каком факте идёт речь. Политика безопасности и прямое указание человека ограничивают действия всегда.

Канонические state.md, backlog.md, logs/ и decisions/ лежат только в Git-backed корне проекта. Папки вроде .hermes/ или .claude/ могут хранить runtime-кэш и короткие pointer-настройки, но не вторую копию проектной памяти. И доступ к одному проекту не означает доступ ко всей личной памяти, секретам, production-данным, сети или git push: агент получает ровно тот scope чтения и действий, который нужен задаче.

Как передать этот промт, зависит от инструмента:

  • Автообнаружение — кладёшь файл с конвенционным именем в корень рабочей папки: CLAUDE.md для Claude Code, AGENTS.md для совместимых coding agents. Инструмент подхватывает его сам, без отдельной настройки.
  • Поле «инструкции проекта» (Cowork Project Instructions и аналоги) — тот же текст вставляется вручную один раз на инструмент. Правила поменялись — вставлять заново не нужно, пойнтер не дублирует содержание, только адрес.
  • Без файлового доступа вообще (веб-агент без интеграции) — контракт не работает, файлы приходится грузить вручную по одному.

Что не идеально

Git-конфликты. Если два агента — или два инструмента с разными провайдерами под капотом — параллельно пишут в один и тот же проект, будет конфликт. Ловил это на практике: одна сессия закоммитилась, другая упёрлась в блокировку и не долетела до общего репозитория, при этом отчиталась об успехе. Помогает мягкая договорённость: кто сейчас работает с проектом, отмечается полем owner в его project.yaml — но это именно договорённость, не железная гарантия.

Дисциплина. Если не обновить state.md в конце сессии — следующий агент заходит в устаревший контекст. Автоматического принуждения пока нет. Обратная сторона той же проблемы — агенты по умолчанию склонны перечитывать больше, чем нужно: пробежаться по истории «на всякий случай», поднять старые логи, даже когда state.md уже дал ясный ответ. Это тоже приходится ограничивать явным правилом, а не рассчитывать, что агент сам остановится вовремя.

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

Несколько раз переделывал

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

Не претендую, что нынешняя версия — «правильная для всех». Но она реально работает: веду на ней свои проекты, фриланс-контракты и рабочие задачи одновременно, у каждого свой темп и свои особенности, и структура не разъезжается. Трения по дороге было много: заводились файлы, которые потом не использовались, промты копились месяцами. Это цена итерации, не признак ошибки в первой попытке.

Куда это движется

Базовая структура обрастает деталями — с разной степенью готовности.

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

Явное поведение при параллельной работе инструментов. Когда два агента редактируют один проект одновременно — сейчас это просто конфликт (см. «Что не идеально»). Нужно правило на этот случай, а не только мягкая договорённость.

В основе всё равно Git и Markdown, остальное достраивается по необходимости.

FAQ

Без AI работает? Да, базовый уровень не требует агента вообще. Это просто дисциплина записывать, где остановился.

Секреты в Git? Нет. Токены и пароли — отдельно, не в этих файлах.

Что с уже существующими заметками в Notion или старых чатах? То, чем реально пользуюсь, переношу постепенно, по мере надобности. Остальное — архивирую как есть, не переписываю задним числом: это мёртвый архив, он не спорит с источником истины, потому что не используется.

Что взять себе

Не обязательно копировать всю структуру целиком. Если брать одну вещь — пусть будет эта: заведите state.md на три раздела — что сейчас, что дальше, что мешает — и обновляйте его в конце каждой сессии, любой, с любым инструментом. Не дописывайте, а переписывайте: state.md — это текущее состояние, а не история, и от помойки его защищает не дисциплина, а сам формат — коротко и заново на каждой сессии. История, если нужна, — отдельным файлом. Остальное достроите, когда станет тесно, не раньше.

Telegram-канал Mind & Mesh: @takeshi_ku.