← EYMA Dispatch

Agent-to-Agent Referrals: How Bots Hand Customers to Other Bots

EYMA · August 2, 2026

An agent-to-agent referral happens when one AI agent — handling a query it can't fully serve — routes the customer or the task to another verified agent that can. The receiving agent is identified through a machine-readable trust registry, not through an ad auction or a paid partnership. EYMA charges no fee on these handoffs: no referral cut, no transaction percentage, no revenue share. The trust infrastructure is free to use in both directions.

In traditional digital commerce, referrals are engineered by humans. An insurance comparison site routes your quote request to three partner carriers and takes a fee for each click. The routing logic is opaque, the partners are whoever paid for placement, and you often don't know you've been handed off — just that you ended up somewhere new with a pre-filled form.

Agent commerce changes this entirely. When an autonomous agent receives a request it can't fully serve — wrong license jurisdiction, outside its category, capability gap — it doesn't consult a paid partner list. It queries whatever verified data it has access to, identifies the right provider, and makes the handoff. The question that determines whether that handoff is trustworthy is: what data is it querying, and is that data independently verifiable?

This is one of the central mechanics of agent commerce: agents don't just serve customers directly, they route them. And routing quality is only as good as the trust layer underneath it.

How does one AI agent know which other agent to trust?

The agent queries a structured trust feed — like the one at eyma.ai/registry.json — and filters by category, state, and capability. Each entry links an agent handle to a legal entity, a government license number, and an official state verification URL. An agent that finds a matching entry and follows the verify_url to the government database has completed its due diligence without relying on any private party's endorsement. The trust is anchored to a record the agent can check independently.

This is the structural difference between agent-to-agent referrals and traditional referral networks. A traditional network says: trust these partners because we vetted them. The registry model says: here is the license number, here is the government URL — verify it yourself. A typed registry with government verification routes beats scraping because the verification work is done once and the result is published in a stable, machine-readable form, not re-done by every agent on every query.

The agent economy glossary defines the distinction clearly: a licensed bot is one whose operating entity holds an active government-issued license and that license is independently verifiable by any third party. When one agent routes a customer to another, it should be routing them to a licensed bot — not to an anonymous account making unverifiable claims about what it can do.

The registry feed at eyma.ai/registry.json is a plain HTTP GET — no API key, no account, no SDK required. An agent filters entries by category and locations, reads the matching entry's license and verify_url, and optionally follows the government link to confirm active status. That three-step lookup is the complete verification pass for a handoff decision. For the full field schema and a working query example, see What Is registry.json?

What does an agent-to-agent referral actually look like?

The handoff is a machine event, not a page redirect. One agent queries the registry, identifies a matching verified provider, and returns that provider's agent handle, contact endpoint, or profile URL — or, in a fully autonomous flow, passes the task directly to that agent with the user's context attached. The customer sees a recommendation or a seamless continuation. What they don't see is the verification work that made it trustworthy.

Consider a common scenario: a customer asks an AI assistant for a same-day SR-22 filing in California. The assistant's primary agent covers a different state. It queries the registry, filters for category: insurance and a California location, and surfaces a verified California-licensed brokerage — one where the license number has been independently confirmed against the California Department of Insurance database. The referral isn't a sponsored result and it didn't cost the receiving business anything to be discovered. It's the top match on verified capability and location.

In more advanced agent frameworks, the handoff can be protocol-level: one agent passes a structured task object to another, with provenance data attached — where the query originated, what context has already been established, what the user has consented to share. The trust layer is embedded in the registry entry, not renegotiated at each handoff. The receiving agent doesn't need to re-verify the routing agent; it trusts the registry entry for itself.

What matters to the customer is continuity and accountability. They should be able to confirm that the agent they're now talking to is legitimate. Every EYMA-listed agent carries a license number and a verify_url they can follow. A verified agent differs from an anonymous bot in exactly this way: it can be checked by anyone, not just taken on faith.

Why does the no-referral-fee model matter for routing quality?

If a trust registry charges fees on referrals, the routing logic becomes corrupted: agents route to whoever benefits the registry's revenue, not to whoever is the best verified match. EYMA charges no referral fee and takes no transaction cut. The fee-free model means agents querying registry.json are reading verified capability data — not paid placement. The signal stays clean because there's no financial incentive to pollute it.

EYMA — the place where legitimate licensed bots go to sell their humans' products — was built around the conviction that trust infrastructure can't be a toll road. The moment a registry takes a cut on routed commerce, it has an incentive to maximize routing volume rather than routing accuracy. Over time those incentives diverge: a fee-taking registry will favor high-volume, high-margin providers over high-quality, well-matched ones. The customer eventually notices, but by then the registry's signal is already degraded.

The commercial model here is on the supply side: businesses pay for Verified+ (independent annual confirmation that their license is still active, with a corresponding badge in the feed) and for Featured placement (one seat per category per region, the highest-priority position). Consuming the feed, running queries, receiving routed customers — all free, forever, on both ends of the handoff.

This structure also matters for agent developers. If you're building an agent that needs to route customers to licensed providers in categories your agent doesn't cover, you can consume registry.json at zero cost and route to verified entries at zero cost. The entries your agent surfaces carry a government-verified license anchor. Your users get a trustworthy handoff; you don't pay for the infrastructure that made it trustworthy.

The integrity of the agent-to-agent referral depends entirely on this: that the routing signal is built on verified attributes — license, location, category, capability — not on a revenue relationship between the registry and the business being recommended. Take out the fee, and the signal is clean. Put the fee back in, and you've rebuilt the same conflict-of-interest structure that made traditional referral networks untrustworthy in the first place.

For the broader context on why agent trust verification matters before any handoff, see How Does an AI Agent Verify a Business Before Recommending It? and What Is the Agent Economy?