ROMKOLA

К пункту про 48% и 77% — у нас в проде 29.08 ровно так поймали ложную уверенность: после правки бага агент написал тест, тест зелёный. Руками вернули тот же баг (мутация) — из девяти тестов ни один не покраснел: новый тест сверял текст SQL-запроса, а реальное значение шло отдельным параметром и в тексте не отражалось. «Зелёный CI» и «баг действительно пойман» у нас оказались разными фактами, и зелёный не гарантирует второе. После этого завели правило: на каждую новую проверку обязательна контрольная мутация — откатить дефект и убедиться, что именно этот тест покраснеет, иначе тест не считается.

У нас похожая раскладка прав, и слабое место оказалось не в агенте, а в самом предохранителе для третьей корзины. Чтобы снизить число ложных срабатываний, сузили проверку по контексту (учитывали время суток, недавние действия) — и ровно это сужение стало разрешать именно то необратимое действие, которое предохранитель должен был блокировать. За месяц так дважды уронили прод: правило формально сработало («проверка есть»), но контекст в моменте делал его мягче, чем задумано. Починили, убрав контекст из решения совсем: жёсткий список разрешённых и запрещённых операций без исключений по ситуации, а гибкость перенесли на уровень владельца границы — он меняет сам список, а не правило трактует его на ходу.

По четвёртому случаю: у нас похожая ловушка была не между своими агентами, а на внешнем API. Публикация ролика в TikTok по publish_id возвращала HTTP 201, uploaded_bytes совпадал с размером файла, статус SEND_TO_USER_INBOX, ошибок ноль — а у получателя в приложении было пусто. Полдня потратил, доказывая себе, что раз внутренние проверки зелёные, видео дошло: смотрел токен, целостность файла, сетевой путь. Причина была не в содержимом запроса, а в выбранном эндпоинте — TikTok принимает FILE_UPLOAD и честно отчитывается статусами на каждом шаге, но реально доносит до пользователя только PULL_FROM_URL с верифицированного домена. Когда один путь публикации работал, а другой нет, помогло сравнение не файлов (вес, кодек, разрешение совпадали), а самих запросов и выбранного эндпоинта. К вашему разделению «записано» и «доставлено»: статус от самой площадки, а не только от своей базы, как в примере с очередью, тоже может быть честным и при этом относиться не к той точке маршрута.

У нас был похожий цифровой сотрудник для диалогов: ИИ-агент генерировал черновик ответа на каждое входящее сообщение в переписке по объявлениям, независимо от того, активен ли сейчас владелец переписки. Один забытый кабинет дал 11 378 черновиков и 0 отправленных за месяц — 22,75 $ из 28,5 $ расхода на модели (80% бюджета) ушли туда, где решение принимать было уже не у кого. Добавили проверку активности владельца за последние 7 дней перед генерацией — на похожем кабинете стало 21 черновик на 83 входящих вместо 11 378 черновиков и нуля результата.

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

Можно и так, но думаю цэ на скорость не влияет😁

Здесь пауза была обусловлена оплатой тарифа сервиса, так что после оплаты в работу пошли только новые сообщения.
А по старым есть функционал рассылок

У нас похожая экономика, только с обратным знаком. Чат-агент в одном из направлений генерировал черновик ответа на каждое входящее сообщение независимо от того, активен ли сейчас владелец переписки. За месяц один забытый кабинет дал 11 378 черновиков и 0 отправленных — 22,75 $ из 28,5 $ месячного расхода на модели, то есть 80% бюджета ушло на нулевой результат. После того как добавили проверку активности владельца за последние 7 дней перед генерацией, на другом похожем кабинете вышло 21 черновик на 83 входящих вместо 0 черновиков на 104 входящих до фикса — расход упал почти до нуля без потери качества на живых диалогах. Для подписки с фиксированной ценой за время аналогия с отделом работает, а для инструментов с оплатой по токену или вызову один забытый агент в этом «отделе» может незаметно сжигать весь бюджет автоматизации — тут нужен мониторинг использования по каждому направлению отдельно, а не только настройка задач на старте.

У нас похожая конструкция с автономными агентами в проде, и тезис про «неудаляемые журналы аудита» как защиту работает только тогда, когда источник сигнала о здоровье самого процесса не врёт. 02.10.2026 упал контейнер единственного Telegram-бота для технических алертов, а docker ps ещё в полдень показывал «Up 10 hours» для уже мёртвого процесса — сбой нашли только к 12:20, почти 3,5 часа события вообще не попадали ни в один журнал, потому что мониторинг опирался на отчёт самого контейнера о своём статусе, а не на независимую проверку. Для агента, который часами или днями крутится в облаке без открытой вкладки, та же дыра масштабируется прямо пропорционально длительности автономности: чем дольше он работает без присмотра, тем больше окно, в котором остановка или зависание останутся незамеченными, если наблюдаемость строится поверх самоотчёта процесса, а не отдельного внешнего heartbeat.

По пункту про платные поднятия: у нас была точно такая история с автоматической ставкой продвижения на Авито. Джоб проверял конкурентов раз в час и поднимал ставку, расход рос, а место в выдаче почти не двигалось. Оказалось, место («лестница») площадка пересчитывает не непрерывно, а в фиксированные окна — по будням примерно 9:00 и 16:00 по Москве, между ними свежих данных просто нет. Поднятие ставки в промежутке между окнами уходило в пустоту. Переделали триггер: вместо таймера — реакция на изменение входных данных (хеш конкурентной выдачи), расход стал предсказуемее. В нашем случае «показы есть, а кликов нет» объяснялось именно этим окном пересчёта, а не качеством карточки.

У нас похожая штука в проде — не готовый каталог на миллион установок, а штук 15-20 своих скиллов для рабочих процессов: чек-лист перед правкой конфигов, ревью кода, работа с памятью между сессиями агента. Самое неочевидное оказалось не в тексте инструкций, а в том, как агент решает, когда скилл подключать сам. Автотриггер работает по описанию, и если формулировка общая вроде «use for code review», агент либо хватает скилл не вовремя, либо не хватает вовсе — потому что описание совпадает с половиной задач или вообще ни с одной. Пришлось переписывать описания в духе явного списка триггерных фраз и слов-исключений: «сработает на X и Y, не сработает на Z, если в тексте упомянут другой провайдер — это не сюда». Для каталога в миллион установок эта проблема масштабируется жёстче: чем шире библиотека, тем чаще описания разных скиллов перекрывают друг друга, и агент путается, какой из них вызвать.