An Audit Trail for an Agent in a Regulated Workflow

An audit trail for an autonomous agent exists to answer one question, months after the fact: why did the agent do what it did, using nothing but the records it left behind. Not what the agent usually does, not what it was trained to do in general. What happened at that one timestamp, given that one set of inputs. If a logging setup can't reconstruct a single decision on demand, it isn't an audit trail. It's a chat log with delusions of compliance. I've sat in enough exam prep meetings to know how fast that distinction becomes real. Regulated industries spent decades building audit expectations around human decision-makers, and none of those expectations translate automatically. A loan officer who denies an application leaves an application file, a credit report, some handwritten notes, and a decision. An underwriting agent denying the same application might have called four APIs, run four retrieval queries against a policy corpus, invoked a model three separate times with three different prompts, and made an internal call about which of two conflicting policy documents governs. Every one of those steps has to be captured somewhere. Otherwise the examiner's question, why was this applicant denied, has no defensible answer, and "the model decided" is not an answer an examiner will accept. ## Capture the decision, not just the output Most teams building their first agent logging system make the same mistake. They log the input, log the output, slap a timestamp on it, and call the job done. That's telemetry. It is not an audit trail, and the gap between the two shows up the instant someone asks a follow-up question. Reconstructing a decision means capturing the full causal chain, not the headline result. Start with the prompt actually sent to the model, system instructions included, not just the user-facing query someone typed into a box. Every tool call the agent made needs the exact parameters passed and the exact response received, because an agent that queried a stale cache made a different decision than one that hit a live database, even when the two outputs look identical on the page. If the agent used retrieval, log which documents came back, in what order, and what the similarity scores were. A policy answer built on an outdated document version is a different failure than a policy answer built on something the model invented outright, and an examiner will want to know which one happened. Where the model exposes its intermediate reasoning, whether through a chain-of-thought trace or a structured plan generated before acting, that reasoning needs to be captured too. So does the exact model version, and ideally the checkpoint or weights snapshot behind the answer. Model providers push updates without always versioning them in a way downstream teams can pin down later. Miss that detail and you can't reproduce the call, and reproduction is the entire point of keeping the record. SR 11-7, the Federal Reserve's model risk management guidance, was written for statistical models long before anyone was building agents, but examiners increasingly apply it here anyway, and it treats reproducibility and documented model changes as baseline, not aspiration. Last, log the decision boundary itself: the threshold or rule that actually triggered the action. If the agent cleared a transaction because a fraud score landed under 0.3, record the score, the threshold, and the policy version that set it. Thresholds move. Someone tunes them. If yours shifted from 0.3 to 0.25 sometime between the decision and the audit, you need to know which number was live at the moment of decision, not which number happens to be live today. ## What "per decision" actually means in practice Agents rarely make one decision per task; they make dozens, and most never surface to the end user. Take a claims-processing agent working a single insurance claim. It decides which document to pull first, whether an exclusion applies, whether to escalate to a person, and finally whether to pay. Each of those is a branch point. Each branch point is a place where the agent could have gone the other way, and a place an examiner can ask about. So the practical question becomes granularity. Log every branch, or only the ones that produced something the customer saw? There's no clean universal rule here, but the safer default in anything regulated is to log every branch involving a judgment call, meaning anywhere the agent chose among options instead of following a fixed rule. A regex flagging a missing field isn't a judgment call; nobody needs a reasoning trace for that. A model deciding two documents conflict, then picking which one wins, absolutely is a judgment call, and it earns its own log entry with its own trace. That adds volume fast, and there's no way around it. One claim might throw off twenty or thirty loggable events where a naive setup would produce one. Worth having the storage conversation early, because the alternative, going back later to figure out which events you wish you'd kept, resolves the same way every time: you should have logged more. ## Retention: longer than you think, tied to the regulation you're under Retention periods come from the regulation governing the workflow, not from what's convenient for engineering, and they routinely outlast the model's own useful life. ECOA and Regulation B require US mortgage lenders to keep adverse action records for 25 months. SEC Rule 17a-4 pushes broker-dealer retention out to six years, with the first two required to sit somewhere easily accessible. HIPAA-adjacent workflows touching PHI often carry a six-year federal floor, longer still in states like California. Agentic systems complicate this in a specific way: what you're retaining isn't a static record, it's a reconstructable environment. Keeping the decision log without keeping a way to interpret it accomplishes almost nothing. Say the agent called a tool version that's since been deprecated, or cited a policy document superseded three revisions ago. A log entry pointing to "policy*v4.docx" means nothing six years out unless policy*v4.docx itself is sitting in an archive somewhere, retrievable on demand. Model versions, prompt templates, tool schemas, referenced knowledge-base snapshots: all of that belongs in the retained record, not floating around as living infrastructure someone can overwrite on a Tuesday. This is where teams get burned, repeatedly and predictably. Engineering culture optimizes for the newest version being the only one that matters, and every deploy quietly buries the last one. Compliance demands the opposite. Every version that was ever live has to stay inspectable for as long as the decisions it produced remain subject to review, which in practice means years after the team has moved on to three newer architectures. ## Reconstruction: the test that actually matters Picture the moment six months out. An examiner points at one transaction and asks why the agent approved it. What happens next can't involve an engineer stitching together logs from four different systems while the examiner sits there waiting. You pull the decision ID. That ID has to trace to a single record: the full input the agent received, the exact model checkpoint invoked, every tool call with its response, the retrieval context if there was one, the intermediate reasoning trace, and the final decision alongside the policy threshold that governed it. From that record alone, without guessing and without a phone call to whoever built the thing, you should be able to say what data the agent saw, what it inferred from that data, what rule it applied, and whether that rule was actually the one in force on that date. If answering any piece of that requires cross-referencing three systems that have since drifted apart, the reconstruction has a gap. Gaps are exactly what examiners are trained to find; it's most of the job. The OCC frames this as effective challenge in its own model risk guidance, now applied to AI systems by extension: the institution has to independently verify that a model did what it was supposed to do. Asserting it isn't good enough. Some teams build a dedicated replay tool for this, essentially an interface where a compliance officer types in a decision ID and watches the full causal chain render in order. Others lean on structured logging pushed into something queryable, Splunk or a data warehouse, with enough metadata to join across tables cleanly. The specific tool matters less than the guarantee behind it: one identifier in, the full story out, readable by someone who has never seen the codebase. ## The counterargument, and why it doesn't hold Engineering teams push back on cost, and the pushback is fair on its face. Full decision-level logging, with snapshots of every tool call, prompt, and model version retained for years, is expensive to store and a pain to maintain, especially at the volume agents run at compared to the human decision-makers they're replacing. But that's the wrong comparison. Logging expense doesn't sit against zero; it sits against the cost of an adverse action nobody can explain, in a regulated line of business, which can mean fines, a consent order, or the workflow getting yanked from production until someone makes it auditable after the fact, under worse conditions and a tighter clock. Storage keeps getting cheaper. Consent orders don't. The real choice was never whether to pay for reconstruction. It's whether you pay upfront, on your own terms, or you pay later, under examination, with no say in the price.