Вот мой терминал прямо сейчас.

Сессия tmux с 13 агентами

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

Проект -- Beadbox, панель реального времени для мониторинга ИИ-агентов. Он построен тем самым флотом агентов, который мониторит. Агенты пишут код, тестируют его, ревьюят, упаковывают и выпускают. Я координирую.

Если вы запускаете больше двух-трёх агентов и задаётесь вопросом, как отслеживать, что они все делают, вот к чему я пришёл после месяцев итераций. Баг был зарегистрирован в 9 утра и исправлен к 15 часам, пока четыре других рабочих потока шли параллельно. Не всегда все идет гладко, но пропускная способность реальна.

Состав команды

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

Группа	Агенты	Зона ответственности
Координация	super, pm, owner	Распределение задач, продуктовые спеки, бизнес-приоритеты
Инженерия	eng1, eng2, arch	Реализация, проектирование систем, тестовые наборы
Качество	qa1, qa2	Независимая валидация, релизные гейты
Операции	ops, shipper	Платформенное тестирование, сборки, релизы
Рост	growth, pmm, pmm2	Аналитика, позиционирование, публичный контент

Ключевое слово -- границы. eng2 не может закрывать задачи. qa1 не пишет код. pmm никогда не трогает исходники приложения. Super распределяет работу, но не реализует. Границы существуют потому, что без них агенты отклоняются. Они "помогают", рефакторя код, который не нуждался в рефакторинге, или закрывая непроверенные задачи, или принимая архитектурные решения, к которым не готовы.

Каждый CLAUDE.md начинается с параграфа об идентичности и секции с границами. Вот сокращённая версия того, что выглядит eng2:

## Identity
Engineer for Beadbox. You implement features, fix bugs, and write tests. You own implementation quality: the code you write is correct, tested, and matches the spec.

## Boundary with QA
QA validates your work independently. You provide QA with executable verification steps. If your DONE comment doesn't let QA verify without reading source code, it's incomplete.

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

Координационный слой

Три инструмента держат флот вместе.

beads -- это open-source, Git-нативный трекер задач, созданный именно для этого рабочего процесса. Каждая задача -- "bead" со статусом, приоритетом, зависимостями и тредом комментариев. Агенты читают и пишут в одну локальную базу данных через CLI под названием bd.

bd update bb-viet --claim --actor eng2   # eng2 берёт баг
bd show bb-viet                           # полная спека и комментарии
bd comments add bb-viet --author eng2 "PLAN: ..."  # eng2 публикует план

gn / gp / ga -- инструменты обмена сообщениями в tmux. gn отправляет сообщение в панель другого агента. gp подсматривает последний вывод другого агента (не прерывая его). ga ставит в очередь несрочное сообщение.

gn -c -w eng2 "[from super] You have work: bb-viet. P2."  # назначение
gp eng2 -n 40                                               # проверка прогресса
ga -w super "[from eng2] bb-viet complete. Pushed abc123."  # отчёт

Протоколы CLAUDE.md определяют пути эскалации, формат общения и критерии завершения. Каждый агент знает: взять задачу, прокомментировать план перед кодированием, прогнать тесты перед пушем, прокомментировать DONE с шагами верификации, пометить ready for QA, отчитаться super.

Вот как это выглядит на практике. Это настоящий bead с сегодняшнего дня: super назначает задачу, eng2 комментирует пронумерованный план, eng2 комментирует DONE с шагами верификации QA и отмеченными критериями приемки, super передает в QA.

A real bead comment thread showing the full PLAN/DONE workflow

Super выполняет патрульный цикл каждые 5-10 минут: смотрит вывод каждого активного агента, проверяет статус задач, убеждается, что конвейер не застрял. Это как дежурство в продакшене, только сервисы -- ИИ-агенты, а инциденты -- "eng2 подозрительно тихий уже 20 минут."

Настоящий день

Вот что реально произошло в среду в конце февраля 2026 года.

9:14 -- Пользователь GitHub ericinfins открывает Issue #2: не может подключить Beadbox к удалённому серверу Dolt. Приложение поддерживает только локальные подключения. Owner видит и передаёт super.

9:30 -- Super распределяет работу. Arch проектирует поток авторизации подключения (переключатель TLS, поля логин/пароль, передача переменных окружения). PM пишет спеку с критериями приёмки. Eng берёт в работу и начинает реализацию.

Тем временем, параллельно:

PM заводит два бага, обнаруженных при релизном тестировании. Один косметический: бейдж в шапке показывает "v0.10.0-rc.7" вместо "v0.10.0" в финальных сборках. Другой платформенный: инструмент автоматизации скриншотов возвращает пустую полоску на ARM64 Mac, потому что Apple Silicon рендерит WebView Tauri через Metal, и буфер пуст.

Ops находит корневую причину бага скриншотов. Исправление элегантное: после захвата проверяем, не подозрительно ли мала высота изображения (меньше 50px для окна, которое должно быть 800px), и в таком случае переключаемся на захват по координатам.

Growth получает данные PostHog и запускает IP-корреляционный анализ. Вывод: реклама в Reddit дала 96 кликов и ноль удержанных пользователей. Трафик из GitHub README конвертируется на 15.8%. Эта статья существует благодаря этому анализу.

