Один workspace — одна работа: когда «универсальный» AI-агент начинает врать памятью

Редакция 28 сентября 2026 г.

Три схемы на столе: один агент на весь репозиторий, общая память на все роли или отдельный workspace под каждую job с координацией через события. Mustafa Turan в разборе на Dev.to ушёл в третью после отказа от «do-everything» агента; соло с несколькими агентами в цикле здесь ближе к rules и skills в IDE, чем к промпту «будь умнее».

Почему общая память ломает доверие к агенту

Сбой начинается с миграции. В одном репозитории верно «не трогать legacy-таблицы», в соседнем нужно наоборот. Агент кладёт урок в shared memory, следующая задача принимает чужое правило за закон.

Узкий workspace держит одно определение «готово». Заметка должна оставаться правдой для любой задачи внутри границы. У Turan в site-workspace около сорока записей, все про один статический сайт: конвертер без курсива в code block, хеш CSS на билде, согласованные slug. Не «engineering вообще», а scope вроде «static marketing site and its SEO content».

Память полезна только если каждая note true для каждой task, так сформулирован TL;DR поста.

Что входит в workspace и зачем там MCP

Workspace у автора это узел подключения агента без привязки к одной IDE. Внутри:

mission: читается при старте задачи;
task board: история работ;
memory: чтение и запись через loadMemory / saveMemory по MCP;
skills: поиск и подгрузка навыков.

Single-purpose значит одно определение done на workspace. Параллельно живут static site, core app, QA, support, social и outreach; контексты не смешиваются. «Не коммить секреты» уходит в shared skills между workspace, а не копируется в memory каждого.

Clear Context: каждая задача стартует с пустого context window. Вместе с узким prefix это бьёт по второй боли монолита: mission, индекс memory, описания skills и инструкции снова попадают в окно на каждый turn в stateless tool-calling loop. Формула автора cost ≈ starting_context × turns + work; процента экономии он не обещает, но при платном inference широкая job на ход дороже узкой.

События вместо переписки между агентами

Координация без shared memory и без agent-to-agent DM. Два механизма:

Supervisor-агент на account-wide Supervisor MCP: видит все workspace, статусы и задачи, создаёт work и переносит задачу из «не того» workspace. Диспетчеризация, не исполнение.
Publish/subscribe: workspace публикует событие в прошедшем времени с коротким payload; подписанные триггеры создают новую задачу с телом из payload. Publisher не знает подписчиков; имена вроде fix_the_bug автор намеренно не использует, это disguised DM.

Цепочка из таблицы поста:

Событие	Когда	Кто реагирует
`code_changed`	merge в core app	QA
`qa_failed`	регресс	core app (fix), support
`bug_fixed`	fix в core	QA re-check, support
`feature_released`	релиз	static site (пост, feature pages)
`blog_published`	пост live	social → X thread

На bug_fixed fan-out может идти параллельно в support и core app без ручного «напиши коллеге-агенту». Минус DM: coupling, комбинаторика n(n-1)/2 каналов и слабая observability; каждый hand-off должен быть задачей на board.

Платформа автора AgentRQ (human-in-the-loop task manager for AI agents), пост 28 сентября 2026 года, оригинал на agentrq.com. Это его стек, но паттерн events + supervisor переносим на любой агентный runtime с MCP и доской задач.

Где модель «один workspace» не обязана побеждать

Turan сам перечисляет контраргументы: огромные context windows, ценность generalist для cross-domain insight, retrieval поверх одной большой memory, overkill для маленьких проектов, риск командных silos вместо ownership.

На что смотреть в практике:

дробить по названиям задач, а не по расхождению knowledge, и получить лишние workspace без выигрыша;
memory устаревает при смене инструментов, нужен пересмотр;
setup cost окупается на повторяющейся работе (у site-workspace автор закрыл more than ninety tasks по своим словам, без независимого аудита).

Пошагового runbook «миграция monolith-agent без даунтайма» нет. Проверка на выходе: вынести одну job, неделю задач, прочитать memory и спросить «каждая заметка true для каждой задачи?» Если нет, split оправдан.

Источники

Mustafa Turan, «Single Responsibility for AI Agents: One Workspace, One Job» (Dev.to, 28 сентября 2026): Dev.to
Оригинал: agentrq.com (указано на странице поста).
Публичная активность на Dev.to на момент подготовки разбора: 2 комментария, 1 реакция (метрика платформы, не HN upvotes).