Audit logging, three ways: a web app, a settlement system, and an AI agent
"Add an audit log" sounds like one task. In practice the design depends on what you have to be able to prove, and the same phrase produces very different systems. Here are three audit trails we have built, what each captures, where it is enforced, and the tradeoff each is making.
A web app: capture at the action boundary
In an admin application the audit log answers "who changed this record, from what, to what, and when." The clean place to capture that is the server-action boundary, where every mutation already passes through. We log the actor and their session, the action and the entity, a before-and-after delta of the fields that changed as JSON, and the request's IP and user-agent. The table is append-only and indexed by entity and by actor, so it answers both "what happened to this order" and "what did this user do."
One deliberate choice: the audit write does not block the mutation. If logging fails it is recorded as an error and the operation still completes. An audit system that can take down the feature it audits is worse than the gap it occasionally leaves.
A settlement system: immutability and reversal
Financial settlement raises the bar from "who changed it" to "nothing can be quietly unmade," and there the audit trail becomes the data model itself. Records are not deleted or edited in place. A correction to an issued invoice is a new record with the opposite sign that references the original, so the history shows the original and its reversal rather than a mutated row. Status lives as a named state rather than a numeric code, because renumbering an integer enum silently rewrites the meaning of every historical row. The operation log here captures the full request and response of each action, which is heavy but is exactly what an auditor asks to see.
That weight is the tradeoff. Logging entire request and response bodies makes the store large, and it now holds sensitive data you have to govern and retain under the same rules as the system itself.
An AI agent: log the decision, not just the result
An agent's audit question is the hardest: "why did it answer that." The final output is not enough, because the reasoning lives in the steps. Our agent ledger records, per turn, which tools were called with which arguments, what they returned, which model and version produced each step, and a quality assessment of the answer. That is what lets you reconstruct a decision weeks later when someone asks why the agent did what it did. The append-only ledger is the agent's version of the settlement system's immutable records.
The common thread
All three are append-only, all three capture an actor (a user, a system, or a model), and all three made an explicit decision about immutability and about what is too sensitive to keep. What differs is the unit of record: a field delta for the app, a signed reversal for money, a tool-call trace for the agent. Designing an audit log starts with naming what you will be asked to prove, then working back to the smallest record that proves it.
Where AgentKick fits
We design audit and observability layers for systems that have to answer for themselves: web applications, regulated financial workflows, and AI agents. If you need an audit trail that will satisfy a regulator, an incident review, or a customer dispute, that is the work we do, usually as a fixed-scope AI Agent Production-Readiness Review into a phased build.