Agent Traces and a GxP Audit Trail

TL;DR Anthropic now exports Claude agent step as an OpenTelemetry trace; here is what that telemetry can and cannot do for a clinical audit trail.

The GxP impact, hiding in plain sight

Halfway down the setup page for Anthropic's new trace export, below the instructions for choosing a destination and above the notes on data retention, sits a critical sentence for the GxP world: "Exported spans aren't guaranteed to be a complete record of your API usage."

Anthropic is being admirably plain there. On October 14, Anthropic released a public beta (an early version open to everyone, still being tested) of a new feature for Claude Managed Agents, the Messages API, and its SDKs. The feature is called OpenTelemetry export, and it works like a flight recorder for software: every time Claude does something, such as thinking through a request or looking something up in another system, a short timestamped note is written down. I explain traces in more detail below. For an engineering team trying to work out why an agent took eleven minutes and four tool calls to do something that should take one, this is a very good week.

Two weeks ago I wrote here that an agent's summary of its own work is a claim and the audit trail is the record. The question that piece left open has now arrived with a product attached: if every step an agent takes can be streamed into a tool your IT department already runs, is that stream the audit trail? My answer is no. It is extraordinarily useful evidence, and it belongs in your validation plan, but it should never be the thing you hand an inspector as the record of what happened to a subject's kit or a site's inventory. The rest of this piece explains why, and what to do with traces instead.

What a trace actually is

A trace is a timeline of one piece of work, broken into nested steps called spans. Think of it as the itinerary a careful traveller keeps: the trip as a whole, and inside it each flight, each taxi, each hotel check-in, with the time each one started and ended. In an agent, the trip is a single turn of work; the flights and taxis are the individual calls to the model and the individual tool calls, such as a query to an IRT (interactive response technology) system or a write to a spreadsheet.

Anthropic's Agent SDK documentation lists the spans by name. One wraps each turn of the agent loop. Underneath it, one wraps each call to the model, carrying the model name, latency, and token counts. Another wraps each tool invocation, with child spans for the time spent waiting on a human's permission and for the execution itself. When an agent hands work to a subagent, the subagent's steps nest under the parent's, so a whole chain of delegation appears as one trace.

OpenTelemetry is the open standard that makes all of this portable. It is why a span produced by Claude can land in the same Datadog dashboard as a span produced by your own Java service, and why the two can be stitched together. Anthropic says its traces follow the OpenTelemetry GenAI semantic conventions, which are the agreed names for things like "model," "input tokens," and "tool call." Those conventions are younger than they look; Dennis Zhuang of Greptime noted in May that they were still in development status, and ibl.ai's engineering team reported this month that they had moved to a dedicated repository with no tagged release yet. None of that is a reason to avoid traces. It is a reason not to build a regulated record on a schema that may rename its fields next quarter.

What the documentation says about completeness and content

The platform documentation is unusually candid on the two properties a quality person would ask about first.

On completeness, it says delivery is "best effort, so a span can be lost," that exported spans "aren't guaranteed to be a complete record," and that "spans can arrive more than once, for example when a delivery is retried." The Agent SDK documentation adds that the exporter fails silently by default; if the collector is unreachable, the agent keeps running and the telemetry is dropped without an error. It also notes that telemetry is batched and exported every few seconds, so a process killed mid-task can lose whatever was still in the buffer.

On content, the default is what Anthropic calls metadata only: identifiers, timing, status, token counts, and the names you gave your agents and tools. The prompts, the model's responses, and the data a tool returned are not in the trace unless you switch the destination to full content. With full content on, each span holds up to 0.75 MB before it is truncated and flagged. One detail will interest anyone working under a business associate agreement: if an organization has a HIPAA data-handling restriction with Anthropic, platform destinations export only metadata regardless of the setting.

Put those two properties next to the language of 21 CFR 11.10(e), and the mismatch is plain. Part 11 asks for "secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions," says that "record changes shall not obscure previously recorded information," and requires the trail to be retained at least as long as the records it covers. A stream that may drop entries, may duplicate them, and by default omits what was changed, and whose retention is set by whoever administers your observability platform, was never designed to meet that description. Anthropic does not claim it does; the documentation sends anyone needing authoritative usage figures to a separate Usage API.

Before anyone writes in to say that a well-governed Splunk instance can be validated: yes, a log platform can be validated like any other computerized system, and I am not aware of anything in Part 11 that forbids it. The problem sits upstream of the platform. A validated store faithfully holding an incomplete, best-effort feed is a validated copy of an incomplete feed.

Three records of one dispensation

Here is how this plays out in a system most readers will recognize. Suppose an agent assists a depot team by processing a resupply request: it reads the site's inventory in the IRT, checks expiry dates, and creates a shipment of twelve kits.

At the end of that work, three records of the same event exist. The first is the agent's own summary, which says it shipped twelve kits; my earlier piece covered why that is only a claim. The second is the trace, now sitting in your observability tool, which shows a model call, a read from the IRT, and a write to the IRT, each with a timestamp and a duration. If the destination is set to metadata only, it does not show which kits, which site, or what the inventory count was before and after. The third is the IRT's own audit trail, written by the validated system at the moment the shipment record was created, with the user identity, the old and new values, and a timestamp the agent could not touch.

