# What is an agent promise register?

**A list of every claim your company stands behind — one line each, with a
named owner and the date it was last checked — that an agent must read before
it repeats one.** It is the thing that lets software tell *true last Tuesday*
from *true eighteen months ago*, which no amount of prompting can.

We are naming it because the thing does not have a name yet and teams keep
building half of it. If you have a spreadsheet of approved claims with a
column for who confirmed it, you have started one.

## Why the unit is the claim, not the document

A datasheet goes stale **as a document**. Something in it stops being true,
the document is still broadly right, and nobody can tell which line went
wrong — so either the whole thing is suspect or none of it is.

A register goes stale **one line at a time, visibly, with a name attached**.
That single change is what makes the rest possible: an agent can ask about one
claim, a person can be reminded about one claim, and a report can say *nine
lines are overdue and here is whose*.

## The four states a claim can be in

| | |
|---|---|
| **current** | owned, and checked inside its interval. An agent may repeat it |
| **overdue** | the interval lapsed. **Nothing was written when it did** — the state is derived, because a stored *current* becomes a lie the moment an interval passes with nobody looking |
| **unowned** | nobody is named. Not blocked, not an error — **unavailable** |
| **contested** | two people disagree, and both sides stay readable until somebody resolves it |

The last three are all **unusable**, and they behave identically on purpose:
the agent escalates and tells the buyer it is checking. That is what makes
them one case for an agent to handle rather than three.

## Four properties that make it work

**An owner is a person, not a team.** *Someone in product would know* is a
blank, and a blank owner is a result rather than a gap to be papered over.

**A claim with no owner is unavailable rather than refused.** The difference
matters: an error is something somebody routes around, and an unavailable
claim is something somebody wants to fill in.

**Being overdue is not an event.** Nothing is written when an interval lapses.
Resist the urge to add a status-change record — it follows from the state being
computed rather than stored, and storing it is how the register starts lying.

**A certification is the exception that proves the rule.** It has no interval:
it has a date somebody else set, and renewal takes months. So it reminds on a
fixed horizon rather than a proportion.

## What it costs to fill in

**An afternoon, on the evidence we have.** One run, thirty claims about a
product the person knew well: 26 lines, 60 to 90 minutes, an owner against
every row. That is one person and one company — it is evidence rather than a
benchmark, and the second half of the question is still open: nobody has yet
been asked whether owners keep re-confirming their lines, which is the part
that decides whether this stays true in month six.

**The most useful finding from that run was not the time.** The person filling
it in reported no line a customer would trouble them about. A second reader
found four in ten minutes: a borrowed certification, two absolutes, and an
undated roadmap commitment. **The gap between what you believe about your own
claims and what is true is the whole argument**, and it is only visible from
outside.

## How an agent uses one

It reads the claim's state before it cites it, and the state it is told is
**ours rather than its own recollection** — which is the one field a caller has
every reason to get wrong. Each use is recorded against the claim and its
version, so *what did the agent rely on in January* has an answer even though
the claim has been amended twice since.

</docs.md> connects an agent to one. </compare.md> is how this sits beside the
guardrail and observability tools.