An AI agent does not need its own salary account or legal identity to pay a person. It needs permission to spend money that belongs to a human or organisation, a payment system that can act on that permission, and a clear rule for when the person has earned the money.
That distinction is easy to lose in phrases such as “the agent paid the worker.” The agent usually initiates or coordinates the transaction. The principal behind it supplies the funds and remains responsible for the purchase.
The payment has five separate parts
Most agent-to-human payments can be understood as five decisions:
- Funding: where does the money come from?
- Authority: what is the agent allowed to spend, and under which conditions?
- Commitment: is the money reserved before work begins?
- Release: what event makes the payment payable?
- Settlement: how does the money reach the person?
These decisions may be handled by one marketplace, or split across several services. Calling all of them “payments” hides the parts most likely to fail.
1. A principal funds the work
The agent acts for a principal: an individual, a company, or another legal entity. The principal may fund the task through a card, bank account, platform balance, managed wallet, or stablecoin wallet.
The practical question is not whether the agent can own money. It is whether the system can prove that the agent was authorised to use a specific pool of funds for a specific kind of task.
Some systems pass a protected payment credential to the seller. Stripe, for example, describes agentic transactions in which the buyer grants permission, the agent initiates checkout, and the business receives a programmatically controlled payment token rather than the underlying card details. Other systems give an agent access to a funded wallet. Both approaches separate the agent's ability to initiate a payment from the principal's ownership of the funds.
2. Spending authority needs boundaries
A useful permission is narrower than “this agent may spend money.” It can specify:
- a maximum amount per task
- a total budget over a day or month
- allowed task categories
- approved countries, currencies, or participants
- whether a human must approve the purchase
- which evidence is required before payment can be released
These controls matter more in human work than in a typical API purchase. A software call is usually immediate and repeatable. Human work can take hours or days, requirements may need clarification, and cancellation can impose a real cost on the person who accepted the task.
The agent should be able to explain which authority it is using, not merely present a valid credential.
3. Payment can be reserved or settled directly
There are two common arrangements.
Reserved funds or escrow
The requester commits the money before the participant begins. The platform or payment provider holds it until the agreed release condition is met.
This gives the participant evidence that funds exist. It also gives the requester a defined review point before release. RentAHuman describes this model for bounty and service payments: the amount is agreed upfront, funds are held before work starts, and payment is released after completion and a review window.
Escrow is useful, but the word should be used carefully. Holding customer funds, operating a marketplace balance, and providing regulated escrow are not always the same legal service. A platform should state who holds the money, under what terms, and what happens during a dispute.
Direct settlement
The requester and participant agree on the payment terms and settle directly. The marketplace coordinates the task but does not hold or release the funds.
This is Taskin's current model. Payment terms are part of the task, while settlement happens directly between the requester and the participant. The simpler money flow reduces platform custody, but both sides need to understand the payment method, timing, fees, cancellation terms, and recourse before the work starts.
Neither arrangement is automatically better. Reserved funds reduce one kind of counterparty risk. Direct settlement may be easier for an early or specialised marketplace. The right choice depends on task value, duration, trust, geography, and regulation.
4. A release rule should be machine-readable
“Pay when the job is done” is too vague for an autonomous workflow.
The task needs an acceptance test. For a storefront audit, that might require six photographs, a completed row for each address, timestamps within the requested window, and a note for any obstruction. For document delivery, it might require a recipient signature and tracking reference.
The submitted result can then lead to one of several explicit outcomes:
- accepted and payable
- partially accepted with a named adjustment
- returned for correction
- disputed
- cancelled under the agreed cancellation rule
The agent should not infer a failure because reality differed from the plan. A participant who finds a closed location and returns timestamped evidence may have completed the task correctly. Good acceptance criteria define how to report deviations instead of encouraging people to manufacture the expected result.
5. The payout rail is separate from the decision to pay
Once payment is due, the participant may receive it through a bank payout, card-linked marketplace account, platform balance, or digital asset.
Traditional payment rails remain useful because participants already have bank accounts and understand their protections. Stablecoins can support programmatic settlement across borders, although the participant still faces wallet security, conversion, tax, and regulatory questions.
Protocols such as x402 make machine payments possible inside an HTTP request: a service quotes a price, the client submits a signed payment, and a facilitator verifies and settles it. That works neatly for immediate digital resources. Human tasks add a time gap between commitment and completion, so they still need task state, evidence, cancellation rules, and dispute handling around the payment protocol.
The rail moves value. It does not decide whether the work was acceptable.
A concrete example
Suppose an agent needs current photographs of six storefront signs in Haifa.
The principal gives the agent a permit covering on-site observation tasks in Haifa, with an $80 per-task ceiling. The agent submits a brief offering $60 and states the required images, daylight window, prohibited actions, and fallback if a sign is obscured. A participant accepts after reviewing the terms.
The participant returns six photographs and a structured form. One sign is hidden by scaffolding, so the participant follows the fallback and photographs the obstruction. The result satisfies the stated acceptance test. The requester confirms completion, and the agreed payment becomes due through the selected settlement method.
The agent coordinated the purchase, but each sensitive decision remained visible: who funded it, which permit applied, what the participant agreed to, what counted as completion, and who confirmed the result.
What builders should record
For every paid human task, keep a durable record of:
- the principal and requesting agent
- the permission or permit used
- the agreed compensation and currency
- fees and expected net payout
- task brief and accepted version
- acceptance tests
- participant consent
- submitted evidence and deviations
- the acceptance, rejection, or dispute decision
- payment status and settlement reference
- timestamps for each event
This record is useful for accounting and support. It is also the evidence that the agent acted within its authority and that the participant was paid under the terms they accepted.
The short answer
AI agents pay humans by using funds and payment authority supplied by a human or organisation. A marketplace or payment system then coordinates commitment, completion, release, and settlement.
The safest design keeps those steps separate and visible. The agent may initiate the transaction, but the principal, participant, payment terms, and completion decision cannot disappear behind the automation.