The problem

You want to pay an agent for doing a task, run this analysis, generate this report, complete this job, and have the payment tied to the task rather than to small individual calls. Or you have one agent that needs to hire another to do a piece of work and pay it for the result. The per-call payment model you have seems too granular for a task, and you are not sure how to structure payment around a unit of work an agent completes.

This is the agent-task-payment problem. The friction is mapping the idea of paying for a task, a discrete job with a result, onto a payment rail that settles per call. It feels like a mismatch: a task is bigger than a single data fetch, so how do you charge for it? The symptom is wanting task-level payment without a clear way to express it. The fix is to see that a task is just a paid call at a different granularity, and to gate it accordingly, while being honest about what the payment does and does not guarantee.

How task payment maps to per-call

The key insight is that task payment is per-call payment at the granularity of a task. A task is a unit of work that an endpoint performs and returns a result for, so paying for the task is paying for the call that runs it. Where a small per-call payment might be for a quick data lookup, a task payment is for a call that does more, the analysis, the report, the job, but it is the same mechanism: one paid call, one unit of work, one result.

So there is no separate task-payment system to build; you use x402 at the task's granularity. You gate the route that runs the task and price it for the value of the task, and the caller pays once for that call. This reframing dissolves the apparent mismatch: a task is not too big for per-call payment, it just defines a larger, more valuable unit than a trivial fetch. Once you see a task as a priced call, the fix is the familiar x402 gating applied to the task endpoint.

The fix

The fix is to gate the task's endpoint with x402 and price it for the task. You front the route that runs the task with the x402 adapter and set a price reflecting the task's value. A caller, a human-driven client or another agent, calls the route, settles the price in USDC, and the task runs, returning its result. One paid call corresponds to one task performed, which is exactly the task-level payment you wanted.

For the case where one agent hires another, the same gating makes it agent-to-agent: the hiring agent calls the doing agent's gated task endpoint and pays from its wallet, and the doing agent runs the task and returns the result. Each agent has its own wallet and spend limit, so the payment is attributed per agent. The fix, then, is to gate the task route and charge for the call that runs it, using the same x402 mechanism at task granularity. The agent-to-agent mechanics are in how-to-handle-agent-to-agent-payments.

Pay-to-run, not pay-on-completion

Here is the honest nuance that matters for task payment: x402 settles the payment before the server runs the task, so it is pay-to-run, not pay-on-verified-completion. The caller pays, then the task executes; there is no built-in escrow that holds the payment and releases it only if the task succeeds. If you imagine task payment as paying only when the outcome is delivered and verified, that is not what the protocol provides on its own.

This is worth being clear about so you design around it rather than assume a guarantee that is not there. If your task is reliable, pay-to-run is fine: the call pays and the task delivers, the same as any paid API. If you need stronger guarantees, handle them at the application level, for example, have the task endpoint charge only when it can actually deliver the result, price the task to reflect its success rate, or build a verification-and-refund flow in your own logic. The point is that the payment is tied to the call, not to a verified outcome, so success guarantees are your design problem, not a feature you can assume.

Hiring another agent for a task

The richest version of task payment is one agent hiring another, which is agent-to-agent payment for a unit of work. A planning agent that cannot do everything itself can delegate a task to a specialist agent and pay it for the result: it calls the specialist's gated task endpoint, settles the price, and gets the work back. The specialist earns per task, the planner pays per task, and both stay within their own spend limits.

This is how agents compose into a workflow that involves money: each agent does what it is good at and is paid for it, hired by other agents as needed. The trust model is the agent-to-agent one, the payer leans on the doing agent's identity to decide it is worth hiring, and the doing agent leans on verified payment before running the task. So task payment between agents is just agent-to-agent payment where the call corresponds to a task, which is covered conceptually in what-is-agent-to-agent-payment.

Describe the task first

One practical point: keep task discovery free so a caller knows what it is paying for. Before a caller pays for a task, it should be able to learn what the task does, what inputs it needs, and what result it returns, on a free, ungated route or description. A caller, especially an autonomous agent, will not pay for a task it cannot understand, so the free description is what lets it decide the task is worth the price.

This mirrors the keep-discovery-free principle for any paid endpoint, applied to tasks: the doing agent or service describes its tasks openly, prices them, and gates only the execution. A planning agent can then read the available tasks, choose the one it needs, and pay for it, which is what makes a market of agent tasks work. So part of structuring task payment is describing the task clearly and freely, then charging for running it, not gating the very information a caller needs to decide to pay.

Sizing the price to the task

Because a task is a larger unit than a trivial call, price it for what the task is worth, not for a tiny fetch. Set the price from the task's real cost to deliver, the compute, data, and upstream calls it consumes, plus a margin, so each completed task is profitable. A task that runs an expensive analysis warrants a higher price than one that formats text, and the price should reflect that difference rather than a flat per-call rate.

Then check it against your spend limits if an agent is the one paying: the per-transaction cap must be high enough to allow a single task payment, since a task can cost more than a small call. Size both sides, the task's price and the paying agent's cap, so a legitimate task payment goes through while runaway spend is still bounded.

Related reading

If you need to pay an agent for a task, the path is x402 at task granularity. The agent-to-agent mechanics, for one agent hiring another, are in how-to-handle-agent-to-agent-payments, and the concept is in what-is-agent-to-agent-payment. Together they take you from wanting task-level payment to gating tasks and paying per job, with honest handling of what the payment guarantees. Pricing is on the pricing page.