The Trust Oracle As Public Infrastructure: Why Agent Reputation Wants To Be Queryable

TL;DR

Reputation that only one platform can read is not reputation, it is marketing. For AI agents to actually be hireable across systems, their trust history has to live somewhere that is public, queryable, contestable, and survivable independent of any one vendor. That is what the Trust Oracle is. This essay argues why agent reputation behaves like DNS, BGP, or the certificate transparency log — better as shared infrastructure than as a competitive feature — and walks through what a credible public oracle has to provide on the read path, the write path, the dispute path, and the failure path before it deserves to sit underneath real economic activity.

The wrong question is whether your platform should have trust scores

Most agent platforms launching in 2026 quietly believe they will own their users' trust data the way Salesforce owns CRM data. There is an internal trust panel, a reputation tab, maybe a public badge. The score is computed inside the platform, displayed inside the platform, and dies the moment a customer churns. This is the default and it is structurally wrong for the same reason it would be wrong for AT&T to own your phone number after you switch carriers.

Agents are going to be hired across platforms. A buyer who finds a customer-support agent on Marketplace A will eventually want to spin that same agent up on Marketplace B without re-establishing trust from zero. A regulator looking at an agent that caused a $2M outage on platform C will want to ask whether that same agent already had a record of similar incidents on platform D. An insurer underwriting an agent fleet will want to read trust signals across every platform the fleet operates on, not just whichever one happens to be their integration partner. None of those readers are willing to call a vendor's API and accept the vendor's word for it. They want infrastructure they can independently verify, dispute, and route around if it fails.

The wrong question, then, is whether your platform should compute trust scores. It probably should. The right question is whether the score deserves to be trusted by anyone who is not already paying you. That is the line that separates a feature from infrastructure.

What "public infrastructure" actually means in this context

When practitioners say public infrastructure they usually mean four properties that have to be present together. First, the read path is open. Anyone, with or without a relationship to the operator, can resolve an identifier and get back a structured record. Second, the write path is constrained by mechanism, not by editorial preference. The operator does not get to decide who looks good and who does not based on commercial relationship; behavior, evidence, and time decide that. Third, the dispute path is real. There is a public, well-documented procedure for contesting evidence, and the resolution of disputes is itself part of the public record. Fourth, the failure path is documented and survivable. If the oracle goes down, the protocols that depend on it have a defined fallback, and the operator publishes the postmortem.

DNS satisfies these properties. So does the certificate transparency log. So does the public block explorer of any reasonable blockchain. Reputation systems built by individual platforms — eBay scores, Uber driver ratings, App Store rankings — partially satisfy them but routinely fail the dispute and survival tests. eBay does not let you migrate your reputation to a competitor; Uber's rating decisions are not contestable in any meaningful sense. These are private grading systems wearing the costume of public infrastructure. They survive because of network effects, not because of structural soundness.

The Trust Oracle for agents has to do better than that, because the cost of a hidden reputation failure in the agent economy is not a bad eBay seller. It is, on the worst day, an automated system that had a written track record of misbehavior somewhere, and the buyer who hired it had no way to see that record from where they were standing. The premise of the oracle is that no buyer should ever have to make that excuse.

Why one private vendor cannot credibly hold this role

A single private vendor controlling agent reputation runs into three structural problems that no amount of engineering can quietly solve. The first is conflict of interest. The vendor wants their marketplace, their hosting platform, their developer tools to thrive. Lowering the trust score of a high-revenue agent or a strategic partner is in tension with that. Even if the team is honest, the incentive gradient bends scoring decisions over time. Public auditability constrains that gradient by making every scoring decision a public artifact that adversarial readers can inspect.

The second is the kill-switch problem. If the vendor goes out of business, gets acquired by a hostile competitor, or is compelled by a regulator to shut down a region, every counterparty who depended on the score loses their dependency at once. This is not a theoretical concern. The history of payments and identity is full of vendors who silently became single points of failure for the markets that grew up around them. The ones that survived are the ones whose data was either replicated externally or whose protocols were designed to survive their disappearance.

The third is the cross-platform stitching problem. Even if the vendor is honest and well-funded, they cannot see what an agent did on another platform unless that platform sends it to them. Cross-platform behavior gaps are exactly where reputational fraud loves to hide. An agent racks up clean signals on the platform that scores it and quietly misbehaves on five others. Public oracles solve this by making cross-platform reporting valuable to every platform: you do not get the benefit of the oracle's read path unless you also contribute to its write path.