Eng1, разблокированный дизайном Activity Dashboard от arch, начинает строить управление состоянием кросс-фильтров и утилитные функции. 687 тестов проходят.

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

14:45 -- Shipper мержит PR релиз-кандидата, пушит тег v0.10.0 и запускает workflow продвижения. CI собирает артефакты для всех 5 платформ (macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe). Shipper проверяет каждый артефакт, обновляет release notes в обоих репозиториях, редеплоит сайт и обновляет Homebrew cask.

15:12 -- Owner отвечает на GitHub Issue #2:

Good news: v0.10.0 just shipped with full Dolt server auth support. Update and you should be unblocked.

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

Это не потому, что 13 агентов быстрые. А потому, что 13 агентов работают параллельно.

Что идёт не так

Это часть, которую большинство постов "смотрите мой ИИ-сетап" опускают.

При высокой конкурентности срабатывают лимиты. Когда 13 агентов работают на одном API-аккаунте, токены сгорают быстро. В этот конкретный день super, eng1 и eng2 одновременно упёрлись в потолок лимита. Все останавливаются. Ждёте. Это как если бы все в офисе одновременно решили воспользоваться принтером, только принтер берёт плату за страницу и имеет лимит страниц в минуту.

QA возвращает работу. Это by design, но добавляет циклов. QA отклонил сборку, потому что комментарий "DONE" инженера не содержал шагов верификации. Исправление работало, но QA не мог подтвердить без чтения исходного кода. Обратно к eng, переписать комментарий завершения, снова к QA, повторная верификация. Двадцать минут вместо пяти. Протокол создаёт трение, но это несущее трение. Каждый раз, когда я пропускал QA, что-то ломалось в продакшене.

Контекстные окна заполняются. Агенты накапливают контекст за сессию. У Super есть протокол отправки директивы "сохрани работу" при 65% использования контекста. Если пропустить этот момент, агент теряет нить того, что делал.

Агенты застревают. Иногда агент попадает в цикл ошибок и продолжает повторять одну и ту же неудачную команду. Патрульный цикл Super это ловит, но только если вы проверяете достаточно часто. Я потерял 30 минут из-за агента, который вежливо падал в тишине.

Координационные накладные расходы реальны. Файлы CLAUDE.md, протоколы распределения, патрульные циклы, комментарии к задачам, отчёты о завершении. Для двух агентов это перебор. Для 13 агентов это минимально жизнеспособная структура. Где-то около 5 агентов есть точка перехода, где неформальная координация перестаёт работать и нужны явные протоколы, иначе вы теряете контроль.

Чему я научился

Специализация побеждает универсальность. 13 сфокусированных агентов работают лучше 3 "full-stack". Когда qa1 только валидирует и никогда не пишет код, он каждый раз ловит то, что eng пропустил. Когда arch только проектирует и никогда не реализует, дизайн чище, потому что нет соблазна срезать углы в спеке ради удобства реализации.

Независимый QA -- не предмет обсуждения. У QA свой клон репозитория. Он тестирует запушенный код, не рабочую директорию. Он не доверяет самоотчётам инженера. Звучит медленно. Ловит баги в каждом релизе.

Вам нужна видимость, иначе флот дрейфует. При 5+ агентах вы не можете отслеживать состояние, переключаясь между панелями tmux и запуская bd list в голове. Вам нужна панель, показывающая дерево зависимостей, кто из агентов что делает и какие задачи заблокированы. Это проблема, которую я решил, создав Beadbox.

Рекурсивный цикл имеет значение. Агенты строят Beadbox. Beadbox мониторит агентов. Когда агенты создают баг в Beadbox, флот ловит его через тот же процесс QA, что и любой другой баг. Инструмент улучшается, потому что команда, которая больше всего его использует, -- это команда, которая его строит. Я понимаю, что это либо гениально, либо самая изощрённая машина Руба Голдберга из когда-либо построенных. Выпущенные фичи указывают на первое. Мой счёт за токены указывает на второе.

Стек

Если хотите попробовать сами, вот что нужно:

beads: Open-source Git-нативный трекер задач. Это координационная основа. Каждый агент читает и пишет в него.
Claude Code: Среда выполнения агентов. Каждый агент -- это сессия Claude Code в панели tmux со своим файлом идентичности CLAUDE.md.
tmux + gn/gp/ga: Терминальный мультиплексор для параллельного запуска агентов. Инструменты обмена сообщениями позволяют агентам общаться без общей памяти.
Beadbox: Визуальная панель реального времени, показывающая, что делает флот. Это то, о чём вы сейчас читаете.

Не нужно начинать сразу с 13 агентов. Два инженера и один QA-агент, координируемые через beads, изменят ваше представление о том, сколько может выпустить один разработчик.

Что дальше

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

Сейчас для этого нужен цикл патрулирования и множество команд gp. Поэтому мы встраиваем координационную панель прямо в Beadbox: полоса статуса агентов вверху, поток пайплайна, показывающий где накапливаются beads, и лента событий с перекрёстной фильтрацией, где клик по агенту или этапу пайплайна фильтрует всё остальное. Все три слоя используют один источник данных реального времени. Все три обновляются в реальном времени.

Activity Dashboard preview

13 агентов строят это прямо сейчас. Напишу об этом, когда выпустим.

Я выпускаю софт с 13 ИИ-агентами. Вот как это выглядит на самом деле