# Агентная коммерция любит чистые данные магазина

> Подготовьте магазин к агентной коммерции: надежные фиды, структурированные данные, явные состояния оформления, безопасная оплата и API заказов.

Агентная коммерция принесет преимущество продавцам со скучными и точными системами. ИИ-покупатель не исправит неоднозначный вариант товара, устаревшую цену или оформление заказа, где итоговая сумма меняется без объяснения. Он сравнит информацию магазина в фиде, разметке товара, ответе корзины и запросе на оплату. Если ответы расходятся, агент выберет магазин, которому безопаснее доверять.

Это меняет порядок подготовки. Новый чат-виджет стоит почти в конце списка. Сначала нужно описать каждый товар в машиночитаемом виде, поддерживать коммерческие данные в актуальном состоянии, сделать состояния оформления заказа явными и сохранять полномочия покупателя при оплате. Большая часть этой работы улучшает и обычные торговые интеграции, поэтому продавцу не придется ставить всю дорожную карту на одного агента или один протокол.

Первые продавцы добьются успеха не потому, что добавят «ИИ» на витрину. Они победят, если агент сможет без догадок ответить на четыре простых вопроса: Это нужный товар? Его можно доставить этому покупателю? Сколько заплатит покупатель? Что произойдет после заказа?

## ИИ-покупатели работают с контрактом, а не с витриной

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

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

Разделяйте обнаружение товара и выполнение транзакции. Данные для поиска могут быть широкими и кешированными. Данные для транзакции должны быть узкими и свежими. Каталог может сообщать, что обувь выпускается в размере 42, а сервис корзины решает, доступна ли конкретная товарная единица для рынка покупателя. Это различие предотвращает распространенную и дорогую ошибку: попытку заставить поисковый индекс резервировать остатки.

Магазину также нужен однозначный источник истины для каждого поля. Сведения о товарах обычно расползаются между торговой платформой, складской системой, таблицей отдела мерчандайзинга, поисковым индексом и менеджером тегов. Назначьте владельца для идентификатора SKU, цены, доступного количества, обещанного срока доставки и правил возврата. Затем опишите, как каждая зависимая система получает обновления. Без владельцев интеграция протокола лишь быстрее распространяет противоречия.

Не создавайте отдельный «ИИ-каталог» вручную. Он разойдется с магазином. Формируйте нормализованную торговую запись из тех же систем, которые обслуживают витрину, а затем преобразуйте эту запись для каждого фида или протокола. Адаптеры могут меняться вместе со стандартами. Внутренние определения должны оставаться стабильными.

## Одна запись каталога должна отвечать на все вопросы о товаре

Полезный фид для агента описывает продаваемые варианты, а не привлекательные родительские карточки. Цвет, размер, количество в упаковке, условия подписки, региональные ограничения и состояние должны относиться к позиции, которую покупатель действительно может положить в корзину. Родительская карточка с шестью фотографиями и диапазоном цен подходит для поиска, но не считается предложением, которое можно заказать.

Каждому варианту как минимум нужны постоянный идентификатор продавца, идентификатор родительской группы при наличии, понятное название, фактическое описание, канонические ссылки на товар и изображения, цена с валютой, наличие, состояние, бренд или производитель и ссылка для оформления заказа. Для физических товаров также нужны вес или размеры, если они влияют на доставку, регионы исполнения заказа и данные, достаточные для расчета доставки. Регулируемым товарам и отдельным категориям нужны соответствующие атрибуты, а не общий абзац.

Постоянный идентификатор должен оставаться постоянным. Не присваивайте старый SKU новому товару ради удобства таблицы. Агенты, маркетплейсы, аналитика и служба поддержки могут хранить прежний идентификатор. Повторное использование превратит повторный заказ в покупку другого товара и испортит историю показателей.

