Сім AI-агентів працюють у нас ночами: агенти за розкладом не лише для коду, з промптами

23 вересня користувач на ім'я Rob написав у нашому публічному беклозі: «would love to get examples of how you guys are doing stuff beyond coding». Слушне запитання. Увесь цей сайт присвячений агентам для коду, а те, що ми насправді запускаємо щовечора, здебільшого не код.

З 28 серпня сім агентів запускаються на Mac mini о 20:00. Вони читають коміти за день, Search Console, адмінські дашборди, беклог, відгуки, які надіслали люди, звіти минулої ночі. Вони виправляють баги, правлять сайт, пишуть і перекладають статтю для блогу раз на три дні, публікують пости у трьох соцмережах, оновлюють базу знань про продукт, а о 22:00 сьомий читає те, що залишили решта шість, і надсилає лист на 25 рядків. Ніхто за ними не стежить. Засновник читає лист на телефоні наступного ранку.

Ця стаття і є відповіддю для Rob. Що працює, як це влаштовано, як агенти передають одне одному роботу, жодного разу не розмовляючи, яка модель робить яку роботу і чому, чотири правила, які їхнім промптам довелося вивчити на гіркому досвіді, і самі промпти, стиснуті в блоки, які можна скопіювати. Кожна цифра нижче взята з репозиторію: звіти комітяться туди ніч за ніччю.

Що дали 33 ночі

У папці звітів у репозиторії 33 датовані директорії, з 28 серпня по 30 вересня. Якщо їх прочитати, виходить ось що:

• 31 ранковий лист, надісланий репортером.
• 51 баг, виправлений фіксером, у кожного посилання на коміт у рядку звіту. Про кілька з них повідомили користувачі в публічному беклозі, і з найближчим релізом вони отримали відповідь.
• 7 статей для блогу, написаних SEO-командою з 10 вересня, по одній раз на три дні, кожна спершу англійською та французькою, потім ще 18 мовами тієї ж ночі.
• 29 днів журналу соцмереж: три мережі і п'ять груп у Facebook за вечір, плюс коментар-подяка під кожним постом, де користувач поділився AgentsRoom.
• База знань про продукт приблизно зі сотні карток, яка звіряється з комітами за день; її читає вбудований асистент, а сайт віддає її як llms-full.txt.

Ніщо з цього не потребувало людини після 20:00. Дещо потребувало людини о 08:00, і в цьому весь сенс останнього агента.

Склад: хто запускається о 20:00

Кожен агент це заплановане завдання в AgentsRoom: промпт, агент (роль, CLI, модель), машина і час. Усі сім працюють на Claude Code. Двоє з них не поодинокі агенти, а команди з двох кроків, і ми ще повернемося до того, чому.

Файли .md з останньої колонки всі лежать у reports/night/<date>/, закомічені й запушені. Ця папка і є вся система координації, а наступний розділ пояснює чому.

Як це влаштовано

Кожен із семи це заплановане завдання однакового вигляду:

• Спрацьовує щодня о 20:00 (о 22:00 для репортера). Жодного cron-виразу; частота вибирається в редакторі.
• Прив'язане до однієї машини. Проєкт відкритий на кількох комп'ютерах, і тригер спрацьовує на кожній машині, де він є, якщо його не обмежити. Наші обмежені Mac mini, тож ноутбук, відкритий о 20:05, не запускає другого CEO.
• Будить машину. Mac mini спить. У завдання є опція «розбудити машину», яка планує пробудження штатним інструментом операційної системи (pmset на macOS, Планувальник завдань із пробудженням для запуску на Windows, rtcwake на Linux) за кілька секунд до запуску. Без неї спляча машина просто пропускає запуск.
• Надолужування ввімкнене чи вимкнене, для кожного завдання окремо. Якщо о 20:00 машина була вимкнена, завдання з увімкненим надолужуванням спрацьовує під час наступного запуску застосунку. У CEO, PM і репортера воно ввімкнене. У завдань SEO, фіксера, соцмереж і документації вимкнене: запуск, що почався б об 11:00 наступного ранку, зіткнувся б із денною роботою в тому самому чекауті.
• Режим дозволів задається на завданні, а не на провайдері. Запуск без нагляду не може зупинитися на запиті підтвердження о 3 ночі, тож завдання працює без них, а агенти, якими засновник керує вручну на тому самому CLI, як і раніше спершу питають.
• Консоль закривається після 60 хвилин бездіяльності. Агент, який закінчив роботу, не висить у бічній панелі, доки його хтось не закриє.
• Промпт це перше повідомлення. Текст кожного промпту зберігається в бібліотеці промптів і збігається з текстом поля промпту в тригері, тож змінити один означає змінити обидва. Промпти написані французькою, бо засновник читає звіти французькою. Усе інше, від повідомлень комітів до бази знань, англійською.

