What audit trails actually require from agent workflows
When an agent touches a financial record, updates a patient file, or modifies a dataset used in a regulatory submission, the question is not whether something went wrong. The question is whether you can show, step by step, what the agent read, what it decided, and what it wrote, in a form that cannot be altered after the fact.
Most teams discover they cannot. A Q1 2026 survey of 420 organizations running AI agents in production found that only 17% could reconstruct the full sequence of tool calls, inputs, and outputs for a specific agent task after the fact. That gap is not a logging problem. It is an architecture problem.
Standard application logs capture that something happened. Audit trails for agent workflows need to capture why: which inputs the agent received, which tools it invoked, what the tool returned, and which of those outputs shaped the next step. Without that chain, you cannot reproduce the decision, and you cannot defend it to a regulator, a counterparty, or your own compliance team.
The core requirement: append-only storage
The property that makes an audit trail defensible is immutability. A record that can be updated or deleted can be manipulated, intentionally or through routine maintenance. Append-only storage prevents both. New facts are written as new entries; older entries are never overwritten.
This is the design Kyle Visner adopted for Jaybase, an append-only fact store built specifically for auditable AI agent business workflows, announced in July 2026. In Jaybase, every fact an agent asserts is a new immutable record. If an agent revises a conclusion, the revision is itself a new entry, and the original fact remains. The audit trail is the database, not a side log attached to it.
That design decision has a concrete consequence: you can reconstruct the exact state of the world as the agent understood it at any point in time by replaying the log up to that timestamp. That is what reproducibility means in practice, not re-running the agent and hoping it produces the same output, but being able to prove what state it was operating on.
For teams building in regulated domains, the compliance article on auditability in CI/CD pipelines covers how this pairs with deployment controls. The underlying principle is the same: the record must be written before the side effect, not scraped from logs after.
Provenance tracking in scientific and research workflows
The same requirement appears in a different form in biological research. When an AI agent proposes a hypothesis, retrieves literature, or summarises experimental results, the downstream user needs to know not just what the agent said but which sources it used, in which order, and under which model version.
Inflexa addressed this directly with an open-source terminal UI for reproducible biological AI research, released in July 2026, that tracks full provenance for every agent action. Every query, retrieval, and inference step is recorded with enough context to reproduce the exact run. The tool is designed for researchers who need to attach an audit record to a result the same way they would cite a method in a paper.
The provenance requirement in research and the immutability requirement in finance are the same thing stated for different audiences. Both come down to: can you show your work, completely, to someone who was not in the room?
RAG-based retrieval agents are a common source of invisible provenance gaps. The agent retrieves several chunks, synthesises an answer, and returns it. Without explicit provenance recording, there is no way to know which chunks were retrieved, whether the retrieval index has changed since the run, or whether the same query would return the same results today. The answer looks correct but cannot be verified.
What financial services deployment makes visible
The scale of agent deployment in finance makes the audit gap concrete. JPMorgan Chase is running more than 400 production AI use cases on its ML platform, processing roughly $10 trillion in daily transactions. AIG's multi-agent underwriting system is processing 370,000 submissions with claims scoring at 88% of human expert accuracy.
At that volume, an audit failure is not a theoretical concern. If an agent in a credit memo workflow makes a decision that a regulator later questions, the organisation needs to produce the input data, the tool calls, the intermediate outputs, and the final decision, in sequence, without gaps. The same applies to insurance underwriting, where individual decisions carry legal weight.
Moody's reported in September 2025 that its agents for credit memo preparation reduced preparation time from 40 hours to two minutes. Speed is useful, but the memo still needs to be defensible. The audit record for a two-minute agent run needs to be as complete as the record for a 40-hour analyst process.
The compliance conundrum article on auditing autonomous agent actions covers how this plays out across different regulatory frameworks. The short version is that speed savings from agents are only retainable if the audit overhead does not scale with the number of decisions.
This is also where agent identity becomes load-bearing. An audit record that says "an agent did this" is not sufficient. The record needs to identify which agent, under which identity, operating on behalf of which principal, using which tool version. Without that, you cannot scope an incident, and you cannot demonstrate control to an auditor.
Designing for reproducibility from the start
Reproducibility is not a property you add to an agent workflow after it is built. It requires three things to be true at design time.
First, every input the agent receives must be recorded before the agent acts on it. If the input can change between recording and acting, the record does not reflect what the agent actually saw.
Second, every tool call must be recorded with its full parameters and the full response. Summaries are not sufficient. A tool that returns a paginated result set, a database query that returns 500 rows, a retrieval that returns five chunks: the audit record needs the actual data, not a description of it.
Third, the record must be written to append-only storage before the side effect is committed. If the agent writes to a database and the audit write fails, the side effect has already occurred. The correct order is: write the audit record, then execute the action.
Prefactor instruments agent runs at the span level, recording tool calls, inputs, outputs, and scoring each step for quality and risk, which gives the audit trail the granularity needed to reconstruct a run rather than just confirm it happened. The evaluation in production article covers how span-level recording connects to broader production measurement.
For autonomous background agents operating without a human in the loop, the audit trail is the only mechanism by which oversight is possible after the fact. A 2026 survey found that 63% of enterprises cannot enforce purpose limitations on their AI agents. Append-only recording does not solve that enforcement problem directly, but it is a prerequisite for detecting when a limit has been crossed.
Where to start
Review whether your current agent runs produce a record from which you could reconstruct every tool call, input, and output in sequence, without relying on mutable logs. If the answer is no, that is the first thing to fix, before scale makes it harder.
Start evaluating your agents and review the docs to see how span-level instrumentation and scoring fit into your existing workflow.