Механизму доставки фида нужны правила удаления не меньше, чем правила обновления. Если товар исчез из инкрементальной выгрузки, получатель не поймет, снял ли его продавец или экспорт оборвался на середине. Отправляйте явную запись об удалении снятых предложений, присваивайте каждой партии идентификатор и признак завершения, а также держите полный снимок для сверки. Получатель должен применять партию целиком либо сохранять предыдущую корректную версию. Частично примененный каталог может соединить вчерашние варианты с сегодняшними ценами.

Региональным предложениям тоже нужна постоянная идентичность. У одного физического SKU могут различаться валюта, налоги, цена, гарантия, обещанный срок доставки и юридический продавец на разных рынках. Не прячьте эти различия в переведенном описании. Создайте постоянный идентификатор предложения внутри SKU либо включите рынок в идентичность предложения, а затем требуйте от агента локаль и данные о месте доставки до показа окончательных условий.

Используйте одну нормализованную запись как входные данные для всех адаптеров. Этот пример намеренно не зависит от конкретного протокола:

```json
{
  "merchant_sku": "shoe-1042-blue-42",
  "product_group": "shoe-1042",
  "title": "Trail shoe, blue, EU 42",
  "description": "Water-resistant trail shoe with a 6 mm drop.",
  "attributes": {"color": "blue", "size_system": "EU", "size": "42"},
  "price": {"amount": "129.00", "currency": "USD"},
  "availability": "in_stock",
  "condition": "new",
  "sellable_regions": ["US"],
  "return_policy_id": "returns-us-standard",
  "updated_at": "2026-08-09T10:15:00Z"
}
```

Поле `updated_at` не освежает устаревшие данные, но позволяет получателю отклонить или перепроверить старый снимок. Храните суммы как десятичные строки, если окружающий контракт требует точного десятичного представления. Не допускайте, чтобы преобразование двоичного числа с плавающей точкой превратило 129.00 в неожиданную сумму корзины.

Проверяйте экспорт в непрерывной интеграции, а не после отказа маркетплейса. Небольшая проверка найдет отсутствующий идентификатор, неверную сумму и пропущенную ссылку на правила до развертывания:

```bash
jq -e '
  .merchant_sku != "" and
  (.price.amount | test("^[0-9]+\\.[0-9]{2}$")) and
  (.price.currency | test("^[A-Z]{3}$")) and
  (.availability == "in_stock" or .availability == "out_of_stock") and
  (.return_policy_id != "")
' product.json
```

При успехе команда выводит `true`, при ошибке возвращает ненулевой код завершения. Запускайте ту же проверку на примерах из каждой категории, поскольку варианты одежды, мебель на заказ, цифровые товары и подписки ломаются на разных полях.

## Структурированные данные должны совпадать с фидом

Структурированные данные товара нужны для сверки, а не для замены фида или торгового API. Размещайте разметку Product и Offer на канонической странице товара и следите, чтобы идентификатор, цена, валюта, состояние и наличие совпадали с вариантом, который покупатель может выбрать на этой странице. Если страница охватывает несколько вариантов, ясно опишите их связь вместо одной удобной цены для всего семейства.

Документация Google Merchant Center прямо рекомендует `price`, `priceCurrency`, `availability` и `condition` для автоматического обновления товаров. Google Search Central также описывает сведения о доставке и `MerchantReturnPolicy`, включая срок, способ и стоимость возврата. Эти свойства нужны агентам по той же причине, по которой они нужны торговым карточкам: полная стоимость и возможность возврата могут изменить выбор подходящего предложения.

Разметка не исправит плохую операционную модель. Если клиентский скрипт подставляет актуальную цену после нескольких запросов, часть получателей увидит старый HTML, а остальные получат новое состояние. Отдавайте существенные коммерческие сведения предсказуемо и проверяйте результат, который получает поисковый робот или обычный HTTP-клиент. Снимок браузера подтверждает внешний вид, но не машиночитаемость.

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

