Audit trail for AI agents
An audit trail is the durable record of what your agents actually did — who did what, when, in which run, and with what result — written by the system, not summarized by the agent afterward. It's the difference between an agent telling you it finished and you being able to check.
The problem shows up the moment you run more than a toy. The whole fleet reports success. Every task says done. And something is still broken — a step that half-ran, a write that landed twice, a decision nobody can reconstruct. An agent's own report is the one source you can't trust to catch the case where the agent was wrong, because it's the same narrator. A real audit trail is written underneath the agent, where it can't round its own work up to success.
Why the agent's own report isn't an audit trail
The default record is whatever the agent says in its final message: "Done — created the project, added the tasks, wired up the deploy." That reads like a log, but it's a self-report. It's produced by the same process whose work you're trying to check, after the fact, from memory the agent may no longer have. If a step silently failed, the summary still says it succeeded — the narrator has no way to know it was wrong, and neither do you. A claim isn't evidence.
The failure compounds across runs. Session two has no durable trace of what session one did beyond that ephemeral summary, so it re-does finished work, contradicts a decision it can't see, or trusts a "done" that was never true. With several agents in the same workspace it's worse: three actors, three separate stories, and no single record of who changed what. An audit trail that holds can't be the transcript. It has to be shared state the system writes as work happens — append-only, attributed, and linked to the thing that proves it.
Four things. Miss one and you're trusting a self-report.
Strip an agent audit trail down and it has to get four things right. Miss any one and you're back to trusting a self-report you can't check.
A record the agent can't fake
The log has to be written by the system as work happens, and it has to be append-only — an agent can add to the record, never quietly rewrite it. Decisions, activity, and completions become permanent entries the moment they occur, not lines the agent composes at the end from memory. When the trail and the agent's summary disagree, the trail wins, because the trail isn't the agent's account of the work — it's the work leaving a mark.
Why the record is append-only →"Done" that's verified, not claimed
A task marked done by the agent that did it is a claim. A trustworthy trail makes done a checked state: the acceptance criteria are actually met, evidence is linked, and — where it matters — a reviewer signed off, before the status can flip. "Done" stops meaning "the agent believes it finished" and starts meaning "the conditions for finished were met and recorded." That's the single line most agent systems can't draw.
How to prove an agent finished →Attribution across runs and actors
Every entry has to name who and when: which actor, in which run, at what time. With one agent that's a timeline you can replay. With several it's the only way to answer "who changed this" without guessing — three agents in a workspace produce one attributed record, not three unlinked stories. When something is wrong, attribution is what turns "something broke" into "this actor, in this run, did this" — the difference between a mystery and a fix.
Many actors, one record →A link to the artifact that proves it
The strongest entry in the trail isn't a sentence — it's a pointer to the thing itself. A completed task should link to the exact commit or pull request that delivered it, the note that captured the finding, the file that was produced. Then "done" isn't an assertion you take on faith; it's a click to the evidence. An audit trail whose entries dead-end in prose is a story. One whose entries resolve to artifacts is a record.
Linking work to the code that delivered it →How Ledgenter gives you an audit trail
Ledgenter is one MCP server — 61 tools over a single typed contract — and the record is a property of the workspace, not something an agent has to remember to write. Activity is logged as it happens. Decisions go into an append-only log: an agent supersedes an old decision, it never edits one away, so the reasoning behind a call is still there months later. Completion runs through gates — acceptance criteria, linked evidence, an optional review — so a task can't reach done on the agent's word alone. Every entry carries the actor and the run that produced it.
And the trail resolves to artifacts: a task links to the commit or PR that delivered it through a code ref, so "done" is one click from the diff that proves it. A human watches all of it through the console — every run, decision, and completion across every agent, in one place, queryable after the fact. That is what lets you leave a fleet of agents running unattended: not because they never get anything wrong, but because when one does, the record shows you exactly what happened, who did it, and where to look — instead of a wall of green checkmarks hiding the one that lied.
▸ whoami
{
"actor": { "handle": "claude-code", "kind": "agent" },
"mode": "loop",
"inbox": 0,
"open_tasks": [
{ "seq": 42, "title": "Wire the overdue sweeper", "status": "ready" }
],
"since_last_seen": { "new_activity": 3 },
"hint": "claim the next ready task"
}The first call of every run. Every entry that follows — each decision, completion, and handoff — is attributed to this actor and this run, so the trail can always answer who did what, and when.
Keep reading.
The ones that actually come up.
What is an audit trail for an AI agent?
It's the durable, system-written record of what an agent actually did — activity, decisions, task completions, and who did each, in which run — kept separately from the agent's own summary. The point is verifiability: you can reconstruct and check what happened instead of trusting the agent's final message, which is a self-report from the same process whose work you're auditing.
Why isn't the agent's own summary a good enough record?
Because it's produced by the process you're trying to check, after the fact, from memory the agent may no longer have. If a step silently failed, the summary still says it succeeded — the narrator can't catch the case where it was wrong. A claim of 'done' isn't evidence of done. A real audit trail is written underneath the agent as work happens, append-only, so it can't be rounded up to success later.
How do you verify an AI agent actually completed a task?
Make 'done' a checked state instead of a claimed one. Ledgenter gates completion: acceptance criteria must be marked met, evidence (a commit, a PR, an artifact) must be linked, and where configured a reviewer must sign off before the status can flip. Then a done task isn't the agent's opinion — it's a record that the conditions for finished were met, with a link to the artifact that proves it.
How is this different from LLM observability or tracing tools?
Tracing tools (token spans, prompt/response logs, latency) tell you what the model emitted — they observe the conversation. An audit trail tells you what the agent did to your work — which tasks it completed, what it decided, what it changed, and whether 'done' was real. They're complementary: tracing debugs the model's reasoning; the audit trail is the durable, verifiable record of the work itself, at the level a human actually needs to trust the outcome.
Can an agent tamper with its own audit trail?
It can add to it, not rewrite it. Decisions and activity are append-only — an agent supersedes an old decision with a new one, leaving both in the record, rather than editing the past. Completions run through verification gates before they land. And every entry is attributed to the actor and run that produced it, so the trail is a record the agent leaves behind, not an account it authors after the fact.