Dev.to AI ๐Ÿค– Ai ๐Ÿ‘ 0 ๐Ÿ“– 3 min read

Your AI agent finished the task. Who decides if it's good enough to pay for?

If you've built anything agentic past a demo, you've hit this wall. The agent can write the SQL, draft the doc, summarize the repo. The hard part isn't generating the output โ€” it's the acceptance step. Someone has to loo

If you've built anything agentic past a demo, you've hit this wall. The agent can write the SQL, draft the doc, summarize the repo. The hard part isn't generating the output โ€” it's the acceptance step. Someone has to look at it and decide: is this done? Is it good enough to pay for?

Right now that "someone" is almost always a human. That's fine when you're one dev reviewing your own agent. It breaks the moment you want an agent to do work for someone else โ€” or hire another agent โ€” and get paid without a person in the loop.

The usual options are all bad:

  • The buyer decides. They can reject anything and keep the money. Workers learn not to trust them.
  • The platform decides. Now a $2 task waits in a support queue.
  • Tests decide. Great for code with a spec. Useless for "write a clear explainer" or "propose a governance design."

Making acceptance explicit

I've been submitting work to Verdikta Bounties for a few weeks, and the interesting idea there is to make the acceptance step itself explicit and automated:

  1. The creator locks ETH in an escrow contract on Base. The contract has no cancel or edit function, so the terms can't move after you start working.
  2. The bounty ships with a rubric โ€” weighted criteria, some marked as hard gates โ€” and a pass threshold.
  3. The submission is scored by a jury of different models (the bounties I've worked on use an OpenAI model and an Anthropic model, weighted 50/50). Their justifications are stored on IPFS.
  4. Score at or above the threshold โ†’ the contract pays. Below โ†’ it doesn't.

The rubric is just JSON:

{
  "id": "concrete-example",
  "description": "References a specific, real result โ€” not generic claims.",
  "weight": 0.25,
  "must": false
}

Flip must to true and that criterion becomes a gate: miss it and the weights don't matter.

What it looks like on real bounties

Bounty #190 asked for a SQL query that finds the second-highest salary in each department. Threshold 88. One submission came in, the jury scored it 98, and it paid out โ€” no review meeting, no invoice, no "let me circle back."

Bounty #182 went the other way. It asked for a high-level proposal for an autonomous AI DAO, threshold 95. Seven submissions scored between 83 and 93 โ€” solid work by most standards โ€” and none of them passed. The bounty only paid out once a submission scored 96. The bar wasn't negotiable, which is exactly what you want when you're the one paying.

My own receipt: a marketing bounty with an 88 threshold that I passed with a 91. Honestly, my first attempts didn't even get scored โ€” the oracle timed out and I had to resubmit. It's young infrastructure.

Why agent builders should care

Swap "human hunter" for "agent" and you get the primitive agent marketplaces are missing: a buyer and a worker who don't trust each other's judgment, both trusting a published rubric and a multi-model jury instead. Hunters prepay a small evaluation fee, so spamming submissions isn't free. There's also an agents.txt and an API, so an agent can find bounties, submit and finalize without a browser.

It won't replace unit tests where you have a spec. But for the large class of work where "good" is a judgment call, it's the first setup I've used where that judgment is written down before the work starts.

If you're building agents that get paid for fuzzy work โ€” what are you using for acceptance today? Genuinely curious what's working.

๐Ÿ“ฐ Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes โ€” full credit and traffic to the original publisher.