Your Agent Logs Everything and Can Prove Nothing

A fintech team called me in after an auditor asked them a question they could not answer. One of their agents had declined a customer's loan top-up, the customer complained, and the auditor wanted to know why. The team had everything, or thought they did. They pulled up the run in their tracing tool and there it was, forty-seven spans, every tool call, every token count, every latency bar laid out in a beautiful waterfall. They scrolled through it with the auditor for twenty minutes.

At the end of it the auditor asked the question again. Why did the agent decline this application. And the honest answer was that nobody could say. The trace showed that a scoring tool had returned a number, that the agent had read it, and that the final message said no. It did not show which policy the agent believed it was applying, what inputs that scoring tool actually ran on, whether a human had signed off, or on whose authority the account had been touched at all. They had a perfect recording of the motions and no record of the decision.

This is the gap almost nobody notices until someone from outside the engineering org comes asking. You can have complete traceability and zero auditability, and the two feel so similar from the inside that teams discover the difference at the worst possible moment.

A trace answers "what happened." An audit answers "why, and who is accountable."

A trace is telemetry. It exists to help an engineer debug a run, so it captures what is cheap to capture and useful at 2am: spans, durations, tool names, token usage, the occasional payload. It is optimized for the person who already understands the system and just needs to see where it spent its time. That person fills in all the context from their own head.

An audit trail is a different artifact for a different reader. The reader is someone who was not in the room, does not understand your architecture, and shows up months later with authority over whether you are allowed to keep operating. They are not asking where the time went. They are asking what decision was made, what rule it was made under, what facts it was made on, and who carries responsibility for it. Those questions are answerable only if you wrote the answers down at the moment of the decision. You cannot reconstruct intent from a latency waterfall.

The industry has a tidy way of saying this now: a trace with forty-seven agent steps is not an audit trail. It is exactly right. The forty-seven steps are evidence that something ran. They are not evidence of a defensible decision, because the thing a decision record has to preserve, the reason, lives in the agent's head for one inference and then evaporates unless you catch it.

The business cost of confusing the two is not abstract. For a high-risk system under the EU AI Act, Article 12 requires automatic record-keeping across the system's lifetime and Article 14 requires that a human can actually oversee and understand its decisions, and those obligations are being enforced now rather than discussed. NIST stood up an agent standards initiative in early 2026 pointing the same direction for anyone operating in the US. Even leaving regulators aside, the first time a customer disputes an automated decision and your answer is "here is a trace, let me interpret it for you," you have already lost the argument. Interpretation is not evidence.

What an audit-grade decision record actually contains

Start by being precise about the unit. You do not audit spans. You audit decisions, specifically the consequential ones: the action that moved money, changed a record, sent a message, granted access, or told a customer yes or no. Everything else is debugging detail. So the object you persist is a decision record, and it has to stand on its own without anyone narrating over it.

Here is the shape I use. It is deliberately boring, because boring is what survives a review.

from dataclasses import dataclass, field
from datetime import datetime, timezone
from typing import Any
import hashlib
import json

@dataclass(frozen=True)
class DecisionRecord:
    action_id: str              # stable id for THIS decision, not the span id
    trace_id: str               # link back to the debug trace, for engineers
    agent: str                  # which agent/role acted
    actor_authority: str        # the scoped credential/role it acted under
    action: str                 # "decline_application", "issue_refund", ...
    inputs: dict[str, Any]      # the facts the decision was actually made on
    rationale: str              # why, in the agent's own words, captured now
    policy_decision: str        # allow | deny | escalate, from the gate
    policy_id: str              # which rule version produced that decision
    approved_by: str | None     # human id if a person signed off, else None
    outcome: str                # what actually happened when it ran
    at: str                     # ISO-8601 UTC timestamp
    prev_hash: str              # hash of the previous record (tamper-evidence)

    def digest(self) -> str:
        # Hash over a stable serialization so the chain is reproducible.
        body = json.dumps(self.__dict__, sort_keys=True, default=str)
        return hashlib.sha256(body.encode()).hexdigest()

Every field here answers a question an auditor actually asks. rationale and inputs answer why and on what. actor_authority and approved_by answer who. policy_decision and policy_id answer under what rule, and pinning the rule version matters because the policy you run today is not the one you ran in March. prev_hash is what makes the log tamper-evident: each record commits to the one before it, so you can show an auditor that nothing was quietly edited after the fact.

Notice what is not in here. There are no token counts, no latencies, no raw model transcripts. Those belong in the trace. Mixing them in is how audit logs become unreadable and, worse, how they end up full of data you are not allowed to retain. An audit record is a summary of a decision, not a dump of everything the model saw.

Emit the record at decision time, not from a log scraper afterward

The single most common mistake I see is teams trying to build audit trails by post-processing their traces. They write a batch job that reads yesterday's spans and tries to infer decisions out of them. It never works, because the one field that matters most, the rationale, was never captured. You are asking a scraper to recover intent that was thrown away.

The fix is to capture the record at the exact point the decision is made, right where the agent commits to a consequential action. In practice that is the same chokepoint where your action-layer authorization already lives. If you have a gate that decides allow, deny, or escalate on every tool call, and I have argued before that you should, then the audit record is emitted from that same seam. The policy decision and the record are produced together, because they are the same event seen from two angles: one enforces, the other remembers.

