Delphi Digital: Узким местом агентской экономики являются не платежи, а «передача и приёмка»

Автор: Delphi

Перевод: AididiaoJP, Foresight News

Обсуждение ИИ-агентов в сфере электронной коммерции длится уже два года, и первым на практике начинает внедряться платежный этап. Stripe позволил агентам производить оплату продавцам, x402 от Coinbase обеспечил канал расчётов стейблкоинами, оплата данных и сервисов инференса по факту использования уже успешно опробована. Однако как только задача выходит за пределы «одного вызова API», проблема трансформируется: агент не может справиться самостоятельно, ему приходится передавать часть процессов на сторону и подтверждать, что контрагент действительно выполнил согласованную работу.

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

Покупка входных данных и покупка результата — это разные вещи

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

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

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

Это и является границей между рынком заданий и обычным рынком API: рынок API продаёт вызовы; рынок заданий продаёт подтверждённые единицы завершённой работы.

Нечёткое определение задач мешает работе рынка

Задачи, допускаемые на рынок заданий, должны быть заранее определены так, чтобы обе стороны чётко понимали, какие средства и за какой результат будут выплачены. Эксперт вполне может предоставить материал низкого качества для апелляции вместе с просто квитанцией о приёме. Если покупатель оплачивает «качественно подготовленный документ», кто-то обязан проверить его перед переводом средств.

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

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

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

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

Платежи решают лишь вопрос перевода денег, найму не хватает приёмки

Перечислить деньги и передать задачу на выполнение — между ними лежат эскроу, сдача работ, приёмка и возражения. Stripe и x402 закрывают первую половину. Агенту по-прежнему нужно найти человека для подачи апелляции и представления интересов собственника. Без приёмки чем удобнее платежи, тем быстрее могут пройти ошибочные заказы.

Существующие продукты уже построены по этой структуре.

TaskMarket от Daydreams позволяет покупателю создавать задания, а агенту — брать их в работу. Сначала покупатель депонирует средства, после чего рабочие могут либо сразу забрать задание, либо покупатель сначала изучает предложения, прежде чем выбрать исполнителя. Средства хранятся в эскроу, размораживаются только после подтверждения результатов.

Agent Commerce Protocol от Virtuals предполагает обсуждение задачи между агентом-заказчиком и агентом-подрядчиком, средства поступают в эскроу, а выплата происходит после сдачи и одобрения. Возможно привлечение внешних оценщиков для проверки соответствия результатов заранее оговоренным условиям. Со стороны NEAR также ведётся интеграция задач, бюджетов, аукционов и проверок в единый процесс, вектор тот же — «оценка завершённой задачи», а не только одного вызова.

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

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

Лишний шаг умножает ошибки

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

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

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

Сегодня виден каркас, а не масштаб

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

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

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