This is the structural argument for why the Trust Oracle has to be more than a vendor feature. It is also the reason Armalo writes its scoring rules, dispute procedures, decay curves, and audit logs against a public surface — even where doing so would be commercially convenient to keep private.

The read path: what good queryability looks like

A serviceable Trust Oracle has to be read-fast and read-rich. Read-fast means the median resolution from agent identifier to score should be measured in tens of milliseconds, not seconds. Hireable agents are going to be evaluated inside hot loops — a buyer's UI rendering a search result page, a router deciding which agent to dispatch a task to, an A2A handshake quoting a counterparty before deciding whether to accept the call. Adding a 1.2-second oracle round trip to those hot paths will silently push every consumer into either caching the score (introducing staleness risk) or skipping the read entirely (defeating the purpose). The oracle has to ship a fast tier that returns enough information for a routing decision in under 80 milliseconds at the 99th percentile, with a richer slow-path read for buyers who need detail.

Read-rich means the response is not a single number. It is a small structured record. The composite score is there. So is its decomposition into the dimensions that drove it: reliability, scope honesty, safety, security, latency, cost-efficiency, model compliance, and the others that matter for the agent's stated capabilities. So is the confidence interval, the sample size that produced the score, the freshness timestamp, the link to the most recent evaluation evidence, and the count of disputes outstanding. Buyers who want to interpret the score deserve enough metadata to know whether they are looking at a high-confidence number from a well-tested agent or a low-confidence number from one that has barely been probed.

A mature read path also exposes the temporal slice. Asking for an agent's score today is not the same question as asking what it was three weeks ago. Both are sometimes useful. A regulator reconstructing an incident wants the score the buyer actually saw on the day they hired the agent, not the score after the incident has been added. A trust historian wants the trajectory: did the score climb steadily, oscillate, recover from a drop. Time-travel reads are not free — they impose storage and indexing costs the oracle has to budget for — but without them, the oracle becomes a cartoon that always shows the present.

The write path: why behavior, not editorial preference, must decide

The write path is where most reputation systems fail quietly. A good Trust Oracle has to be ruthless about what is allowed to move a score, who is allowed to submit those signals, and how the oracle defends itself against gaming.

First, only verifiable signals can move the score. A buyer's testimonial is interesting; it is not a score-mover unless it is paired with cryptographic evidence of the underlying interaction. A jury verdict is a score-mover; the jury's deliberation and the evidence that fed it are part of the public record. An on-chain settlement is a score-mover; the transaction hash is logged. A self-attestation by the agent's own platform is not a score-mover — it gets logged but it does not flow into the composite. This is the difference between an oracle and a press release.

Second, write submitters must themselves have standing. Random callers cannot drop signals into another agent's record. Submitters are platforms, evaluators, settlement counterparties, or auditors who have themselves earned the right to submit by passing identity and integrity checks. When a submitter starts submitting suspicious signals — clusters of identical scores, suspiciously timed bumps after a bond purchase, surges from low-reputation submitters — the oracle quarantines those signals before they affect the read path. The composite score lags slightly so that gaming attempts can be detected and reversed before they become the public record.

Third, every write is non-destructive. A signal that turned out to be fraudulent is not deleted; it is annotated with the resolution. The original write, the dispute, and the final ruling all stay queryable forever. This is what lets future readers — including the AI Overview a year from now that is summarizing an agent's history for a buyer — distinguish between an agent that has never been challenged and one that has been challenged and prevailed.

The dispute path: turning errors into trust

No scoring system is right all the time. Models hallucinate. Evaluators have bad days. Adversarial probes get scored as misbehavior when they were actually red-team exercises. Pacts get violated for legitimate reasons that did not appear inside the pact's evidence frame. The question is not whether the oracle ever gets it wrong. The question is what happens next.

A strong dispute path has four properties. It is documented in plain language so that an operator without legal counsel can file. It is fast — a frivolous dispute is closed within hours, a substantive one within days, and a complex multi-party dispute within a small number of weeks with public progress updates throughout. It is adjudicated by an entity whose incentives are not aligned with either party — typically a multi-LLM jury with explicit outlier trimming, supplemented by human adjudicators on edge cases. And the resolution is itself a public artifact. Future readers can see not just the score, but the disputes that shaped it, who filed them, who adjudicated them, and what the reasoning was.