Ежедневно сравнивайте разметку страницы, основной фид и API товара на выборке из лидеров продаж, редких товаров, акционных позиций и всех типов вариантов. Сверяйте точные SKU, цену, валюту, наличие и идентификатор правил. Сообщайте о расхождениях, а не только об отсутствующей разметке. Безупречно валидный блок с неверной ценой хуже отсутствующего, потому что во время проверки он выглядит надежным.

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

## Свежие остатки важнее подробного текста

Агенту нужен свежий ответ в момент создания или обновления корзины. Ночной фид подходит для поиска, но не может безопасно обещать последнюю единицу товара в полдень. Конечная точка корзины должна заново рассчитать каждую позицию, проверить наличие, применить правила рынка и вернуть каждое изменение как структурированные данные.

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

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

Возвращайте причины, по которым программа может действовать. `out_of_stock` полезнее сообщения «Что-то пошло не так». Еще лучше указать затронутый SKU, запрошенное количество, доступное количество, если его можно раскрыть, и допустимые действия вроде уменьшения количества или выбора другого варианта. Не подменяйте молча цвет, размер, продавца или новый товар восстановленным. Покупатель разрешил купить конкретное предложение.

Проверьте неприятную гонку. Два агента видят последнюю единицу, оба начинают оформление, а получить ее может только один. Решите, резервирует ли создание корзины товар, сколько действует резерв и какой ответ получит второй покупатель. Если резервирование происходит только после разрешения на оплату, заранее сообщите, что прежние данные о наличии предварительны. Верное правило зависит от товара, но неявное правило приводит к двойным извинениям и лишним возвратам денег.

Границы акции требуют такого же внимания. Фид может показывать скидку в 23:59, а корзина рассчитает цену уже после полуночи. Верните новую сумму и запросите повторное разрешение. Никогда не считайте прежнее согласие покупателя разрешением на более высокую сумму.

## Протоколы оформления заказа делят работу на отдельные уровни

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

Agentic Commerce Protocol, который поддерживают OpenAI и Stripe, задает модель взаимодействия агентов и системы оформления продавца. Публичная спецификация использует версии по датам и по-прежнему помечена как beta. Продавец сохраняет роль merchant of record, принимает или отклоняет заказ, проводит оплату через существующие системы и отвечает за исполнение и поддержку. ACP нужен, когда поддерживаемая агентская площадка или платежный партнер приводит покупателей по этому контракту.

Universal Commerce Protocol охватывает более широкий торговый процесс с обнаружением возможностей, корзинами, оформлением и заказами. Его спецификация оформления использует профиль продавца и явные состояния. Документация Shopify по UCP отделяет исследовательскую корзину от сессии оформления, требует аутентификацию или подписанный запрос для инструментов оформления и предоставляет `continue_url`, когда покупателя нужно вернуть продавцу. Она также предупреждает, что одна операция обновления корзины полностью заменяет данные, поэтому пропущенные поля исчезают. Именно такая мелочь приводит к потере позиций, когда интеграция рассчитывает на частичное обновление.

Google Agent Payments Protocol решает другую задачу: подтверждает, что пользователь разрешил агенту заплатить. Руководство Google для разработчиков отделяет запись UCP о составе заказа от записи AP2 о том, кто одобрил покупку. AP2 использует мандат намерения, привязанный к корзине и сумме платежный мандат и квитанцию. Не заявляйте о совместимости с AP2 только потому, что храните флажок рядом с заказом. Подписанные полномочия, область действия, срок и привязка к транзакции составляют суть протокола.

Эти протоколы пересекаются и продолжат меняться. Не реализуйте все черновики в одной огромной конечной точке. Разместите стабильный внутренний сервис оформления за тонкими адаптерами ACP, UCP или партнера. Версионируйте каждый адаптер, сохраняйте версию входящего протокола вместе с заказом и держите контрактные тесты на основе опубликованных примеров. Когда поле или состояние изменится, вы замените адаптер, а не перепишете расчет цены и исполнение заказа.

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

