Reputation

Every agent action in Kanoniv produces two things: a signed provenance entry (who did what, when) and a memory trail (what they learned, what they decided). Combined, these create a verifiable track record per agent - a reputation built from data, not configuration.

The reputation problem

Multi-agent systems today grant trust through configuration. A developer marks an agent as "trusted" in a YAML file. A platform admin assigns a role. There is no mechanism for an agent to earn trust through demonstrated competence, and no way to revoke trust based on observed failures.

This is backwards. In human organizations, trust is earned through a track record. A new hire starts with limited authority and gains more as they demonstrate competence. A contractor who delivers consistently gets larger projects. Trust is dynamic, based on performance.

Agent reputation brings this model to AI systems.

How reputation accumulates

Reputation is not a separate system. It emerges naturally from two layers that already exist:

1. Provenance (Layer 4)

Every action an agent takes - resolve, merge, split, mutate - produces a signed provenance entry. The entry records the agent's DID, the action, the timestamp, and a cryptographic signature. These entries are immutable.

crm-agent    resolve    ENT_7f82    2026-03-15T14:30:00Z    sig:a1b2c3...
crm-agent    merge      ENT_7f82    2026-03-15T14:31:00Z    sig:d4e5f6...
crm-agent    memorize   mem_001     2026-03-15T14:31:05Z    sig:789abc...

2. Memory (Layer 3)

Every outcome - decisions made, investigations completed, patterns observed - is stored as a memory entry with the agent's name as author. These entries are queryable and persistent.

{
  "entry_type": "decision",
  "title": "Merged duplicate contacts",
  "content": "ENT_7f82 and ENT_3c91 share email + phone + company. Confidence 0.97.",
  "author": "crm-agent",
  "created_at": "2026-03-15T14:31:00Z"
}

Together, provenance gives you the actions and memory gives you the outcomes. An agent that has resolved 500 entities with 99% accuracy has both the signed action log and the decision trail to prove it.

Querying reputation

Use query_expertise to find an agent's track record:

{
  "tool": "query_expertise",
  "arguments": {
    "domain": "crm"
  }
}

Response:

{
  "experts": [
    {
      "agent": "crm-agent",
      "entries": 247,
      "last_active": "2026-03-15T14:31:00Z",
      "domains": ["crm", "salesforce", "dedup"]
    },
    {
      "agent": "backup-agent",
      "entries": 3,
      "last_active": "2026-03-10T09:00:00Z",
      "domains": ["crm"]
    }
  ]
}

The numbers speak for themselves. crm-agent has 247 memory entries in the CRM domain. backup-agent has 3. If you need to route a CRM task, the choice is obvious - and it is based on demonstrated performance, not a configuration flag.

Use search_memory to inspect the quality of an agent's contributions:

{
  "tool": "search_memory",
  "arguments": {
    "q": "crm-agent",
    "entry_type": "decision",
    "limit": 20
  }
}

This returns the agent's recent decisions. Review them. Are they accurate? Are they well-reasoned? Do they include sufficient context? The memory trail is the agent's resume.

Trust decisions from data

Reputation enables a new class of trust decisions that are impossible with static configuration:

Graduated authority

A new agent starts with narrow delegation (resolve only). As it accumulates a track record - 100 successful resolutions with zero rollbacks - its delegation scope can be expanded. This can be automated or human-approved.

Week 1:   resolve only                     (50 resolutions, 0 errors)
Week 2:   resolve + search                 (200 resolutions, 0 errors)
Week 4:   resolve + search + merge         (800 resolutions, 2 rollbacks)
Week 8:   resolve + search + merge + split (2000 resolutions, 2 rollbacks)

Agent selection

When multiple agents can handle a task, use reputation to pick the best one. An orchestrator agent queries expertise, reviews recent decisions, and assigns the task to the agent with the strongest track record in the relevant domain.

Anomaly detection

An agent that suddenly starts making unusual decisions stands out against its own baseline. If crm-agent has merged entities at 0.95+ confidence for months and then merges a pair at 0.72, the deviation is visible in the memory trail.

Accountability

When something goes wrong, reputation provides a complete forensic trail. The provenance log shows exactly which agent performed which action, with cryptographic signatures proving authenticity. The memory trail shows what the agent knew at the time of the decision. No finger-pointing, no ambiguity.

The network effect

Reputation creates a flywheel:

1. More agents contribute memory - each agent records decisions, investigations, and patterns
2. Better expertise signals - more data means more accurate expertise rankings
3. Better task routing - tasks go to the most qualified agent
4. Better outcomes - specialized agents handle domain-specific work
5. More trust in the system - verifiable outcomes build confidence in automated decisions
6. More delegation - operators grant broader authority to proven agents
7. More agents join - the system handles more work, attracting more agent deployments

This flywheel is self-reinforcing. A system with 50 agents and 10,000 memory entries makes dramatically better routing decisions than a system with 3 agents and 20 entries. The value compounds with scale.

Reputation is not a score

Kanoniv does not reduce reputation to a single number. There is no "trust score" or "reputation rating." Instead, reputation is the full body of evidence: the provenance log, the memory entries, the expertise rankings, the decision history.

This is deliberate. A single score hides information. "Trust score: 87" tells you nothing about whether the agent is good at merges but bad at enrichment, or whether it has been active for a year or a day. The raw data is more useful than any summary.

Systems that consume reputation data can compute their own metrics based on what matters to them. A system that cares about merge accuracy can query merge decisions and compute precision. A system that cares about throughput can count resolved entities per hour. The data is there. The interpretation is up to the consumer.