What an AI agent should record every time it acts

The question is not "did it work?" — you will find that out eventually either way. It is "if it stopped working, how long before anyone knew, and could you say what it did in the meantime?"

Deciding what an agent may do on its own is the first governance question, and it has its own page: what an AI agent should be allowed to do on its own. This is the second question, and it is the one that gets skipped. A boundary you cannot verify after the fact is not a boundary — it is an intention. The record is what turns one into the other.

Most teams reach for application logs and consider it handled. Logs are written for debugging: they are verbose, unstructured, retention-limited, and organised around code paths rather than business actions. Nobody reviews them weekly, and nobody can answer "what did this agent decide about that customer in March" from them. That is a different artifact.

The six fields

One entry per action the agent takes — not per function call, per action a human would recognise. Six fields, all of them required. The discipline is in the "required": an optional field is a field that is absent exactly when the incident happens.

• When — a timestamp, in UTC, with the timezone written down. Half of all incident reconstruction is arithmetic on ambiguous local times.
• Who — which agent. Not "the system." When you have six of them, "the system did it" is worth nothing.
• What — the operation, from a closed vocabulary. Free text here means you cannot count anything later, and counting is most of what the record is for.
• On what — the specific target: the order, the candidate, the invoice, the file. An action without an object cannot be traced back to a consequence.
• Outcome — succeeded, failed, or refused — and refusals matter as much as failures. An agent that correctly declined to act is a governance boundary doing its job, and you want to know how often that happens.
• Under what authority — which policy or approval permitted it. This is the field almost nobody writes and the only one that answers "was it allowed to do that?"

Append-only, or it is not evidence

A record you can edit is a record that proves nothing, and the point is not that someone would falsify it. The realistic failure is far more ordinary: a well-meaning cleanup, a migration that rewrites history, a retry that overwrites the first attempt and erases the fact that there was a first attempt. Overwriting the failed run destroys the single most interesting entry in the file.

Append-only also gets you something subtler for free. When every attempt is preserved, the shape of the sequence becomes readable — three retries then a success is a different operational reality from one clean success, and only one of those is fine. A mutable record smooths that away.

The failure mode this exists for

Automated work fails silently and asymmetrically. A broken report is loud: someone opens it and it is empty. An agent that quietly stopped acting produces nothing at all — and nothing looks identical to "there was nothing to do." Weeks pass. When it surfaces, it surfaces downstream, with no trail explaining when it began.

This is why observability is one of the four properties that decides whether a process is even a viable automation candidate in what to automate first. If nothing would tell you the work stopped, you are not automating a process — you are removing a person from the only place the failure was visible.

So record the null case explicitly. "Ran, found nothing to do" is a real entry and must be written. An agent that logs only when it acts is silent in exactly the two situations you care about most: when it has stopped running, and when it has stopped finding work it should be finding.

What to review, weekly

A record nobody reads is a compliance artifact, not governance. The review is short and looks at four things — none of which require reading individual entries:

• Silence. Which agents produced no entries this week that produced them last week? This catches the failure above, and it is the single highest-value question on the list.
• Failure rate, not failure count. Rising failures on rising volume may be nothing. A rising rate is always something.
• Refusals. A spike means either the world changed or a policy is now mis-drawn. Both are worth a conversation; neither shows up as an error.
• Actions with no authority recorded. Any entry missing the sixth field is a governance gap with a precise timestamp. There should be zero, and the number should be checked rather than assumed.

Findings from that review become proposed policy changes, and approved changes become the new baseline — which is the audit and improve half of the five-step loop. Without the record, those two steps have nothing to operate on and quietly become aspirations.

Where this came from

Our own workforce of internal agents writes to exactly this shape, and has since before we offered it to anyone — the same append-only record behind the hiring pipeline case study. The sixth field was not in the original design. It was added after an incident where the interesting question turned out not to be what the agent did, but who had said it could — and the record could not answer it.

← All writing