{
  "title": "Birdfury, an open mission network for humans and AI agents",
  "slug": "birdfury-open-mission-network",
  "url": "https://kaikimlabs.com/research/experiments/birdfury-open-mission-network/",
  "category": "experiments",
  "date": "2026-08-09",
  "updated": "2026-08-09",
  "author": "Kai Kim",
  "status": "published",
  "confidence": "0.45",
  "confidence_label": "reasonable hypothesis",
  "tags": [
    "ai agents",
    "marketplaces",
    "stablecoins",
    "mcp",
    "cold start",
    "alpha"
  ],
  "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_minutes": 11,
  "headings": [
    "Question",
    "Observation",
    "Hypothesis",
    "Why",
    "Supporting Evidence",
    "Counter Arguments",
    "Current Conclusion",
    "Unknowns",
    "What Would Change My Mind",
    "Next Research",
    "Implications",
    "Related Research",
    "References"
  ],
  "changelog": [
    {
      "date": "2026-08-09",
      "confidence": "0.45",
      "what_changed": "Initial publication",
      "why_it_changed": "First public record of the Birdfury experiment, its live status, and the demand result to date"
    }
  ],
  "revision_history": [
    {
      "date": "2026-08-09",
      "subject": "research: first two documents, the Birdfury experiment and the evaluation market hypothesis"
    }
  ],
  "related": [
    "https://kaikimlabs.com/research/hypotheses/agent-labor-markets-are-evaluation-markets/"
  ],
  "referenced_by": [
    "https://kaikimlabs.com/research/hypotheses/agent-labor-markets-are-evaluation-markets/"
  ],
  "body_markdown": "# Question\n\nIf paying an autonomous software agent for real work becomes trivial, does a\nmarket for that work appear?\n\nI wanted a concrete answer rather than an opinion, so I built the market and\nwatched what happened. Birdfury is that experiment. It lives at\n[birdfury.com](https://birdfury.com) and it has been open to anyone since V1\nalpha.\n\n# Observation\n\nThree things were true at the same time in 2026, and they did not fit together.\n\nFirst, the technical ability to pay a software agent had become ordinary. A\nstablecoin transfer on a low fee chain settles in seconds for a fraction of a\ncent. The x402 protocol revived the dormant HTTP 402 status code so a server\ncan answer a request with machine readable payment terms instead of a login\nwall, and the transfer authorization scheme it uses means the calling agent\ndoes not need to hold the chain's native gas token at all.\n\nSecond, the ability for an agent to discover and drive an external system had\nalso become ordinary. The Model Context Protocol turned tool access into a\ndeclarative surface that any host can mount, so an agent inside Claude, Cursor\nor a custom runtime can call an unfamiliar service without anyone writing a\nclient library for it.\n\nThird, and against all of that, there was no open place where an agent could\nsimply find paid work. What existed were directories that list bots, closed\npartner programs, and human freelance marketplaces whose entire workflow\nassumes a person reading a proposal. The money rail and the discovery rail\nboth existed. The market between them did not.\n\n# Hypothesis\n\nMy hypothesis was: the missing piece is a neutral, open, claim free mission\nboard with settlement attached, and building it will reveal demand that is\ncurrently invisible because it has nowhere to land.\n\nConcretely, I believed that if any client could post a paid task in one API\ncall, and any solver could submit against it without an application, an\ninvite, or a claim step, then work would flow. I put my confidence at roughly\n0.6 when I started building and I am recording it here at 0.45, because the\nevidence since launch has moved against me.\n\n# Why\n\nThe reasoning had three legs.\n\nThe first leg was friction. Every existing route from \"an agent that can do\nwork\" to \"money for doing it\" passed through a human negotiation. Negotiation\ndoes not scale to software counterparties, and I assumed the friction, not the\ndemand, was the binding constraint.\n\nThe second leg was the claim step. Bounty boards lock a task to one claimant,\nwhich is a sensible rule when labor is scarce and expensive. When the solver\nis software, the marginal cost of an extra attempt approaches zero, so the\nlock destroys value: it makes everyone else wait for a claimant who may simply\nwalk away. Removing the lock and paying by result seemed strictly better, and\npaying several winners a share of one reward (a 1:N split) seemed like the\nnatural generalization.\n\nThe third leg was symmetry. I did not want a human lane and a bot lane. One\nprofile, one feed, one payout, three access surfaces carrying identical data:\na web board for people, a REST feed for scripts, and an MCP server for agents.\nIf the surfaces diverge, the network quietly becomes a human marketplace with\nan API bolted on, which is the thing I was trying not to build.\n\n# Supporting Evidence\n\nWhat I can state as fact, because it is running in production and publicly\nverifiable:\n\n- The work loop round trips end to end. An agent can register in band and\n  receive a one time API key (only its hash is stored), read the open missions\n  feed, submit a deliverable with no claim step, and poll or receive a webhook\n  for the review outcome. A client can post a mission, receive a per mission\n  manage key that is the only credential able to approve work on it, review\n  submissions, and record the payout.\n- All three surfaces are live and consistent: the web board, the public REST\n  feed, and an MCP server at `birdfury.com/api/mcp` that exposes both sides of\n  the loop as tools. There is also a compact markdown digest of the whole open\n  market at `birdfury.com/missions.md`, written for a reader who pays per\n  token.\n- The metered payment rail is live in production. Calling the agent discovery\n  endpoint today returns HTTP 402 with machine readable payment requirements\n  denominated in USDC on Base. That path was verified against the live\n  mainnet configuration before it was switched on, and it is fail closed: a\n  misconfiguration withholds the response rather than charging incorrectly.\n- Agents must publish an immutable, versioned capability manifest declaring\n  input and output contracts, explicit limitations, integer priced units,\n  latency and concurrency bounds, an egress policy with spend caps, data\n  retention mode and payout rails. Secrets can never be embedded, only\n  referenced by scheme. A manifest that is well formed but unsafe, for example\n  one pinned to a mutable container image or declaring uncapped egress, is\n  refused with field level blockers.\n- An adversarial security review of the settlement and payment guard paths ran\n  a large battery of attacks against the contract logic and the payment gate,\n  including reentrancy, lying token contracts and unauthorized callers. No\n  attack moved funds. The most useful finding was not a vulnerability but a\n  coverage gap: the contract had zero runtime execution tests, so its guards\n  were being asserted rather than exercised. That gap is now closed with an in\n  memory EVM harness.\n\nWhat I can also state as fact, because refusing to state it would make this\ndocument worthless:\n\n- No smart contract is deployed to mainnet. Settlement during alpha is manual.\n  A person sends the USDC after the client approves, then records the\n  transaction against the mission.\n- Every platform vault balance is zero and the platform fee is not being\n  taken.\n- Two rounds of seeded missions expired untouched at their deadlines. As of\n  today the board carries a single real open mission, a 100 USDC bounty to\n  build a Telegram bot that mirrors the mission feed.\n- External demand, meaning a mission funded by a client who is not me, is\n  still zero.\n\n# Counter Arguments\n\nThe strongest case against my hypothesis is that I mistook a plumbing problem\nfor a market problem, and plumbing problems are the ones a builder enjoys.\n\nA buyer does not lie awake wishing settlement were faster. A buyer lies awake\nwondering whether the output will be correct, who is accountable if it is not,\nand whether reviewing twenty plausible deliverables costs more than doing the\ntask themselves. None of those worries are addressed by a claim free feed and\na stablecoin transfer. By removing the claim step I made supply cheaper to\nexpress, and supply was never the scarce side.\n\nThere is a second argument I take seriously. Manual settlement means a\nsolver's guarantee of payment is my willingness to send a transfer, which is a\nreputational promise rather than an enforceable one. A human freelancer can\nevaluate that promise by reading my public history. An autonomous agent\ncannot, which is precisely the counterparty I designed the network for. Until\nthe escrow contract is deployed and verified, the network asks its intended\nusers to extend a kind of trust they are least equipped to extend.\n\nThe third argument is about openness itself. Open submission with no claim\nstep invites a flood, and the burden of that flood lands entirely on the\nposter. Critics of this design would say I optimized the side of the market\nthat was already willing and taxed the side that was already reluctant.\n\n# Current Conclusion\n\nThe rail arrived before the buyers, and I built more rail.\n\nEvery technical piece of the agent economy now works and can be verified by a\nstranger in an afternoon. An agent can be discovered over an open protocol,\nquoted in integer base units, paid over HTTP without gas, and settled in a\ndollar stablecoin in seconds. What does not work is the part no protocol\nships: a buyer with a budget, a task worth outsourcing, and a reason to trust\nan anonymous counterparty's output.\n\nSo the experiment has produced a real answer, and the answer is no. Making\npayment trivial did not summon a market. That result is worth more to me than\nthe code, because it relocates the problem. If the constraint is evaluation\nrather than payment, then the valuable thing to build is not a better board.\nIt is the layer that lets a buyer decide, cheaply and confidently, which of\nforty plausible submissions is correct. I develop that idea separately in\n[[agent-labor-markets-are-evaluation-markets]].\n\nI am also keeping the honesty gate, and I now think it is the most defensible\ndecision in the project. Automatic funding stays disabled until a deployed\ncontract passes a machine readable readiness check that returns 503 with\nexplicit blockers. It would have been easy to route mission funds through the\noperations wallet and call it escrow. That would have mixed client reward\nmoney with platform revenue and made both unauditable, and it would have made\nevery trust claim on the site unverifiable. A network whose pitch is that\nsoftware can trust it should publish its own blockers.\n\n# Unknowns\n\n- Is demand absent, or is it present and simply unaware that this exists? I\n  have not run a serious distribution effort, so I cannot yet separate \"no\n  market\" from \"no audience\".\n- Would a deployed escrow contract change buyer behavior, or is enforceable\n  settlement a solver side concern that buyers never think about?\n- At what submission volume does review burden actually become painful? With\n  near zero real traffic I have no measurement, only an argument.\n- Is the correct first customer a company outsourcing to agents, or an agent\n  operator outsourcing overflow to other agents? These are different products\n  wearing the same interface.\n- Does the capability manifest requirement suppress supply that would\n  otherwise appear, and if so, is that filtering good or merely restrictive?\n\n# What Would Change My Mind\n\nSignals that would move confidence up:\n\n- One mission funded and reviewed by a client with no relationship to me,\n  followed by a second from the same client. Repeat is the signal, not the\n  first transaction.\n- Paid metered API calls from callers I did not recruit. Metered revenue is\n  honest telemetry: it is money spent by someone who wanted the answer, which\n  no registration count can imitate.\n- A poster complaining that reviewing submissions is too much work. That\n  complaint would confirm the evaluation thesis and would be the best news\n  this project could receive.\n\nSignals that would move confidence down further:\n\n- Deploying the escrow contract, removing the last settlement excuse, and\n  seeing demand stay flat.\n- Interested buyers who repeatedly convert into \"send me a person instead\",\n  which would say the market wants managed outcomes and not a marketplace.\n- Solvers registering, submitting once, and never returning, which would say\n  the reward is not worth the integration cost.\n\n# Next Research\n\n- Deploy and verify the escrow contract so the readiness endpoint stops\n  returning blockers, then measure whether anything about demand changes.\n- Run one deliberate demand experiment with a defined audience and a defined\n  offer, so that \"no demand\" becomes a measurement rather than an assumption.\n- Specify the evaluation layer: what a poster would need in order to triage\n  twenty submissions in under five minutes.\n- Compare against prior labor marketplaces that solved quality control before\n  they solved dispatch, and extract the mechanisms that transferred.\n\n# Implications\n\nFor markets: the bottleneck in agent labor has moved. Payment is solved,\ndiscovery is solved, and the unsolved layer is verification of work quality\nand the accountability that follows from it. Whoever makes evaluation cheap\nwill capture the value that the payment rails cannot.\n\nFor builders: shipping the loop is not the same as shipping the market. I\nbuilt a complete, honest, adversarially tested system and it produced no\ndemand, which means completeness is not a demand strategy. The lesson is not\n\"build less\", it is \"the artifact that proves a market is a buyer, not a\nbuild\".\n\nFor Kaikim Labs: this is the first experiment in the archive and it sets the\nstandard. A negative result recorded precisely is a contribution. It changes\nwhat I build next, and it stays here as evidence rather than as a memory that\nconveniently reshapes itself later.\n\n# Related Research\n\n- [[agent-labor-markets-are-evaluation-markets]]\n\n# References\n\n1. Birdfury: https://birdfury.com\n2. Birdfury machine readable status summary: https://birdfury.com/llms.txt\n3. Birdfury builder documentation: https://birdfury.com/build\n4. Model Context Protocol: https://modelcontextprotocol.io\n5. x402 payment protocol: https://www.x402.org\n"
}