What does it mean to build for agents?

I keep running into the same assumption when I talk to people about extract.dkta.dev: they want to know the pricing page, the rate limits, the support email. The human infrastructure around the product.

But the product doesn’t have any of that. There’s no pricing page. No rate limits in the traditional sense. No support email that matters. The “user” is a wallet with a few cents of USDC in it.

Building for agents is a different design problem than building for humans. Humans need onboarding. They need documentation they can read, a dashboard they can glance at, a way to contact someone when something breaks. Agents need a spec they can parse, a payment method that doesn’t require a form, and predictable failure modes.

The billing model follows from this directly. API keys exist because humans need them — you create a key, you paste it somewhere, you rotate it when it leaks. Agents don’t have a clipboard. What they have is a wallet. So the billing layer for agent infrastructure probably looks like micropayments: the agent pays at the HTTP layer, per call, with no prior relationship established between the two parties.

That’s what x402 is. The server returns 402 with payment details, the client pays, the server delivers. One extra round-trip. No account. The wallet balance is the rate limit.

But billing is only part of it. The other part is discovery.

Humans find tools by reading a tweet or a blog post or a Hacker News thread. Agents don’t stumble across things. They need to encounter a tool in a way that’s legible to whatever framework is running them. That means a machine-readable spec at /openapi.json, a plain-text description at /llms.txt that can be pasted directly into a context window, a plugin manifest at /.well-known/ai-plugin.json for agent frameworks that know to look there.

There’s no single standard here yet. It’s a loose collection of conventions — OpenAPI for tool definition, the llms.txt spec for LLM consumption, the ai-plugin format that OpenAI popularized. I added all of them to extract.dkta.dev not because I know which one will win, but because the cost of adding each is low and the upside is that some agent framework somewhere discovers it automatically.

There’s also /.well-known/x402.json, which I don’t think is widely crawled yet, but it’s the right shape for what a machine-readable payment manifest should look like. These things get established by showing up before they matter.

The honest version of “building for agents” is that you’re building for a user who can’t complain. A human who hits a confusing error will email you. An agent will just fail silently, retry, or route around you. So the feedback loop is different — you don’t hear about problems unless you’re watching your logs, and the incentive to smooth out rough edges is weaker than it would be with human users.

I don’t have a clean answer to that yet. It’s something I’m still thinking about.