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. Питання і заперечення — пишіть, найцікавіші розберу окремо.