Delphi Digital: узкие места агентской экономики — это не платежи, а «передача и приемка»

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

Автор: Delphi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Платежи решают только вопрос оплаты, а наем все еще требует приемки

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

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

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

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

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

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

Один шаг вперед — и ошибки увеличиваются

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

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

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

В настоящее время мы видим лишь структуру, а не масштаб

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

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

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