У вас есть фича, которая требует трех вещей одновременно. Можно запустить субагентов внутри одной сессии Claude Code и дать им работать параллельно. Или разбить работу на три независимые задачи, передать каждую отдельному агенту в его собственном tmux-панели, и дать им работать, не зная друг о друге.

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

Это фреймворк принятия решений, который я использую каждый день, запуская 13 агентов Claude Code на одной кодовой базе. Не теория. Результат достаточного количества ошибок, чтобы знать, где проходит граница.

Два вида параллелизма

Claude Code поддерживает два различных способа конкурентного выполнения работы.

Субагенты это дочерние процессы, запущенные внутри одной сессии Claude Code. Родительский агент запускает несколько субагентов, каждый берется за часть задачи, затем собирает результаты. Они делят одну рабочую директорию и контекст родителя. Думайте о них как о потоках в одном процессе.

Parent agent
  ├── Subagent A: "Search lib/ for all usages of parseConfig"
  ├── Subagent B: "Search server/ for all usages of parseConfig"
  └── Subagent C: "Search components/ for all usages of parseConfig"

Отдельные агенты работают в независимых сессиях Claude Code, обычно в отдельных tmux-панелях. У каждого своё окно контекста, свой файл идентичности CLAUDE.md и свой взгляд на кодовую базу. Они не делят память. Общаются через артефакты: комментарии к задачам, обновления статусов, закоммиченный код. Думайте о них как об отдельных процессах без общего состояния.

tmux pane 1: eng1 agent → "Build the REST endpoint"
tmux pane 2: eng2 agent → "Build the React component"
tmux pane 3: qa1 agent  → "Write integration tests for both"

Ментальная модель важна, потому что определяет, как работа течет между единицами. Субагенты могут дешево передавать данные родителю. Отдельные агенты передают данные через файловую систему, git или внешний трекер задач.

Когда побеждают субагенты

Используйте субагентов, когда работа разделяет состояние и результаты должны сойтись.

Параллельное исследование. Нужно найти паттерн в пяти директориях, прочитать три файла документации и синтезировать находки в одну рекомендацию. Субагенты могут взять каждый по пути поиска, вернуть результаты, и родитель может объединить их без накладных расходов на сериализацию.

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

Быстрое исследование. Вы дебажите и нужно одновременно проверить git log, вывод тестов и конфигурацию runtime. Субагенты могут собрать все три параллельно, и родитель синтезирует диагноз.

Паттерн: разослать, собрать, действовать на основе комбинированного результата. Если ваш параллелизм заканчивается тем, что родитель должен рассуждать обо всех выходах вместе, субагенты правильный инструмент.

В чем субагенты плохи: все, что занимает больше нескольких минут на ветку, все, что модифицирует файлы в пересекающихся путях, или все, что требует независимой верификации. Субагенты делят рабочую директорию, поэтому два субагента, пишущих в один файл, испортят работу друг друга. И поскольку они делят контекст, долго работающий субагент съедает доступное окно родителя.

Когда побеждают отдельные агенты

Используйте отдельных агентов, когда работу можно верифицировать независимо и ей не нужен общий контекст, чтобы иметь смысл.

Разные компоненты одной фичи. "Построить API-эндпоинт" и "Построить фронтенд, который его вызывает" независимы до интеграции. API-инженеру не нужен React-компонент в контексте. Фронтенд-инженеру не нужна схема базы данных. Дать каждому свой агент с ограниченным CLAUDE.md держит контекст чистым и предотвращает утечку сложности одного агента в работу другого.

Разные критерии приемки. Если задача A выполнена, когда эндпоинт возвращает 200 с правильной JSON-структурой, а задача B выполнена, когда компонент отображает данные с правильными состояниями ошибок, это отдельные цели верификации. QA-агент может проверить каждую независимо. Субагенты не могут быть проверены независимо, потому что производят один комбинированный выход.

Работа, затрагивающая разные части кодовой базы. Владение файлами это простейший способ предотвратить конфликты слияния. Агент A владеет server/, Агент B владеет components/. Ни один не заходит на территорию другого. Если попробовать это с субагентами, родителю придется управлять блокировкой файлов, что обесценивает параллелизм.

Задачи с разными временными горизонтами. Одна задача занимает 10 минут, другая 2 часа. С субагентами родитель ждет самого медленного ребенка. С отдельными агентами короткая задача завершается, верифицируется и отправляется, пока длинная ещё работает.

