Funds are first held in escrow, and only released after acceptance.

Written by: Delphi

Compiled by: AididiaoJP, Foresight News

The discussion about Agent e-commerce has been ongoing for two years, with the payment phase implemented first. Stripe allows Agents to make payments to merchants, and Coinbase's x402 provides a stablecoin settlement channel, enabling data and inference services to be purchased by the instance. However, once the task exceeds "calling an interface once," the issues change: Agents cannot complete it independently and need to outsource some phases, confirming that the counterpart has indeed completed the agreed work.

This article by Delphi focuses on this phase. The task market is not another payment protocol; rather, it allows Agents to outsource parts they cannot complete: first clarifying the deliverable, then proceeding to execution, with payment released only after the results are accepted. If the handover is reliable, the task can continue advancing without needing to bring the user back to act as a project manager, sequentially connecting with suppliers.

Buying inputs and buying results are not the same

When landlords screen tenants, Agents can retrieve credit and eviction records from existing service providers. The counterpart returns standard materials, which the landlord uses to make a judgment. At this point, what is purchased is input for decision-making, and the endpoint of the task remains in the landlord's hands.

Property tax reconsiderations are different. Agents can compare recent transactions to find that the assessments may be inflated, but this discovery does not automatically modify the tax bill. To push forward, it generally requires finding someone familiar with the county procedures to submit materials and represent the landlord in court. The task market should help Agents find this person, and clarify the working methods and payment terms in advance.

The former approaches the current pay-per-instance model: clear pricing, standardized deliverables, and almost automatic acceptance. The latter is purchasing something that has been completed. Submitting materials does not equate to the case being ready, and a receipt does not guarantee qualification. Payment conditions must be tied to "verifiable results," not "what the counterpart claims to have done."

This also delineates the boundary between the task market and the ordinary API market: the API market sells calls; the task market sells confirmed completed units.

Unclear task definitions hinder market operations

Tasks that can enter the task market need to be defined such that both parties understand how funds are linked to what kind of results. It is entirely possible for an expert to submit a very poor reconsideration material and include a receipt. If the buyer is paying for "a qualified material," someone must review the materials before funds are released.

Who reviews, and how either party can raise objections to the review results, should ideally be written into the order in advance. In this way, the buyer does not fear receiving poor quality deliverables, and the party accepting the order does not fear unreasonable refusal of payment. Without this layer, the market can slide towards two bad directions: either the buyer arbitrarily refuses payment, leading professional suppliers to hesitate; or materials can be submitted superficially, securing payment while the buyer dares not place further orders.

Tasks that are too small are also not worthwhile. If the costs of review and dispute resolution exceed the savings from outsourcing, people will revert to completing them themselves or continue using only standardized interfaces. Therefore, early implementations are more likely to appear in clearly defined, repeatable tasks with verifiable acceptance, rather than one-off, ambiguous commissions.

Enterprises are more suitable as early buyers. They already fragment tasks among multiple suppliers and have internal processes and standards for comparison. Agents can prepare tasks within the company and then outsource the necessary parts, able to verify the returned results against existing processes. If a task recurs, the party accepting the order can also accumulate completion records for certain types of tasks. Once reputation can accumulate, the next match will not require building trust from scratch.

Individual users are not excluded, but they resemble a template in the early stage. Enterprises have budgets, recurrences, and internal acceptance habits, making them closer to the order density required for a market's cold start.

Payment only resolves payment; hiring still lacks acceptance

Sending out money is different from outsourcing a task; it involves escrow, delivery, acceptance, and disputes in between. Stripe and x402 cover the first half. Agents still need to find someone to submit reconsiderations and represent the landlord. Without acceptance, the more convenient the payment, the faster erroneous orders can move.

Current products have been built upon this structure.

Daydreams' TaskMarket has orders placed by buyers and accepted by Agents. Buyers first deposit funds, allowing workers to directly claim tasks or review proposals before selecting individuals. Funds are held in escrow, and payment is released only after the submitted results are accepted.

Virtuals' Agent Commerce Protocol involves a task negotiated between the outsourcing Agent and the accepting Agent, where funds go into escrow, and payment is released after delivery and approval. An external evaluator can be added to verify whether the results meet the prior agreements. On the NEAR side, there is also integration of tasks, budgets, bidding, and verification into a single process, with the same direction being to "price for completed tasks," rather than just pricing for a single call.

While paths differ slightly, the skeleton is similar: order placement, matching, escrow, submission, acceptance, and disbursement. Without acceptance, escrow simply delays the transfer; with acceptance, escrow becomes a constraint on the results.

Some people have made acceptance documents more detailed: specifying the outsourcing content, the accepting party, pricing, verifier, deliverables, dispute window, and refund status. The more complete the documents, the easier it is for Agents to hand over tasks without reverting the user back to being a scheduler.

One more step, and errors will magnify

The task market has been proposed not only because outsourcing sounds advanced but also because multi-step processes amplify errors. In a ten-step task, with a 95% correctness rate for each step, the probability of completing all steps without errors dwindles to just about 60%. Every additional handover without verification carries forward previous errors into the next step.

Thus, the market needs to set checkpoints at handover points: this phase must pass before purchasing the next phase. Errors must be contained at each step rather than cumulatively discovered at the end to void the entire order. This is especially true for Agents. They are not like company employees, who can hold meetings to pursue accountability when something goes wrong; they need pre-established acceptance conditions and disbursement rules.

This also explains why the majority of current Agent transactions remain in native crypto and simple services: tasks are short, results are easy to verify, and disputes are few. The real differentiation will arise from interlinking multiple suppliers into longer workflows, ensuring checks at each step.

What we currently see is the structure, not the scale

The task market aims to achieve something very specific: allowing Agents to outsource parts of tasks, with payments made only after the results are recognized, thus enabling more tasks to be genuinely completed. The payment layer is already in place. What is missing are verifiable completed units, acceptably costly acceptance processes, and a sufficiently dense repetition of orders.

Extending internal processes outward will likely create the first batch of acceptable demands. The complex commissions on the individual side will need to wait until acceptance costs and dispute resolutions come down. Before that, it is more worthwhile to focus not on another payment protocol but on whether these three things can coexist: can tasks be written into verifiable documents, can escrow hold funds before approval, and does the accepting party have accumulatable completion records.

With these three in place, Agents will have the chance to complete tasks rather than getting halfway and calling the user back to continue acting as project manager.