class AuditLog:
    def __init__(self, store):
        self._store = store  # append-only sink: WORM bucket, ledger table, etc.

    def _last_hash(self) -> str:
        last = self._store.latest()
        return last.digest() if last else "genesis"

    def record(self, *, trace_id, agent, authority, action,
               inputs, rationale, policy, approved_by, outcome) -> DecisionRecord:
        rec = DecisionRecord(
            action_id=f"{trace_id}:{action}:{self._store.count()}",
            trace_id=trace_id,
            agent=agent,
            actor_authority=authority,
            action=action,
            inputs=inputs,
            rationale=rationale,
            policy_decision=policy.decision,
            policy_id=policy.rule_version,
            approved_by=approved_by,
            outcome=outcome,
            at=datetime.now(timezone.utc).isoformat(),
            prev_hash=self._last_hash(),
        )
        self._store.append(rec)   # append-only; never update or delete
        return rec

The call site is where the discipline shows. When the agent is about to take a consequential action, you capture its rationale as a first-class input, not as a hope that the transcript has it somewhere. A compact way to do that is to make the agent state its reason as part of the structured arguments it already produces for the tool call, so the reason is a field you read rather than prose you parse.

def execute_consequential_action(agent_call, ctx, audit: AuditLog):
    # agent_call carries the structured action the model committed to,
    # including a `reason` field the model is required to fill.
    decision = policy_gate.evaluate(agent_call, ctx)   # allow/deny/escalate

    approver = None
    if decision.decision == "escalate":
        approver = request_human_approval(agent_call, ctx)  # blocks, persists
        if approver is None:
            outcome = "aborted: no approval"
        else:
            outcome = run_action(agent_call)
    elif decision.decision == "allow":
        outcome = run_action(agent_call)
    else:
        outcome = "blocked by policy"

    audit.record(
        trace_id=ctx.trace_id,
        agent=ctx.agent_name,
        authority=ctx.scoped_credential,
        action=agent_call.name,
        inputs=agent_call.audited_inputs(),   # the facts, redacted as needed
        rationale=agent_call.reason,          # captured, not reconstructed
        policy=decision,
        approved_by=approver,
        outcome=outcome,
    )
    return outcome

The escalation branch is where the "who" gets real. If a human approved the action, their identity lands in the record next to the agent's rationale, which is exactly what an oversight obligation under Article 14 is asking you to demonstrate. This is also why an approval gate that persists the pending decision pairs so naturally with the audit log: the moment a person says yes is a decision worth recording on its own.

Making the record answer questions out loud

A log you cannot query under pressure is not much better than no log. The whole point is that when someone asks why the agent declined that application, you run one query and read back a human-sentence answer, without an engineer standing there translating spans.

def explain_decision(audit_store, action_id: str) -> str:
    rec = audit_store.get(action_id)
    who = rec.approved_by or f"agent {rec.agent} under {rec.actor_authority}"
    return (
        f"On {rec.at}, {who} performed '{rec.action}'.\n"
        f"Decision: {rec.policy_decision} (rule {rec.policy_id}).\n"
        f"Reason given: {rec.rationale}\n"
        f"Based on: {json.dumps(rec.inputs)}\n"
        f"Outcome: {rec.outcome}\n"
        f"Debug trace: {rec.trace_id}"
    )

That last line matters more than it looks. The audit record links back to the full trace by trace_id, so the two artifacts are not rivals. The trace is still there for the engineer who needs to debug the run. The decision record is there for the reviewer who needs to understand it. One points at the other, and each stays good at the job it was built for.

The parts that bite

A few things are worth knowing before you ship this.

The rationale can be a story the model tells after the fact. A language model asked to explain itself will happily produce a plausible reason that is not the real cause of its behavior. You reduce this by requiring the reason to be committed as part of the action arguments before the action runs, not solicited afterward, and by keeping the inputs in the record so a reviewer can check the reason against the facts it claims to rest on. It is not a perfect window into the model's cognition, and you should not claim it is. It is a contemporaneous, checkable statement of intent, which is what an audit actually needs.

Append-only has to mean append-only. If your "audit log" lives in a table that your app can update or delete, it is not an audit log, it is a cache. Put it somewhere with write-once semantics, a WORM bucket or a ledger database, and let the hash chain prove the ordering. The first question a serious auditor asks is whether the record could have been changed, and "trust us" is not an answer.

Redaction and retention fight each other, so decide on purpose. The inputs you record are the ones the decision rested on, which means they can contain exactly the personal data you are otherwise trying not to hoard. Redact or tokenize at write time, keep enough to defend the decision, and set a retention policy that matches your legal obligation rather than keeping everything forever out of habit. This is the same tension I wrote about for output guardrails and egress, and it does not go away just because the destination is a log.

And do not try to audit everything. If you emit a decision record for every span, you drown the signal and your review becomes as useless as the raw trace was. Reserve the audit log for consequential actions, the ones with a real-world effect, and let ordinary reasoning steps stay in the trace where they belong.

The takeaway

Traceability and auditability feel like the same thing right up until a person with authority asks you to prove a decision, and then the difference is the whole ballgame. A trace records that your agent acted. An audit trail records what it decided, why, under which rule, and who stands behind it, written at the moment it happened and sealed so it cannot be quietly changed. Build the decision log as a thin, boring layer at the same seam where you already enforce policy, keep it append-only and tamper-evident, and make it answer questions in plain sentences. The traces are for you. The audit trail is for everyone who comes asking later.

If your agents are moving money, touching records, or telling customers yes and no, and your only answer to "why" is a trace someone has to interpret, that gap is worth closing before an auditor or a lawsuit closes it for you. Book a consultation call and we can look at where your agents make consequential decisions, what you are capturing today, and how to turn it into a record that holds up.