My Architect, часть 1: память и план для AI-агента

Это первая статья серии про My Architect — систему, в которой проект живёт между сессиями AI-агента. Человек видит и правит картину через визуальный интерфейс, агент управляет тем же проектом через MCP. В серии семь частей, план — в конце статьи.

Проблема: агент гениален и беспамятен

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

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

Чем это обычно лечат:

CLAUDE.md и заметки в репозитории. Работает, пока файл короткий. К сотой строке он превращается в свалку, где рядом лежат правила линтера и судьбоносные архитектурные решения.
Планы в markdown-файлах. PLAN.md, ROADMAP.md, TODO.md — каждый живёт своей жизнью, противоречит соседям, и агент сам решает, какой из них считать правдой.
Jira или Linear. Сделаны для людей и процессов. У агента туда в лучшем случае API-доступ без структуры, которую ему удобно читать: ни наследования требований, ни понятия «возьми следующую задачу с учётом релиза и глубины дерева».

Общая беда у всех трёх: нет одного места, которое одинаково удобно и человеку, и агенту.

Идея: один источник правды, два интерфейса

My Architect хранит проект как иерархию узлов: Epic → Feature → Story → Task (есть схемы SAFe и упрощённая). На узлы вешаются требования, документы и диаграммы. Под капотом это обычные YAML- и Markdown-файлы — никакой закрытой базы, данные переживут любой инструмент.

Поверх одного хранилища — два равноправных входа.

Человеку — canvas: дерево WBS с автоматической раскладкой, User Story Map с релизами по горизонтали, drag-n-drop для переподчинения узлов, статусы цветом. Перетащили story в другой релиз — файл изменился.

Агенту — больше 30 MCP-инструментов. Типичная сессия выглядит так:

get_project_context(pid)   → иерархия, бэклог, релизы — одним вызовом
get_next_task(pid)         → задача с учётом релиза и глубины дерева
start_task(pid, node-42)   → статус in-progress, агент назначен
create_doc(...)            → спека прикреплена прямо к узлу
complete_task(pid, node-42, summary)
                           → done, статусы родителей пересчитаны,
                             в ответе сразу следующая задача

Синхронизация живая: агент закрыл задачу — узел на канве стал серым прямо во время сессии, без перезагрузки. Сработал file watcher: бэкенд заметил изменение YAML на диске и разослал событие в браузер по WebSocket.

Что агент помнит между сессиями

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

Решения хранятся не в тексте диалога, а как требования четырёх типов: функциональные (FR), нефункциональные (NFR), архитектурные (SAR) и ограничения (CON). Требования наследуются вниз по дереву: NFR «ответ до 200 мс», повешенный на эпик, виден из каждой вложенной задачи. Агент, взяв задачу третьего уровня, получает и её собственные требования, и всё, что накопилось у предков.

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

Почему MCP, а не очередная интеграция

MCP — открытый протокол, и My Architect строился вокруг него с первого дня, а не как надстройка. Подключается любой совместимый агент: Claude Code, агенты на Anthropic SDK, что угодно завтрашнее. Конфигурация — пять строк в .mcp.json.

Обратная сторона той же монеты: и UI, и MCP-инструменты ходят через один бэкенд и одну доменную логику. Агент не может сломать то, что видит человек — у них физически одни и те же файлы и одни и те же правила изменений.

Мелочь, которая дорогого стоит

Система не даст агенту назвать узел «Implement login» или «Fix bug in auth». Узлы называются сущностями: «Login system», «Auth flow». Встроенный линтер заворачивает глаголы, императивы и формулировки-приёмки ещё на этапе build_hierarchy.

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

Все части серии

Память и план для AI-агента — эта статья.
Архитектура без базы данных — YAML-файлы как источник правды, атомарная запись, мьютекс проекта и живая синхронизация через WebSocket. И история о том, как параллельные записи теряли 85% изменений.
Модель планирования — иерархия, требования с наследованием, User Story Map и релизы: как заставить агента планировать как архитектор, а не как генератор тудушек.
Рабочий цикл агента — от get_next_task до complete_task: документация как часть задачи, living source of truth и сверка плана с реальным кодом.
Дистрибуция через Claude Code marketplace — плагин, который одной командой ставит и skill, и MCP-сервер: как устроен маркетплейс, версионирование и почему skill живёт в публичном репозитории.
Сторона человека — WBS, Building Blocks и User Story Map — как инструментом пользуется архитектор руками: WBS поверх building blocks, User Story Map для приоритизации и диаграмма, которую исполняет агент.
Obsidian, Claude Code docs и OpenClaw — полевые заметки — какую работу делают чужие инструменты хранения знания, где у каждого потолок и почему «вести проект с агентом» — отдельная работа.

Попробовать My Architect можно на my-architect.app. Вопросы и возражения — пишите, самые интересные разберу отдельно.