agent-identity-continuity-reputation

name	agent-identity-continuity-reputation
description	Design durable agent identity and reputation systems for multi-agent / coding-agent fleets. Use when building or reviewing: agent memory/checkpoint that survives a process death, "persons not spawns" (role + continuity), registered outcome ledgers, Elo/Bradley-Terry/TrueSkill reputation for backends or agents, learned-outcome (bandit) routing, and agentic LLM-as-judge reviews. Covers the chain memory+checkpoint -> continuity -> durable person -> registered outcomes -> reputation -> a tradeable/hireable asset, and the failure modes that make each link theater (Sybil-reset, whitewashing, Goodhart, judge bias, cold start). Triggers: "agent reputation", "Elo for backends/agents", "agent identity that survives respawn", "outcome ledger", "learned routing", "resurrection with teeth", "episodic memory for agents", "credit assignment for agents".
license	Apache-2.0
allowed-tools	Read,Write,Edit,Bash,Grep,Glob
metadata	{"category":"Agent & Orchestration","tags":["agent-identity","reputation-systems","continuity","outcome-ledger","elo-trueskill","agent-coordination"],"provenance":{"kind":"first-party","owners":["port-daddy"]},"pairs-with":[{"skill":"episodic-memory-algorithms","reason":"Supplies the memory/checkpoint mechanics continuity is graded on; this skill decides what continuity must persist, that skill designs how."},{"skill":"mechanism-design-for-agent-labor","reason":"A labor market needs a trust signal to price; this skill defines the identity/reputation chain that feeds it, and where that chain silently breaks."},{"skill":"agent-labor-pricing-function","reason":"Pricing a hireable agent depends on a reputation input; this skill is the soundness check on that input before it is trusted by a pricing function."},{"skill":"multi-agent-coordination","reason":"Coordination protocols assume they are talking to the same durable party across restarts; this skill is the identity/continuity layer that assumption relies on."}],"io-contract":{"kind":"deliverable","consumes":["[Truncated]","[Truncated]"],"produces":["[Truncated]","[Truncated]"]}}

Agent Identity, Continuity & Reputation

A reputation system is only as real as the identity it keys on, and an identity is only durable if it carries continuity. This skill is the design discipline for the whole chain — and, crucially, for spotting where each link silently breaks.

The thesis (the through-line)

memory + checkpoint  →  continuity  →  a PERSON (not a spawn)  →  registered
outcomes  →  reputation (Elo/credit)  →  a hireable / sellable asset  →  a market

• A role is {obligation, capability, authority} — org-chart, not biography. "Cartographer" is a role; any spawn can fill it.
• A person is a role instance + continuity: memory, checkpoint, and an outcome history that survives the death of any one process/context window.
• No reputation without continuity (you cannot grade an identity that resets). No market without reputation (you cannot price what you cannot trust).

This mirrors the philosophical psychological-continuity criterion of personal identity (Locke 1689; Parfit, Reasons and Persons, 1984): a person at t2 is the same as at t1 iff there is an overlapping chain of memory/intention connections — continuity, which is transitive, not raw connectedness, which is not. An agent that keeps a memory stream but loses its outcome ledger is connected, not continuous.

Decision points (work them in order — earlier links gate later ones)

1. Is the identity non-forgeable? If an agent can pick its own id, every downstream reputation is "climbing an imaginary staircase." STOP and fix identity first. Mint an opaque id from the trusted substrate (daemon/server), bind it to a credential the agent cannot cheaply re-pick (signing key / body-lease). Self-asserted strings become display aliases only.

2. Does continuity actually persist the load-bearing state? Distinguish three things people conflate: (a) memory (episodic record of what happened), (b) checkpoint (restorable execution/belief state), (c) outcome ledger (append-only, externally-witnessed record of what was delivered). Reputation keys on (c). If your "resurrection" only passes a text note to a successor, you have weak continuity — say so; do not sell it as checkpointing.

3. Are outcomes registered against an oracle? An outcome must close against ground truth the agent cannot author: a merged SHA, a passing test id, a released claim, a satisfied monitor. Free-text "Result: done" is not an outcome. Add a that re-opens a random + risk-weighted fraction of cleared outcomes and re-runs the validation — the only defense against hollow-but-technically-met compliance.