Disclosure: BlueBear builds an agent platform that produces audit evidence, so we have a commercial interest in this distinction. The article is explicit about what your existing observability genuinely does cover, because overstating the gap would be the easy and dishonest version of this argument.
The short answer: different question, different reader, and two fields that cannot cross
These are conflated constantly, usually in a meeting where an engineer says "we have full tracing" and a compliance lead says "so we have an audit trail". Both are being reasonable and they are talking about different artefacts.
| Observability | Audit trail | |
|---|---|---|
| Question | Is the system working? | Was this action allowed? |
| Reader | An engineer, now, with context | A reviewer, later, with none |
| Unit | The request, the span, the service | The action, and who stood behind it |
| Completeness | Sampling is correct and necessary | Sampling is fatal |
| Retention | Weeks, sized by cost | Years, sized by obligation |
| Mutability | Format changes freely; that is healthy | Append-only; schema change is controlled |
| Optimised for | Volume and query speed | Completeness and durability |
| Cannot record | The policy decision; the business outcome | Nothing — those two are the point |
Notice that the differences are not degrees of the same thing. Sampling is correct for one and disqualifying for the other. A retention period that is responsible in one is non-compliant in the other. These are opposed requirements, which is why one store cannot serve both.
What observability genuinely does give you
It would be easy and dishonest to argue that existing tooling contributes nothing here, so let us be specific about what it does.
Distributed tracing gives you the shape of a run: which calls happened, in what order, how long each took, where the latency went, which one failed. For agents specifically that is more valuable than it is for ordinary software, because the sequence was chosen at run time and there is no code to read that describes it.
The open conventions for AI telemetry have improved this materially — there are now agreed field names for a model call, its tokens and its operation, which means an agent trace is legible to tooling without inventing a private format. If you are instrumenting agents, using those conventions is straightforwardly the right decision. AI agent observability with OpenTelemetry is the existing technical guide.
What you should keep: all of it. This argument is and, not or.
The four things tracing cannot tell you
1. Whether the action was permitted, and by which rule. A permission decision exists for a moment inside a decision function. It is not an execution event, so nothing observes it unless something deliberately emits it — and a tracing system, by design, observes rather than participates.
2. Who was accountable. A trace records which service made a call. An audit record needs the human or team behind it and the boundary they belong to, established from the credential at admission. Service identity and accountability are different concepts and only one of them is in a span.
3. Whether the result was accepted. This never exists in your infrastructure at all. It exists in a person's judgement or a downstream approval. No amount of instrumentation reaches it; it needs a producer in the product surface where the work is accepted.
4. Whether the plan is what ran. This one is recoverable, but only if you decided in advance to record the plan as a separate event from the execution.
That fourth point is worth expanding, because it is the place where the two worlds touch most interestingly, and it is concrete in our own system. Our route planning and its execution are deliberately separate records. Routing runs in one of three modes — off, shadow or active — and in shadow a plan is produced and recorded while execution is unchanged. Because the two are distinct events, the system can classify the relationship between them rather than assuming it: an exact match, an expected mismatch because shadow mode was running, an expected mismatch because a fallback fired, or an unexpected mismatch, which is the one worth an alert. There is a corresponding record of whether the plan was honoured at all, with named reasons covering cases like the model not being executable or the provider being unavailable.
A tracing system watching the same traffic sees only the call that happened. It cannot report an unexpected mismatch, because it never saw the plan. The plan-honoured gap is the detailed treatment.
Where the two stores meet
They should share exactly one thing: the run identifier.
That single shared value means an incident found in one can be pursued in the other. A reviewer with an audit record can pull the trace for latency and error detail. An engineer with a trace can pull the authority record for who and why. Neither store has to grow into the other's job.
| Goes in telemetry | Goes in the audit record |
|---|---|
| Span timings, latency, service topology | Actor, tenant or workspace, credential reference |
| Token counts, model name, operation | Policy evaluated, decision, reason |
| Errors and stack detail | Plan, approval, and what the approver was shown |
| Steps per run, retries | What executed, and whether it matched the plan |
| Sampled, weeks, mutable format | Complete, years, append-only, versioned schema |
The conversation this usually settles
If you are having the "do we already have this" argument internally, the fastest way through it is not a principled discussion. It is the retention numbers.
Ask what your telemetry retention is, and ask what your obligation is. If the answers are thirty days and seven years, the argument is over and nobody has to be wrong about anything. That framing also makes the budget conversation easier, because the audit store is small — authority records are tiny compared with spans — and the two costs are not comparable.
The second-fastest route is the reconstruction drill in audit trail vs. application logs: hand one action to an uninvolved person and see what they can produce in a day.
If you operate in a regulated industry
Ask your observability vendor one question in writing: are these records sampled, and at what rate? Sampling is a default nobody volunteers because to an engineering team it is not a defect. It is, however, the property that disqualifies telemetry as evidence, and it is better discovered now than during an examination. Audit trails for financial services covers what a review expects.
If you are a platform or engineering lead
Do not extend the tracing pipeline to carry authority records. It is a tempting shortcut — the plumbing exists — and it ends with a store that is sampled, short-lived and mutable being asked to do a job with the opposite requirements. Separate stores, one shared identifier. The control plane architecture walkthrough covers where each record is written.
If you resell this to customers
Your customers may ask for their audit records and will never ask for your traces. That asymmetry tells you which store needs per-customer partitioning and export, and it is the cheaper of the two to get right early. Multi-tenant isolation for buyers covers the boundary.
Do this next
Look up two numbers: your current telemetry retention, and the longest retention obligation that applies to what your agents do. If they differ by an order of magnitude, you have your answer and your business case in one line. Then read what to trace in an AI agent for the telemetry side, or the audit trail requirements list for the other one.
Questions people actually search for
- observability vs audit trail
Observability answers "is the system working" for an engineer, and sampling is correct because the goal is to find problems. An audit trail answers "was this action allowed" for a reviewer, and sampling is fatal because the goal is to establish accountability for a specific instance. They differ in reader, retention, completeness requirement and content, and the two fields an audit trail needs most - the policy decision and the business outcome - are ones a tracing system structurally cannot observe.
- can observability replace an audit trail for ai
No, for a structural reason rather than a feature gap. A tracing system observes execution: it records events that happened in the software. A permission decision and a business outcome are not execution events - the first exists for a moment inside a decision and is not emitted unless something deliberately emits it, and the second exists in a person judgement outside your systems entirely. No amount of additional instrumentation reaches either.
- do I need both observability and audit logging for ai agents
If agents take consequential actions, yes, and they should be separate stores. They have different retention - weeks against years - different completeness requirements, different readers and different cost profiles. Trying to make one store serve both produces something too expensive to keep for the required period and too incomplete to rely on when a specific instance is questioned.
- what can tracing not tell you about an ai agent
Four things. Whether an action was permitted, and by which rule. Who was accountable, as distinct from which service made the call. Whether the result was accepted by the business. And whether the plan the system formed is the plan that actually ran, unless the plan was recorded as a separate event. The first and third are unrecoverable afterwards; the fourth is recoverable only if someone decided in advance to record both.
- how long should you keep ai agent traces
Traces: weeks, sampled, sized by what is useful for debugging and by cost. Audit records: years, complete, sized by whichever obligation reaches furthest. The fact that these two answers differ by two orders of magnitude is the practical reason they cannot share a store, and it is usually the argument that settles the internal debate faster than any principled one.