## Оформлению заказа нужны состояния, передача и идемпотентность

Ответ агентского оформления должен сообщать, что произошло и что требуется дальше. Обычный успешный HTTP-код не объяснит агенту, нужен ли корзине адрес, должен ли покупатель одобрить изменившуюся сумму или принял ли продавец заказ.

Опишите оформление как конечный автомат. Публичный процесс UCP содержит такие состояния, как `incomplete`, `requires_escalation` и `ready_for_complete`. Внутренние названия могут отличаться, но каждому состоянию нужны разрешенные переходы, ответственный участник и способ восстановления. Конечные состояния должны оставаться конечными.

Полезная структура ответа делает изменения заметными:

```json
{
  "checkout_id": "chk_7f31",
  "status": "requires_escalation",
  "currency": "USD",
  "line_items": [{"sku": "shoe-1042-blue-42", "quantity": 1, "unit_amount": "129.00"}],
  "totals": {"items": "129.00", "shipping": "12.00", "tax": "11.63", "grand_total": "152.63"},
  "messages": [{"code": "buyer_approval_required", "field": "totals.grand_total"}],
  "continue_token": "handoff_29b8",
  "expires_at": "2026-08-09T10:30:00Z"
}
```

Ответ отделяет отображаемый текст от стабильного машинного кода. Он указывает поле, которое требует внимания, дает агенту непрозрачный токен передачи и ограничивает срок действия расчета. В рабочей системе привязывайте токен к оформлению, сессии покупателя, разрешенному действию и короткому сроку. Не помещайте в него данные карты, полный адрес или многоразовые учетные данные.

Требуйте токен идемпотентности для каждой операции, способной зарезервировать товар, разрешить платеж или создать заказ. Храните токен вместе с хешем запроса и результатом. Если тот же токен приходит с теми же данными, верните исходный результат. Если данные отличаются, отклоните запрос. Повтор после сетевой ошибки не должен создавать второй заказ.

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

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

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

При передаче нужна непрерывность. Когда покупатель открывает оформление продавца, он должен увидеть те же товары, варианты, суммы и скидки, которые показал агент. Объясните каждое изменение до запроса подтверждения. Храните атрибуцию отдельно от идентификации, чтобы потерянный маркетинговый параметр не ломал оформление.

## Делегированная оплата не передает риск продавца

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

Используйте платежные данные с ограниченной областью действия. Описание агентского оформления OpenAI говорит, что платежные токены ограничены конкретным продавцом и суммой с разрешения пользователя. AP2 похожим образом привязывает подтверждение к намерению и деталям транзакции. Многоразовые данные карты, переданные через агента, создают гораздо большую зону утечки и дают продавцу слабое доказательство того, что именно одобрил покупатель.

Разделяйте разрешение и списание там, где бизнесу нужна проверка принятия. Продавцу дефицитных, заказных или регулируемых товаров может понадобиться проверка остатков или права на покупку до списания. Записывайте версию оформления, позиции, сумму, валюту, событие подтверждения покупателем, идентификатор агента, ссылку на мандат или токен и результат процессора. По возможности храните ссылки вместо чувствительных платежных данных.

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

Меняйте проверочные учетные данные без поломки активных оформлений. Публикуйте текущий и следующий открытые идентификаторы, на короткое время принимайте оба и записывайте, каким идентификатором проверен каждый запрос. Отклоняйте неизвестный идентификатор до разбора большого тела, ограничивайте размер запроса и сравнивайте подписи за постоянное время через поддерживаемую криптографическую библиотеку. Это обычные средства защиты API, но при делегированной покупке слабая защита дает атакующему прямой доступ к резервам и попыткам оплаты.

