В автоматизации публикаций есть опасная подмена: зелёный workflow легко принять за опубликованный результат. Для Agency это разные состояния. Сценарий может успешно отработать внутри системы, API может вернуть успех, браузер может нажать кнопку — и всё равно материал снаружи окажется не там, не полностью или вообще не появится.
Поэтому в нашем production-контуре публикация не закрывается по внутреннему статусу. Terminal success начинается только после внешней проверки.
Что мы считаем опубликованным результатом
Рабочая цепочка выглядит так:
- система отправляет материал или выполняет browser/API effect;
- получает внешний URL или ID;
- открывает результат снаружи;
- проверяет, что страница действительно существует;
- сверяет title, начало body, баннер и ссылку;
- только после этого фиксирует состояние external verified.
Если один из этих этапов не подтверждён, публикация остаётся незакрытой. Это принципиально отличается от обычной логики «HTTP 200 = всё хорошо».
Почему внутренний статус недостаточен
В распределённых системах полезно разделять внутренние сигналы и наблюдение за тем, что реально получает пользователь. Google SRE описывает white-box monitoring как наблюдение за внутренними метриками системы, а black-box monitoring — как проверку поведения сервиса снаружи. Для публикационного контура эта разница практическая: внутренний workflow сообщает, что наш механизм дошёл до определённого шага, а public read-back проверяет, что внешний мир действительно увидел нужный результат. Подробнее этот подход описан в Google SRE — Monitoring Distributed Systems.
Что именно защищает fail-closed логика
Главная цель — не допустить ложного успеха. Без внешней проверки легко получить несколько неприятных сценариев.
- Материал не появился. Внутренний submit завершился, но внешний сервис не сохранил результат.
- Материал появился частично. Например, текст есть, а баннер или CTA не загрузились.
- Открылся не тот объект. Система получила ID, но последующий маршрут ведёт не к нужной публикации.
- Повторная отправка создаёт дубль. Если первый результат существует, но система считает попытку неуспешной, автоматический retry может опубликовать второй экземпляр.
- Браузер выполнил не тот эффект. Кнопка была нажата, но интерфейс изменился или сохранил черновик вместо публикации.
Поэтому у нас external effect и подтверждение результата разделены. Сначала действие, затем read-back.
Dzen — пример, где остановка является правильным результатом
С 2 сентября 2026 года для Dzen действует отдельная граница: Agency может заполнить материал, дождаться автосохранения, проверить черновик и зафиксировать DZEN_DRAFT_SAVED_VERIFIED / USER_PUBLISH_REQUIRED. Финальную кнопку Publish система не нажимает.
Это важный пример того, что автоматизация не обязана доводить любой процесс до максимального внешнего эффекта. Если политика требует человека на последнем шаге, корректный terminal state — проверенный черновик и явная передача действия владельцу.
Как это выглядит в MediaMashin
Публикационный контур Agency использует release locks, variant digests, approval gates и public verification. Платформенный вариант фиксируется до отправки. Баннер также должен иметь подтверждённый provenance и visual QA. После внешнего действия система сверяет фактический результат и только затем меняет runtime-status на подтверждённый.
Эта логика распространяется не только на контент. Тот же принцип полезен для любых AI-действий, которые меняют внешнее состояние: отправка сообщения, изменение записи, создание заказа, публикация или другое write-back действие.
Что этот кейс доказывает — и чего не доказывает
Кейс доказывает, что Agency строит автоматизацию внешних действий как контролируемый контур: эффект, подтверждение, проверка и audit trail. Он не доказывает, что любой внешний сервис всегда можно автоматизировать полностью. Наоборот, архитектура рассчитана на то, что часть действий может требовать ручного подтверждения или быть недоступной.
Для AI-ассистента руководителя это принципиальная граница: чтение данных, подготовка решения и выполнение действия — разные уровни полномочий. На странице AI для управления бизнесом мы отдельно показываем, где система читает и анализирует, а где действие требует прав и подтверждения.