Ще одна деталь спільна для всіх семи: скіл під назвою «нічні агенти, спільні правила». Кожен промпт починається словами «завантаж цей скіл і застосуй його», а скіл містить усе, що правдиве для всіх: хто за що відповідає, правило «одна ніч, один запуск», права в git, формат звіту, правила беклогу і формат листа для репортера. Коли правило змінюється, воно змінюється в одному місці.

Як вони передають одне одному роботу, не розмовляючи

Сім агентів ніколи не пишуть одне одному. Могли б, в AgentsRoom є обмін повідомленнями між агентами, але повідомлення не видно наступного ранку, і по ньому не зробиш grep. Усе йде через три речі, які переживають ніч:

Репозиторій. Кожен агент пише reports/night/<date>/<agent>.md, відкриває його в першу хвилину запуску, переписує після кожної завершеної частини роботи, комітить і пушить. У звіту чотири фіксовані розділи: «У двох словах» (маркований список, один пункт на кожну зроблену справу), «Вирішити» (лише те, що промпт залишає людині), «Перевірити» (локальний URL або екран, який треба відкрити), «Деталі» (скільки знадобиться). Закінчується він міткою запуску: останнім комітом, який бачив агент.

Беклог. Агент, який знаходить роботу для іншого, сам цю роботу не робить. Він відкриває тікет із тегом: ceo-fix для перевіреного невеликого бага, який візьме фіксер; ceo-seo для завдання з контенту з цільовим запитом; ceo-decision для всього, що потребує людини (база даних, білінг, авторизація, шифрування, ціни, проіндексований URL, поведінка за замовчуванням). Хранитель документації, читаючи коміти, знаходить фічу без сторінки на сайті: він заводить тікет ceo-seo, і SEO бере його наступної ночі. CEO, читаючи логи помилок, знаходить баг із його причиною в коді: ceo-fix, і фіксер бере його наступної ночі.

Учорашній звіт. Перш ніж братися за будь-яку роботу, кожен агент читає свій звіт за минулу ніч, а також список тікетів, закритих за день. Те, про що він повідомив учора, часто вже виправлено за день. Уже розібрана тема не порушується знову; уже відкритий тікет не створюється заново.

Цикл замикається на людині. Лист репортера закінчується одним рядком: щоб відповісти продакт-менеджеру, додай розділ «## Рішення» в кінець rapport.md (P1 OK / P2 НІ: причина / P3 ПІЗНІШЕ), commit, push. PM читає запушену версію наступного вечора і виконує те, що схвалено: створює тікет, об'єднує дублікати, відкладає решту із зазначенням причини. Рішення, на яке три ночі немає відповіді, це теж рішення: пропозиція зникає з листа і залишається тікетом.

Яка модель робить яку роботу і чому

У таблиці вище дві моделі. Це поточна конфігурація, а не бенчмарк, і вона змінюється. Але поділ зроблено навмисно.

