Ключевое правило teams - заранее назначать ownership файлов. Два агента на одном модуле создают не ускорение, а merge-конфликт: каждый исходит из своей картины, и результаты не сходятся. Workflows выражают устойчивый процесс - исследование, реализация, тесты, независимый review, - но их вводят только после того, как ручная процедура стала стабильной и измеримой. Иначе автоматизируется неопределённость, а не порядок.

Безопасная декомпозиция задаёт каждому worker минимальный контекст, определение готовности, ограничения инструментов и ожидаемый выход. Полезно один раз увидеть такую раскладку: две read-only задачи на исследование границы API и test harness, одна задача реализации с ownership на свой каталог в изолированном worktree и одна независимая read-only задача review финального diff. Результаты принимают только после общего интеграционного теста, а не по отдельности от каждого worker.

Контроль стоимости - обязательная часть параллельности. У каждой сессии и субагента свой контекст и свои вызовы модели, поэтому параллельность уменьшает wall-clock time, но обычно увеличивает суммарный расход токенов. Более дешёвую модель на ограниченные lookups направляют только после того, как качество измерено; и не дробят на агентов задачу, которая решается одним rg и чтением пары файлов. Стая агентов - это множитель расхода, и запускать её без нужды дороже и глупее, чем один проход.

Инженерный вывод про параллельность прост и практичен: параллелить стоит независимые области знания или ownership, а не последовательные стадии одного изменения. Стадии одного изменения по определению зависят друг от друга, и разносить их по агентам - значит плодить рассинхронизацию. Самый предсказуемый первый шаг - два read-only исследователя и один owner реализации: исследование идёт параллельно и дёшево, а меняет файлы только один, и конфликтов не возникает.

Типичные провалы параллельности предсказуемы. Два агента на одном модуле, дающие merge-конфликт вместо ускорения. Team там, где хватило бы независимых сессий, - лишний расход и сложность. Workflow поверх ещё не стабильной ручной процедуры - автоматизированная неопределённость. И дробление на агентов того, что решается одним проходом. Выбирайте механизм под задачу, назначайте ownership заранее, принимайте результаты после интеграционного теста и параллельте независимое, а не стадии одного изменения.