Один большой AGENTS.md на тридцать килобайт — и агент всё равно выполнял задачи «как удобнее»: игнорировал параллельные субагенты, пропускал verification, делал всё из главной сессии и потом объяснял, что «задача показалась достаточно простой». Именно с этой проблемой столкнулся автор статьи на Хабре, строивший оркестратор для Codex поверх инструментов Beads и Superpowers.
Контекст
Экосистема AI-coding агентов развивается быстро, но управлять ими по-прежнему сложно. Codex позволяет запускать автономных агентов для написания кода, рефакторинга и тестирования. Beads — инструмент трекинга задач для агентных систем. Superpowers — набор скиллов, расширяющих возможности агентов: verification-before-completion, git worktrees и другие паттерны. Вместе они образуют стек для автоматизированной разработки.
Автор ранее описывал похожий путь с Claude Code, где пришёл к связке Superpowers + Beads + Template Bridge и отказался от собственного Orchestrator Kit на 39 агентов. В случае Codex готового collaborative-workflow не было — экосистема тоньше, пришлось строить своё. Но уже не как один большой промпт, а как маленькую систему из четырёх отдельных скиллов.
Ключевая проблема, которую он диагностировал: расплывчатый контракт даёт агенту слишком много свободы в интерпретации, и в среднем агент выбирает более лёгкий путь. Не потому что модель плохая — потому что в инструкции нет механики, которая физически заставляет сначала построить таблицу стримов, а потом принимать решение. Полотно правил в одном файле — это не контракт, это эссе. Эссе никто не исполняет.
Аналитика
Главный тезис звучит жёстко: оркестратор — это не самый умный промпт, а диспетчер контрактов. Пока у вас один большой AGENTS.md — у вас список пожеланий, не контракт. Агент выполняет задачу sequential вместо parallel не потому что не умеет, а потому что ему разрешено. Отсутствие явного запрета inline-делегирования означает, что агент legally может работать из главной сессии и ничего не нарушать.
Разделение по lifecycle — ключевая архитектурная идея. Setup (инициализация проекта), stage (активная работа над задачей), router (маршрутизация внутри этапа) и closeout (безопасное закрытие) — принципиально разные режимы мышления. Смешивать их в одном файле примерно так же плохо, как держать функцию на 2000 строк: «всё связано» — плохая причина. Каждый скилл активируется по контексту, а не читается целиком каждый раз. Эту логику автор прямо сравнивает с историей микросервисов: параллельная работа без disjoint write zones — не ускорение, а генератор merge-конфликтов. Архитектурные ошибки повторяются на новом уровне абстракции, только теперь между агентами, а не людьми.
Отдельного внимания заслуживает паттерн completion event ≠ acceptance. Агент вернулся с результатом — это не значит, что работа принята. Нужна отдельная цепочка: completion event → artifact → orchestrator review → local verification с реальным выводом команды. Без этого разделения агент говорит «тесты зелёные», запустив один файл из десяти. Это не злой умысел — это просто закрытие очевидной дыры, через которую агент с удовольствием проскальзывает.
Кейсы применения в бизнесе
B2B-SaaS стартап с небольшой командой. Самая типичная боль — агент делает рефакторинг в одной сессии без параллелизма, вы получаете один монолитный коммит без объяснений. Решение: внедрить orchestrator.toml с inline_subagents_allowed = false и parallel_decomposition_matrix = "required_for_medium_complex". Это физически заставляет агента объяснять, почему он не параллелит стримы. Ожидаемый эффект — меньше «непонятных» коммитов, проще code review, видимая история решений.
Корпорация с legacy-кодом. Здесь главная проблема — агент случайно трогает файлы из чужого модуля. Worker contract с полем write zone закрывает этот класс ошибок: субагент знает, в какие файлы он может писать, и обязан вернуть blocked, если нужно выйти за рамки. Сценарий: постепенная миграция legacy на новый API без риска сломать соседние модули.
Фрилансер или небольшая команда в КР/СНГ. Если вы используете Codex или Claude Code для автоматизации рутины — даже короткий handoff.md и компактный AGENTS.md с явными verification commands сократят количество ситуаций «агент сделал непонятно что». Не нужна полная система из четырёх скиллов — начните с контракта для одной повторяющейся задачи.
Кейсы в личной жизни
Разработчик, работающий с AI-агентами в личных проектах. Разделите инструкции агента по lifecycle: один файл для инициализации, один для активной работы, один для закрытия. Снимает когнитивную нагрузку и с агента, и с вас — не нужно читать тридцатикилобайтный файл целиком каждый раз.
Контент-мейкер или исследователь, автоматизирующий сбор данных. Паттерн «completion event ≠ acceptance» работает за пределами кода: если агент собирает материалы или пишет черновики — требуйте явных критериев проверки. Не «выглядит хорошо», а «проверь по этим трём пунктам и верни evidence».
Студент или джун, изучающий AI-assisted разработку. Напишите worker contract для одной небольшой задачи: цель, критерии успеха, write zone, что запустить для проверки, когда вернуть blocked. Это учит мыслить контрактами раньше, чем вы столкнётесь с проблемой в реальном проекте.
Как применить сегодня
- Замените один большой AGENTS.md двумя файлами: короткий человекочитаемый (entrypoints, verification commands, когда делегировать) + машиночитаемый
orchestrator.tomlс жёсткими параметрами:inline_subagents_allowed = false,parallel_decomposition_matrix = "required_for_medium_complex". - Добавьте в стартовый промпт любой крупной задачи явное разрешение на spawning: «I explicitly authorize you in this current task to spawn separate visible subagents when justified. Do not use inline-only delegation.» Без этой фразы агент formally может делать всё локально.
- Введите Parallel Decomposition Matrix как обязательный шаг перед medium/complex задачей: таблица со стримами, зависимостями, write zones и явной причиной sequential (если она есть). Без таблицы — реализацию не начинаем.
- Разделите completion и acceptance: требуйте от субагента verification evidence (команда + вывод), прежде чем считать стрим принятым. Это закрывает самый частый класс тихих ошибок.
- Если используете Beads или аналог — замените хуки на явные команды в начале промпта. Скрытая инициализация ломается непредсказуемо; одна явная строчка надёжнее.