Fable там, де робота потребує судження. CEO вирішує, чи «палець униз» в оракула це справжня помилка, чи справа смаку. Фіксер вирішує, чи повідомлення про баг це баг, чи налаштування конкретної машини, а потім знаходить причину в коді. Крок 1 SEO вирішує, яка фраза на сайті стала неправдою після сьогоднішнього коміту, яку статтю написати і яку сторінку не чіпати. Крок 1 соцмереж вибирає тему вечора і пише для аудиторії, яка розпізнає згенерований текст за три рядки. Ці промпти довгі (у SEO близько 4 000 слів) і повні правил «ти вирішуєш, ти не питаєш» із короткими списками винятків. Саме тут найсильніша модель виправдовує свою ціну.

Opus із контекстом 1M там, де робота це обсяг. Перекласти статтю 18 мовами за допомогою субагентів, по три локалі на кожного, а потім звірити об'єднаний результат із французьким еталоном, це читання й письмо, дуже багато, з тими самими правилами, застосованими 18 разів. Хранитель документації читає денні дифи проти сотні карток. PM читає 8-мегабайтний експорт розмов при виході. Репортер читає п'ять звітів і копіює, він не думає. Там великий контекст і нижча ціна за токен важать більше за судження.

Тому двоє із семи це команди з двох кроків, де кожен крок це агент зі своєю моделлю. Крок 1 на Fable закінчує роботу тим, що пише розділ «Передача» у спільному звіті: точний список файлів і ключів, які має здати перекладач, або точні пости, які має опублікувати публікатор. Крок 2 на Opus читає цей розділ і робить лише те, що в ньому перелічено. Граф команди лінійний, один цикл, і звіт зберігає рядок «запуск триває», доки крок 2 його не прибере. Ззовні, о 22:00, звіт, досі позначений «триває», означає або обірваний запуск, або команду між двома кроками, і репортер каже, що саме.

Чотири правила, які довелося вивчити промптам

Перші промпти були посадовими інструкціями. Нинішні складаються переважно з правил, і в кожного правила є дата, бо кожне було написане після ночі, яка пішла не так.

1. Мітка запуску, прочитана у вчорашньому звіті. Перша версія SEO-агента читала «коміти за останні 24 години». Дві проблеми: запуск о 20:00 і запуск о 20:10 наступного дня бачать не ті самі 24 години, а ніч, коли агент не запускався, це день комітів, на які ніхто не дивиться. Тепер кожен звіт закінчується рядком Останній побачений коміт: <sha>, і наступний запуск починає з цього коміту, хоч би що показував годинник. Немає мітки (перша ніч, звіт відсутній): два дні назад, і звіт це зазначає.

2. Історія лежить на диску, тож зроби по ній grep, перш ніж щось порушувати. Скарга, яка звучала найчастіше в перші два тижні: «ти мені це вже казав, я вчора це виправив». Виправлення це правило з командою всередині: перш ніж повідомляти про тему чи братися за роботу, grep -ril "<тема>" reports/night/ і git log --since="30 days ago" -- <файл>. Збіг означає: спершу прочитай той звіт. Три випадки, і лише три, дозволяють знову говорити про розібрану тему: виправлення не спрацювало, і ти щойно це перевірив; виправлення часткове, і ти називаєш, що залишилося; тема змінила свою природу. Разом із цим прийшли два наслідки. Одна ніч, один запуск: якщо звіт за цю ніч існує, містить «У двох словах» і більше не каже «запуск триває», агент зупиняється. І пропозиція без відповіді три ночі поспіль зникає зі звіту; тікет залишається.

3. Звіт відкривається до початку роботи. Запуск, обірваний о 21:30, раніше не залишав нічого. Тепер перше, що робить агент після завантаження скіла, це mkdir -p reports/night/$(date +%F) і запис каркаса звіту з чотирма заголовками розділів і рядком запуск триває, почато о 20:01. Після кожної завершеної роботи він переписує файл повністю. Обірваний запуск залишає частковий звіт, який репортер може скопіювати, і це набагато краще, ніж агент, який «не запускався».

4. Коміть по ходу роботи, ніколи наприкінці. Виміряно 9 вересня: два агенти були зупинені в ту саму хвилину. Той, що комітив після кожної роботи, нічого не втратив. Інший залишив 45 змінених, незапушених файлів, які ні до кого не можна було віднести; засновник розбирав їх вручну наступного ранку, а звіту цього агента не існувало. Відтоді правило таке: один коміт на кожну завершену роботу, файли перелічені по одному, останній коміт для звіту і хоча б один push під час запуску. Коміт це ще й датований слід, і саме по ньому робить grep правило 2.

