В первой части я показывал agent-memory-mcp v0.1.0: MCP-сервер на Go + SQLite, который даёт AI-агентам persistent memory, semantic search и RAG по документации проекта.

Во второй части разбираю, что изменилось после нескольких месяцев реального использования. Почему fallback между embedding-моделями оказался опаснее отказа, зачем понадобились local-only режим и reembed, почему одного semantic search мало для инженерной памяти, как появились session close, Claude Code hooks, canonical knowledge, stewardship, sedimentation и multi-hop recall.

Это не changelog, а разбор эволюции архитектуры: как простой memory tool вырос в memory backbone для инженерных агентов — слой, который не просто хранит заметки, а помогает поддерживать актуальное, проверенное и полезное знание проекта.

AI-агент каждую сессию начинает с нуля — не помнит, что вчера разбирали архитектуру, какие баги нашли и почему выбрали именно это решение. Знакомо?
Я сделал open-source MCP-сервер на Go, который даёт агентам persistent memory с semantic search. Один memory-layer для Cursor, Claude Code и Codex — чтобы контекст не терялся между инструментами.
В статье — не обзор, а инженерный разбор: схема БД, embedding pipeline с fallback между провайдерами (и почему я в итоге от этого отказался), in-memory cosine similarity вместо vector DB, RAG-индексирование с инкрементальным обновлением, и реальные промпты для агентов.
Отдельно разобрал грабли: почему fallback между разными embedding-моделями — это не отказоустойчивость, а источник тихих багов, и как я это починил.