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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Коротко

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

Что такое ИИ-агенты для бизнеса и чем они отличаются от чат-ботов — в статье [что такое ИИ-агент](/resources/ii-agenty-dlya-biznesa). Как агент работает с конкретными системами — в разборах [МойСклад](/resources/kak-podklyuchit-ii-k-moysklad) и [Ozon](/resources/kak-podklyuchit-ii-k-ozon), а обзор ИИ для маркетплейсов — в [подборке сервисов для селлеров](/resources/ii-dlya-sellerov-marketplejsov-2026-dashbord-pokazyvaet-agent-delaet). Чем агент отличается от сценариев в Make, Zapier и n8n — в [сравнении с конструкторами автоматизаций](/resources/ii-agent-ili-make-zapier-n8n). А что видно владельцу, когда агент работает без него, — в статье [что видит владелец, когда ИИ работает без него](/resources/chto-vidit-vladelec-kogda-ii-rabotaet-bez-nego).

## Источники

- [Latent Space, Jev: System One models for Prod, not God — интервью с Диогу Алмейдой, TypeSafe AI, сентябрь 2026](https://www.latent.space/p/jev)
- [Browserbase, What is Jev?, сентябрь 2026](https://browserbase.com/blog/what-is-jev)
- [n8n, Prompt Testing Frameworks for Production AI Workflows, сентябрь 2026](https://blog.n8n.io/prompt-testing-frameworks/)
- [Zapier, Most developers like that others code with AI, сентябрь 2026](https://zapier.com/blog/ai-coding-survey/)
- [ЮKassa API, идемпотентность](https://yookassa.ru/developers/using-api/interaction-format#idempotence)
- [МойСклад JSON API 1.2, общие сведения: назначение поля syncId, права сущностей](https://dev.moysklad.ru/doc/api/remap/1.2/)
- [RFC 9110, HTTP Semantics, §9.2.2 Idempotent Methods](https://www.rfc-editor.org/rfc/rfc9110#section-9.2.2)
- [Stripe API, Idempotent requests](https://docs.stripe.com/api/idempotent_requests)