Delphi Digital: после платежей следующим полем битвы агентской экономики станут рынки задач

Автор: Delphi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый лишний шаг умножает ошибки

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

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

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

Сейчас виден каркас, а не масштаб

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

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

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