П'яте правило не про пам'ять, а про сміливість, і саме воно найбільше змінило результат. Промпт SEO каже: «Ти не аудитор, який доповідає про знахідки: уночі сайт належить тобі. Запуск, який закінчується шістьма ідеями на затвердження, це провальний запуск». Далі він перелічує шість випадків, і лише шість, коли агент має спитати, а не діяти: видалити або перейменувати URL, змінити заголовок сторінки, яка ранжується, юридичний текст, ціна чи квота, твердження про приватність або шифрування, зміна, що зачіпає понад п'ять сторінок. Усе інше він робить, а засновник наступного ранку прибирає те, що йому не подобається. У фіксера те саме правило з трьома випадками. До цього правила звіти були списками пропозицій. Після нього це списки комітів.

Промпти

Оригінали написані французькою і довгі. Нижче та частина, яка переноситься, без шляхів і назв, специфічних для нашого проєкту. Три блоки: спільні правила, які завантажує кожен агент, репортер і два розділи «ти вирішуєш, ти не питаєш».

Блок 1: спільні правила (усі сім завантажують їх як скіл)

# Нічні агенти: спільні правила
Вони важливіші за твій власний промпт, якщо вони розходяться.

## Одна ніч, один запуск
DAY=$(date +%F); F=reports/night/$DAY/<ти>.md
Якщо F існує, містить «У двох словах» і більше не містить «запуск триває»:
зупинись. Нічого не пиши, нічого не надсилай, закінчи повідомленням в один рядок.
Якщо там досі написано «запуск триває»: це твій власний запуск, обірваний кілька хвилин тому.
Продовж із того місця, де він зупинився, не починай заново.

## Що тобі можна
- Git: add <перелічені файли>, commit, push ТВОЄЇ роботи, по ходу справи.
  Ніколи: add -A, commit -a, push --force, stash, reset, checkout, clean, нова гілка.
- Збірка: typecheck, lint, скрипти перевірки, локальна збірка для перевірки.
  Ніколи: скрипт, який деплоїть або публікує.
- Беклог: створити тікет, дописати в тікет, закрити тікет, який ти виправив.
  Ніколи: відповідати користувачу (це надсилає лист), видаляти тікет, перезаписувати опис.
- Ніколи не вигадуй цифр. Джерело недоступне: скажи про це і йди далі.
- Перед будь-яким записом у git: git status --short. Дерево спільне з іншими агентами.

## Надолужити зміни і знати, що ВЖЕ зроблено
git fetch && git status -sb
Відстаєш, дерево чисте: git pull --ff-only. Відстаєш, дерево брудне: не роби pull, напиши про це на початку звіту.
Твоя мітка запуску: рядок «Останній побачений коміт: <sha>» наприкінці вчорашнього звіту.
Немає мітки: --since="2 days ago", і скажи про це.
Три обов'язкові читання перед будь-яким аналізом:
1. git log --no-merges --format='%h %s' <sha>..HEAD і git diff --stat <sha>..HEAD
2. тікети, закриті від учора, і тікети, які людина поставила на паузу
3. твій власний учорашній звіт: «У двох словах» і «Вирішити»

## Папка звітів І Є твоя історія
Перш ніж порушувати знахідку чи братися за роботу:
grep -ril "<тема>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <файл>
Є збіг: прочитай той звіт, перш ніж щось вирішувати.
Дві ночі поспіль на одну тему: друга змарнована.
Сторінку чи текст, яких ти торкався, не чіпають знову три тижні,
хіба що щоб виправити те, що стало неправдою.

