Самая дорогая ошибка ИИ-агента — не «не сделал», а «сделал дважды». У записи через API три исхода: прошла, отклонена и неизвестно, и повтор на неизвестном исходе даёт двойные платежи, заказы и приёмки. Разбираем, как Сам Решу решает это одним правилом для всех интеграций, как проверяет запись в ЮKassa, МойСклад и Ozon, и какие шесть вопросов задать поставщику ИИ-агента для бизнеса.

Самая дорогая ошибка ИИ-агента — не «не сделал», а «сделал дважды». Агент проводит платёж, создаёт заказ поставщику или приходует поставку, запрос уходит, а ответа нет: сеть моргнула, сервис задумался, соединение оборвалось. Прошла запись или нет, в этот момент не знает никто — ни агент, ни вы. Агент, который на всякий случай повторит запрос, оставит вам два платежа или две приёмки. Агент, который скажет «не получилось», оставит дыру, если запись на самом деле прошла. Ниже — почему у записи через API не два исхода, а три, как ИИ-агент для бизнеса должен вести себя в третьем на примерах платежей, склада и маркетплейса, и какие вопросы задать поставщику, прежде чем доверить агенту деньги и кабинеты.

ИИ решает олимпиадные задачи, но легко создаст вам дубль

Модели сегодня пишут код, разбирают договоры и решают задачи, над которыми математики сидят годами. В подкасте Latent Space основатель TypeSafe AI Диогу Алмейда сформулировал это как парадокс: как ИИ может быть настолько умным, что берётся за задачи уровня «премии тысячелетия», и при этом до сих пор не автоматизирует самую базовую работу?

Часть ответа — в том, что базовая работа проходит не в чате, а в чужих системах: кабинете маркетплейса, учётной программе, банке, CRM. Там у ума модели нет права на «примерно». Платёж либо один, либо их два. Browserbase в разборе новой модели Jev пишет об этом точно: ответ может убедить человека и всё равно не годиться для автоматизации без присмотра. Инженер из Raindrop сказал ещё короче: настоящая среда, которая нужна агенту, — та, в которую его выпускают. Не демо, а ваш кабинет с его таймаутами, правами и сбоями.

Автоматизация бизнеса с ИИ упирается не в то, насколько модель умна, а в то, что она делает, когда что-то пошло не так.

У записи три исхода, а не два

Когда агент читает данные — остатки, заказы, выписку, отзывы, — сбой безвреден: не получилось, прочитал ещё раз. Когда агент пишет — проводит платёж, создаёт заказ или приёмку, меняет цену, — всё сложнее. У такого запроса три исхода.

Исход	Что произошло	Что делать
Запись прошла	Сервис ответил «создано» и вернул результат	Перечитать и сверить с тем, что просили
Запись отклонена	Сервис ответил отказом: нет прав, неверные данные	Прочитать причину и либо исправить запрос, либо честно сказать, что мешает
Исход неизвестен	Запрос ушёл, ответ не пришёл: таймаут, обрыв связи, ошибка на стороне сервиса	Сначала узнать, что случилось, и только потом решать, повторять ли

Третий исход — самый опасный, потому что выглядит как второй. Для простой автоматизации «нет ответа» и «ошибка» — одно и то же: сценарий падает или повторяет шаг. Но запрос, на который не пришёл ответ, мог дойти до сервиса и выполниться. Сервис провёл платёж, а ответ потерялся по дороге обратно.

Сетевой стандарт HTTP говорит об этом прямо: запрос, повтор которого создаёт новую запись, нельзя повторять автоматически, если нет способа узнать, что первый не выполнился.

Почему «просто повторить» даёт дубли

Представьте: агент выставляет покупателю счёт или создаёт заказ поставщику на 40 позиций. Запрос ушёл, прошло 30 секунд, ответа нет. Что будет дальше, зависит от того, как устроен агент.

Повторить сразу. Если первая запись всё-таки прошла, теперь их две. Покупатель получит второй счёт, поставщик — двойную заявку, и дубль придётся искать и отменять руками.

Сказать «не получилось». Если запись прошла, вы о ней не знаете. Попросите агента ещё раз — получите тот же дубль, только уже своими руками.

