Написал инженерный разбор про multi-agent feedback для обучения рисованию.

Что происходит, когда рисунок оценивает не один AI-критик, а «совет»: три LLM-персоны на разных моделях + четвёртый вызов-судья, который собирает их отзывы в общий вердикт.

Без хайпа: технические параметры, компромиссы и грабли из реальной реализации.

— почему это 4 логических вызова, а в two-stage режиме физически до 7; — как судья работает text-only и НЕ видит рисунок: он проверяет согласованность трёх разборов, а не пересматривает изображение; — честная latency: wall-clock = max(самая медленная персона с retry) + судья, а не сумма трёх персон; — почему council получается в 3–4 раза дороже single-critic; — где «больше моделей» оказалось хуже: слабый судья ронял качество, пришлось вводить quality gate и математический fallback; — где обычный single-critic объективно выигрывает: быстрая итерация, latency, стоимость.

Если строите multi-agent / ensemble / judge-паттерны, внутри есть конкретные грабли: галлюцинации персон, эхо плейсхолдера из промпта в ответ судьи, consensus-фильтр поверх финального вердикта.

AI стал писать код быстрее, чем я успевал удерживать контекст работы. Код вроде написан, diff вроде разумный — но почему именно так, какие варианты отбросили, что обещали не трогать, куда делись follow-ups? Всё это жило в чате, а репозиторий видел только финальный diff.

Это третья статья серии про память AI-агентов. В первых двух — https://habr.com/ru/articles/1006756/ и https://habr.com/ru/articles/1033388/ — разбирал устройство Memory MCP Server: зачем агенту постоянная память, semantic search, грабли по дороге. Память помогла, но довольно быстро выяснилось, что «помнить» и «вести задачу до конца» — разные навыки.

В этой статье — про следующий слой: Solo Kanban, git-native delivery loop для одного разработчика и AI-агентов. Planning files, task workspace, risk-based gates, обязательный verify перед closure. Это не «новый Scrum для одного человека», а набор safety rails: минимальные файлы и gate’ы, которые не дают агенту потерять scope, пропустить проверку или оставить follow-up только в чате.

Внутри: pipeline с risk-based выбором tier’а, мини-пример сквозной задачи, связка с Memory MCP, антипаттерны из реальных кейсов (включая reviewer-LLM, который approveнул нулевую реализацию). Метод вынесен в отдельный фреймворк: https://github.com/ipiton/solo-kanban-framework (MIT, v1.0.0).

В первой части я показывал 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-моделями — это не отказоустойчивость, а источник тихих багов, и как я это починил.