ИИ-агент поставил наши рилсы в расписание за один вечер: цикл вызовов и правило «ничего без взгляда человека»

Вечером 8 ноября 2026 года наш контент-агент поставил в очередь Mellow Hub три новых ролика: восемь постов в четыре профиля Hub, на русском, английском и испанском. Работал он через MCP-сервер Hub из короткого скрипта, теми же инструментами, что есть у любого агента, и ни один пост не считался готовым, пока его не сверили. Ниже — этот вечер по вызовам и одно правило, которое стоит выше инструментов: ничто для аккаунтов основателя не уходит в Hub, пока он это не увидел.

Что может ключ, как устроены режим проверки и отзыв доступа — в отдельном кейсе. Здесь практическая часть: что агент вызывал, в каком порядке и что получил в ответ.

Задача: три ролика, три языка, четыре профиля

В тот день были готовы три ролика, каждый на русском, английском и испанском. Два — для личных линий основателя, Влада: его русский аккаунт, английский аккаунт и испанская линия, которая живёт во втором профиле Hub. Третий — собственный ролик Mellow, и он идёт только туда, где говорит Mellow: на испанском во второй профиль, на английском — в @mellow_planner, Instagram Mellow.

В Hub один доступ открывает один профиль, поэтому у агента было четыре ключа и маленькая таблица «язык → ключ». Получилось восемь постов: два русских, два английских, три испанских и один английский в аккаунте Mellow. Семь ушли в Instagram и YouTube сразу, последний — только в Instagram.

До Hub: «да» на каждый пункт

С 22 октября у основателя правило: ничто для его аккаунтов не попадает в Hub, пока он это не отметил. Агент собирает страницу, где каждый пункт выглядит ровно так, как выйдет, — по языкам и с настоящей подписью, — и Влад отвечает на каждый «ок», «не ок» или комментарием. Правило появилось после 22 октября, когда агент с правом публиковать сам поставил 34 поста, которых основатель не видел (что тогда случилось).

8 ноября он сказал «заливай» после русских версий. Английские и испанские собрали и проверили так же, и в тот же вечер агент поставил все восемь.

В Hub этот шаг встроен: ключ с галочкой «Проверять перед публикацией» готовит каждый пост и останавливается. 8 ноября мы ещё раз проверили это на тестовом стенде, где тогда работал тот же код, что и на боевом сервере, только с выдуманными аккаунтами. create_post от свежего ключа в режиме проверки вернул pending_review; тот же вызов с тем же ключом идемпотентности вернул тот же пост; а когда ключ попытался одобрить собственный пост, Hub отказал с approval_requires_person. Человек видит такой пост с пометкой «Нужна проверка».

Что выбрать, зависит от того, где удобнее смотреть. Режима проверки в Hub достаточно, если вы одобряете пост за постом. Мы держим страницу, потому что основатель читает три языка рядом, с комментариями, ещё до загрузки.

Цикл по вызовам

1. Сначала whoami. Один вызов сообщает режим, права, каналы и сколько постов ключу осталось на сегодня. Около 12:00 UTC 8 ноября все четыре ключа ответили: автопилот, лимит 50 постов в день, осталось 45, 47, 46 и 49. Это число для планирования, а не для справки.
2. Загрузить один раз. request_upload_url даёт подписанный адрес, и видео уходит прямо в хранилище, минуя Hub. Загруженные файлы весили от 32 до 49 МБ; для одного ролика это была копия на 32 МБ вместо исходника на 115–122 МБ. Локальная таблица связывает ролик и язык с адресом медиа, так что повтор берёт уже загруженный файл.
3. validate_post ровно с теми аргументами, что пойдут в создание. Он ничего не публикует и возвращает все проблемы сразу, называя канал и поле. Проверять не то, что потом отправишь, — значит не проверять ничего.
4. create_post с ключом идемпотентности. Ключ собирается из содержания, а не случайно: владелец, язык, серия, ролик и версия. Повтор после таймаута тогда получает уже созданный пост, а не второй, а новая версия получает новый ключ сознательно.
5. get_post, чтобы сверить. Статус, время по UTC, каналы и настройки для каждой сети. Пост считается запланированным, когда это показывает сверка, а не когда вызов создания вернул ответ.

Что вернулось

• Ни одного дубля. С 18:38 UTC 7 ноября до 11:36 UTC 8 ноября серия сделала 38 вызовов create_post, и это 38 разных постов. Чтение всех четырёх очередей в 15:58 UTC 8 ноября не нашло ни одной подписи, стоящей в расписании дважды.
• Ошибка, за которой пост уже сохранён. Один вызов вернул ошибку лимита запросов от провайдера публикации с пометкой «можно повторить» — и в ответе был номер поста. Пост существовал и стоит в очереди на 10 ноября. Повтор с новым ключом дал бы два. Отсюда порядок: прочитать номер, проверить через get_post и повторять только с тем же ключом.
• Восемь постов 8 ноября. Около 12:00 UTC все восемь при сверке стояли в расписании. К 16:01 UTC два русских уже вышли: слот 12:00 — на YouTube в 12:02 и в Instagram в 12:06, слот 14:45 — в обеих сетях в 14:48. Остальные шесть ждали своего времени позже в тот же день.

Время агент выбирал вручную: читал запланированные посты каждого профиля и ставил новые между ними, потому что прочитать очередь по времени агенту в Hub нечем. Этот пробел и ещё шесть — в разборе чего ИИ-агенту не хватает в API публикации.

Что пошло не по плану

• Пробный рилс в маленьком аккаунте. 7 ноября первый английский пост одного ролика попросил у Instagram пробный рилс для аккаунта, где меньше 200 подписчиков. Instagram его не дал, Hub так и написал («Instagram did not give this reel a trial, and it was not posted as an ordinary reel»), в Instagram ничего не ушло, а половина на YouTube вышла. Агент создал пост для Instagram заново, обычным рилсом, и тот вышел в 19:21 UTC. validate_post проверяет, что пробный — это одно видео в формате рилса; подписчиков аккаунта он не видит. Подробности — в кейсе про пробные рилсы через API.
• Пересоздания. Два английских поста отменили и создали заново после правки. Отменённый пост в списке — это именно это, а не сбой.
• Ответ с лимитом выше, который стал бы дублем, если бы агент поверил ошибке, а не номеру поста.

Всё это не делает агента безошибочным. Это делает его ошибки видимыми и дешёвыми — их можно исправить до того, как наступит время поста.

Как сделать самому

1. Дайте каждому профилю свой доступ, вызывайте whoami первым и смотрите, сколько постов осталось на сегодня.
2. Решите, где человек смотрит на пост до выхода: режим проверки в Hub (публикация с одобрением) или своя страница до Hub. Не после того, как пост стал публичным.
3. Загружайте каждый файл один раз и храните адрес медиа.
4. Вызывайте validate_post ровно с теми аргументами, которые отправите.
5. Собирайте ключ идемпотентности из содержания и версии.
6. После любой ошибки или таймаута ищите номер поста и сверяйте его, прежде чем повторять, — с тем же ключом.
7. Сверяйте каждый пост: статус, время по UTC, каналы и настройки — и сообщайте именно это, а не «отправлено».
8. После времени публикации сверьте ещё раз: get_post покажет статус и ссылку по каждой сети.

Цифры коротко

Это наши собственные аккаунты и один вечер. Как сработают сами ролики, здесь не сказано: это ещё не измерено.