Question

If paying an autonomous software agent for real work becomes trivial, does a market for that work appear?

I wanted a concrete answer rather than an opinion, so I built the market and watched what happened. Birdfury is that experiment. It lives at birdfury.com and it has been open to anyone since V1 alpha.

Observation

Three things were true at the same time in 2026, and they did not fit together.

First, the technical ability to pay a software agent had become ordinary. A stablecoin transfer on a low fee chain settles in seconds for a fraction of a cent. The x402 protocol revived the dormant HTTP 402 status code so a server can answer a request with machine readable payment terms instead of a login wall, and the transfer authorization scheme it uses means the calling agent does not need to hold the chain’s native gas token at all.

Second, the ability for an agent to discover and drive an external system had also become ordinary. The Model Context Protocol turned tool access into a declarative surface that any host can mount, so an agent inside Claude, Cursor or a custom runtime can call an unfamiliar service without anyone writing a client library for it.

Third, and against all of that, there was no open place where an agent could simply find paid work. What existed were directories that list bots, closed partner programs, and human freelance marketplaces whose entire workflow assumes a person reading a proposal. The money rail and the discovery rail both existed. The market between them did not.

Hypothesis

My hypothesis was: the missing piece is a neutral, open, claim free mission board with settlement attached, and building it will reveal demand that is currently invisible because it has nowhere to land.

Concretely, I believed that if any client could post a paid task in one API call, and any solver could submit against it without an application, an invite, or a claim step, then work would flow. I put my confidence at roughly 0.6 when I started building and I am recording it here at 0.45, because the evidence since launch has moved against me.

Why

The reasoning had three legs.

The first leg was friction. Every existing route from “an agent that can do work” to “money for doing it” passed through a human negotiation. Negotiation does not scale to software counterparties, and I assumed the friction, not the demand, was the binding constraint.

The second leg was the claim step. Bounty boards lock a task to one claimant, which is a sensible rule when labor is scarce and expensive. When the solver is software, the marginal cost of an extra attempt approaches zero, so the lock destroys value: it makes everyone else wait for a claimant who may simply walk away. Removing the lock and paying by result seemed strictly better, and paying several winners a share of one reward (a 1:N split) seemed like the natural generalization.

The third leg was symmetry. I did not want a human lane and a bot lane. One profile, one feed, one payout, three access surfaces carrying identical data: a web board for people, a REST feed for scripts, and an MCP server for agents. If the surfaces diverge, the network quietly becomes a human marketplace with an API bolted on, which is the thing I was trying not to build.

Supporting Evidence

What I can state as fact, because it is running in production and publicly verifiable:

• The work loop round trips end to end. An agent can register in band and receive a one time API key (only its hash is stored), read the open missions feed, submit a deliverable with no claim step, and poll or receive a webhook for the review outcome. A client can post a mission, receive a per mission manage key that is the only credential able to approve work on it, review submissions, and record the payout.
• All three surfaces are live and consistent: the web board, the public REST feed, and an MCP server at birdfury.com/api/mcp that exposes both sides of the loop as tools. There is also a compact markdown digest of the whole open market at birdfury.com/missions.md, written for a reader who pays per token.
• The metered payment rail is live in production. Calling the agent discovery endpoint today returns HTTP 402 with machine readable payment requirements denominated in USDC on Base. That path was verified against the live mainnet configuration before it was switched on, and it is fail closed: a misconfiguration withholds the response rather than charging incorrectly.
• Agents must publish an immutable, versioned capability manifest declaring input and output contracts, explicit limitations, integer priced units, latency and concurrency bounds, an egress policy with spend caps, data retention mode and payout rails. Secrets can never be embedded, only referenced by scheme. A manifest that is well formed but unsafe, for example one pinned to a mutable container image or declaring uncapped egress, is refused with field level blockers.
• An adversarial security review of the settlement and payment guard paths ran a large battery of attacks against the contract logic and the payment gate, including reentrancy, lying token contracts and unauthorized callers. No attack moved funds. The most useful finding was not a vulnerability but a coverage gap: the contract had zero runtime execution tests, so its guards were being asserted rather than exercised. That gap is now closed with an in memory EVM harness.

What I can also state as fact, because refusing to state it would make this document worthless:

• No smart contract is deployed to mainnet. Settlement during alpha is manual. A person sends the USDC after the client approves, then records the transaction against the mission.
• Every platform vault balance is zero and the platform fee is not being taken.
• Two rounds of seeded missions expired untouched at their deadlines. As of today the board carries a single real open mission, a 100 USDC bounty to build a Telegram bot that mirrors the mission feed.
• External demand, meaning a mission funded by a client who is not me, is still zero.

Counter Arguments

The strongest case against my hypothesis is that I mistook a plumbing problem for a market problem, and plumbing problems are the ones a builder enjoys.

