Прежде чем позволить AI-агенту распоряжаться деньгами

AI-системы переходят от рекомендаций к участию в коммерции. Google описывает UCP как открытый стандарт для agentic commerce, а AP2 — как совместимый слой авторизации с типизированными мандатами, ограничениями и проверяемым следом намерения. OpenAI и Stripe отдельно разработали Agentic Commerce Protocol для взаимодействия пользователей, агентов и бизнеса в процессе покупки.

Это важный сдвиг. Агент теперь может не просто сказать человеку, что купить. Он может участвовать в выборе, согласовании, авторизации и исполнении экономически значимого действия.

Эксперимент Anthropic Project Deal показывает ещё один сигнал: AI-представители людей договаривались о реальных товарах и заключили 186 сделок общей стоимостью более $4 000. Это не production-платёжная сеть, но это уже реальное делегирование экономического поведения агентам.

Обычный сбой распределённой системы.

Агент должен оплатить счёт поставщика. Запрос отправлен. Сеть отвечает таймаутом до того, как агент получил однозначный результат.

Если первый платёж не прошёл, повтор может быть правильным. Если платёж уже committed, но acknowledgement потерялся, слепой retry может создать дублирующую транзакцию.

При этом второй API-вызов способен вернуть 200 OK, а агент — сообщить об успешном выполнении. Финальный ответ выглядит правильным, но бизнес-инвариант уже нарушен.

Авторизация закрывает только часть доверия.

AP2 полезен именно потому, что делает делегированное намерение и ограничения расходов более явными. В документации Google показана цепочка от intent mandate к payment mandate, привязанному к конкретной корзине и сумме, а затем к receipt, который завершает audit trail авторизации.

Но прикладная система всё равно должна самостоятельно сохранить корректность через свою state machine, поведение провайдера, конкурентные изменения, retries и recovery.

Trust contract должен пережить смену модели.

Хороший контракт для финансового агента не звучит как «модель должна быть осторожной». Он фиксирует условия, которые можно проверить независимо от того, какой planner выбрал действие.

INTENT
Пользователь разрешил платёж поставщику ≤ $1 000

STATE
Счёт ещё не оплачен

TIME
Authority действительно в момент исполнения

TRANSITION
UNPAID → PAYMENT_PENDING → PAID

RECOVERY
Unknown commit → reconciliation, а не blind retry

VERIFICATION
Provider state согласован с authoritative ledger

EVIDENCE
Intent + authority + attempts + reconciliation + decision сохранены

Тогда вопрос становится намного точнее:

Более безопасная траектория неоднозначного сбоя.

Это не универсальный алгоритм для любого платёжного провайдера. Где-то есть idempotency primitives, где-то reconciliation устроен иначе, где-то settlement отложен во времени. Смысл другой: recovery path должен быть явным, тестируемым и подтверждённым evidence.

И здесь нам нужен рынок.

Синтетические failure cases можно генерировать бесконечно. Настоящие ограничения production-систем научат нас гораздо большему.

На сильный кейс мы сначала хотим вернуть не продажу, а ценность: выделить missing guarantee, построить trajectory и предложить одну конкретную verification hypothesis. Если одна и та же missing capability повторится у независимых команд, это уже будет основанием думать о продукте.

Что происходит с ответами?

Содержательный ответ превращается в Problem Card: workflow → failure → impact → workaround → missing capability → acceptance condition. Затем signals получают score и собираются в Demand Graph. Синтетические примеры помечены отдельно и никогда не считаются реальным market evidence.

Article #005 не будет называться «выбранным рынком», пока у нас не появится достаточный объём реальных данных. Текущее правило: минимум десять содержательных внешних workflows и минимум три реальных кейса в выбранном кластере.

Не спрашивать рынок, нравится ли ему наш продукт. Создать разговор, в котором рынок сам раскрывает продукт, который ему нужен.