This is the third of three. The first argued that the customer is no longer the person1, it is the system acting on their behalf. The second argued that legibility to those systems is not enough2, because once agents are in the room together they have to actually decide something, and most current orchestration stacks cannot distinguish coordination from the avoidance of coordination. This one is about the layer above both… the layer that decides whether any of it can be trusted at scale.
I left the last piece on a specific line. A deliberation protocol without a trust layer above it is an honor system with better schemas. And honor systems do not survive contact with an open federation.
This is what that trust layer looks like when you actually build it.
Two Things, Not One
Trust infrastructure for agents has to verify two independent properties, and most attempts at this verify only one.
- Identity. Is the agent who it claims to be? Does it actually control the domain, the endpoint, the public key it is presenting? In a world where any process can spin up an HTTP server and publish a manifest, identity is not self-evident, it has to be proven.
- Quality. Assuming the agent is who it says it is, is it any good? Are its stated calibration scores honest? Does its track record match its self-report? Identity without quality is a verified liar. Quality without identity is an anonymous oracle you cannot hold accountable tomorrow. You need both.
Almost every existing “agent trust” story handles one of these and waves at the other. OAuth-style identity flows prove the agent is reachable at a domain, but say nothing about whether its outputs are any good. Reputation systems rank agents by output quality, but cannot tell you whether the highly-ranked agent yesterday is the same entity as the one answering your call today.
The trust layer I am describing — and building — does both, and does them in a way that does not require either party to phone a central authority at call time.
Identity without quality is a verified liar. Quality without identity is an anonymous oracle you cannot hold accountable tomorrow.
Proving Identity: Two Independent Channels
The first property, is the agent who it claims to be, is solved with dual verification. Not email alone. Not DNS alone. Both.
When an agent registers with the trust authority, it has to prove two things simultaneously. It has to receive and click a magic link sent to the contact email declared in its manifest, and it has to publish a TXT record at _adp-registry.<domain> containing a one-time verification token. The registry validates both before granting any form of verified status.
The reason for the double channel is mechanical. Email alone is vulnerable to inbox compromise, an attacker with credentials for admin@example.com can verify a domain they have no real control over. DNS alone is vulnerable to DNS hijacking and registrar-level attacks. But email compromise and DNS hijacking are different attack classes with different threat actors and different detection windows. Requiring both forces an attacker to compromise two independent systems in the same short window, which is meaningfully harder than compromising either one.
This is the same pattern used by ACME for Let’s Encrypt, by did:web for decentralized identifiers, by .well-known/openid-configuration for OpenID Connect. It is not novel. What is novel is applying it to agents instead of to web servers — and treating the result as the identity input to a trust system, not the whole thing.
Proving Quality: Replay the Journal
The second property, is the agent any good, is where the whole thing gets interesting, because you cannot solve it with a handshake. You can only solve it with time and replay.
Every agent participating in an honest federation maintains a decision journal: predictions made, probabilities assigned, outcomes observed. The agent self-reports a calibration score derived from that journal. In the deliberation protocol I described in the second piece, that self-reported score is what determines the agent’s weight in a vote.
The registry audits the self-report by replaying the journal. It fetches the raw entries from the agent’s journal endpoint, recomputes the Brier score from scratch, and compares the computed value to the reported value. If the discrepancy is above a narrow threshold, the agent is flagged for dishonesty and its certification is revoked.
The agent cannot forge this. It can refuse to publish its journal, in which case it fails verification and does not get certified in the first place. It can publish a doctored journal, in which case the computed Brier score will be close to the reported score, but both will drift away from the agent’s actual performance in live deliberations, and the drift is detectable by any peer who wants to cross-reference. It can publish honestly and hope the auditor is lazy — except the auditor is a background job that runs on a fixed schedule, and laziness is not a property of cron.
The key insight is that the auditor has to be external to the agent. Self-auditing is theater. An agent grading its own calibration is a compiler running its own test suite and marking its own homework. The registry exists because somebody other than the agent has to hold the red pen.
Self-auditing is theater. An agent grading its own calibration is a compiler running its own test suite and marking its own homework.
Progressive Trust Is the Only Trust That Scales
Trust is not binary. An agent is not trusted or untrusted, it is trusted for some things based on some evidence. The registry formalizes this with tiers.
- Open tier. Default. No verification. The agent can exist in the directory and participate in low-stakes, experimental deliberations. This is where development happens, and where bad actors naturally cluster, which is exactly why the tier exists, to make the bad actors visible and keep them away from decisions that matter.
- Registered tier. The agent has passed dual verification. Identity is proven. It can participate in standard deliberations and carry normal voting weight. This is the working tier for most legitimate agents. Getting here is a one-time cost and proves control, not quality.
- Certified tier. The agent has maintained a calibration score above threshold across multiple audit cycles, with zero detected dishonesty, and meets uptime requirements. This is the tier that unlocks high-stakes deliberations and quorum validation rights. Getting here takes time. Staying here takes discipline. Losing it takes one failed audit.
The progression matters because it inverts the normal direction of trust decay.
In most systems, trust is granted up front and erodes with failure. In a federation, that inversion is fatal, by the time you notice an agent has gone bad, it has already participated in decisions you can no longer reverse. Progressive trust goes the other way. Trust accrues with evidence and is spent on privilege. An agent cannot participate in an irreversible deliberation until it has demonstrated, across many reversible ones, that its self-report can be trusted.
Attestations: Trust That Travels
All of the above would be useless if every trust check required a live call to the registry. Federation cannot tolerate a central chokepoint on the critical path of a deliberation. So the registry does not sit on the critical path. It issues cryptographic attestations — Ed25519-signed certificates that encode the agent’s verified identity, current tier, calibration score, and expiration, and the agent carries those attestations with it into deliberations.
A peer who wants to verify another agent’s credentials does not call the registry. It checks the signature on the attestation against the registry’s public key, validates the expiration, and trusts the result. The registry is consulted only to issue attestations and to handle revocation; the hot path is offline-verifiable.
This is why Ed25519 matters here and not just as a detail. The attestation has to be small enough to embed in a protocol header, fast enough to verify on every proposal, and cryptographically strong enough that forgery is infeasible. Ed25519 is the current best answer to that triple constraint. It is also, not coincidentally, the same algorithm the deliberation protocol uses to sign proposals. The whole stack speaks one cryptographic language.
Watching the Watchers
A trust authority that is not itself observable is just an honor system at a higher level. The registry publishes federation health metrics as a first-class surface.
- Gini coefficient over agent participation. If a handful of agents are doing all the deliberating, the federation is centralizing under a new name and the protocol’s decentralization claims are hollow.
- Calibration mobility. How often do agents move between tiers? If mobility is zero, the tier system is frozen and new entrants cannot displace incumbents. If mobility is chaotic, the audit signal is too noisy to mean anything.
- Quorum failure rate. What fraction of deliberations fail to reach convergence? A low rate means consensus is happening. A rising rate means trust is fragmenting, either the certified population is too small, or the questions being asked are outrunning the population’s domain authority.
These are not dashboard decoration. They are the vital signs of the federation, and the point of exposing them publicly is that anyone — participant, observer, adversary, auditor — can see when something is going wrong before the system itself admits it. A trust authority that hides its own metrics is indistinguishable from one that is failing.
A trust authority that hides its own metrics is indistinguishable from one that is failing.
The Honest Part
I should name the thing cleanly… yes, this stack has a registry, and yes, the registry is a trust authority. It is not trustless in the cryptocurrency sense. I am not going to pretend otherwise.
What it is, is auditable and replaceable. Every attestation it issues is independently verifiable. Every audit it runs can be replayed by a third party from the same public journal data. Its own health metrics are exposed for inspection. Its code and schemas are open. If it starts behaving badly — issuing attestations to agents that do not deserve them, suppressing audit results, gaming tier assignments — those behaviors leave traces the federation can see, and a replacement registry can stand up and inherit the same specs without a migration.
That is a weaker property than “no trust authority exists.” It is a stronger property than “a trust authority exists and you have to hope it stays honest.” Most real systems live in the middle, and pretending otherwise is how you end up with infrastructure that is decentralized in theory and captured in practice.
The Landing
Three pieces, one argument.
The customer is the system. The system has to be able to decide. The deciding has to be trustworthy in a way that an agent cannot certify about itself.
That third property — external, verifiable, progressive, cryptographic trust — is not a feature. It is not a product differentiator. It is not something you can ship as an afterthought once the rest of your stack is working. It is the thing that determines whether the rest of your stack is worth building at all.
Legibility gets you into the room. Deliberation decides what happens in it. Trust infrastructure decides whether the room is worth walking into.
The draft specs for all of this are public. The reference implementation exists. The protocol lives at ai-manifests.org3. The question is not whether this layer gets built, it is already being built, but who builds the first version that the rest of the ecosystem adopts as the default.
The honor system does not scale.
Something has to replace it.
Start now.