HomeServicesPortfolioAboutContactBlogCareers
Book a call
E-commerce

What to Log From an AI Support Agent — and Why the Audit Trail Matters

September 2026 · ISTRALLEN Team

One log, three jobs

An AI support agent audit log has to answer three different questions, and each needs something different recorded. Why did the agent refund this order? Why did this one conversation go wrong? What should we fix next? Build for only the first and you can't debug; build for only the second and you can't defend an action six weeks later.

Job 1: defend an action

For every action the agent takes — especially write actions like refunds, address changes, cancellations — record: which customer, which tool, the exact arguments, the result, the agent's stated reason, its confidence, the timestamp, and the model and prompt version. Append-only. This is the record you pull when someone asks why money moved. On our support agent project every action writes exactly this — customer, tool, arguments, result, and the agent's reason — so "why was this refunded" has an answer that isn't a guess.

Job 2: debug a bad conversation

Different needs: the full context sent to the model, the retrieved policy passages, the tool calls and their raw results, the model's raw output, and timing per step. This is verbose and expensive to keep for everything, so sample it — keep full traces for a fraction of conversations and for any that escalated or scored badly.

Job 3: improve the agent

Tag every escalation with a reason — missing tool, weak knowledge-base coverage, an unhandled intent, low confidence. Link each conversation to its containment outcome, any re-contact within a few days, and its satisfaction score. This is what tells you whether the agent is getting better and where the next fix is.

A concrete record shape

For a write action, a usable audit entry looks roughly like: conversation ID, customer ID, timestamp, tool name (create_return), the exact arguments passed, the raw result returned, the agent's one-line stated reason, the confidence score at the point of the call, the idempotency key, and the model and prompt version in effect. Ten fields, structured, one row per action. That's enough to reconstruct what happened and why, months later, without replaying the whole conversation.

Read vs write actions

Log both, but write actions get the fuller record and the tighter retention. A stale order-status answer is a minor bug; an unexplained refund is a dispute.

The tension with deletion

Complete, append-only action records pull against a customer's right to have their data erased. You resolve it by policy, not by keeping everything forever: define a retention window tied to your dispute and regulatory obligations, after which records are deleted or irreversibly anonymised, and make sure an erasure request inside that window is handled by a documented routine rather than an ad-hoc scramble. "We keep it because we might need it" is not a retention policy.

Keep PII out of debug logs

The structured audit record is deliberate and access-controlled. Application logs and error traces have wider access and looser retention — scrub personal data out of them. The two are different systems with different rules, not one big log.

Idempotency shows up in the log

A retried refund call must be visible as a retry, not a second refund. The idempotency key in the record is how you prove the customer was paid once.

Thread everything on one conversation ID

The transcript, the audit records, the escalation payload, the satisfaction survey, and any re-contact should all carry the same conversation ID, so "did this actually resolve" is answerable.

Where this stops being right

  • A read-only informational bot has almost nothing to audit — log the conversation and move on.
  • Scale retention to the consequence. An apparel store's refund log and a regulated context have very different retention needs.
  • Full context on every turn is expensive storage. Keep action records complete; sample the deep traces.

FAQ

What's the one thing we must log? Every write action with its exact arguments, its result, and the agent's stated reason. That's the defensible core.

How long do we keep transcripts? Your dispute or regulatory window, then delete — and make sure the deletion reaches every store, including backups.

Can we log the full model context for every message? You can, but it's costly. Keep action records complete and sample the full traces for debugging.

ISTRALLEN builds support agents with a per-action audit trail and outcome-linked logging designed in from the start; see AI for E-commerce.

See it in production
AI for E-commerce → Support agent case study →
← All articles