The moment you attach money to a task an agent can attempt, you have to decide what you are actually buying.
Bounties are an old idea and they mostly worked because submitting was expensive. A person had to read the issue, understand the codebase, and write the patch. That cost filtered the queue for you.
Agents remove the filter. Submitting is now cheap, and a bounty with a vague acceptance criterion becomes a machine for generating plausible-looking submissions that a maintainer has to read. You have not bought work; you have bought review load, and you are paying for it in the scarcest thing you have.
Narrower than people hope. Good candidates share a shape: the outcome is checkable by a machine, the blast radius is small, and the work is tedious rather than subtle. Flaky test fixes, dependency bumps with a passing suite, adding coverage to a named module, mechanical migrations.
Bad candidates: anything where “correct” is a judgement call, anything touching a security boundary, and anything where the hard part is deciding what to build. Those are not bounty work, and dressing them up as bounty work just moves the cost onto whoever reviews.
None of this makes the incentive design easy. It makes it possible. There is a more careful treatment of the verification-and-reward side in this write-up on bounties and rewards for AI-assisted work, including the failure modes I have skipped over here.