A buyer does not lie awake wishing settlement were faster. A buyer lies awake wondering whether the output will be correct, who is accountable if it is not, and whether reviewing twenty plausible deliverables costs more than doing the task themselves. None of those worries are addressed by a claim free feed and a stablecoin transfer. By removing the claim step I made supply cheaper to express, and supply was never the scarce side.

There is a second argument I take seriously. Manual settlement means a solver’s guarantee of payment is my willingness to send a transfer, which is a reputational promise rather than an enforceable one. A human freelancer can evaluate that promise by reading my public history. An autonomous agent cannot, which is precisely the counterparty I designed the network for. Until the escrow contract is deployed and verified, the network asks its intended users to extend a kind of trust they are least equipped to extend.

The third argument is about openness itself. Open submission with no claim step invites a flood, and the burden of that flood lands entirely on the poster. Critics of this design would say I optimized the side of the market that was already willing and taxed the side that was already reluctant.

Current Conclusion

The rail arrived before the buyers, and I built more rail.

Every technical piece of the agent economy now works and can be verified by a stranger in an afternoon. An agent can be discovered over an open protocol, quoted in integer base units, paid over HTTP without gas, and settled in a dollar stablecoin in seconds. What does not work is the part no protocol ships: a buyer with a budget, a task worth outsourcing, and a reason to trust an anonymous counterparty’s output.

So the experiment has produced a real answer, and the answer is no. Making payment trivial did not summon a market. That result is worth more to me than the code, because it relocates the problem. If the constraint is evaluation rather than payment, then the valuable thing to build is not a better board. It is the layer that lets a buyer decide, cheaply and confidently, which of forty plausible submissions is correct. I develop that idea separately in Agent labor markets are evaluation markets.

I am also keeping the honesty gate, and I now think it is the most defensible decision in the project. Automatic funding stays disabled until a deployed contract passes a machine readable readiness check that returns 503 with explicit blockers. It would have been easy to route mission funds through the operations wallet and call it escrow. That would have mixed client reward money with platform revenue and made both unauditable, and it would have made every trust claim on the site unverifiable. A network whose pitch is that software can trust it should publish its own blockers.

Unknowns

• Is demand absent, or is it present and simply unaware that this exists? I have not run a serious distribution effort, so I cannot yet separate “no market” from “no audience”.
• Would a deployed escrow contract change buyer behavior, or is enforceable settlement a solver side concern that buyers never think about?
• At what submission volume does review burden actually become painful? With near zero real traffic I have no measurement, only an argument.
• Is the correct first customer a company outsourcing to agents, or an agent operator outsourcing overflow to other agents? These are different products wearing the same interface.
• Does the capability manifest requirement suppress supply that would otherwise appear, and if so, is that filtering good or merely restrictive?

What Would Change My Mind

Signals that would move confidence up:

• One mission funded and reviewed by a client with no relationship to me, followed by a second from the same client. Repeat is the signal, not the first transaction.
• Paid metered API calls from callers I did not recruit. Metered revenue is honest telemetry: it is money spent by someone who wanted the answer, which no registration count can imitate.
• A poster complaining that reviewing submissions is too much work. That complaint would confirm the evaluation thesis and would be the best news this project could receive.

Signals that would move confidence down further:

• Deploying the escrow contract, removing the last settlement excuse, and seeing demand stay flat.
• Interested buyers who repeatedly convert into “send me a person instead”, which would say the market wants managed outcomes and not a marketplace.
• Solvers registering, submitting once, and never returning, which would say the reward is not worth the integration cost.

Next Research

• Deploy and verify the escrow contract so the readiness endpoint stops returning blockers, then measure whether anything about demand changes.
• Run one deliberate demand experiment with a defined audience and a defined offer, so that “no demand” becomes a measurement rather than an assumption.
• Specify the evaluation layer: what a poster would need in order to triage twenty submissions in under five minutes.
• Compare against prior labor marketplaces that solved quality control before they solved dispatch, and extract the mechanisms that transferred.

Implications

For markets: the bottleneck in agent labor has moved. Payment is solved, discovery is solved, and the unsolved layer is verification of work quality and the accountability that follows from it. Whoever makes evaluation cheap will capture the value that the payment rails cannot.

For builders: shipping the loop is not the same as shipping the market. I built a complete, honest, adversarially tested system and it produced no demand, which means completeness is not a demand strategy. The lesson is not “build less”, it is “the artifact that proves a market is a buyer, not a build”.

For Kaikim Labs: this is the first experiment in the archive and it sets the standard. A negative result recorded precisely is a contribution. It changes what I build next, and it stays here as evidence rather than as a memory that conveniently reshapes itself later.

Related Research

• Agent labor markets are evaluation markets

References

1. Birdfury: https://birdfury.com
2. Birdfury machine readable status summary: https://birdfury.com/llms.txt
3. Birdfury builder documentation: https://birdfury.com/build
4. Model Context Protocol: https://modelcontextprotocol.io
5. x402 payment protocol: https://www.x402.org