Я поставил 8 Claude-агентов работать в 17:00 и пошёл спать. К утру они написали Telegram-бота с 37 файлами исходного кода, 266 тестами, деплоем на сервер и документацией.
Это не симуляция и не cherry-picked демо. Код реально задеплоен и работает. Вот что произошло и почему это важно.
Зачем вообще команда агентов
Стандартная работа с Claude — один контекстный window. Это означает: начал сессию, попросил написать бот, получил код, закрыл — Claude забыл всё. На следующий день начинаешь заново. Параллелизации нет, специализации нет, верификации нет. Один agent — один поток мысли, который обрывается при закрытии вкладки.
Я строю автономных AI-агентов как продукт — и меня давно интересовало, можно ли сделать так, чтобы Claude работал без меня. Не 30 минут пока я пью кофе, а 7-8 часов. С реальным результатом на выходе.
Идея проста: команда специализированных агентов с persistent state через файлы и cron-планировщиком. Каждый агент — это claude -p (Claude Code CLI в pipe mode) с system prompt, определяющим его роль. Координация через SQLite, JSONL и Maildir. Никакого кастомного кода на Python или специальных оркестраторов — только bash и стандартные unix-утилиты.
Архитектура: 8 агентов, 1 Conductor
Каждые 5 минут launchd запускает dispatcher.sh. Он поднимает Conductor — лёгкий агент на Sonnet, который читает состояние системы (задачи, занятые слоты, heartbeats) и выдаёт JSON: {"agent": "builder", "reason": "...", "task": 42}. Дальше agent-wrapper.sh запускает выбранного агента изолированно.
launchd (5 min) → dispatcher.sh → Conductor → picks agent
↓
agent-wrapper.sh
↓
claude -p (10-15 min)
↓
SQLite + JSONL + Maildir
Максимум 3 агента одновременно. Каждый агент пишет только в свою область файловой системы — жёсткие file ownership правила предотвращают конфликты.
8 агентов и их роли:
| Агент | Модель | Роль |
|---|---|---|
| Conductor | Sonnet | Scheduling brain. Читает состояние, выбирает следующего агента. Read-only, не меняет данные |
| Sage | Opus | CEO+CTO. Создаёт задачи, расставляет приоритеты, разблокирует зависимости |
| Builder | Opus | Пишет production TypeScript, коммитит код, запускает тесты |
| Guardian | Sonnet | Health checks (10-point checklist), cleanup stale PIDs, WAL checkpoint |
| Scout | Sonnet | Рыночный research, web search, сбор данных |
| Judge | Opus | Code review по структурированным рубрикам, создаёт fix-задачи для Builder |
| Oracle | Opus | Meta-improvement. Единственный агент, который может редактировать SYSTEM.md других агентов |
| Pixel | Sonnet | HTML/Tailwind landing pages, деплой на сервер |
Coordination stack намеренно минималистичный:
- SQLite WAL — задачи (board.db). Atomic claims через
UPDATE ... RETURNING,busy_timeout=30000 - JSONL ledger — append-only audit log каждого действия
- Maildir — сообщения между агентами. Atomic rename
new/→cur/гарантирует delivery
Результаты в цифрах
| Метрика | Значение |
|---|---|
| Общее время работы | ~7 часов |
| Всего agent runs | 110 |
| Задач создано | 54 |
| Задач завершено | 51 |
| Файлов исходного кода | 37 |
| Тестов (passing) | 266 |
| API cost | $0 (Claude Max subscription) |
| Самый активный агент | Guardian (45 runs, 41%) |
| Самый продуктивный | Builder (16 runs, 31 задача) |
| Timeout rate | Builder 32%, Scout 67% |
Guardian с 45 runs — это не баг. Он работал каждые несколько циклов Conductor, потому что система под нагрузкой постоянно генерирует мусор: stale PID файлы, незакрытые WAL-транзакции, фрагментированные логи. Guardian чистил это фоново, пока остальные агенты делали основную работу.
Что каждый агент сделал за ночь
Builder написал полный MVP Review Autopilot — Telegram-бот для автоответов на отзывы маркетплейсов (WB, Ozon). Архитектура marketplace-agnostic: общий интерфейс MarketplaceAdapter, отдельные реализации для каждой площадки. Stack: TypeScript strict mode, grammY (Telegram), Drizzle ORM + SQLite, Claude API для генерации ответов, node-cron для расписания. 33 файла исходного кода, 266 тестов. За 16 runs.
Sage создал 54 задачи с нуля. Начал с трёх high-level эпиков, декомпозировал их до конкретных имплементационных задач, трижды пересматривал приоритеты по ходу работы. Ключевые архитектурные решения, которые он принял автономно: marketplace-agnostic engine (не hardcode WB/Ozon), adapter pattern для расширяемости, разделение bot-логики и business-логики.
Guardian провёл 45 health checks. 91% success rate — то есть 4 раза что-то шло не так. Два раза — stale PID от упавших агентов, один раз — накопившийся WAL, один раз — критически фрагментированный log файл. Автоматически починил все четыре. Без него система накапливала бы мусор и деградировала.
Judge сделал 8 code reviews. Средний скор: 7.2/10. Реальные находки: отсутствующий error handling в двух адаптерах, missing input validation на Telegram webhook, race condition в concurrent review processing. По каждой находке создавал fix-задачи для Builder — с конкретными инструкциями, не просто “исправь это”.
Oracle запустился 3 раза. Проанализировал паттерн частых timeout’ов у Scout и Builder, предложил оптимизацию Conductor prompt (добавить учёт исторических timeout’ов при выборе агента). Написал proposal → Sage одобрил → Oracle применил изменение к SYSTEM.md Conductor. The system improved itself.
Scout — самый честный провал. 2 runs, 0% completion. Оба timeout’а. Web search занимает слишком много времени при 600-секундном лимите: Scout пытался собрать данные по конкурентам, но инструменты поиска не укладывались в окно. Lesson learned: для Scout нужен timeout 900-1200 секунд, или задачи нужно дробить мельче.
Pixel собрал landing page для Review Autopilot за 4 runs. HTML + Tailwind, мобильная версия, hero section с конкретными числами из реального продукта. Задеплоил на сервер по SSH. Работает.
Самоисцеление: 28 consecutive failures
Самый впечатляющий момент эксперимента случился между 19:42 и 20:42.
Builder начал получать TypeScript errors. Circular imports, missing dependencies, неправильные module resolution paths. Guardian засёк паттерн в health checks — не просто один failed run, а систематические failures. Отправил сообщение Sage через Maildir.
Sage проанализировал ledger, увидел 28 consecutive failures за 40 минут, создал таргетированные fix-задачи с конкретными инструкциями (не “поправь TypeScript”, а “исправь circular import в src/core/review-pipeline.ts — он импортирует из src/bot/index.ts, который импортирует обратно”).
Builder применил фиксы один за одним. В 20:42 система вернулась в healthy state. В 20:45 все 266 тестов проходили.
Timeline:
- 19:42 — первый TypeScript error (circular import)
- 19:42–20:22 — 28 failures Builder/Guardian/Scout
- 20:22 — Guardian фиксирует паттерн, пишет Sage
- 20:25 — Sage создаёт 6 targeted fix-задач
- 20:30–20:42 — Builder применяет фиксы последовательно
- 20:42 — система в healthy state
- 20:45 — все тесты проходят
Ни одного человеческого действия. Система диагностировала себя, скоординировала восстановление и вышла из кризиса самостоятельно.
Команда vs один Claude
| Аспект | Один Claude | Команда из 8 |
|---|---|---|
| Контекст | Один window, теряется при закрытии | Persistent через SQLite + JSONL |
| Параллельность | Нет | До 3 агентов одновременно |
| Специализация | Jack of all trades | Specialist per role |
| Quality gate | Нет (сам себя не проверит) | Judge reviews Builder’s code |
| Self-healing | Нет | Guardian + Sage + Builder loop |
| Память между сессиями | Отсутствует | SQLite + JSONL + Maildir |
| Cost per hour | Same (Claude Max) | Same (Claude Max) |
| Human supervision | Требуется | Optional — set and forget |
Ключевое отличие не в мощности модели — та же Claude Opus. Отличие в архитектуре: persistent state + специализация + верификационные петли. Именно эта комбинация даёт автономность.
Один Claude написал бы код за сессию. Но он не проверит свой код независимым reviewer, не проведёт health check через час, не отправит сам себе сообщение “вот тут circular import”. Для этого нужны разные агенты с разными ролями и каналами коммуникации.
Что нужно докрутить для полного цикла
Текущий эксперимент — proof of concept, не production. Вот что нужно для полной автономии:
| Интеграция | Зачем | Сложность | Приоритет |
|---|---|---|---|
| GitHub CI/CD | Auto-test on push | Medium | HIGH |
| Telegram test account | End-to-end bot testing | Low | HIGH |
| Structured error reporting | Auto-create fix tasks из stacktrace | Low | MEDIUM |
| Metrics dashboard | Визуализация ledger данных | Medium | MEDIUM |
| Notification channel | Алерты в Telegram | Low | MEDIUM |
| Scout timeout fix | 900-1200s или декомпозиция задач | Low | HIGH |
| Cost tracking | Token usage per agent | Medium | LOW |
Главный gap — отсутствие GitHub CI/CD. Сейчас Builder коммитит код, который Judge проверяет только через code review (статический анализ). Автоматические тесты на push закрыли бы петлю полностью: Judge видит результат CI, создаёт fix-задачи по реальным test failures, а не по предположениям.
Второй gap — Scout. 0% completion неприемлемо для агента, который должен собирать рыночный intel. Простое решение: увеличить timeout до 1200 секунд и разбить задачи “собери данные по 5 конкурентам” на “собери данные по одному конкуренту” x5.
Выводы
Multi-agent > single agent для любого проекта, требующего больше одной сессии. Это не про мощность — это про persistence, специализацию и верификацию.
Ключевой инсайт: persistent state + специализация + верификационные петли = автономная возможность. Уберите любой из трёх элементов — система деградирует. Без persistent state агенты забывают. Без специализации нет quality gate. Без верификационных петель ошибки накапливаются.
Это не симуляция. Код задеплоен, тесты проходят, бот работает. 266 тестов — не mock, не placeholder. Builder написал реальный TypeScript с реальными unit-тестами через vitest.
Cost: $0 marginal. Claude Max — flat rate. 110 agent runs, 7 часов, production-ready продукт — без дополнительных расходов. Infrastructure: MacBook с launchd.
Когда это станет mainstream? 6-12 месяцев. Инструментарий (Claude Code CLI, claude -p) уже достаточно хорош. Недостающий элемент — оркестрация. Именно это я и строю — и теперь у меня есть рабочий proof of concept.
Следующий шаг: Ubuntu сервер вместо MacBook, 24/7 работа вместо overnight эксперимента, CI/CD интеграция, и ещё один агент — Shipper, который умеет деплоить на production самостоятельно.