Как отслеживать протоколы агентной коммерции (Agentic Commerce Protocols)

Это commerce flow, где AI-agent участвует в discovery, comparison, cart, checkout, payment или post-purchase actions от имени пользователя. Уровень автономии может быть разным: от рекомендации до transaction execution с approval.

Обычный web checkout рассчитан на человека и UI. Agentу нужны machine-readable products, capabilities, cart state, identity, payment tokenization, approvals и transaction handoff. Стандарты пытаются сделать эти взаимодействия interoperable.

ACP — открытый стандарт, поддерживаемый OpenAI и Stripe. Он соединяет покупателей, AI-agents и merchants для discovery/checkout flows. Репозиторий протокола использует date-based versioning; на момент проверки latest stable snapshot указан как 2026-04-17, а unreleased changes ведутся отдельно.

• Merchant остаётся merchant of record в соответствующей модели интеграции.
• Machine-readable checkout sessions.
• Capability negotiation и extensions.
• Payment handlers / delegated payment flows.
• Versioned OpenAPI/JSON Schema.
• Product discovery и richer commerce surfaces.

Google представил UCP в январе 2026 как open-source standard для commerce journey между consumer surfaces, businesses и payment providers. Google указывает compatibility с Agent2Agent, Agent Payments Protocol и Model Context Protocol.

UCP позиционируется шире checkout: discovery, cart, purchase и post-purchase. В обновлениях 2026 Google описывал real-time product details, multi-item cart и identity linking. Для merchant это означает необходимость следить не только за payment, но и за product/catalog interface.

Stripe и Tempo объявили MPP в марте 2026 как open standard для agent-to-business и agent-to-agent payments. Его задача ближе к payment layer, а не полному commerce journey. Stripe также описывает agentic commerce infrastructure как набор commerce и payment primitives.

Один protocol может покрывать несколько слоёв, но architecture бизнеса лучше моделировать по capabilities, а не по названию стандарта.

• ACP versions and changelog.
• UCP releases and merchant tooling.
• MPP/payment standards.
• Agent Payments Protocol and related payment authentication.
• MCP/A2A compatibility where relevant.
• Merchant platforms and payment provider implementations.

Protocol beta/rapid evolution означает breaking changes и new capabilities. Интеграция должна хранить supported version и иметь compatibility tests. Не подключайтесь к unreleased spec как к стабильной production contract без осознанного риска.

Кто контролирует price, inventory, customer relationship, payment, fulfillment, refunds и post-purchase service? Agentic distribution не должна разрушать core commerce ownership без понятной economics.

Structured IDs, titles, variants, price, availability, images, shipping constraints, return terms, taxonomy и freshness. Agent не может качественно продавать stale or ambiguous catalog.

Real-time или sufficiently fresh data должна иметь canonical source. Если agent показывает устаревшую цену или out-of-stock item, trust падает.

Cart create/update/retrieve, fulfillment, tax, discounts, payment, completion/cancel, order status. Даже если конкретный protocol меняется, эти commerce capabilities останутся полезными.

Agent may retry after timeout. Checkout/payment endpoints должны предотвращать duplicate orders/charges. Idempotency — базовый requirement для action-oriented commerce.

Пользователь должен понимать, что будет куплено, по какой цене, у кого, с какой доставкой и условиями. High-value или unusual purchases требуют explicit confirmation по продуктовой и risk policy.

Agent не должен получать raw card data без необходимости. Используйте tokenized/delegated payment primitives и provider controls. Payment authorization должен быть отделён от language reasoning.

Account linking, loyalty, stored addresses и order history требуют explicit identity/authorization model. Не позволяйте agent «угадывать», какой customer account использовать.

Velocity, amount, unusual merchant, location, device/context, repeated attempts. Agentic commerce добавляет automation speed, поэтому payment/business risk controls должны работать до transaction.

Machine-readable eligibility, coupon rules, stacking, expiration и margin floors. Агент не должен обещать скидку, которая не подтверждена merchant system.

Shipping methods, pickup, delivery windows, restrictions, split shipment и returns. Commerce flow не заканчивается payment.

Order status, modification, cancellation, returns, support. Agent может стать interface после покупки, поэтому APIs и policy должны покрывать lifecycle.

Отдельно маркируйте agent-origin discovery, checkout initiation и completed order. Attribution scheme должна быть transparent и согласована с channel economics.

Продажа через agent surface могла бы произойти через direct/organic channel. Для mature scale нужны experiments или подходы к incrementality, а не только attribution tag.

Structured product data, canonical URLs, merchant identity, clear policies и accessible machine interfaces. Не нужно создавать «текст для роботов» вместо полезной product information; нужен authoritative structured source.

Вместо жёсткой привязки business logic к одному protocol используйте internal canonical commerce model + adapters. Тогда ACP/UCP или другие integrations переводятся в вашу domain schema.

New protocol version или agent channel включайте controlled rollout. Это позволяет быстро остановить integration при ошибках в cart, price, payment или attribution.

• Catalog/product lookup.
• Price/inventory freshness.
• Cart create/update.
• Discount eligibility.
• Checkout completion.
• Idempotent retry.
• Refund/cancel.
• Authentication.
• Payment failure.
• Version compatibility.

Spec maturity, governance, version cadence, provider dependence, privacy, customer ownership, economics, fraud, support burden. Open standard сам по себе не устраняет platform risk.

Если catalog data unreliable, checkout полностью ручной, margin слишком низкая, support не готов или channel пока не даёт relevant audience, protocol integration может быть преждевременной. Сначала улучшите commerce foundation.

Ограничьте geography, product category, order value и payment method. Используйте простые SKU, стабильный inventory и понятный return process. Это снижает edge cases.

Раз в месяц проверяйте official specs, changelogs и merchant/payment provider announcements. Раз в квартал обновляйте capability matrix. Не основывайте roadmap на конференционных заявлениях без released documentation.

• Не выбирать standard только по бренду компании.
• Не интегрироваться без authoritative price/inventory.
• Не отдавать raw payment credentials agent layer.
• Не считать attributed agent sales incremental.
• Не внедрять unreleased protocol version без explicit risk decision.
• Не привязывать core business logic к одному external schema.

D2C-бренд хочет быть доступен в AI shopping surfaces. Вместо отдельной business logic под каждый канал команда создаёт canonical Product/Cart/Order API, затем adapters для нужных protocols. Pilot ограничивают частью ассортимента и order value, измеряют agent-origin conversion и support incidents. Это позволяет тестировать ACP/UCP-compatible channels без переписывания checkout каждый раз.

• D2C/e-commerce playbook
• Оркестрация AI-агентов
• Почему AI не даёт измеримого эффекта
• 25 экспериментов для электронной коммерции: корзина, оформление заказа, средний чек и повторные покупки (E-commerce Experiments)
• Как провести трансформацию маркетинга с искусственным интеллектом (AI Marketing Transformation)

• Risk Register
• Decision Log
• Measurement Plan
• SOP

• RACE
• RACI

• Agentic Commerce Readiness
• Agentic Commerce Transaction Handoff
• AI Agent-origin Measurement
• E-commerce Payments

• OpenAI — Agentic Commerce Protocol and Instant Checkout
• ACP — official specification repository
• Google Developers — Universal Commerce Protocol
• Stripe — Machine Payments Protocol