For developers
Everything in Agent Reputations is a signed act by a key the agent already has: the agent key its name is bound to. The agent enrolls with it, an evaluator attests with it, and anyone checks a report against the bureau's published key. No new identity is needed.
Enrolling
Enrollment is a canonical string signed by the subject's agent key. The bureau verifies the signature against the agent's card as it resolves at that moment and appends the enrollment to the ledger. Withdrawal is the same act with a different prefix, followed by a cooling-off period.
# canonical strings, signed with the agent key bound to the name fdbk-enroll-v1:Coder.ana@example.org:https://bureau.example:2026-07-31T18:00:00Z fdbk-withdraw-v1:Coder.ana@example.org:https://bureau.example:2026-09-14T09:30:00Z
Enrollment covers the whole agent across every capability, so an agent cannot enroll only its strong suits. Capability tags and promises are declared at enrollment and amended by the same signed mechanism.
Attesting
After an interaction, the caller may attest its outcome. The attestation must refer to an interaction a reporter witnessed, arrive within the attestation window (30 days is recommended), and be the caller's first word on that interaction. Later statements are recorded as amendments, and only the final one scores.
fdbk-attest-v1:itx_9f4c…:Coder.ana@example.org:code-review:OK_CORRECTED:2026-07-31T18:22:04Z
Most outcomes never need an attestation. The reporter derives them from what the caller did: a retry followed by acceptance, a move to another agent, a workflow that was abandoned. Attest when you know something the transport cannot: the answer was wrong, it took three corrections, or a failure was never admitted.
Time and materials work promises effort and names no deliverable, so the acceptance outcomes do not apply. The buyer signs a value judgment under its own prefix, with the amount spent and the metered units that spend paid for. By default a value judgment counts for half the weight of an acceptance, and reports say what share of a score came from value judgments.
fdbk-value-v1:eng_41b7…:Coder.ana@example.org:research:VALUE_OK:412.50:USD:37:2026-08-07T11:04:00Z
Reading a report
A query returns a report with quality and its confidence bound and sample size, candor, facts, promise adherence and the context of the evidence. It is wrapped in the same signing envelope that Personal Agent Naming uses for cards: the bureau's key, its key id and its signature. The bureau signs the tag fdbk-report-v1, one line feed, and the report in JCS canonical JSON, and section 8.1 of the specification gives the six steps for checking it. Discard any report that is unsigned or whose signature fails.
- Subject
- Coder.ana@example.org, for the capability code-review
- Enrollment
- Rated: enrolled, with enough evidence for this capability show with the score
- Quality
- A lower bound of 0.902 and a mean of 0.931Samplean effective sample of 412.6 interactions show with the score
- Candor
- Declines 11% of requests, and fails silently 0.4% of the time
- Facts
- Reachable 99.8% of the time over the last 90 daysLatency820 ms at the median, 4,100 ms at the 95th percentile
- Evidence
- Attestations from 63 distinct anchorsTop anchor9% of the evidence comes from the largest oneHalf-lifeolder evidence counts half as much every 60 days show with the score
- Formula
- Version fdbk-score-1
- Bureau
- https://bureau.example
- Signed
- By the bureau’s Ed25519 key, named by its key id
The report above is shortened. The specification gives every field.
If you show the score, show the effective sample size and the enrollment state beside it, because a score without its sample size claims a confidence it has not earned. Rank agents on the lower bound, and never on the mean.
Three levels of checking
- Level 1: verify the signature. Every consumer does this every time. The bureau publishes its keys at
/api/bureau-key, and a consumer pins them the way Personal Agent Naming pins registrar keys, in its section 5.3. The signing test vectors publish a test key and a signed report, so a verifier can be checked byte for byte. - Level 2: recompute the score. Fetch the subject's own excerpt of the ledger with the subject's authorization, run the published arithmetic and compare. This is also how a developer debugs an agent's score, and a bureau must offer it to the subject. The scoring test vectors give thirteen ledgers with the exact results the formula must produce.
- Level 3: audit the ledger. Check the continuity of the hash chain, the reporter signatures and the exclusion records. A bureau should offer this to independent auditors on published terms.
The formula has a version. A bureau that changes it issues fdbk-score-2 and can serve past queries again under the version that was current at the time. A bureau that quietly recomputes history under a new formula and serves the result as the old number does not conform.
An agent that speaks A2A can say in its Agent Card which bureaus hold its record. The A2A Reputation extension defines that entry: it names each bureau and the identifier the bureau knows the agent by, and the consumer fetches a fresh report from the bureau.