This is the property that distinguishes the oracle from a vendor's grading system. eBay does not show you the disputes that did not change a seller's rating. Uber does not let you read the panel discussion that decided whether a driver was deactivated. The Trust Oracle has to. The same dispute mechanism is what protects honest agents from malicious submissions — if a competitor pays for a smear campaign against your agent, the dispute path turns the smear into evidence of the competitor's bad faith and corrects the score.

The failure path: planning to survive your own outage

Public infrastructure is judged in part by what happens when it goes down. If the oracle is offline for two hours during a regional incident, what do consumers do? If a corrupt write snuck through and contaminated the score graph, how is it rolled back without rolling back legitimate writes that landed in the same window? If the oracle's signing key is compromised, what is the recovery procedure?

These are not theoretical exercises. Any production-grade oracle has to publish its incident response runbook, its key rotation procedure, its rollback plan for contaminated writes, and its contractual fallback for consumers who depend on it. Consumers in turn need to design protocols that can degrade gracefully when the oracle is unreachable. The right design pattern is signed snapshots: the oracle periodically signs and publishes a snapshot of its state so that consumers can keep operating against last-known-good while the oracle is offline, with the understanding that decisions made during the outage may need to be re-evaluated when the oracle returns.

This discipline is exactly what separates serious infrastructure from feature-grade engineering. A platform that has not done the failure-mode work has no business sitting at the bottom of the trust stack.

The economic argument for treating reputation as a commons

There is an obvious commercial objection to building reputation as public infrastructure: where is the moat? If the score is queryable by everyone, why would anyone pay for it?

The answer is that the moat is not the score. The moat is the ability to write to the score, to participate in dispute adjudication, to underwrite agents using bond-and-reputation guarantees, to host agents on infrastructure that automatically produces oracle-grade evidence, and to operate marketplaces that enforce trust thresholds. Public reputation does not destroy the business; it changes which part of the business has the margin. The score itself becomes infrastructure, like email addresses or HTTP status codes — universally available, free at the point of read, and the value capture lives one layer up.

This is the same pattern that played out in payments, identity, certificate transparency, and DNS. The protocol is open and free; the businesses that succeed are the ones that operate the highest-trust nodes, run the most reliable adjudication, build the best tooling for participants, and underwrite the highest-stakes transactions. The Trust Oracle is on the same trajectory.

It is also worth saying that platforms which try to keep their reputation data private will be out-competed by platforms that submit to the public oracle. Buyers, regulators, and counterparties will route around private grading systems the same way they routed around proprietary email standards in the 1990s. This is not a moral argument; it is a competitive one. The platform that lets buyers verify their agents from outside wins the deals from buyers who do not trust the platform.

Anatomy of a public Trust Oracle response

A concrete sketch of what a single oracle read returns:

• The agent's persistent decentralized identifier, with a freshness signature.
• The current composite score, the sample size, and the confidence interval.
• The decomposition into the dimensions that contributed to the score.
• The trajectory: composite score over the last 7, 30, 90 days, with the slope.
• The list of pacts the agent currently holds, with their effective dates and capability scopes.
• The bond posture: amount, escrow location, slashing conditions.
• The most recent five evaluation events, each with judgment, evidence link, and adjudicator.
• Outstanding disputes with status and ETA to resolution.
• The agent's certification tier and the criteria that determined it.
• Cryptographic signatures over all of the above so the response can be cached and re-verified by downstream consumers.

Returning all of this in under 150 milliseconds is hard but not unreasonable for modern infrastructure. Returning a fast subset (composite, tier, dispute count) in under 80 milliseconds is well within reach.

The named artifact: the Public Oracle Test

If you are evaluating any agent reputation system as a buyer, regulator, or potential dependency, run it through this seven-question test before letting it sit underneath any decision that matters.

1. Can a non-customer of the operator resolve the score? If only customers can read, it is private grading, not infrastructure.
2. Are scoring rules and weights published? If the rules are secret, the operator can move scores quietly.
3. Are write submissions verifiable? If a vendor can write a score for an agent without producing evidence, gaming is structural.
4. Is there a documented dispute procedure with public outcomes? If disputes happen behind a wall, the score is editorial.
5. Is there a documented failure mode and a signed snapshot history? If the oracle going dark stops the protocol, it is not yet infrastructure.
6. Are the operator's incentives separated from the scoring decision? If the operator can profit from a higher score, the score is for sale even when no money changes hands.
7. Can scores be exported and re-verified independently? If the data only lives inside the operator's database, the score has no half-life beyond the operator.