Сказать «готово». Хуже всего. Агент не видел ответа, но отчитался. В разборе тестирования ИИ-сценариев n8n описывает ровно этот тип ошибки: ответ звучит убедительно, но важная деталь в нём неверна.

Правильный ход — четвёртый: признать, что исход неизвестен, и проверить.

Одно правило на все интеграции

В Сам Решу больше ста интеграций: маркетплейсы, склады, банки, CRM, 1С, почта, мессенджеры. Все вызовы агента проходят через один слой, и вопрос «можно ли повторить запрос, на который не пришёл ответ» решает он, а не модель и не отдельный сценарий. Ответ у него один для всех.

Чтение повторять можно всегда. Оно ничего не меняет.
Запись, которая заменяет значение, повторять можно. Поставить цену 990 ₽ дважды — всё равно 990 ₽.
Запись, которая создаёт новое, повторять можно, только если сервис сам обещает защиту от дублей. Такое обещание записано у интеграции явно, для конкретных операций, и слой не верит заголовку, который кто-то придумал сам.
Всё остальное слой сам не повторяет. Агент получает пометку «исход неизвестен, проверь состояние, прежде чем повторять запись» — и дальше действует по ней.

Поверх этого есть ещё одна страховка — наша собственная. Каждая запись агента получает свой ключ, и если тот же вызов с тем же ключом придёт повторно в течение пяти минут, в сервис он второй раз не уйдёт: агент получит сохранённый ответ первого.

Дальше — как это выглядит на трёх самых чувствительных направлениях.

Платежи: ключ, который не даёт заплатить дважды

У платёжных сервисов защита от дублей обычно встроена. В ЮKassa она называется ключом идемпотентности: запрос несёт уникальную метку, и если ЮKassa получит второй запрос с той же меткой, она не проведёт новый платёж, а вернёт результат первого. У Stripe механизм устроен так же.

Тонкость в том, кто ставит метку. Если попросить модель «придумай уникальный номер», на повторе она придумает новый, и защита пропадёт. Поэтому у нас метку ставит программа: один ключ на одну операцию, и все попытки этой операции несут его. Сеть оборвалась, запрос ушёл снова — ЮKassa видит знакомый ключ и возвращает тот же платёж.

Для отдельных операций Т-Банка и Модульбанка такое же обещание записано в описании интеграции, и слой повторов его учитывает.

Склад: как агент проверяет себя в МойСклад

У МойСклад похожий механизм — поле syncId. Если сервис получает повторный запрос на создание документа с уже занятой меткой, он не создаёт второй документ, а возвращает первый.

Вот как этим пользуется агент, когда создаёт заказ, приёмку или списание:

Метку ставит программа, а не модель — по той же причине, что и в платежах.
Потерянный ответ — не отказ. Если ответ не пришёл, агент не сообщает об ошибке, а ищет документ по метке.
Нашёл — запись прошла. Агент возвращает найденный документ и продолжает работу.
Не нашёл — исход всё ещё неизвестен. Сервис мог не принять запись или ещё не закончить её. Агент не говорит ни «создано», ни «не создано» и знает единственный безопасный повтор: тот же запрос с той же меткой.
Новый черновик — это дубль. Собрать документ заново значит получить новую метку. Этого агент на повторе не делает.

С массовыми правками правило то же, но механика другая. Обновления агент перечитывает по номерам документов и досылает только то, что не применилось, меньшими порциями. Созданные записи сначала ищет и только потом решает, что отправлять заново.

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

Маркетплейс: «успешно» — ещё не итог

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

Поэтому агент не верит ответу на слово. После записи он перечитывает затронутые заявки и показывает, что на самом деле стоит в кабинете. Если перечитанных заявок меньше, чем «успешных», агент ищет их шире, а не считает запись подтверждённой.

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

Отказ по правам — не тупик

Ещё одна частая ситуация: сервис ответил, но отказом. Здесь важно понять, от чего именно он отказался.

В МойСклад права на документ разделены: «создавать» и «проводить» — разные галочки в роли. Проведённая приёмка сразу меняет остатки, непроведённая лежит черновиком. Если у ключа есть право создавать, но нет права проводить, МойСклад отвечает ошибкой с кодом 1092. Смысл у неё узкий: документ провести нельзя. Создать его — можно.