## Ніколи не порушуй те саме двічі
Уже розібрана знахідка, яка повертається наступного дня, це помилка.
Це допустимо лише в трьох випадках:
1. виправлення не спрацювало, і ти щойно це перевірив: «виправлено <дата> в <коміт>, досі зламано: <доказ>»
2. виправлення часткове: назви точно, що залишилося
3. тема змінила природу: нова причина, новий вимір, новий обсяг
Не перераховуй запас. Повідомляй про зміну, ніколи про запас.

## Пропозиція без відповіді вмирає через три ночі
Ночі з 1-ї по 3-тю: рядок несе свій лічильник і першу дату («2-га ніч, порушено 07/09»).
З 4-ї: вона зникає з «Вирішити». Тікет залишається; щонайбільше один рядок у «Деталях».
Якщо рішення у твоїй зоні, ухвали його на 3-тю ніч і скажи про це.

## Коміть і пуш по ходу роботи
Перший коміт, щойно перша робота завершена й перевірена. Далі по одному на роботу.
Останній коміт для твого звіту. Пуш хоча б раз під час запуску і один раз наприкінці.
Push відхилено (віддалений репозиторій пішов уперед): git pull --ff-only, потім push. Знову відхилено: не форсуй,
не роби rebase, напиши про це у звіті.

## Твій звіт: відкритий на початку, ніколи не пишеться лише наприкінці
reports/night/<YYYY-MM-DD>/<ти>.md, створений ДО роботи, з таким вмістом:
  # <Агент> - <дата>
  _запуск триває - почато о <HH:MM>_   (прибирається наприкінці)
  ## У двох словах     (від 3 до 5 рядків або маркований список: один пункт на кожну зроблену справу)
  ## Вирішити          (лише те, що твій промпт залишає людині; інакше «Нічого»)
  ## Перевірити        (- [ ] що : де : що має бути видно; інакше «Нічого»)
  ## Деталі            (скільки знадобиться: докази, файли, команди)
  ## Мітка запуску
  Останній побачений коміт: <git rev-parse HEAD після твого останнього коміту>
Переписуй файл повністю після кожної завершеної роботи.
Читач дивиться з телефона, дві хвилини: короткі фрази, без шляхів до файлів,
без SHA, без назв функцій у першому розділі. Цифра лише тоді, коли вона змінює рішення.

Блок 2: репортер (22:00)

Ти репортер. Ти запускаєшся через дві години після інших.
Твоє єдине завдання: прочитати, що вони залишили, і надіслати ОДИН лист, який засновник прочитає
за хвилину на телефоні і зрозуміє, нічого більше не відкриваючи.
Ти нічого не аналізуєш, нічого не виправляєш, нічого не пропонуєш. Ти збираєш і прояснюєш.

Ніч, про яку ти звітуєш, читається з диска, а не з годинника:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only, якщо дерево чисте: звіти закомічені.
2. ls reports/night/$DAY: дочекайся п'яти файлів (ceo, seo, pm, fixer, social).
   Якихось немає: sleep 9 хвилин і перерахуй, максимум 6 кіл. Потім однаково надсилай, назвавши, кого немає.
3. Звіт, у якому досі написано «запуск триває», це обірваний запуск, а не відсутній.
   Скопіюй те, що в ньому є, і напиши в «Що не спрацювало», що цього агента обірвали.
4. З кожного звіту бери лише три розділи: «У двох словах», «Вирішити», «Перевірити».
   Ніколи не цитуй «Деталі».
5. Виправлені баги фіксера це пункти з трьох частин, розділених « > »:
   що терпів користувач > причина одним реченням > URL коміту.
   Копіюй їх символ у символ, разом із посиланням, у «Виправлені баги».
6. git status -sb і git log --oneline --since="4 hours ago": звіт, який заявляє
   роботу без коміту, змінені файли, які ніхто не визнає своїми, або незапушені коміти: перший рядок листа.

Напиши reports/night/$DAY/rapport.md. Не більше 25 рядків тексту
(заголовки розділів і рядки «Виправлених багів» не рахуються).
Шість правил, які застосовуються рядок за рядком:
1. Один пункт = одне завершене речення, зрозуміле саме по собі. Ніколи «як повідомлялося вчора».
2. Тема з'являється лише в ОДНОМУ розділі.
3. Нуль жаргону: ні шляхів, ні SHA, ні назв ключів, ні внутрішніх скорочень.
   Один виняток: повний GitHub URL коміту, обов'язковий у кожному рядку «Виправлених багів».