Паттерн: запустить, забыть, верифицировать отдельно. Если каждый кусок работы стоит сам по себе и может быть проверен сам по себе, отдельные агенты со структурированными задачами чище.

Проблема передачи

Настоящая точка принятия решения сводится к передачам.

Передачи субагентов дешевые. Ребенок возвращает данные родителю в том же контексте. Без сериализации, без записи файлов, без ожидания обновлений статуса. Родитель запускает трех субагентов, они возвращают три результата, у родителя есть все необходимое.

Передачи между отдельными агентами дорогие, но долговечные. Агент A завершает работу, коммитит код, обновляет статус задачи и комментирует, что сделал. Агент B подхватывает этот сигнал (через координатора или опрашивая трекер задач) и начинает свою зависимую работу. Накладные расходы реальны: нужна система задач, протокол статусов и способ для агентов узнать, что сделали другие агенты.

Правило: если работа требует больше одной передачи между параллельными единицами, используйте субагентов. Для одного fan-out-and-gather субагенты проще. Если выход Агента A является входом Агента B, который становится входом Агента C, стоимость координации отдельных агентов оправдана, потому что каждая передача производит проверенный, закоммиченный артефакт, который не потеряется, если агент упадет или достигнет лимита контекста.

Конкретный пример. Нужно:

Найти все API-эндпоинты, возвращающие пользовательские данные
Добавить rate limiting к каждому
Написать тесты для новых rate limits
Обновить документацию API

Шаги 1 и 2 тесно связаны. Результаты поиска (шаг 1) непосредственно питают модификацию (шаг 2). Субагент обрабатывает поиск; родитель применяет изменения. Это паттерн субагента.

Шаги 3 и 4 независимы друг от друга, но зависят от шага 2. Тестам нужен реальный код эндпоинта. Документации нужна финальная форма API. Это отдельные задачи для отдельных агентов, каждая со своими критериями приемки, каждая верифицируемая самостоятельно.

Структурированная декомпозиция на практике

Когда ответ "отдельные агенты," нужен способ декомпозировать фичу в задачи, которые могут работать параллельно, не мешая друг другу.

Процесс декомпозиции:

1. Определить граф зависимостей. Прежде чем что-то разделять, нарисуйте, что от чего зависит:

Feature: User profile page with activity feed

- API endpoint: GET /users/:id/profile     (no deps)
- API endpoint: GET /users/:id/activity     (no deps)
- React component: ProfileHeader            (depends on profile API)
- React component: ActivityFeed             (depends on activity API)
- Integration test: profile page end-to-end (depends on all above)

Два API-эндпоинта не имеют зависимостей. Могут работать параллельно. Два React-компонента зависят каждый от одного API. Интеграционный тест зависит от всего.

2. Провести границы владения. Каждой задаче назначается область файлов. Агент profile API владеет server/routes/profile.ts и server/services/profile.ts. Агент activity API владеет server/routes/activity.ts и server/services/activity.ts. Ни один не трогает файлы другого. Если общая утилита требует изменений, один агент создает изменение, а другой ждет.

3. Определить критерии приемки для каждой задачи. Каждая задача должна иметь четкое условие "готово", которое можно проверить без просмотра других задач. "Profile API возвращает 200 с правильной структурой" проверяемо. "Страница профиля работает" нет, потому что зависит от интеграции.

4. Указать артефакты передачи. Что нужно нижестоящему агенту от вышестоящего? Обычно: закоммиченный код на известной ветке, обновление статуса и комментарий, описывающий контракт интерфейса (структура API, пропсы компонента, сигнатуры функций).

Эта декомпозиция превращает расплывчатое "построить страницу профиля" в пять дискретных задач с явными зависимостями и критериями верификации. Каждая задача может быть назначена агенту, который имеет ровно тот контекст, который нужен, и ничего лишнего.

Beads для структурированной декомпозиции

Здесь наличие настоящей системы задач становится важным. Нельзя отслеживать пять параллельных задач стикерами и выводом терминала.

beads это локальный трекер задач, который моделирует эту декомпозицию нативно. Epic представляет фичу. Дочерние задачи представляют подзадачи. Зависимости не дают агентам начать работу до выполнения предусловий.

Вот как выглядит декомпозиция на практике:

