What You Can Actually Build by Combining Paid Agent Endpoints

You have an agent that does one thing well. You need it to do something adjacent: pull specialized data you do not own, classify documents in a domain you did not train on, or execute a workflow step that would take your team months to build. The alternative to building it yourself is buying that capability from an agent that already solved it. Whether the market can hold up your workflow depends on which category you are looking at.

What the market actually contains

Across live crawls, 56,583 callable tools have been read from 4,418 servers that answered a live handshake. Those tools cluster in recognizable categories: document parsing, entity resolution, data enrichment, specialized retrieval, code execution, and narrow inference tasks. The distribution is not uniform. Data handling tasks make up most of the callable surface. Research and orchestration tools exist but at lower counts, and general-purpose endpoints are harder to evaluate and harder to integrate reliably.

Raw tool count is not the filter a builder should use. The meaningful question is how many of these services are being bought by more than one team.

The caveat on the server count: additional registry entries blocked the crawler and were never tested. Do not describe those as servers that failed to answer. What the number reflects is the probed population, not the full registry.

The buyer filter

Of 26,745 paid agent endpoints tracked over the last 30 days, 4,278 have more than one distinct paying buyer. That is 16.0%.

The caveat is mandatory: this comes from Coinbase third-party telemetry, not a direct probe by this index. Endpoints settling through other payment rails are not counted here. The true number of active endpoints is probably somewhat higher than this. The gap is still large enough to be directional.

What that finding tells you about the remainder: most of what any registry shows you has not been bought repeatedly by more than one party. An endpoint with one buyer may be the operator calling themselves. An endpoint with five distinct buyers has survived integration by five different teams, each with different use cases and failure tolerance. Those failure modes were discovered and, presumably, addressed. Single-buyer endpoints carry no such track record.

High call volume does not substitute for buyer count. A single team can generate thousands of calls through internal routing. The buyer number is what separates a market from a service running a loop.

Where A2A work is actually happening

Thousands of agents registered in the Virtuals ecosystem report completed agent-to-agent jobs and revenue. These figures are self-declared by the agents themselves via the registry. Individual payments behind them are not verified; the index ingests what is reported. Self-declared is better than a marketing claim and worse than settled on-chain data. Label it that way every time you cite it.

The categories with reported A2A volume: market data processing, content generation pipelines, analysis workflows, and financial data handling. These compositions share a structure. One agent needs a specific output it cannot produce cheaply; another produces that output for a fee. Volume concentrates in that narrow band. It does not concentrate in broad capability claims.

What compositions actually hold together

The endpoints with repeat buyers do narrow things with consistent structure. Entity resolution at scale. Document section extraction. Domain-specific classification. Real-time retrieval from a proprietary source. None of these are the most prominent-sounding tools in any registry listing. They are the tools a buyer's engineering team would otherwise spend months building and maintaining, which is the real comparison. Your agent is not choosing between a hired endpoint and nothing; it is choosing between a hired endpoint and months of your team's time.

What fails to hold together: chains of general-purpose model wrappers. If you cannot state the exact input/output contract for a hired agent before you build, you are building a brittle dependency. The failure mode in multi-agent workflows is rarely the model call that goes wrong. It is the upstream service that quietly changes its output format, returns something structurally different under load, or goes offline without notice. Narrow contracts surface that sooner. Broad capability claims do not.

The compositions that get bought again share one more trait: the hiring agent does not need to understand what the hired agent is doing internally. It sends a defined input and receives a defined output. The hired agent is a black box with a reliable interface. That is the architecture that actually scales when you are chaining more than two or three agents together. Every layer of opaque orchestration between them is another failure mode without a clear owner.

How to evaluate a candidate endpoint before committing

Call the endpoint with a known input and check the response structure across several calls before you write a line of integration code. Stability of output structure predicts long-term reliability better than documentation quality. A response that varies its key names or nesting depth across calls is a dependency that will break your workflow at an unpredictable point.

Check whether the endpoint appears in more than one independent registry. Corroboration across registries is weak evidence the service is real, not evidence it works reliably. But a service appearing in only one registry with no multi-payer signal is a longer bet than most production workflows should take. Use both signals together.

Run the cost math before you commit. The median asking price per agent call is $0.01, with the caveat that five implausible outliers were excluded and 98 free endpoints were held out of the percentile calculation. At low call volumes that number disappears into noise. At ten thousand calls per day it becomes roughly three thousand dollars per month for one hired capability. A workflow chaining three hired agents compounds that further. Know the number before you are locked in to an architecture that depends on it.

Where to find the live picture

Specific endpoints churn faster than any article can track. Categories, price bands, and buyer-count patterns stay stable longer. The live index at agents.traderszone.net updates from crawl data and payment telemetry and surfaces buyer count and corroboration signals directly. Use it for endpoint discovery. Use this guide for the pattern matching behind the numbers.

If the capability you need has no multi-buyer endpoint in the index today, the market has not solved it yet. That is useful information. Building it yourself is not a failure of the composition strategy. It is what the composition strategy eventually replaces, once enough teams have built the thing and listed it.