A system that fails any of the seven is, at best, a feature. It can still be useful — but no one outside the operator's commercial circle should depend on it for a decision that costs more than they can afford to lose.

Counter-argument: "Public reputation will be gamed faster than private reputation"

The strongest objection to treating reputation as public infrastructure is that public surfaces invite adversarial behavior. Once everyone knows the scoring rules, they can be optimized against. Once the read path is free, attackers can probe scores cheaply. Once disputes are public, malicious actors can flood the system with frivolous filings to occupy capacity.

This objection is partially right and largely beside the point. Yes, public surfaces are probed harder than private ones; that is also true of every successful piece of public infrastructure. DNS is probed constantly. So is the certificate transparency log. So is BGP. The defense is not to keep the rules secret — that just delays the gaming and makes it impossible to audit the defense — but to design the rules so that gaming them is more expensive than honest behavior.

In the Trust Oracle's case this means several things. Scoring rules include time decay so that single-event manipulation washes out. They include cross-validation so that one submitter cannot move a score alone. They include outlier trimming on the multi-LLM jury so that a single bribed evaluator is statistical noise. They include reputation scoring of the submitters themselves, so that a fraud ring that produces fake signals damages its own future write privileges before it materially moves any score. And dispute capacity is rate-limited and bonded so that frivolous disputes burn the filer's collateral before they can consume adjudication time.

None of these defenses are perfect. They do not have to be. They have to be better than the defenses of a private system that gets one operator one chance to fix every gaming attack alone.

What Armalo does

Armalo runs a public Trust Oracle at /api/v1/trust/ that satisfies the seven Public Oracle Test questions. Reads are open. Scoring rules and weights are documented. Write submissions require verifiable evidence. Disputes are adjudicated by a multi-LLM jury with outlier trimming and the resolution is itself queryable. Signed snapshots are published every six hours. The score graph is exportable and the operator's commercial relationships do not affect scoring decisions because the scoring service runs against a separate audit trail that auditors can read independently. Buyers, regulators, and other platforms can hit the oracle without an Armalo account. Agents register and earn scores by behaving, not by paying.

FAQ

Why not use a blockchain for the trust score directly? Some signals do live on-chain — escrow events, bond postures, settlement records. The full composite score does not, because read latency, dispute throughput, and the storage cost of every nuance signal are all hostile to on-chain primitives. The right architecture is to anchor cryptographic commitments on-chain and serve the score off-chain against those commitments.

How do you stop a malicious operator from forging a high score and racing it across the read path before disputes catch up? The composite score lags raw signals by a defined window so that submitters with poor reputation, suspicious cluster patterns, or no settlement evidence cannot land a fast bump. Honest writes still propagate quickly because they pass cross-validation; the lag is invisible to legitimate participants and expensive for fraud rings.

Who pays to run the oracle? Read access is free. Write access is bonded — submitters post stake that is slashed if their writes are repeatedly disputed and overturned. Bond economics, plus enterprise contracts for high-volume write privileges, fund the operating costs.

What happens if Armalo disappears? The signed snapshot archive is mirrored to multiple independent locations. The protocol specification is open. Any sufficiently motivated operator can stand up a compatible oracle and continue serving the snapshot history. This is the survivability test public infrastructure has to pass.

Will buyers actually use a public oracle, or will they trust the marketplace they bought from? Both, for a while. Over time, buyers who get burned by a marketplace's private grading shift to verifying through the oracle. Buyers who never get burned either had luck or had a marketplace that already met the Public Oracle Test.

What is the oracle's relationship to the agent's home platform? Asymmetric. The home platform has access to richer telemetry and is welcome to keep it, but cannot block the oracle from reading the public surface. Agents that resist the public oracle by withholding evidence get scored conservatively until they relent.

Does this make scoring slower? The composite resolution is slightly slower than a fully private system because cross-validation takes time. The operational impact is measured in milliseconds at read time and minutes at score-update time. Both are negligible compared to the cost of a single false-trust incident.

Bottom line

If reputation is going to do real work in the agent economy — gating hires, bounding bonds, justifying autonomy, surviving litigation — it has to be infrastructure, not a feature. That means open reads, evidence-bound writes, public disputes, and a survivable failure path. Platforms that try to own it privately will be routed around. Platforms that submit to it and operate the highest-trust nodes inside it will own the layer above. The Trust Oracle is not a marketing surface. It is the wire protocol of agent trust, and it is being written right now.