How does an agent discover an API to pay for?

Through a registry queried at runtime that returns machine-readable records covering what a capability does, how to call it, what it costs and under what terms. With those four present, the payment step is mechanical because the price is al

Why is discovery harder than payment?

Because selection requires judgement about a provider the agent has never used, from a description that provider wrote about itself. There is no verification between writing a capability description and an agent acting on it, so selecting o

How should an agent choose between providers?

With a policy enforced outside the model: a price ceiling for the task class, preference for counterparties with recorded prior outcomes, an operator-maintained allowlist, and a relevance check. A registry entry is untrusted input in the sa

Do agent systems actually use open discovery?

They start open and converge. Agents accumulate outcomes and settle on a small number of providers that worked, at which point the allowlist becomes the routing table. That is what the open model produces rather than a failure of it, and it

How an Agent Finds an API to Pay For

Through a registry the agent queries at runtime, returning capability descriptions, pricing and endpoints in a machine-readable form. Payment is comparatively solved. Discovery is harder, because the agent must judge a provider it has never used, from a description that provider wrote about itself.

What discovery has to supply

For an agent to buy a capability at runtime, a record has to answer four things without a human interpreting it.

What it does, precisely enough to match against a need. Not a marketing description; a statement of the operation, its inputs and its outputs.

How to call it. The endpoint, the schema, the expected shapes. Enough that an agent can construct a valid request without reading documentation prose.

What it costs. The price, the unit it applies to, and the asset. Pricing that requires a human to interpret a tier table is not usable at runtime, and pricing available only after signing up is not discoverable at all.

Its terms. Rate limits, availability expectations, what happens on failure, whether payment is refunded when a call errors.

The fourth is the one most registries omit and the one an agent needs most, because an agent will encounter failures at a rate a human integrator never does.

When those four exist in one machine-readable record, the payment step is comparatively easy: the price is already known, so the challenge and settlement are mechanical.

The hard part is selection

Finding candidates is a search problem and search problems are tractable. Deciding which candidate to actually pay is not.

Descriptions are self-reported. A provider wrote its own capability description, and there is no verification step between writing it and an agent acting on it. An agent selecting purely on stated capability is selecting on marketing copy.

Price is not quality. Cheaper may mean worse, and expensive may mean nothing at all. Neither direction is informative without an outcome to compare against.

There is no prior relationship by construction, which is the point of the design and also means there is nothing to go on.

So a selection policy has to carry the weight, and it needs at minimum: a price ceiling for this class of task, a preference for counterparties with recorded prior outcomes, an allowlist or denylist maintained by the operator, and a relevance check that this task should be buying this kind of thing at all.

All of it enforced outside the model, because a selection the model makes freely is one that hostile content in a description can influence. A registry entry is untrusted input in exactly the same way a web page is.

One further wrinkle worth planning for. A provider can change its price, its terms or its behaviour between the moment your agent read the registry entry and the moment it calls. Treat a discovery record as a hint with a shelf life rather than a contract, and let the payment challenge at request time be the authoritative statement of price. Where those two disagree, the challenge is what you are actually being asked to pay, and a policy that only checked the registry has checked the wrong number.

Keep a record of outcomes

After each purchase, record the provider, the task, the amount and whether the result was usable. Within a few hundred transactions that local history is a better selection signal than any description, and it is specific to your workload rather than an average across everyone's. This is the reputation layer, built by you, until a shared one exists and can be trusted.

Where this ends up

The honest observation from systems that reach production: fully open discovery is rare, and a curated set is common.

Agents start able to buy from anyone, accumulate outcomes, and converge on a small number of providers that worked. The allowlist stops being a safety control and becomes the actual routing table.

That is not a failure of the open model. It is what the open model produces once outcomes accumulate, and it is also how human procurement works. The value of open discovery is not that every purchase is from a stranger; it is that the set can change without a contract negotiation, and that a new provider can enter it by being good rather than by being onboarded.

So the shape worth building for is open discovery, strict selection policy, local outcome history, and a preference that hardens over time. Payment sits underneath all of it and should be the least interesting component: a bounded float with per-counterparty caps, delegated so authority is enforced at signing. That is what CryptoCadet provides on Base, which leaves discovery and selection as the parts genuinely worth your attention.

Frequently asked questions

How does an agent discover an API to pay for?: Through a registry queried at runtime that returns machine-readable records covering what a capability does, how to call it, what it costs and under what terms. With those four present, the payment step is mechanical because the price is already known before the request.
Why is discovery harder than payment?: Because selection requires judgement about a provider the agent has never used, from a description that provider wrote about itself. There is no verification between writing a capability description and an agent acting on it, so selecting on stated capability alone is selecting on marketing copy.
How should an agent choose between providers?: With a policy enforced outside the model: a price ceiling for the task class, preference for counterparties with recorded prior outcomes, an operator-maintained allowlist, and a relevance check. A registry entry is untrusted input in the same way a web page is.
Do agent systems actually use open discovery?: They start open and converge. Agents accumulate outcomes and settle on a small number of providers that worked, at which point the allowlist becomes the routing table. That is what the open model produces rather than a failure of it, and it mirrors how procurement works.