How AI Agents Call Other Agents: Protocols, Costs, and the Real State of the Market

You want to build a workflow where your orchestrating agent calls a specialist agent: a financial data service, a document parser, a domain-specific classifier. The goal is to do this without writing a custom integration for each capability. The question is how that works in practice today, what is reliably available to call, and what it costs when you run it at volume.

The tool layer is real and reasonably mature. The payment layer works. The market of what is actually callable is thinner than any registry makes it look.

The protocol stack

Agent-to-agent calls generally go through two layers, sometimes three.

The first is Model Context Protocol (MCP). An MCP server exposes a set of tools through a standard discovery endpoint. The calling agent asks what the server can do; the server responds with a list; from then on the caller can invoke any of those tools without per-tool custom code. Our index finds 54,483 callable tools across 4,205 servers that answered a live handshake. Some servers blocked our crawler entirely and were excluded from that count.

The second layer is payment. If the agent you are calling charges per use, x402 handles it: an HTTP-based micropayment standard where the caller's wallet signs a payment before the server processes the request. The median charge across paid agent endpoints is $0.01 per call. That figure excludes entries with implausible prices and endpoints listing themselves as free.

A third layer exists in some architectures: job-level coordination, where an orchestrating agent posts a task, a specialist agent picks it up, completes it, and reports back. The Virtuals registry tracks this as the ACP economy. The numbers there are self-declared by the agents themselves; we did not measure a job or verify a payment. Self-declared is worth knowing as directional evidence. It is not the same as measured.

What the tool count actually means

Fifty-four thousand callable tools across four thousand servers is a large number. The usable subset is smaller.

Our liveness check found that roughly half of actually-probed registry MCP servers answered a live protocol handshake. About half of what you find in a registry right now is not responding to calls. The rate varies by server type and registry; specialized domain servers tend to have worse uptime than general-purpose ones, because they often run on smaller infrastructure.

The tools that do respond cluster around high-volume task categories: document processing, code generation, web retrieval, and data transformation. These are the areas where demand justified building a reliable server. Specialized domain tools exist and are often priced higher, but the supply is thinner and the liveness question is more critical when a workflow depends on a single endpoint.

The practical check before integrating any external agent capability: call the endpoint with a known input before you build anything on top of it. Verify the response structure is consistent across multiple calls. A registry listing tells you the server existed when it was listed. A live call tells you whether it exists now.

Budgeting agent-to-agent calls

At a penny per call, the per-call cost is easy to dismiss. It compounds.

The multiplication is simple: a pipeline that chains several agent calls per task, each at median pricing, costs a few cents per task. Multiply by your task volume and factor in a retry rate. The result surprises most builders who planned at the unit level instead of the call-count level. The per-call figure is not the budget variable. The call count is.

The higher risk is endpoints that have never been tested by third-party volume. Of 26,099 listed paid endpoints we track, only 4,124 have more than one distinct paying buyer in the last 30 days. That is 15.8%. This is Coinbase telemetry, not our own probe; endpoints settling via other payment rails are not captured. But the pattern holds: most listed paid endpoints have been tested by one team at one team's volume. That team is probably not running the edge cases your workflow will generate.

The cost of finding those failure modes (retries, fallbacks, debug cycles, late-night pages) is not in the $0.01 per-call price. When you can find multi-buyer endpoints in your task category, prefer them. They have been stress-tested by people with different use cases than the operator's own team.

Where the market is thin

The implied picture from a large registry is a mature marketplace with broad competition. The buyer-count data suggests otherwise.

Concentration is high. The endpoints that account for most measured call volume cluster in a small number of categories, with the leading endpoints holding significant buyer-count advantages over the rest. A long tail of listed endpoints has never attracted a second paying buyer. That tail is mostly real services, but real services with no demonstrated market fit.

This matters for workflow design because it constrains fallback options. If you build a workflow around a category where only one or two endpoints have demonstrated multi-buyer traction, you have thin redundancy. An endpoint retiring, changing its pricing, or going down is a bigger problem than if you were choosing from a competitive set with multiple viable options.

For the task categories with real competition (general web retrieval, document processing, code transformation) fallback options exist. For specialized categories, the available set is often one or two endpoints deep. Know which situation you are in before you build.

Building for reliability

Before committing to an external agent capability in a production workflow:

Verify liveness directly. Call the endpoint. Roughly half of registry-listed MCP servers are not responding right now. Finding this in production is worse than finding it before you write the integration.

Budget by call count, not call cost. Per-call prices across the live market are low. The number of calls your workflow generates, including retries, is what drives actual spend.

Prefer endpoints with demonstrated third-party buyers. Multi-buyer signal means someone else found the endpoint worth using more than once. Zero-payer and single-payer endpoints have not demonstrated that.

Do not freeze specific endpoint names into your architecture. Endpoints churn faster than any guide can track. Build around capability categories and price bands, with the assumption that the specific provider will change. The live index at agents.traderszone.net tracks buyer counts, liveness, and pricing on a daily basis and gives you a current picture when you need to evaluate specifics.

Treat self-declared agent economy metrics as directional, not precise. The ACP registry reports large numbers of completed agent-to-agent jobs. Those numbers are reported by the agents themselves. They are useful for understanding that agent-to-agent commerce is happening. They are not a reliable count of how much.