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:

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.

That is the gap this article is about. Agents are very good at producing data that is shaped correctly. They are much weaker at knowing when the data is true. For a lot of real work, the fastest way to close that gap is still a person checking the output against the source.

Confident and wrong: the failure mode of extraction agents

When a person copies data by hand, mistakes tend to look like mistakes: a missing field, an obvious typo, a row that doesn't match the others. When a model extracts data, the errors look exactly like correct answers.

A builder we talked to on Reddit described it well. Their agent pulled product dimensions from supplier sites. The output was consistent and well formatted, and a meaningful share of it was simply wrong: the model had read the shipping box size instead of the product size, mixed up units, or filled a missing value with something plausible.

Typical extraction errors that pass every format check:

• Right field, wrong value. The page lists several numbers (package, product, pallet) and the model picks the wrong one.
• Unit drift. Centimeters read as inches, grams as kilograms, prices without the currency.
• Plausible filling. When a value is missing, the model fills the gap with something that fits the pattern instead of leaving it empty.
• Stale or cached pages. The agent read a version of the page that no longer matches what a customer sees.
• Entity mix-ups. Two companies with similar names, or a parent company instead of the subsidiary you asked for.

None of these break your schema. All of them break the decision you make with the data.

Why "just add another model" is not enough

The natural reaction is to add a second model as a checker. That helps with some errors (format, internal consistency, obvious outliers), and it is worth doing. But two models reading the same page often make the same mistake for the same reason: the page is ambiguous, and both resolve the ambiguity the same way.

A human validator brings something different:

• They can open the page, scroll, compare images and spot that "40 x 30 cm" is the box, not the chair.
• They notice when something is off even if it is formatted correctly.
• They can say "this source is unreliable" instead of forcing an answer.

The goal is not to replace automation. It is to put a person exactly where the agent's confidence stops being a good signal.

Where human validation pays off

Human validation is worth paying for when an error is expensive and hard to see. Common cases:

If an error would only cost you a few seconds to fix later, skip human review. If it would end up in front of a customer, in a training set or in a financial decision, a 20-minute check is cheap.

How to brief a validator so they actually catch errors

The same builder made a second point that matters more than the first: finding someone to validate 200 rows was easy, but the first person just marked everything as correct. Most validation projects fail at the brief, not at the hiring.

Five things that make human validation work:

1. Define "correct" for each field. "Check the dimensions" is vague. "Dimensions are the assembled product in cm, not the box; if only the box is listed, mark it as missing" is checkable.
2. Plant known errors. Add a few rows you know are wrong. If the validator doesn't flag them, you know the review wasn't real before you rely on it.
3. Ask for evidence, not just a checkmark. A column for the source URL or a short note ("box size only") turns "looks fine" into something you can audit.
4. Allow "can't verify". Forcing a yes or no pushes people to guess. A third option keeps bad data out.
5. Start small. Send 20 rows first, check the result yourself, then send the rest with a clearer brief.

These rules also make the job easier to price: a validator can estimate time much better when "done" is defined.

Paying a person when the buyer is an agent

Once an agent can identify that it needs a person, the next problem is payment. A one-off task of 20 to 100 dollars is too small for a contract and too large to send on trust. Both sides worry about the same thing: who pays first.

Escrow solves that. The buyer puts the money in first, the worker can see it is there, and it is released when the work is approved. Some marketplaces built for this use stablecoin escrow, which also works when the buyer is software with its own wallet.

Mercadopleis is one example (and the project behind this article). An agent, or the person running it, can find a validation service or post a request through an MCP server or the API, fund a non-custodial USDC escrow on Base, and approve the delivery when the check is done:

• The money waits in a smart contract, not with the platform or the seller.
• The seller submits the delivery, and its SHA-256 hash is recorded on-chain.
• The buyer has 5 days to review. 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 in 14 days.
• The seller pays a fixed 3% fee; the buyer pays the listed price.

Whatever tool you use, the point is the same: make the payment conditional on a delivery that both sides can check.

A simple workflow you can copy

1. Your agent extracts the data and marks rows where its confidence is low or sources disagree.
2. It sends those rows (or a random sample) to a human validator with a written definition of "correct" and a few planted errors.
3. The validator returns each row as correct, corrected or "can't verify", with a source.
4. Your agent merges the corrections, re-runs on the rows marked "can't verify" or drops them.
5. You pay when the planted errors were caught and the sample checks out.

This keeps people on the 10–20% of the work where they add the most, and keeps the rest automated.

FAQ

Can't I just use a better model? Better models reduce errors but don't remove the ambiguous cases, and those are the ones that cost the most. A person checking a sample is still the cheapest way to know your real error rate.

How much should human data validation cost? It depends on how hard each row is to check. For simple fields, a few hundred rows can take a few hours. Defining "correct" clearly and including evidence columns usually reduces the time more than negotiating the rate.

Should the validator see the agent's output or start from scratch? Checking the agent's output is faster. Starting from scratch on a small sample tells you whether the reviewer is anchoring on the agent's answers. Doing both on a small batch is a good test.

Can an AI agent hire the validator itself? Yes, if it has a wallet and a way to discover and pay for services, for example through an MCP server connected to a marketplace with escrow. A person should still approve the budget and the brief the first time.