Собирайте минимум данных покупателя. Запрашивайте электронную почту, телефон или адрес только тогда, когда они нужны текущему шагу. Укажите, кто отправит подтверждения и сообщения поддержки, агент или продавец. Если при передаче чувствительные сведения можно собрать в существующем оформлении продавца, выбирайте этот путь вместо копирования через еще одну систему.

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

## Заказ не заканчивается после успешной оплаты

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

Создайте машиночитаемую запись заказа с постоянными идентификаторами товаров, состоянием исполнения, событиями доставки, возможностью отмены, сроком возврата, состоянием возврата денег и передачей в поддержку. Используйте те же идентификаторы правил, которые показывались при поиске. Если товар обещал возврат в течение 30 дней, сервис заказов должен рассчитать и вернуть фактическую дату по соответствующему событию, а не повторять «30 дней» и заставлять агента считать.

Публикуйте изменения состояния как события и поддерживайте чтение текущего состояния. Вебхуки дают скорость, но получатели пропускают и дублируют их. Каждому событию нужны идентификатор события, идентификатор заказа, тип, время возникновения и версия схемы. Получающий агент или платформа должен подтверждать событие идемпотентно, а операция типа `get_order` восстанавливает пропущенную историю.

До запуска решите, кто отвечает за общение с клиентом. В современных торговых протоколах продавец обычно сохраняет роль merchant of record и владельца поддержки. Подтверждение должно называть продавца, описывать заказ и давать покупателю рабочий способ получить помощь. Агентская площадка может передать сообщение, но не должна оставаться единственным хранилищем квитанции.

Возвраты обнаруживают сокращения в каталоге. Поддержке нужны точный купленный вариант, состояние при продаже, уплаченная цена, распределенные скидки, путь исполнения и версия правил. Текущая страница товара не восстановит эти факты после изменений в мерчандайзинге. Сохраняйте снимок коммерческих условий в заказе.

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

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

## Первым продавцам стоит доказать один узкий сценарий

Разумный ранний шаг охватывает одну категорию, один рынок, один путь оформления и реального владельца процесса. Широкое открытие каталога выглядит амбициозно, но умножает пограничные случаи вариантов, налогов, доставки и правил до того, как команда поймет характер сбоев.

Выберите категорию с чистыми идентификаторами, умеренным количеством вариантов, предсказуемым исполнением и обычными возвратами. Не начинайте с самых сложных регулируемых, заказных, подписных или маркетплейсных товаров. Затем проведите проверку готовности:

1. Опишите источник истины и допустимый возраст каждого коммерческого поля.
2. Экспортируйте нормализованные записи вариантов и останавливайте сборку при нарушении контракта.
3. Сверяйте фид, разметку страницы, API товара, корзину и суммы оформления.
4. Добавьте идемпотентные операции оформления, явные состояния и передачу человеку.
5. До живого трафика воспроизведите гонки остатков, смену цен, повторы платежа, отмены и возвраты.

Не ждите победителя среди ACP, UCP и протоколов платежных полномочий. Создайте внутренний контракт и наблюдаемость, которые требуются им всем. Добавляйте адаптер только тогда, когда реальный партнер по распространению, торговая платформа или путь клиента оправдывает постоянные расходы на его поддержку. Объявление протокола еще не означает спрос.

Назначьте одного владельца для мерчандайзинга, разработки, платежей, исполнения и поддержки. Агентское оформление проходит через все пять областей, а комитет оставит разрывы между ними. Еженедельно разбирайте неудачные сессии по коду причины и связывайте их с системой-владельцем. Исправляйте повторяющиеся ошибки данных в источнике, а не добавляйте подсказки агенту, которые объясняют обходной путь.

Основателям, которые не понимают, где узкое место, в каталоге, архитектуре оформления или работе команды, я предлагаю через oleg.is Team & AI Audit: фиксированные $5,000 за пять рабочих дней с гарантией найти экономию не меньше $50,000 в год, иначе аудит ничего не стоит.

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