Ещё недавно агент читал такой отказ широко: «доступа нет» — и бросал задачу. Сейчас на код 1092 он повторяет запрос с пометкой «не проводить» (applicable=false), создаёт черновик и говорит прямо: приёмка создана, провести её нужно вам, вот где.

Там, где выдать право нельзя, агент не отправляет вас его выдавать. У приложения, установленного из маркетплейса решений МойСклад, права на проведение нет в принципе: набор прав задан описанием приложения, и ни администратор, ни пользователь его не расширят. Совет «попросите администратора дать доступ» в таком случае — второе обращение в поддержку вместо результата. Честный итог — черновик и одна кнопка «Провести», которую нажимаете вы.

Разница между «не получилось» и «сделал черновик, осталось провести» — это разница между задачей, которую вы делаете с нуля, и задачей, на которую тратите пять секунд.

Робот-пылесос и провода

В свежем опросе разработчиков Zapier есть хорошая метафора. Робот-пылесос действительно уберёт пол, пока вы отдыхаете, — но сначала вы 15 минут убираете провода и двигаете стулья, чтобы он ничего не съел. С ИИ-агентом так же. Потерянные ответы, отказы по правам, частично применённые пачки, «успешно», за которым стоит другая цена, — это провода. Хороший агент не делает вид, что их нет, а умеет с ними обращаться.

Показательно, что в том же опросе пять навыков, которые разработчики считают самыми важными на будущее, по сути об одном: решить, безопасно ли это, правильно ли и можно ли это выпускать. Это же главный вопрос и к ИИ-агенту.

Вопросы поставщику ИИ-агента

Прежде чем подключать агента к платежам, складу, заказам или ценам, спросите:

Вопрос	Хороший ответ	Красный флаг
Что агент делает, если на запись не пришёл ответ?	Считает исход неизвестным, проверяет, записалось ли, и только потом решает	«Повторяет запрос» или «сообщает об ошибке»
Как агент защищается от дублей при повторе?	Метка на запросе, которую ставит программа; повтор с той же меткой	«Модель следит, чтобы не было дублей»
Решает ли это каждый сценарий сам или есть общее правило?	Общее правило для всех интеграций, плюс проверки там, где у сервиса свои механизмы	«Зависит от интеграции» без подробностей
Проверяет ли агент результат после записи?	Перечитывает и сверяет с запрошенным	«Сервис ответил "успешно" — значит, всё в порядке»
Что будет, если у агента не хватает прав?	Сделает то, что можно, например черновик, и скажет, что осталось вам	«Сообщит, что нет доступа»
Что агент отвечает, если не знает, чем закончилась запись?	Так и говорит: исход неизвестен, вот как проверить	Отчитывается «готово»

Проверить можно и руками: попросите агента создать тестовый документ, а потом спросите, как он поступит, если ответ не придёт. Агент, который ответит «попробую ещё раз», ответил на главный вопрос.

Коротко

Главные ошибки ИИ-агента происходят не в чате, а на записи: у неё три исхода — прошла, отклонена и неизвестно. Самый опасный — третий, потому что выглядит как ошибка.
«Просто повторить» на неизвестном исходе даёт дубли: двойные платежи, заказы и приёмки.
Правильный ход — проверить. Платёжные сервисы и МойСклад дают для этого метку на запросе; повтор с той же меткой возвращает уже созданное, а не второе.
Ответ «успешно» тоже стоит перечитать: у Ozon утверждённая цена может отличаться от отправленной.
Отказ по правам надо читать узко: нет права провести — не значит нет права создать. Черновик лучше, чем ничего.
Спрашивайте поставщика не «что агент умеет», а «что он делает, когда что-то пошло не так».

Что такое ИИ-агенты для бизнеса и чем они отличаются от чат-ботов — в статье что такое ИИ-агент. Как агент работает с конкретными системами — в разборах МойСклад и Ozon, а обзор ИИ для маркетплейсов — в подборке сервисов для селлеров. Чем агент отличается от сценариев в Make, Zapier и n8n — в сравнении с конструкторами автоматизаций. А что видно владельцу, когда агент работает без него, — в статье что видит владелец, когда ИИ работает без него.

Ошибки ИИ-агента: что будет, если он не получил ответа от маркетплейса, склада или банка