The IRT audit trail is the record. It was built to be, it was validated to be, and it is the one the inspector will ask for. Clinical research has an advantage here that most software teams would envy: our systems of record already carry the audit trails regulators expect, and an agent that acts through them inherits that protection automatically. The risk is an agent that acts around them, through a spreadsheet, a shared mailbox, or an unvalidated script, where the trace becomes the only evidence that anything happened at all.

What the trace adds is the part the IRT cannot see: why the agent made that write. It shows what the agent read first, how long it deliberated, whether it waited for a human's approval, and whether a subagent did the work. When a shipment looks wrong a month later, that is exactly the material an investigation needs.

What clinical teams should do

I use these tools daily, and I would turn trace export on for any agent touching trial operations. These are the rules I would write into the validation plan alongside it.

1. Name the system of record for every write an agent can make. For each tool the agent can call, the validation plan should state which validated system's audit trail records the action. If the answer for any tool is "the trace," that tool should not be available to the agent in a GxP context.

2. Route regulated actions through interfaces that write their own audit trail. An agent creating a shipment should do so through the IRT's API under its own service identity, so the IRT records the action the same way it records a human's. The trace then explains the action; it never substitutes for it.

3. Choose the content mode as a data-handling decision, not a debugging preference. A full-content destination receives prompts, responses, and tool results, which in our world can include subject identifiers, kit numbers, and site correspondence. That destination is now a system holding trial data, with its own access list and retention settings. If your organization has not assessed it as one, leave the destination on metadata only. Note also that the platform documentation says Managed Agents are not eligible for zero data retention, and that turning on trace export does not change that.

4. Use traces to reconcile, and read gaps in the right direction. My earlier piece recommended reconciling an agent's claims against the record. Traces make that reconciliation automatable: every write span should match an audit trail entry, and every audit trail entry made under the agent's identity should match a span. Read the mismatches asymmetrically. An audit trail entry with no matching span may be a dropped span, which the documentation says can happen. A span showing a write with no matching audit trail entry is a deviation to investigate.

5. Make the two records joinable. The Agent SDK propagates standard trace context, and spans carry request and session identifiers. Where your system of record accepts a reference field on a transaction, store the trace identifier there. An investigator who can move from an IRT audit entry to the exact trace that produced it, in one lookup, will thank you for it.

Try this tonight

If you already have an agent connected to anything in your clinical stack, pick one completed run and try to answer the four questions an inspector would ask about it: who performed the action, on which record, what the value was before and after, and when. Answer each one twice, once from the trace and once from the system of record. The column the trace cannot fill is the reason it is not your audit trail; the column only the trace can fill, why the agent acted, is the reason to keep it.

Credit where it is due

The Claude Platform team deserves credit for documentation that states its limits instead of burying them; the sentences quoted above did most of the work in this piece. Dennis Zhuang's write-up on the GenAI semantic conventions is the clearest explanation I have found of how content capture is meant to work. Gabriel Buta's iSpeak piece for ISPE on what §11.10(e) actually requires is worth reading in full if your audit trails are append-only tables and you have never been asked to prove they are tamper-evident. The ibl.ai engineering team's post on agent observability standards makes a similar argument from the financial services side, where SEC Rule 17a-4 got there first.

At BC Consulting, we run AI Bootcamps and build custom tools for sponsors and service providers in clinical research, including agent workflows designed so the audit trail and the trace tell the same story. If your team is turning on agent observability and wants to work out where it sits in your validation approach, I would be glad to talk.

Talk About Your Team: https://bcconsulting.io/book Browse the Catalogue: https://lms.bcconsulting.io/catalogue

Sources

Anthropic, "Agent observability on the Claude Platform," Claude Blog, October 14, 2026, https://claude.com/blog/agent-observability-on-the-claude-platform Anthropic, "OpenTelemetry" (beta), Claude Platform Documentation, accessed October 20, 2026, https://platform.claude.com/docs/en/manage-claude/opentelemetry Anthropic, "Observability with OpenTelemetry," Claude Agent SDK Documentation, accessed October 20, 2026, https://code.claude.com/docs/en/agent-sdk/observability Tom Smith, "Claude Platform Now Sends Agent Traces Straight to Your Observability Stack," DevOps.com, October 15, 2026, https://devops.com/claude-platform-now-sends-agent-traces-straight-to-your-observability-stack Dennis Zhuang, "How OpenTelemetry Traces LLM Calls, Agent Reasoning, and MCP Tools," Greptime Blog, May 21, 2026, https://greptime.com/blogs/2026-05-09-opentelemetry-genai-semantic-conventions ibl.ai Engineering, "AI Agent Observability Has No Standard to Buy Yet," ibl.ai Blog, October 12, 2026, https://ibl.ai/blog/agent-observability-fragmenting-stack-own-the-audit-trail US Food and Drug Administration, 21 CFR 11.10, Controls for closed systems, Electronic Code of Federal Regulations, accessed October 20, 2026, https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11/subpart-B/section-11.10 Gabriel Buta, "What 21 CFR Part 11 §11.10(e) Actually Requires of an Audit Trail - and Why Most QMS Implementations Stop Short," ISPE iSpeak Blog, undated, https://ispe.org/pharmaceutical-engineering/ispeak/what-21-cfr-part-11-ss1110e-actually-requires-audit-trail-and-why Bryan Clayton, "What an AI Agent Says It Did Versus What the Audit Trail Shows," BC Consulting Blog, October 8, 2026, https://bcconsulting.io/blog/what-an-ai-agent-says-it-did-versus-what-the-audit-trail-shows