How Can AI Agents Hire Humans? A Practical Guide for Builders

Most agent frameworks have a "human in the loop" step. In practice it usually means one thing: the agent stops and asks you. That works for approvals. It doesn't work when the task needs hours of someone's time, a skill you don't have, or a person who isn't on your team.

This guide is about the other case: an agent that hands a task to a person it doesn't know, waits for the result, checks it and pays for it. It covers when that makes sense, the options that exist today, a concrete flow using the Model Context Protocol (MCP), and the parts that usually go wrong.

When should an agent hire a person?

Hiring someone adds cost and waiting time, so it only makes sense when the alternative is worse. Good signals:

• The error is expensive and hard to see. Extracted data that looks right but isn't, labels that will end up in a training set, claims that will reach a customer.
• The task needs judgment on messy input. Noisy audio, ambiguous product pages, edge cases in a dataset, sites that block scrapers.
• The work is bounded. A clear input, a clear output and a deadline. "Verify these 200 rows" is a good task; "help with marketing" is not.
• The volume is too small for a vendor. A few hours of work is too little for an annotation company and too much to do yourself every week.

If the task is an approval or a yes/no decision, you don't need to hire anyone. Ask the user.

The options that exist today

There are roughly four ways an agent can get a person to do something:

Option	How it works	Good for	Weak spot
Ask the user	The agent pauses and asks whoever runs it	Approvals, quick decisions	Doesn't scale, the user may not have the skill
Internal reviewer	A task goes to a colleague's queue, the agent polls until it's done	Teams with reviewers on staff	Only works with employees
Annotation or data vendor	You send a batch to a company with a contract	Large, recurring volumes	Minimums, contracts, slow to start
Marketplace with escrow	The agent posts or buys a task, a person delivers, payment is released on approval	One-off or small tasks with strangers	Newer, fewer providers

One builder we talked to had built the second option for document approvals: the model reviewed documents and sent the doubtful ones to a manager, then polled the task every few minutes. It worked inside the company. Their answer to "what about paying someone outside?" was that they never found a good solution. That gap is what the fourth option tries to fill.

A concrete flow using MCP

MCP lets an agent call tools exposed by a server. If a marketplace exposes its catalog, orders and payments as MCP tools, the agent can hire someone with the same mechanism it uses for everything else.

Here is the flow using the open-source Mercadopleis MCP server (the project behind this article) as an example. The same steps apply to any tool you build yourself.

1. Connect the server. Locally with npx -y @mercadopleis/mcp-server, or through the hosted endpoint at https://mercadopleis.club/mcp. The server never holds keys: it returns unsigned transactions that your wallet signs.

2. Find a service, or post a request. The agent calls search_services with the capability it needs ("validate a company list", "transcribe Portuguese audio"). If nothing fits, post_request publishes the task so people can send proposals, and list_proposals and accept_proposal let the agent (or you) pick one.

3. Fund the order. create_order builds the unsigned transactions that lock the price in a USDC escrow on Base. The money now waits in a smart contract, not with the seller or the platform.

4. Send the details privately. The request is public, so anything sensitive goes through send_message, the order's private thread.

5. Receive and check the delivery. The seller delivers a file and its SHA-256 hash is recorded on-chain. get_deliverable downloads it and checks the hash against the commitment.

6. Approve, dispute or claim a refund. prepare_order_action builds the next step: approve the delivery, open a dispute, or claim a refund if the deadline passed without delivery.

7. Withdraw. Payouts and refunds are credited in the escrow, and each side moves them to its wallet with prepare_withdraw.

For the first few orders, keep a person in the loop for steps 3 and 6. Letting an agent spend money and accept work on its own is a decision to make after you've seen it behave.

Write the task like a spec, not a prompt

Most failed hires fail at the brief. Another builder told us they paid a freelancer to verify a few hundred product listings. Finding someone was easy. The first person marked everything as correct without really checking, and it took a second hire to get real results.

What helps:

1. Define "done" per item. "Check the dimensions" is vague. "Dimensions are the assembled product in cm; if only the box size is listed, mark it as missing" is checkable.
2. Give an example of a good result and one of a rejected one.
3. Plant a few known errors. If they come back unflagged, the review wasn't real.
4. Ask for evidence. A source link or a short note per row turns "looks fine" into something you can audit.
5. Allow "can't verify". Forcing a yes or no makes people guess.
6. Start with a small batch. Twenty rows first, then the rest with a better brief.

If your agent writes the brief, have it use a template with these fields. Agents are good at filling templates and bad at guessing what a stranger needs to know.

Waiting for a person without hanging forever

People are slow compared with tool calls, and they go on holiday. Many MCP clients give up on a tool call after about 30 seconds, so the wait can't live inside one call. Patterns that work:

• Split the call in two. The tool that needs a person returns right away with an id and a "pending" status; a separate status tool returns the result later. The agent can do other work or stop and resume.
• Deadlines on every task. An order should carry a delivery deadline, and the agent should know what happens when it passes. Treat "nobody answered" as its own decision (refund, reassign, escalate), not as a timeout error.
• Poll with a hint, not on a fixed timer. Checking every five minutes for two days is wasteful. If the status tool says when the next change can happen (the delivery deadline, the end of the review window), the agent only needs to look then.
• Use MCP elicitation for approvals only. MCP lets a server ask the connected user for input during a session. It only reaches whoever is attached to the client, so it fits "approve this budget?", not a stranger doing hours of work.
• Make the agent resumable. Store the order id and pick up where it left off instead of keeping a process alive for a day.
• Keep the decision, not just the outcome. Record who approved, which exact version they saw and why they rejected. Weeks later it's the only way to tell a bad input from a bad review.

In the Mercadopleis server (0.4.1 or later, run locally with npx), get_order_status returns expectedBy and nextCheckAfter, and wait_for_order_update waits up to five minutes for the next status change.

Paying a stranger safely

When the person isn't an employee, both sides face the same question: who pays first? Paying upfront puts the risk on the buyer, paying after puts it on the worker. For small tasks of 20 to 100 dollars, neither will sign a contract.

Escrow removes most of that tension. In the Mercadopleis contract, for example:

• The buyer funds the order; the seller can see the money is locked.
• The buyer has 5 days to review a delivery. If they don't respond, the seller can claim payment.
• If the seller misses the deadline, the buyer gets a full refund.
• Disputes follow a public arbitration policy, with a default outcome if no ruling is made within 14 days.
• The seller pays a fixed 3% fee; the buyer pays the listed price.

Whatever you use, the principle is the same: make the payment depend on a delivery both sides can check, and decide in advance what happens when something goes wrong.

FAQ

Can an agent hire a person completely on its own?
Technically yes, if it has a wallet, a budget and tools to find, fund and approve work. In practice, keep a person approving the budget and the first deliveries until you trust the setup.

What kinds of tasks work best?
Bounded tasks with a checkable output: data validation, labeling, transcription, translation, scraping hard sites, research with sources, small automations.

How much does it cost?
It depends on the task. As a reference, verifying a few hundred simple rows can take a few hours of work. A clear brief usually saves more than negotiating the rate.

Do I need crypto to do this?
With a stablecoin escrow like the one above, the buyer needs USDC on Base and a wallet to sign transactions. That is also what makes it work when the buyer is software.

What's the difference from asking the user in the loop?
Asking the user is a decision; hiring a person is work. The first needs a prompt, the second needs a brief, a deadline and a payment.