Can a failure to write that record stop it from working?
The moment arrives when somebody on the vendor’s side says the word audit. It comes as reassurance, near the end, with a screenshot of a tidy list. Ask them to leave the list on the screen. Then ask what happens on the morning that list cannot be written to: does the agent carry on and note the gap, or does it stop and wait for the storage to come back? The answer decides what your evidence is worth.
Two properties of a usable ledger
A record of what an agent did is useful only if two things hold. The first is that entries are added and never altered. In the Cabinet, ArkOne’s reference design for an executive agent, the Record is append only: a correction is a new line and the mistaken one still stands, which is what makes it evidence rather than notes somebody has been tidying.
The second property is what this question is about. The Record never blocks a turn. If the storage behind it is unreachable, the failure is written down elsewhere and the meeting carries on. The Register, the standing page of every setting in the design, states the cost alongside it: a minute of lost ledger is a minute in which the evidence is a line saying the evidence is missing.
Put the two together and the shape is this. Writing either happens or is missed visibly, and it never stops the work, because a room that falls silent whenever a database is slow is a room somebody quietly switches the logging off in.
The morning the storage is slow
Suppose the vendor agrees to break the logging in front of you, in a demonstration invented for the exercise. The agent is halfway through a supplier renewal, and one write fails.
| What the room does | What you should see | What it means if you do not |
|---|---|---|
| The write fails | The work continues; the reply is still composed | A halted run means your evidence layer can stop your business |
| A minute later | A line elsewhere naming the entry that could not be written, and when | The gap is invisible, so a missing hour reads as a quiet hour |
| The storage returns | The gap is still marked; nothing is back-filled to look complete | Back-filling produces a record that is tidy and untrue |
| You ask for a correction | A new entry stating the correction, the old one intact above it | Editing in place means anyone with access can rewrite yesterday |
Exhibit 1. Illustrative. One audit write fails mid-demonstration, and the four places a room shows you what it did about it.
The second row is the whole question in one line. A system that works through a logging fault and says nothing hands you a record with silent holes in it, and the holes sit exactly where the trouble was, because trouble is what breaks things.
The third row catches something subtler. A vendor proud of completeness may buffer the failed writes and put them back once the storage recovers, producing a ledger with no gap in it at all. That is a defensible choice, and it stops being defensible the moment nobody can tell a recovered entry from an original one.
The answer to want, and the one to press
A good answer is short and carries a location. The work continues, the failure is logged elsewhere, and here is the line from the last time it happened. That last clause is the tell. Logging storage fails everywhere, so a team running a real system has seen it, and whoever saw it remembers the week.
A capable vendor who has not thought it through says the audit trail is comprehensive, or that everything is logged automatically. Both are honest descriptions of intent, and intent is not a behaviour you can test. The follow-up that separates them: break it in front of me, or show me the run where it broke.
Hold one more for the vendor who passes. Ask who can open the record without asking them. A ledger you reach only by raising a support request is held by somebody whose interests may not match yours on the day their product does something you have to explain to a regulator.
What you are actually buying
The record outlives the software. Contracts end, vendors get acquired, the agent is replaced by a better one, and what remains is a file of what was done in your name and why. The ledger and the rules around it are set out in the Cabinet paper on the Signature and the Record. What it is meant to catch is the question about actions that cannot be undone.
Asked plainly
Should an AI agent stop working if it cannot write its audit log?
In most designs, no. An agent that halts every time its logging storage hiccups is an agent that stops in the middle of ordinary infrastructure trouble, and the people running it soon switch the logging off. The safer arrangement lets the work continue and records the gap somewhere else, so a missing entry is itself an entry.
What makes an AI agent's record usable as evidence?
Two properties. Entries are added and never altered, so a correction is a new line and the mistaken one still stands. And the record sits somewhere your own people can read without asking the supplier, because a log only the vendor can open is the vendor's evidence rather than yours.
How do I check an AI agent's audit trail in a vendor demonstration?
Ask for the record of the run you have just watched, in front of you, and read one entry aloud. You are looking for the action, the reason beside it, a timestamp, and a named person or specialist. Then ask what the record shows when a write to it fails.