# Create the epic
bd create --title "User profile page with activity feed" \
  --type epic --priority p2

# Create subtasks as children
bd create --title "GET /users/:id/profile endpoint" \
  --parent bb-epic1 --type task --priority p2

bd create --title "GET /users/:id/activity endpoint" \
  --parent bb-epic1 --type task --priority p2

bd create --title "ProfileHeader React component" \
  --parent bb-epic1 --type task --priority p2 \
  --deps bb-profile-api

bd create --title "ActivityFeed React component" \
  --parent bb-epic1 --type task --priority p2 \
  --deps bb-activity-api

bd create --title "Profile page integration test" \
  --parent bb-epic1 --type task --priority p2 \
  --deps bb-profile-header,bb-activity-feed

Структура теперь явная. Агент, выполняющий bd show bb-profile-header, видит, что зависит от задачи profile API. Если эта задача ещё не выполнена, агент знает, что не надо начинать. Когда агент API заканчивает и отмечает свою задачу выполненной, зависимость фронтенд-агента разрешается.

Рабочий процесс агента следует предсказуемому циклу:

# Agent claims the task
bd update bb-profile-api --claim --actor eng1

# Agent comments its plan before writing code
bd comments add bb-profile-api --author eng1 "PLAN:
1. Create route handler at server/routes/profile.ts
2. Add service layer at server/services/profile.ts
3. Return shape: { id, name, avatar, bio, joinedAt }
4. Test: curl localhost:3000/users/1/profile returns 200"

# Agent implements, tests, commits
# ...

# Agent marks done with verification steps
bd comments add bb-profile-api --author eng1 "DONE: Profile endpoint implemented.
Returns { id, name, avatar, bio, joinedAt }.
Verified: curl returns 200 with correct shape.
Commit: abc1234"

bd update bb-profile-api --status ready_for_qa

Каждый шаг записан. QA-агент читает комментарий DONE и точно знает, как верифицировать. Нижестоящий агент читает комментарий PLAN и знает контракт API ещё до того, как код готов.

Это не накладные расходы ради процесса. Это минимальная структура, которая не дает пяти параллельным агентам произвести пять несовместимых кусков кода.

Выбор по умолчанию

После месяцев работы параллельных агентов на продакшн-задачах, вот дерево решений, которому я следую:

Начинайте с субагентов, когда:

Задача это исследование или разведка (поиск, чтение, сравнение)
Результаты должны сойтись в одно действие
Вся работа помещается в одно окно контекста
Не нужна независимая верификация каждой параллельной единицы

Переключайтесь на отдельные задачи, когда:

Разные части работы затрагивают разные файлы
У каждой части свои критерии приемки
Вы хотите, чтобы QA проверяло части независимо
Работа достаточно длинная, чтобы одна часть могла завершиться на часы раньше другой
Агентам нужен разный контекст (фронтенд-агенту не нужны внутренности базы данных)

Гибридный подход для сложных фич: Используйте субагентов для фазы исследования и планирования (разослать, собрать информацию, синтезировать план), затем разбейте реализацию на отдельные задачи для независимых агентов. Workflow spec-driven development естественно вписывается сюда: один агент с субагентами пишет спецификацию, затем спецификация декомпозируется в задачи для мультиагентного флота.

Визуализация декомпозиции

Когда у вас пять или десять структурированных задач с зависимостями между ними, отслеживать прогресс в терминале становится сложно. bd list показывает плоский список. Не показывает, какие задачи заблокированы, какие готовы к запуску или насколько продвинулся epic.

Это проблема, которую решает Beadbox. Он читает ту же базу данных beads и рендерит деревья epic с индикаторами прогресса, связями зависимостей и назначениями агентов. Вы видите, какие подзадачи выполнены, какие заблокированы предусловиями, а какие готовы для агента. Граф зависимостей, указанный через --deps, становится визуальной картой вашей параллельной работы.

Когда агент заканчивает задачу и обновляет статус, Beadbox отражает изменение в реальном времени. Без обновления страницы, без повторного запуска bd list. Дерево обновляется, полоса прогресса движется, заблокированные задачи разблокируются по мере разрешения зависимостей.

Те же данные. Просто видимые.

Если вы строите подобные рабочие процессы, поставьте звезду Beadbox на GitHub.

Субагенты Claude Code или структурированная декомпозиция задач: когда что использовать