What should an AI agent audit trail record?

The standard fields are a stable run ID, the trigger and inputs, the model and its version, every tool call in order, human approvals with names and timestamps, and the final outcome, kept append-only and on by default. Kaykas-Wolff adds one field most guides skip: what a person did with each output, whether it was used as is, edited, rewritten, discarded or ignored, plus who did it and when.

Why should an audit trail continue past the agent's last action?

Because the consequences usually begin after the agent reports success. Someone rewrites the draft, forwards the summary, or a spreadsheet pulls the number into a forecast. When an agent turns out to have been wrong, the hard question is who relied on its output, and only a trail that records the human's next move can answer it quickly.

Should an AI agent's audit trail be deleted when the agent is retired?

No. Kaykas-Wolff separates the two. An agent's memory, meaning its notes and embeddings plus conversation history, should be kept under normal retention policy or deleted on purpose. The audit trail is a record of what the company did, so it outlives the agent. Storing pointers to inputs rather than copies keeps the trail from duplicating customer data.

How can executives test whether an AI agent audit trail works?

With a quarterly one-hour test. Someone outside the owner's reporting line picks one agent action from the previous month at random, and the owner has an hour to explain from the trail alone what triggered it, which model version ran, what it touched and who used the result. Kaykas-Wolff recommends running it on the CEO's own agents first.

What should a board see about AI agent audit trails?

One number: the share of sampled agent actions that management fully reconstructed within an hour this quarter, plus a yes or no on whether the CEO's agents were in the sample. It shows directors whether the company can answer basic questions on the night an agent fails.

AI Agent Audit Trails: Keep Logging After the Agent Stops

The best argument I have for a better audit trail comes from my own fleet. An agent I had replaced in the spring was still waking up on its old schedule in late summer, pulling data with credentials nobody had revoked and writing a status file that one other system read every morning. A dashboard I trusted was quietly showing stale numbers because of it.

The agent’s logs were fine. Every run was recorded, start to finish, and every run ended in success.

The logs did not lead me to the problem. A machine running out of process headroom did, which I described in retiring an AI agent. What no log anywhere could tell me was the thing I most needed to know that morning: who had been reading that file, and what they had decided because of it.

What the audit trail guides agree on

The pages that rank for this are written mostly by API gateway and security vendors, with a compliance platform or two mixed in, and they land on a similar list. Give every run a stable ID so its events can be stitched together later. Record what triggered the run and what came in. Note the model and its version, since the same prompt behaves differently after an upgrade. Log every tool call in order, every human approval with a name and a timestamp, and the final outcome. Make the record append-only, and switch it on by default so nobody can turn it off for a noisy agent. One of the better guides draws a clean line between monitoring, which tells you something is wrong right now, and a trail, which lets you rebuild a single decision weeks later. Most of them end with SOC 2 or ISO 42001.

I agree with all of it. The model version most of all, because I think a model upgrade is the largest unreviewed change most companies make to their operations, and I made that case in change control for model upgrades. A trail without the version on every line cannot tell you whether a bad week started on the day the model changed.

Where every trail I read stops

At the agent’s last action. The email went out, the file was written, the record was updated, status success, end of trace.

From the agent’s side that really is the end. From the company’s side it is usually where the consequences begin, because somebody opened the draft and rewrote half of it, or forwarded the summary to the board chair without reading past the first paragraph, or a spreadsheet pulled the number into next quarter’s forecast, and none of those moves appear anywhere in the trail the vendors describe.

Success is the agent’s word for it.

Add one field: what a person did with it

For every output, record what a human did next. Used as is, edited, rewritten from scratch, discarded, or nothing at all. Add who did it and when. Most of the tools agents write into already keep this in version history or a sent folder, so the work is mostly joining it back to the run ID rather than building something new.

The field pays for itself in a couple of ways. It is the raw material for cost per accepted output, the number I argued for in who owns the AI agent bill, since you cannot count accepted outputs if nobody wrote down which ones were accepted. It also runs my retirement trigger. If no human has acted on an agent’s output in thirty days, a review starts, and the trail is where that thirty-day clock lives.

The bigger payoff shows up on a bad day. When an agent turns out to have been wrong for two weeks, what it did is the easy part, and you mostly know it already. Who relied on it is the hard part. With this field the answer is a query you can run in a minute. Without it, you are sending a message to the whole company asking whether anyone used the numbers from the Tuesday report.

Log the readers, too

Some outputs never get a human verdict, because no human opens them. A status file feeds a dashboard. A summary lands in a folder that another agent reads at six every morning. For those, the trail should record what read the output, at least by system name. My stale status file had exactly one consumer, and if that consumer had been written down anywhere, I would have found the problem in the spring instead of late summer.

The retirement post asks you to list an agent’s consumers before you turn it off. That list should be kept all along, and read off the trail on the day you need it.

Keep the trail, delete the memory

People confuse these two, and they need opposite treatment. An agent’s memory is working material, mostly notes and embeddings plus conversation history that often has customer data mixed in. When the agent retires, that memory should be kept under your normal retention policy or deleted on purpose. The trail is a record of what the company did, so it outlives the agent and sits with your other business records. To keep it from becoming a second copy of every customer conversation, store a pointer to the input instead of the input itself. The trail says which ticket the agent read. The ticket system keeps the ticket.

The one-hour test

Once a quarter, have someone outside the owner’s reporting line pick one agent action from the previous month at random. The owner then has an hour to explain it from the trail alone: what triggered it, which model version ran, what it touched, and who used the result. If they have to ask around or open the code, the trail is decoration.

Run it on the CEO’s agents first, for the same reason I hand my own grants to the CFO in AI agent access reviews. The executive agents touch the most sensitive material and get the least scrutiny. I would expect my own fleet to fail its first round on the last question, because that is precisely the part I did not log.

What the board should see

One number, on the AI page in the board pack: of the actions sampled this quarter, how many were fully reconstructed within the hour. Then a yes or no on whether the CEO’s agents were in the sample. I sit on the board of ACT | The App Association, and the AI items I find useful in a boardroom are the ones management can answer with a count instead of a story. This is one of them. It also tells directors whether the company will be able to answer anything at all on the night something goes wrong, when the first job in the incident playbook is freezing the evidence before it rotates away.

Start with the last bad output

Think of the most recent time an agent at your company got something wrong. Write down everyone who saw it, used it or forwarded it before the mistake was caught. If you can produce that list from a record instead of from memory, your trail is already better than most. If you cannot, that list is the field to add first, and I would add it before buying anything with the word observability in the name.

This article is part of the Executive Leadership cluster, focused on board governance and the operating discipline required to run AI systems responsibly at the executive level.