What Evidence Does an AI Agent Actually Need to Leave Behind?

A developer argues that AI agents making real changes to code, configs, and infrastructure leave insufficient evidence behind, since a Git commit alone cannot show what the user asked for, which tools the agent called, what context it read, or whether a human approved the action. The piece proposes that every meaningful agent action outside its own scratchpad should leave a replayable trail covering the original request, tool-call sequence, read context, risk category, and type of human review.

There is a question that keeps surfacing as AI agents move from answering questions in chat to actually doing things, writing code, modifying configs, calling APIs, deploying services. The question is not "how do we stop them from acting?" The question is: what evidence do we need after they act? The reflex answer is: just look at the diff. A Git commit shows you what changed. That used to be enough when a human sat behind every change. The human held the context. You could ask them. The commit message, however brief, was a pointer to a person who understood the decision. With an AI agent, the commit is often the only artifact. And it hides almost everything that mattered: A commit hash answers none of those questions. We have spent years building approval workflows for human code changes. Pull requests, code review, change advisory boards, ticket numbers in commit messages. These processes assume a human author who can be questioned, who made a conscious decision, who can explain their reasoning. AI agents break that assumption quietly. The agent acts faster than review cycles were designed for. It calls ten tools in thirty seconds. It reads a config file, writes a new one, runs a test, opens a PR, and waits, all before anyone noticed it started. The change looks reasonable. The tests pass. The PR gets merged. Three months later, something unexpected happens in production. You need to understand what the agent knew, what it read, what choices it made, and what a human approved. If the only record is the commit, you have nothing. I am not arguing for heavyweight approval workflows on every AI action. That path leads to agents being so throttled they are useless. But I do think every meaningful AI action, anything that modifies state outside the agent's own scratchpad, should leave enough evidence to answer questions when it matters. Here is what that looks like in practice: What did the user ask for? Not the agent's interpretation, the actual message. This is the anchor for everything else. If the change cannot be traced back to a human request, that is itself meaningful information. Which tools did the agent call, in what order, and what did it pass to them? This is the chain of decisions. A file read that preceded a file write tells you the agent saw the old value before replacing it. A secrets lookup before a config change is a different kind of event than a blind write. Before an agent modifies something, it usually reads something. That read context is often the difference between "the agent made a reasonable change given what it saw" and "the agent made a change that only makes sense if it misread something." Did the interaction touch authentication, authorization, secrets, infrastructure definitions, or production configuration? These are not just higher-risk changes, they are the category of changes that auditors, security teams, and incident responders will ask about first. Was a human shown anything before the change happened? Did they click through a permission prompt, review a plan, or simply let the agent run autonomously? The presence or absence of human review is material. So is the kind of review, "I saw a one-line summary" is different from "I read the full plan and the diff." Can someone who was not in the room replay the sequence? Not re-run the agent, but follow the evidence trail and understand what happened. This is the test. If the answer is no, the evidence is insufficient. In practice, teams end up in one of a few places: Git history only. Fast, familiar, already required. Works fine when agents are doing what a junior developer would do and the stakes are low. Fails when something goes wrong and you need to explain the decision chain. Tool-call logs. A step up. You know what the agent touched. You do not always know why, or what it read, or what the user originally asked for. Better for incident response than for governance. Approval records. Some teams require a human sign-off checkpoint before the agent can modify certain surfaces — production, secrets, auth config. This is reasonable for high-stakes surfaces. It does not help you reconstruct what happened before the approval, or what the agent read to arrive at its proposal. Full session traces. The full conversation, user messages, tool calls, reads, writes, tool results, stored with tamper-evident hashes. This is the complete evidence set. It is also the most expensive to store and the most sensitive to handle, because it may contain secrets that appeared in tool results. The honest answer is that the right level depends on the surface. An agent writing unit tests probably does not need a full session trace. An agent modifying IAM policies probably does. Chron https://www.npmjs.com/package/chron-mcp is an MCP server that creates tamper-evident audit logs of AI sessions — stored locally, on your own machine, in a SQLite database you control. Every tool call is logged with a cryptographic hash chain. The user's original message is captured. The sequence is reconstructable. The database does not leave your environment. It crossed 9,000 npm downloads this week, which is a signal that the question this article is asking is not just theoretical. People are encountering it in real work and looking for answers. Chron's position is deliberately minimal: it records, it does not certify. It does not tell you whether a change was authorized or correct. It gives you the evidence to answer those questions yourself, or to hand to someone else who needs to answer them later. That boundary - recording vs. certifying - matters. The tool that captures evidence should not be the same tool that decides what the evidence means. Those are different jobs. If an AI agent in your environment made a change right now, something it wrote, deployed, or modified, and three months from now you needed to explain that change to a customer, an auditor, or your own security team, what would you show them? If the answer is "the commit," that is worth thinking about. Not because commits are bad. Because they were designed for a world where a human sat behind every change, and that world is changing faster than our evidence practices are. Chron is available as an MCP server: npx chron-mcp . It works with Claude, Cursor, and any MCP-compatible AI tool. The audit database is yours - local SQLite, no cloud egress.