Что сказал Тони Сюй: цифры и формулировки
На отчётном звонке за третий квартал 2026 года сооснователь и CEO DoorDash Тони Сюй отвечал на вопрос аналитика про AI-агентов. Ответ содержал цифру, которая плохо стыкуется с разговорами о том, что агенты вот-вот заберут себе потребительские покупки: внешние агенты сгенерировали «несколько сотен заказов» за всё время, что они работают. За один третий квартал 2026 года DoorDash обработал чуть меньше 1 млрд заказов (Ars Technica).
Сюй назвал заказ еды через стороннего агента «очень слабым сценарием использования» (very low use case). Объяснение короткое: когда задача сводится к заказу еды, пользователи приходят в DoorDash напрямую.
Три оговорки, без которых цифра читается неправильно. Точное число заказов не раскрывается, есть только формулировка «несколько сотен». Речь идёт о внешних агентах, а не о собственных агентных функциях DoorDash, данных о них в материале нет. И всё это один отчётный звонок в пересказе одного источника, так что переносить вывод на весь рынок доставки оснований мало.
Почему «несколько сотен» - это статистический шум
Посчитаем на пальцах. Возьмём верхнюю границу формулировки, 500 заказов, и сопоставим с 1 млрд за квартал: получается 5×10⁻⁷, или 0,00005%. Один заказ на примерно 2 млн. Если брать нижнюю границу, картина становится ещё скромнее. Расчёт оценочный: точных чисел источник не даёт, но порядок величины он задаёт однозначно.
Есть и второй эффект, который усиливает разрыв. Заказы через агентов накопились за всё время их работы, а миллиард относится к одному кварталу. То есть реальная доля агентов в общем потоке ещё ниже, чем в этом сравнении.
Практический вывод из таких чисел один: на массиве в несколько сотен событий нельзя увидеть динамику, сезонность или эффект отдельных изменений в продукте. Зато можно уверенно утверждать, что массового спроса на заказ еды через сторонних агентов сейчас нет. Это разные утверждения, и путать их не стоит.
Почему заказ еды - плохой сценарий для AI-агента
Сюй описывает поведение пользователей так: простая задача вроде заказа еды идёт напрямую в DoorDash. Дальше начинается аналитика сценария, и её стоит отделить от данных компании. Ниже аргументация о механике задачи, а не статистика DoorDash.
Заказ еды укладывается в короткий цикл: несколько минут от «хочу есть» до оплаты. Решение почти не требует сравнения источников, потому что меню, адреса, способы оплаты и история заказов уже лежат в приложении. Цена ошибки низкая: не тот соус или лишняя порция не стоят отдельного разбирательства. И главное, пользователь не пытается сэкономить время, которого на задачу уходит меньше, чем на постановку задачи агенту.
Где именно агент добавляет трение, а не убирает его
- Лишний шаг подтверждения. Агент всё равно возвращает выбор на согласование: состав заказа, адрес, сумму. Это дополнительный цикл вместо одного нажатия «повторить заказ».
- Вопросы доверия. Оплата и адрес доставки касаются денег и личных данных. Пользователю нужно понимать, какие права получил агент и что произойдёт при ошибке.
- Риск неверной интерпретации. «Что-нибудь сытное, но без острого» допускает десятки трактовок, и любая из них может оказаться не той.
- Отсутствие выигрыша по времени. На горизонте двух-трёх минут посредник в виде агента не даёт преимущества, которое оправдало бы новый интерфейс.
- Слой без снятия работы. Агент стоит между пользователем и сервисом, но решение о еде всё равно остаётся за человеком.
Как именно внешние агенты технически оформляли заказы в DoorDash, в источнике не описано. Поэтому детали интеграции, доступов и подтверждений здесь не разбираются: их пришлось бы выдумать.
Что Сюй считает правильным применением: покупки с длительным обдумыванием
Позиция CEO DoorDash состоит из двух частей. Для простых транзакций агент проигрывает прямому обращению. Зато потенциал есть в «покупках с длительным обдумыванием» (long consideration purchases) и крупных решениях, где агент проактивно работает в фоне от имени пользователя (Ars Technica).
Логика читается: длинный цикл решения означает много факторов, много источников и высокую цену ошибки. Именно там появляется работа, которую можно делегировать: собрать варианты, отсеять неподходящие, свести параметры в таблицу, дождаться снижения цены, напомнить о дедлайне. Это оценка перспективы, а не подтверждённые метрики: результатов таких сценариев в источнике нет.
Критерии задачи, которую стоит отдать агенту
Чек-лист, собранный из этой логики. Чем больше пунктов совпало, тем выше шанс, что агент окажется полезнее прямого интерфейса.
- Длительный горизонт решения: дни или недели, а не минуты.
- Много вариантов и параметров, которые нужно сопоставить между собой.
- Данные разбросаны по разным источникам и обновляются.
- Время пользователя дорого, а сама работа рутинная.
- Допустим отложенный результат и фоновая работа без постоянного контроля.
- Рекомендацию можно проверить до оплаты.
Классы задач, подходящие под эти критерии: подбор сложной техники с десятком характеристик, сравнение страховых условий, выбор подрядчика для ремонта, сопоставление тарифов на услуги, крупные бытовые решения вроде переезда или замены оборудования. Это иллюстрации критериев, а не подтверждённые кейсы из отчётного звонка DoorDash.
AI-агенты в e-commerce: где заканчивается демо и начинается спрос
Многие компании пытаются применять LLM, чтобы улучшить покупку товаров и услуг в интернете. При этом использование внешних AI-агентов для покупок источник прямо называет относительно новым сценарием, который находится на ранней стадии. Отсюда и разрыв между демонстрациями и реальными цифрами.
Демо показывает возможность: агент открывает сайт, находит товар, заполняет корзину. Массовое использование требует другого набора условий: доверия к оплате, предсказуемости результата и понятной выгоды по времени или деньгам. Пока хотя бы одно звено отсутствует, пользователь выбирает привычный путь. У части сервисов к этому добавляется техническая стена: антибот-защита и намеренные блокировки агентов, о которых мы разбирали отдельно в материале про блокировки агентов и открытый стандарт взаимодействия.
Важная деталь: Сюй не говорил, что агенты бесполезны для e-commerce в целом. Он разделил задачи на простые, где выигрывает прямой канал, и длительные, где видит перспективу. Приписывать DoorDash более широкие выводы было бы искажением.
Внедрение AI-агентов в бизнес: как решить, нужен ли он вам
Рамка для продакта и предпринимателя начинается с классификации задачи, а не с выбора модели. Определите длительность цикла решения и цену ошибки. Если задача решается за пару минут и стоит недорого, агент почти наверняка добавит шаг. Если решение занимает дни и ошибка дорогая, появляется место для фоновой работы.
Второй вопрос: агент снимает работу или перекладывает её? Проверить просто, достаточно пройти сценарий целиком и посчитать действия пользователя. Когда агент просто повторяет уже настроенное действие, прямой интерфейс обычно быстрее и дешевле. Когда агент собирает и сравнивает данные, которых пользователь сам не соберёт, ценность появляется. Как ограничения автономности выглядят на практике, видно по кейсу Project Vend от Anthropic: агент в реальном магазине упирается в границы полномочий, а не только в качество модели.
Метрики, которые стоит смотреть до запуска агента
- Доля задач, завершённых без вмешательства человека. Показывает, где агент реально закрывает сценарий, а где превращается в подсказку.
- Число шагов подтверждения. Прямая мера трения: чем больше согласований, тем меньше смысла в посреднике.
- Время от запроса до результата. Сравнивать нужно с прямым сценарием, а не с пустотой.
- Доля ошибок и отмен. Показывает цену неверной интерпретации запроса.
- Возвраты пользователей к агенту. Повторное использование говорит о привычке, единичные попытки говорят о любопытстве.
- Стоимость поддержки на один заказ. Агент может добавить обращений, даже если формально справляется.
Без базовой линии по прямому сценарию эти цифры бесполезны: сравнивать агентный поток нужно с тем, как та же задача решается сейчас. И помните про ограничение данных: выводов по конверсии агентных сценариев в потребительских сервисах мало, а один отчётный звонок не описывает рынок.
Что должно измениться, чтобы агенты стали массовыми
Условия вытекают из позиции Сюя и природы сценария. Первое: доверие к оплате и к действиям от имени пользователя. Пока человек не понимает границ полномочий агента и не видит понятного отката при ошибке, крупные покупки он оставит себе. Второе: предсказуемость результата, когда одинаковый запрос даёт сопоставимое качество. Третье: интеграции с сервисами, потому что агент, упирающийся в проверку на человека, не доводит задачу до конца.
Четвёртое условие: измеримая выгода. Она бывает во времени, в деньгах или в охвате сравнения, которое человек физически не сделает. Пятое: сценарий должен быть длинным настолько, чтобы фоновая работа имела смысл. Источник характеризует использование агентов для покупок как раннюю стадию, поэтому текущие цифры могут не отражать будущий спрос. Гарантией роста это не становится: ранняя стадия бывает и у сценариев, которые так и остаются нишевыми. Конкретных сроков здесь назвать нельзя, и придумывать их не стоит.
Как меняются интерфейсы под агентный трафик и какие экраны люди оставляют себе, разбирали в материале про переход интерфейсов к AI-агентам.
Выводы для тех, кто строит продукты с AI-агентами
- Простые транзакционные задачи не выигрывают от агента. Если сценарий укладывается в минуты и уже настроен в приложении, посредник добавляет шаги.
- Ценность смещается к длительным решениям с фоновой работой: сбор вариантов, сравнение параметров, мониторинг условий, напоминания.
- Несколько сотен заказов против почти 1 млрд за квартал - это сигнал о текущем спросе, а не приговор рынку. Сценарий молодой, и сам источник называет его ранней стадией.
- Перед запуском нужны метрики и базовая линия по прямому сценарию: доля завершённых задач, шаги подтверждения, время до результата, доля ошибок и отмен.
- Ограничения материала стоит держать в голове: один отчётный звонок, пересказ в одном источнике, отсутствие точного числа заказов и данных о собственных агентных функциях DoorDash (Ars Technica).
Практическое действие для команды, которая рассматривает агента: возьмите три своих сценария, разные по длительности цикла и цене ошибки, и сравните для каждого путь через агент и прямой путь по числу действий пользователя. Если агент не уменьшает число шагов и не добавляет информации, которой у пользователя нет, начинать с него не стоит.