Как только агентов становится больше одного, возникает соблазн запустить их роем на одну задачу и ждать кратного ускорения. Иногда так и выходит, но чаще получается хаос: агенты правят одно и то же, дублируют исследование, и распутывание их работы съедает всё выигранное время и добавляет сверху. Проблема не в числе агентов самом по себе, а в отсутствии границ между ними.

Наивная модель - "больше агентов значит быстрее", как будто работу можно линейно разложить на сколько угодно рук, и каждая новая рука добавит ровно свою долю. Отсюда запуск нескольких implementer-ов на общую фичу в надежде, что каждый сам возьмёт свой кусок и разойдётся с соседями. Возьмёт - но границы куска ему никто не задал, и пересечение почти неизбежно.

Ломается это на общем изменяемом состоянии. Два агента, пишущие один файл без разных worktree, - это не параллелизм, а гонка за один ресурс: их diff-ы конфликтуют, и кто-то молча затирает чужое, причём вы узнаёте об этом позже всех. Документация по subagents прямо отмечает: раздача разных профилей с ограниченным набором инструментов и есть то, что мешает нескольким агентам одновременно менять одни и те же файлы. Иначе говоря, параллелизм безопасен ровно настолько, насколько разделены артефакты, и ни на йоту больше.

Профессиональный ход - делить работу не по объёму, а по артефактам и ownership. У каждой единицы работы должен быть один владелец результата и свой отдельный выход. Один агент владеет изменением API, другой - независимыми тестами к нему, третий - review этих изменений. Пока каждый пишет строго в своё, они действительно идут параллельно и не мешают друг другу; как только двое метят в один файл, нужен либо разный worktree, либо merge owner, назначенный заранее, а не по факту конфликта.

Роли удобно закрепить явно, чтобы у каждого агента были своя поверхность и свой тип выхода, известные до старта. Ниже - минимальная топология, которая держится без хаоса даже на нескольких сессиях: исследователь, implementer, verifier и интегратор. К этой таблице возвращаются как к чек-листу перед тем, как развести работу на параллельные сессии, и по ней же потом сверяют, кто за что отвечал.

Почему роли разведены именно так, а не слиты. Исследователь работает read-only - как subagent_explore на более дешёвой модели: его выход это карта кода и рисков, без единой правки, поэтому его можно запускать смело и рано, не боясь испортить состояние. Implementer меняет код и потому сидит в отдельном worktree или в Cloud, отдавая ровно один связный diff. Verifier смотрит на результат чужими глазами - Quick Review или другой агент - и даёт независимые проверки, а не самооценку автора. Интегратор - всегда человек: решение о merge не делегируют, потому что именно оно связывает разрозненные выходы в одно целое и несёт ответственность за итог.