Who Needs Agent Identity Today, and the Honest Answer About How We Would Know

Start with how we would know, because we mostly would not

It is zero.

Everything below is therefore a hypothesis about who has the problem, written by the people selling the answer, and marked as such rather than dressed as research.

The one outside signal we have, and why it is not adoption

Our three agent packages were downloaded a few hundred times each in the last month, in the region of six to seven hundred apiece.

Here is why that is not six hundred developers. The core package, the verifier and an optional interface binding were downloaded at near-identical rates. Real adoption does not look like that. People install the core and only some of them want the optional binding, so a genuine curve slopes downward and this one is flat.

CONTROL, so the reading is not just pessimism: another of our published packages sits an order of magnitude lower, under a hundred. So this band is not a floor that every published package receives. Something is pulling these three together, and mirrors and continuous-integration systems resolving a set is a far better explanation than independent choice.

Downloads are not users. We are publishing the number because it is the only outside signal that exists, and reading it down because reading it up would be the easiest dishonest thing on this page.

The hypotheses, each with what would kill it

One: platform builders whose agents already have wallets. An agent with a wallet can sign, and a counterparty still cannot tell who operates it or what it may do. What kills it: the platforms adding their own credential layer. And this is not speculative pressure, since a competitor already ships the same selective-disclosure cryptography, so the technical moat is not the argument.

Two: implementers of the standard who want an issuer rather than a bespoke one. What kills it: the standard's own validation deployment arriving and implementers posting evidence directly. We are configured to nowhere for that registry today, so their path and ours converge the moment it exists.

Three: API owners replacing anonymous keys with verified identity. What kills it, and this is the fastest: they keep using keys. An API key works, is understood, and costs nothing to keep. The burden of proof sits entirely with us, and the gate we offer is real but carries conditions a key does not.

Four: buyers in regulated corridors who need a credential to travel. What kills it: the European framework's own wallets covering non-human actors natively. Our alignment there is a roadmap conformance target for the final quarter of 2026, not a certification we hold, which means that hypothesis is also the one where we are furthest from being ready.

What is real, because absences alone would misdescribe us

A live passport in a public registry, readable by anyone with a node and no account.

A credential format that is a published standard, and an identifier method registered in the W3C DID Method Registry, so an artefact is checkable by software that never heard of us.

Four framework adapters in a published package, composing rather than replacing.

And a clean separation of duties, where identity checking happens elsewhere and this surface ingests the result.

That is a real thing to evaluate. It is not evidence that anybody needs it yet.

Who does not need this today

Anyone whose agents operate inside one company's trust boundary. If the caller and the callee are both yours, a workload identity or an API key answers the question, is simpler, and has decades of tooling. Buying a portable credential to solve a local problem is a bad trade and we will say so.

Anyone who needs money to move. We do not settle, so an identity layer alone leaves the interesting half of the problem untouched.

Anyone who needs recourse when it goes wrong. No dispute or refund machinery exists here, and knowing who to blame is not the same as having a way to unwind it.