4. Цифра лише тоді, коли вона змінює рішення, і це зміна, ніколи не запас.
5. Максимум два рядки на пункт. Подробиці у звіті агента.
6. Погані новини раніше за добрі, і перший рядок каже, чи щось зламано.

Розділи, по порядку: Вирішити / Перевірити / Виправлені баги / Що зроблено /
Соцмережі (максимум 3 рядки, з посиланнями) / CLI і моделі (1 рядок) /
Що не спрацювало. Порожній розділ це одне слово: «Нічого».
Ніколи не вирізай: «Вирішити», «Виправлені баги» з посиланнями, посилання на пости, статтю SEO.
Надішли. Перевір HTTP-код. Допиши внизу «Надіслано на ... - HTTP <code>».
Commit і push для rapport.md. Ніколи не надсилай двічі: якщо в сьогоднішньому rapport.md уже є
рядок «Надіслано на», зупинись.

Блок 3: розділи «ти вирішуєш, ти не питаєш»

SEO-агент, розділ 0 його промпту:

# 0. Ти вирішуєш, ти не питаєш
Це найважливіше правило цього промпту, і воно сильніше за твій рефлекс обережності.
Ти не аудитор, який доповідає про знахідки: уночі сайт належить тобі.
Запуск, який закінчується фразою «ось 6 ідей, на затвердження», це провальний запуск.
Коли вагаєшся, стань на місце засновника і вирішуй за чотирма орієнтирами:
- що продукт робить насправді, прочитане в репозиторії та в опублікованій версії, ніколи в наявних текстах;
- що сайт уже каже: його кут зору, його тон, його обіцянки. Ти продовжуєш, ти не винаходиш заново;
- що каже Search Console: які сторінки живуть, які наміри справді існують;
- аудиторія: розробники, які шукають у Google, і AI-асистенти, які рекомендують інструменти.
  Що для них важить: твердження, яке можна перевірити і датувати; сторінка, яка відповідає на одне точне запитання;
  актуальний llms.txt, узгоджений зі сторінками; чесні порівняння.
Засновник читає твій звіт наступного ранку і скаже тобі прибрати те, що йому не подобається.
Одна зайва правка коштує п'ять хвилин; ніч без результату втрачена назавжди.

Ти питаєш його думки лише в цих шести випадках:
1. видалити або перейменувати наявний URL;
2. змінити title або meta description сторінки, яка ранжується, коли він не хибний;
3. юридичний текст (умови, конфіденційність, ліцензія);
4. ціна, комерційна квота, пропозиція;
5. твердження про приватність, шифрування або про те, де обробляються дані;
6. зміна, яка зачепила б понад п'ять сторінок одразу.
У цих шести випадках: тікет із тегом для рішення, один рядок у «Вирішити», і ти йдеш далі.
Усе інше ти робиш цієї ночі. Якщо у «Вирішити» є щось інше,
значить, ти делегував рішення, яке було твоїм.

Фіксер, розділ 0 його промпту:

# 0. Ти виправляєш, ти не класифікуєш
Баг, про який повідомив користувач, це обіцянка. Хтось знайшов час написати, він чекає,
і ніхто інший цієї ночі цим не займеться. Запуск, який повертає «5 багів проаналізовано, 1 виправлено,
4 задокументовано», це провальний запуск. Твоя мета це порожня черга: спершу баги користувачів,
від найстаріших, потім решта, доки їх не залишиться.
Коли вагаєшся щодо виправлення, вирішуй за трьома орієнтирами:
- що код робить сьогодні, прочитане, а не припущене;
- чого користувач явно очікував, коли писав повідомлення;
- найменший ризик: найвужче виправлення, яке усуває причину, а не найелегантніше.
Спірне виправлення коштує п'ять хвилин на скасування; баг, залишений ще на місяць, коштує користувача.

