If you run agents in production, you probably already have observability: traces, dashboards, latency charts, token counts. So here is the uncomfortable question — if a regulator asked what your agent did on a specific Tuesday, would you hand them your tracing dashboard? Almost everyone says no. That instinct is correct, and it's worth understanding why.
Observability is for you. Accountability is for them.
Observability answers questions you ask about your own system: why is this slow, where did the error start, what changed after the deploy. Its audience is an engineer who already trusts the data because they operate the system that produced it. Accountability answers questions other people ask — auditors, regulators, customers, courts — and those people extend no such trust. They don't want a chart. They want a record that proves itself.
The two disciplines even fail differently. When observability fails, you find out fast: a dashboard goes blank, an alert goes quiet, an engineer complains within the hour. When accountability fails, nothing happens — for months. The gap only becomes visible on the day someone outside the company asks a question, and by then the record you needed either exists or it doesn't. That asymmetry is why teams with world-class monitoring can still be caught flat by a routine audit: nothing in their daily experience ever tested the thing the auditor tests.
Three gaps between a trace and evidence
- Traces are editable; evidence must be tamper-evident. Anyone with access to your observability stack can delete or rewrite what it holds, and nothing about the data would show it. An audit record needs the opposite property: every event signed at the source and chained to the one before, so any alteration is visible to whoever checks. It isn't that anyone on your team would rewrite a trace — it's that you cannot prove nobody could have, and "prove nobody could have" is the actual question.
- Traces are sampled; evidence must be complete. Observability samples aggressively because volume is expensive and debugging rarely needs every request. An audit trail cannot sample. "We retained ten percent of the evidence" is not a sentence anyone wants to say aloud to a regulator — and the one action that matters is always, by Murphy's law, in the ninety percent.
- Traces assert; evidence attests. A trace says "the system reports that this happened." A signed record says "the operator of this agent attested to this exact action, and here is the cryptographic proof — verify it yourself." The difference is who has to be believed, and the answer for evidence should be: nobody.
The day you notice the difference
A concrete version, because this is where it stops being abstract. A customer disputes something your agent did in March. It's now August. In the observability world, March is gone — the traces aged out on a 30-day retention policy, and what survives is an aggregate chart with no individual actions in it. In the recorder world, the March events are still there, still signed, still chained, and the dispute is settled by reading them. Same company, same agent, same incident — the only variable is which instrument was pointed at it.
Keep your observability. Add a recorder.
None of this is an argument against observability — you should absolutely keep your tracing and your dashboards, and nothing about a recorder replaces them. They are different instruments for different audiences, the way a hospital keeps both a whiteboard and a patient chart. The whiteboard is fast, informal, and wiped nightly. The chart is complete, signed, and what the review board reads. Trouble only starts when someone tries to make the whiteboard serve as the chart.
In practice the two even share a pipeline: the same agent activity that feeds your traces feeds the recorder, captured once at the source. There's no double instrumentation and no choice to make per event — the whiteboard and the chart are written in the same motion, each in its own form.
The one-question test
For any system your agents touch, ask: who has to believe this record, and does the record give them a reason to? If the audience is your own engineers, observability is exactly right. If the audience is anyone else — start with why agents need an audit trail, and see how the recorder works. Questions about running both side by side? Ask us.