Overview
The agent, working
Every stage below is read from committed database state, not from any in-process progress tracking. It stays correct even when the agent that started the work has died, which is the same property the protocol itself depends on.
go run ./cmd/demo -incidents 3 a full incident, memory compounding
go run ./cmd/demo -crash acts on the world, then dies before recording it
go run ./cmd/demo -reconcile verifies against ground truth and settles it
go run ./cmd/demo -escalate an action that cannot be attributed, then reconcile
Memory accumulating
Cumulative episodes recorded. Memory is the product, so its growth is the headline.
What proved each action happened
Every committed action cites external evidence. An unattributed action is the failure this project exists to prevent.
Incidents
Every incident the agent has seen. Select one to see its full trace.
| Status | Symptom | Outcome | Salience | Retention |
|---|
Anchor versus the standard architecture
Both implementations act on the same external API and are killed at the same
point by a real process exit. These are recorded measurements from cmd/compare,
not a description of what should happen.
Many agents, one action
Every agent proposes the identical action against the same incident, so all of them derive the same idempotency key. Exactly one may act. This runs for real against the cluster and removes everything it creates afterwards.
Action intents
The durable record, written before acting. A row here exists before the world changes.
| State | Action | Idem key | External ref | Attempts | Evidence |
|---|
Search the agent's memory
Runs a real cosine search against CockroachDB's distributed vector index, prefix-filtered by scope and status. Ranking components are shown separately so you can see why something was recalled.
Playbooks
Written by the agent after seeing an incident class repeatedly. Steps are derived from actions that actually committed, never generated.
| Title | Confidence | Provenance | Steps |
|---|
What did the agent believe?
Reads history through AS OF SYSTEM TIME over MVCC, not an application audit table. It can answer for rows nobody thought to log.
| Status | Symptom | Outcome | Salience |
|---|
Contention
crdb_internal.cluster_contention_events. Restricted by default in v26.2; the panel does not enable an unsafe setting silently.
| Table | Index | Events | Cumulative wait |
|---|
The claim
You cannot achieve exactly-once against a non-idempotent external API by retrying. Retry gets you at-least-once. You get exactly-once by pairing a durable intent log with an external verifier, and that intent log has to commit in the same transaction as the memory write, or the agent's history diverges from reality.
Why it matters. An agent scales a cluster. The connection drops. It never hears back. If it assumes failure and retries, it scales twice. If it assumes success and is wrong, its memory is a lie and every later decision inherits it.
What we do. Write the intent before acting. On recovery, ask the external system what actually happened, matching on an identifier derived from the intent itself, so the evidence is attributable to this call and not merely to a world that looks right. Then commit the intent, the world state and the memory in one serializable transaction.
Verdicts are three-valued. Applied, NotApplied, and Unknown. Unknown escalates to a human rather than guessing, because guessing either way is how an agent doubles an action or fabricates history.