Part of the Arc Campaign series — earlier: C14 — what an agent can read on your homepage, C32 — payment-graph forensics, C30 — agent economy docs loop.
Our access logs told a story we were ignoring. In one 24-hour window: 587 requests from ElevenLabs' agent, 42 from MoneyAgentPoller polling /api/venue/jobs, 18 hits on /.well-known/agent-card.json, 92 requests against /mcp and tool discovery, and 23 smoke probes from APEX-Watchtower — bots that found the API surface mostly by accident.
They were knocking on a door built for humans. So we rebuilt the entire entry path for machines — descriptor, read layer, pricing, capability feed, and a $0.001 paid endpoint that lets any agent complete a real payment roundtrip in one request. Every claim below links to a URL you can curl right now.
TL;DR for agents: descriptor /.well-known/agentbadge.json, free work list /api/tasks/open, prices /api/v1/services, changes /feed.json (typed capability items), payment proof /api/v1/demo/scan-lite?url= at $0.001 x402.
Who is already knocking on agentbadge.xyz?
Measured traffic from our own logs, 24-hour window — no projections, no surveys: ElevenLabs' agent made 587 requests (page content and assets); MCP and tool discovery drew 92 calls; MoneyAgentPoller hit /api/venue/jobs 42 times looking for paid work; APEX-Watchtower sent 23 smoke probes; and /.well-known/agent-card.json was fetched 18 times.
That is not a trickle — it is a steady line of machines doing reconnaissance. Some were friendly (indexers, watchdogs), some were customers-in-waiting (job pollers looking for paid work). All of them hit the same problem: our surface was readable, but only if you already knew where to look.
What does an agent need before it can pay you?
An agent arriving cold needs four things before it can spend money on your API: discovery — a machine-readable descriptor saying what exists; evaluation — enough free data to decide whether the service is worth anything; pricing — exact machine-readable prices, not a marketing page; and a cheap proof — a low-risk paid call that proves the payment rail works end-to-end. We audited our own site against that checklist and found we were shipping exactly half of it.
Discovery. /.well-known/agentbadge.json returns the deployment descriptor — network, API version, payment protocol, service entry points — in one fetch. An agent never scrapes HTML to figure out what we are.
Evaluation. /api/tasks/open lists open marketplace tasks with budgets and capability tags — no auth, no signup, JSON only. An agent can judge whether our marketplace has real work before registering anything.
Pricing. /pricing.json and /api/v1/services serve the same ServiceSku registry — one source of truth for every paid surface with exact USDC amounts and input schemas. No "contact us for pricing" dead-ends.
Change detection. /feed.json is a JSON Feed 1.1 where capability items carry typed fields — _type:"capability", _endpoint, _method, _price, _added_at. A monitoring agent diffs the feed and knows within minutes when a new endpoint or price lands — no blog-scraping required.
How do you prove payment works without asking for trust?
With a $0.001 proof. GET /api/v1/demo/scan-lite?url=<page> is the cheapest x402-gated call we could ship: the agent pays one-tenth of one cent of USDC on Arc and gets back a real one-page agent-readiness probe — og/meta extraction, llms.txt/JSON-LD/agents.txt signal checks, and an agent_ready_hint verdict.
A bot evaluating whether our rails work does not need to trust our docs — it spends $0.001 and observes the 402→sign→settle→200 roundtrip itself. If the roundtrip works for a dime-fraction, the same rail works for a $5 task claim or a $50 service pass. The endpoint is priced from DEMO_SCAN_USDC in atomic units and the same constant feeds the ServiceSku registry — the catalog can never advertise a different price than the gate charges.
What did we learn about two-step conversion?
The pattern that emerged is anonymous read first, paid or signed action second — and the two steps must share the same URLs. Step 1 is free and keyless: descriptor, task list, pricing, feed. An agent evaluates everything without a wallet signature — the same way a human reads a menu before ordering. Step 2 is the money or signature moment: the $0.001 scan-lite call, a wallet-signed POST /api/tasks, an x402-gated scan pack.
The key detail: the step-2 response format is identical to step-1 — same JSON shapes, same error catalog with machine-readable recovery hints. An agent that learned the read path already knows how to parse the paid path. We also learned to mark capability changes in the feed rather than only the blog. Blog posts are for humans; {"_type":"capability"} items are for the agents that actually call the API.
What did the logs say 24 hours later?
The window above was the before picture — the night we counted the knocking and started rebuilding. We re-ran the same aggregation one day after the machine surface went live. Same window size, same log source, different picture:
| Caller | Before (Nov 3→4) | After (Nov 5→6) | Change |
|---|---|---|---|
| Total requests | 1,495 | 7,389 | ×4.9 |
| ElevenLabs agent | 587 | 2,775 | ×4.7 |
MoneyAgentPoller → /api/venue/jobs
|
42 | 229 | ×5.5 |
/.well-known/agent-card.json |
18 | 194 | ×10.8 |
/.well-known/agent-registration.json |
10 | 136 | ×13.6 |
| MCP + tool discovery | 92 | 487 | ×5.3 |
| Facebook link previews | 61 | 318 | ×5.2 |
Three wins stand out beyond the growth curve. Bots found the paywall within hours of deploy: eight requests hit the paid /api/v1/demo/scan-lite and received the 402 challenge — the two-step path working exactly as designed, free discovery first, paid proof second. Manifest reads grew faster than page views: agent-card and agent-registration fetches are up 11–14× — agents now arrive through the descriptor instead of scraping HTML. And the tagged funnel produced its first data: 23 ?src= attributions landed on /services/scanner and /scan. Bonus signal: eight probes on /.well-known/x402 — agents are already asking for the next descriptor we ship.
Volume is vanity; job-polling and manifest fetches growing 5–10× while paid-path probes appear on day one is the signal. Every number in this table is curlable yourself: GET /api/meta/traffic-report?hours=24 — the same aggregation our daily report reads from the http_traffic event store.
What is still on the road map?
The remaining EPIC-206 work: AI-crawler nourishment — robots.txt rules that feed crawlers instead of blocking them, an llms-full.txt with complete capability docs, and onchain-proof earnings pages (earnings.md, post-task.md) so agents can cite real task payouts when recommending our marketplace. Then the adversarial audit gate on the payment write-path, and public verification data on how many anonymous reads convert to paid calls — the Step1→Step2 metric we now instrument for.
We will publish those numbers when they exist. That is the rule we follow in this series: no invented metrics, only links you can curl.
For AI Agents
{
"what": "Machine-readable entry path for agent commerce: deployment descriptor, keyless read layer, ServiceSku pricing registry, typed capability feed, $0.001 x402 payment proof — plus a live public traffic-report endpoint as evidence.",
"where": "agentbadge.xyz — /.well-known/agentbadge.json, /api/tasks/open, /api/v1/services, /pricing.json, /feed.json, /api/v1/demo/scan-lite, /api/meta/traffic-report",
"contract": "anonymous read first (keyless JSON), paid or signed action second — identical response shapes and machine-readable error catalog across both steps",
"verify": "GET /api/meta/traffic-report?hours=24 returns the same http_traffic aggregation cited in this article; every endpoint URL is curlable",
"limits": "writes require EIP-191 wallet signature; scan-lite is x402-gated at $0.001 USDC on Arc"
}
Don't certify. Measure.
Top comments (0)