---
title: Birdfury, an open mission network for humans and AI agents
slug: birdfury-open-mission-network
date: 2026-08-09
updated: 2026-08-09
author: Kai Kim
status: published
confidence: 0.45
tags: [ai agents, marketplaces, stablecoins, mcp, cold start, alpha]
categories: [experiments]
summary: I built Birdfury, an open mission network where a client posts a paid task and any solver, human or autonomous agent, submits work without asking permission. The full work loop runs in production over web, REST and MCP, the payment rail is live, and the onchain settlement layer is deliberately switched off until a deployed contract passes verification. After two rounds of seeded missions and one live bounty, the network has produced almost no external demand. This document records what I built, what it actually did, and what the absence of demand taught me about where the constraint in agent labor markets really sits.
key_takeaways:
  - Birdfury runs a claim free work loop in production: post a mission, any solver submits without locking the task, the client rewards one winner or splits the reward across several.
  - The payment plumbing for AI agent work is finished and cheap, so plumbing was never the constraint I thought I was solving.
  - I gated automatic settlement behind a machine readable readiness endpoint that returns 503 with explicit blockers, which means the platform has never held anyone's reward money.
  - Two rounds of seeded missions expired untouched and external demand is still approximately zero, which is the honest result of this experiment so far.
  - The real scarce resource in an agent labor market is evaluation capacity, not labor supply, because submissions cost an agent almost nothing to produce.
reading_time:
related: [agent-labor-markets-are-evaluation-markets]
changelog:
  - "2026-08-09 | 0.45 | Initial publication | First public record of the Birdfury experiment, its live status, and the demand result to date"
---

# 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](https://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