Залишити повідомлений баг без виправлення можна лише в трьох випадках, доведених у тікеті:
1. ти не знайшов причину після справжнього розслідування: напиши, що ти виключив,
   а не просто «не відтворюється»;
2. це не баг, це рішення: база даних, білінг, авторизація, шифрування, приватність,
   проіндексований URL, поведінка за замовчуванням. Тікет для рішення, з твоєю рекомендацією;
3. перевірка відхиляє твоє виправлення, і ти не можеш її полагодити.
«Це велике», «це зачіпає кілька файлів», «я б краще спитав» не причини.
Один баг = один коміт. Потім тікет переходить у завершені, і якщо про нього повідомив користувач,
повідомлення з двох речень стає в чергу на наступний реліз. Ніколи «в очікуванні»: ця колонка
належить людям.
Твій рядок звіту для кожного виправленого бага, який дослівно копіюється в ранковий лист:
- <що терпів користувач> > <причина, одним простим реченням> > <URL коміту>

Решта чотири промпти (CEO, PM, хранитель документації, крок 2 SEO) мають той самий каркас: завантаж скіл, назви файли, які тобі можна писати, перелічи читання по порядку, скажи, що йде в тікет і що у звіт, закінчи міткою запуску.

Що не спрацювало і досі не працює

Деякі ночі потрапляють у розділ «Що не спрацювало» листа, і їх варто перелічити, бо саме з цим ти зіткнешся.

• П'ять агентів пушать в одну гілку в ту саму хвилину. Push відхиляється, бо віддалений репозиторій пішов уперед. Правило: git pull --ff-only, потім push, ніколи не форсувати, а якщо це не вдалося двічі, звіт каже про це, і людина пушить уранці. Таке трапляється приблизно раз на тиждень.
• Коміт, який захопив файл, підготовлений іншим агентом. 29 вересня перший коміт SEO забрав видалення, яке хранитель документації додав в індекс у спільному чекауті. Нічого не втратилося (видалення було навмисним), але коміт приписано не тому агенту. Відтоді кожен коміт використовує явні pathspec, і правило «файли перелічені по одному» це не питання стилю.
• Диск, на якому о 20:10 скінчилося вільне місце, два вечори поспіль. Причина зовнішня щодо агентів, місце повернулося саме о 20:25, жоден файл не втрачено. Але звіти про це кажуть, бо ніч із заповненим диском виглядає точнісінько як ніч, коли агент нічого не зробив.
• Репортер, який 54 хвилини чекає звіт, що не прийде. Шість кіл по дев'ять хвилин це стеля. Команда між двома кроками о 22:00 виглядає як обірваний запуск, і лист каже «не завершив», що чесно і трохи тривожно читати.
• Перші тижні повторюваних знахідок. Правила 2 вище не існувало, доки засновник учетверте не написав «ти мені це казав три дні тому».

Як налаштувати це в себе

Тобі не потрібні сім агентів. Тобі потрібен один, який пише звіт, що ти читатимеш, а репортер корисний лише починаючи з третього агента. В AgentsRoom:

1. Напиши промпт у бібліотеці промптів. Почни з блоку 1 вище як скіла і короткого промпту, який каже, за що відповідає цей агент і які файли йому можна писати.
2. Створи заплановане завдання в проєкті: щодня о потрібній тобі годині, роль, CLI і модель агента, промпт, а в розширеному блоці режим дозволів для запуску без нагляду. Прив'яжи його до машини, яка його виконуватиме, і ввімкни «розбудити машину», якщо ця машина спить.
3. Створи папку reports/night/ у репозиторії і закоміть її. Це і є весь шар координації.
4. Додай другого агента того дня, коли перший почне створювати тікети для когось іншого: тег ceo-fix щось означає, лише якщо фіксер читає його наступної ночі.
5. Коли одна робота розпадається на судження й обсяг, зроби з неї команду з двох кроків із двома моделями, і нехай крок 1 пише розділ передачі, який читає крок 2.

