Audit Trails at Machine Scale
The audit model most engineering organizations use was designed around human actors. Someone picks up a ticket, makes a change, records a commit, opens a pull request, gets a review, merges. The audit evidence is implicit in the workflow — the ticket, the commit, the PR, the reviewer — and a human reader can reconstruct what happened by reading it.
That model does not scale to agentic workflows.
The volume problem
When an agent can open a pull request in two minutes, the bottleneck on change velocity is no longer the engineer — it is the reviewer. A team that could previously absorb thirty PRs a week is suddenly looking at three hundred. Each one comes with its own commits, its own test output, its own changeset.
The reviewer cannot read all of it. If they try, review quality collapses. If they do not, the audit trail becomes a narrative they are no longer actually constructing from evidence — it becomes an assertion that the reviews happened. That is exactly the position compliance frameworks are designed to prevent.
The first instinct is to make the reviewer's job easier by adding tooling — summaries, risk scores, diffs ranked by impact. These help, but they do not solve the underlying problem: the audit evidence being produced is shaped for human-scale review, and the work is no longer happening at human scale.
The structure shift
The alternative is to stop relying on narrative audit and start producing structured audit. Instead of "a reviewer read this PR and approved it," the evidence becomes "this PR passed gate A, gate B, and gate C; was authorized against ticket X; was executed under session Y; was reviewed by actor Z against the specific scope defined in prompt file P."
Each element is a structured fact. A query can surface all PRs that passed gate B but failed gate A. An auditor can ask for all sessions against a specific ticket and receive them directly, not via a reviewer's recollection. The evidence is not narrative — it is queryable.
This shift is uncomfortable for engineering teams used to lightweight process. It looks like bureaucracy. In the human-scale regime, it is. In the agentic regime, it is the only way to preserve audit integrity while absorbing the volume.
What this looks like in our workflow
Every agent session in our internal workflow is tracked through NAICOM. The session has an identifier, a starting state, a persona assignment, an authorizing issue, and a terminal state. The artifacts produced during the session — commits, prompt files, test outputs — are tied to the session identifier. The reviewer's decision on the resulting PR is tied to the session identifier. The merge record is tied to the session identifier.
None of this is narrative. A query against the session store returns the full provenance of any change in the system, ordered by time, keyed by identifier, across persona boundaries. The reviewer never had to write a paragraph explaining what they reviewed. The paragraph is reconstructable from the structured record.
When an auditor asks for evidence, the question is no longer "can we produce it" but "which slice do you need." That is the regime compliance frameworks were always intended to produce. Most organizations did not need to get there while humans were the bottleneck. With agents, they do.
The reframe
The audit trail was never really about logs. It was about accountability: a chain of decisions that can be reconstructed after the fact by someone who was not present when they were made. Agentic workflows do not break that requirement. They raise the volume at which it has to be satisfied. Meeting the new volume is a structural problem, not a logging problem.
Teams that treat it as the former will build systems their auditors can actually work with. Teams that treat it as the latter will drown in log output and still fail the audit.