Claude Platform Agents Leave a Trail

Anthropic has added activity tracing across Claude Managed Agents, the Messages API and Claude SDKs. The update makes model calls and tool actions inspectable alongside application activity; it is not a new model or a view into private reasoning.

A plausible final reply can leave us with an operational question: what happened along the way? A trace records the agent's model calls and tool use, with latency, tokens and IDs. We can inspect those steps rather than trying to reconstruct the workflow from its answer.

Placed beside application logs and metrics, that record helps us locate which service a slow or failed step came from. It gives us somewhere concrete to investigate; the investigation and any repair remain separate work.

Claude Managed Agents, the Messages API and Claude SDKs can send traces to compatible OpenTelemetry tools. The shared format lets Claude activity appear in the same monitoring environment as the rest of our application.

Each agent turn, model call and tool use arrives with latency, tokens and IDs. Claude traces follow the OpenTelemetry GenAI semantic conventions and work with tools that accept a standard OTLP endpoint. The destination determines how we explore and use that data.

For an accounting workflow, the final answer is not enough to explain an agent's activity. FloQast connects its Claude Platform agents to Grafana Cloud, bringing model calls into the timeline of the financial work they run inside.

Ankush Sharma, FloQast's Head of Infrastructure, describes seeing prompt version, tool calls, latency and token spend alongside the rest of the stack. That is the practical value of a shared timeline: the accounting task and the agent activity can be examined together.

The destinations serve different jobs. In tools such as Grafana Cloud, Honeycomb, Sentry and Splunk, agent traces sit beside logs and metrics for debugging. Databricks Unity Gateway supports a view of token usage by team and unusual activity.

Evaluation tools provide another use for the record: turning real traces into evaluations and measuring whether a change helped. Exporting the trace supplies material for that process; it does not perform the improvement itself.

An agent turn might include a model call, a tool action and another model call. Following those recorded steps beside application logs and metrics helps us place a delay or failure in context. The sequence describes activity, not the model's private reasoning.

Once we have found something worth investigating, selected traces can become evaluation material. We can examine a quality issue and measure a proposed change against it. That is a deliberate next step, not an automatic consequence of switching tracing on.

We start with the public-beta setup guidance for our Claude integration. For Managed Agents and the Messages API, we add a destination in the Claude Console. Claude SDKs export traces automatically; we follow the current SDK guidance for our environment rather than assuming every environment needs no configuration.

We check that our monitoring destination accepts a standard OTLP endpoint, then open a trace and compare its model calls and tool actions with the surrounding application activity. Recorded latency and token usage give us a concrete starting point for inspection.

Before enabling the connection, we also check the current setup requirements and destination usage terms.

The useful change is where agent activity becomes visible. Model calls and tool actions can now sit beside the application records we already examine, with latency and token usage attached.

That gives us a better starting point for asking what happened. We still need to interpret the record, identify what it cannot explain and evaluate changes separately. The prompt below helps us review a redacted trace without filling its gaps with guesses.

A trace gives us recorded activity to investigate. Improving the workflow is the next piece of work.

Altior editorial takeaway