Сторінка запланованих завдань описує поля, а стаття про те, як поставити агентів для коду на нічну зміну, це міркування, яке передувало цьому складу. Якщо твої агенти ділять одну машину, спершу прочитай, що відбувається, коли десять із них запускають ту саму команду: це сталося в нас, уночі, і рішенням стало невелике спільне блокування.

Rob, ось що ми робимо, крім коду. Промпти і є продукт.

Поширені запитання

Чи потрібен AgentsRoom, щоб запускати агентів за розкладом отак?

Ні. Рядок cron і claude -p запустять сесію Claude Code о 20:00 на будь-якій машині. Решту ти пишеш сам: розбудити сплячий комп'ютер, надолужити запуск, який машина пропустила, залишити один запуск на ніч, коли проєкт відкритий на двох комп'ютерах, передати звіт від одного агента другому на іншій моделі і побачити на телефоні, що запуск застряг на запитанні. Заплановані завдання AgentsRoom беруть на себе ці частини, і сім агентів із цієї статті використовують їх усі. Промпти й правила переносяться як є, хоч би що запускало сесію.

Скільки коштує ніч семи агентів?

Вони працюють як сесії Claude Code на підписці Claude, як будь-який агент, запущений в AgentsRoom, тож окремого рахунку за токени для них немає, і вартість однієї ночі ми не публікували. Тримає її в межах правило «одна ніч, один запуск»: тригер, який спрацював двічі, або запуск, обірваний і розпочатий знову, не повторює роботу, бо перше, що робить кожен агент, це перевіряє, чи звіт за цю ніч уже існує і чи він закритий.

Чи безпечно дозволяти агентам робити commit і push, коли ніхто не дивиться?

Безпечно завдяки тому, що їм заборонено, а не тому, чого їм наказано хотіти. Спільні правила забороняють git add -A, commit -a, примусовий push, stash, reset, checkout, clean, створення гілки і будь-який скрипт, що деплоїть. Кожен коміт перелічує свої файли по одному, дерево перевіряється через git status перед будь-яким записом, а push, відхилений через те, що віддалений репозиторій пішов уперед, розв'язується через pull у режимі fast-forward або залишається людині. Ранкова перевірка це список комітів за ніч, а все, що не так, скасовується revert за п'ять хвилин.

Чому агенти пишуть звіти в Markdown просто в репозиторій, а не в дашборд?

Бо звіт це ще й пам'ять. Кожен агент починає з читання свого звіту за минулу ніч, знаходить там свою мітку запуску (останній коміт, який він бачив) і робить grep по всій папці звітів, перш ніж щось порушувати, тож тема, розібрана минулого тижня, не порушується знову. Дашборд показав би ті самі цифри і нічого б не пам'ятав. Коміт звіту ще й датує його, і саме це дає наступній ночі точно знати, чого торкалася попередня.

Чому два із семи агентів це команди з двох кроків на двох різних моделях?

Бо дві половини роботи це не та сама робота. SEO-крок, який читає Search Console, вирішує, що на сайті стало неправдою, і пише статтю англійською та французькою, потребує судження і працює на Fable. Перекласти цю статтю ще 18 мовами, прогнати i18n-перевірки і збірку це обсяг, і він працює на Opus із контекстом 1M. Перший крок пише у спільному звіті явний розділ передачі, другий робить лише те, що перелічено в цьому розділі. Так само поділена команда соцмереж: тексти й візуал на Fable, публікація в Chrome і подяки на Opus.

Що відбувається, коли запуск обривається посередині?

Звіт існує з першої хвилини запуску, з рядком «запуск триває», і кожна завершена частина роботи комітиться одразу. Тож запуск, обірваний о 21:40, залишає частковий звіт, свої коміти і жодного невідстежуваного файлу. Репортер копіює частковий звіт і пише, що агента обірвали. Ми засвоїли це на гіркому досвіді 9 вересня: два агенти зупинилися в ту саму хвилину, той, що комітив по ходу роботи, нічого не втратив, інший залишив 45 змінених файлів, які ніхто не міг ні до кого віднести.