Cloudflare Agent Tracing: Truncation Limits and Uneven Payload Defaults

Cloudflare has launched agent tracing as the first component of its Cloudflare Agents dashboard, adding agent-level spans on top of the Workers tracing infrastructure already in place. The feature is free during beta, with billing switching to Workers Observability pricing on October 1, 2026. The gap it fills is real: an agent can return HTTP 200 while silently picking the wrong tool, passing stale context to a subagent, or burning tokens in a retry loop — none of which application-layer telemetry will surface. As agentic architectures become more common across production systems, the absence of agent-native observability has been an increasingly loud problem.

Span Hierarchy

Workers tracing previously covered infrastructure operations — fetch calls, KV reads, D1 queries — with no representation of agent behaviour above them. The new layer adds spans for agent invocations, model calls, tool execution, and approvals, with model identity and token usage attached as metadata. Each turn produces one trace:

invoke_agent {agent class}
├── chat {model}
└── execute_tool {tool}
    └── tool_approval {tool}

Subagent work nests under the invoking operation, so a parent agent delegating to a subagent that subsequently calls a model, executes a tool, queries D1, and writes to KV appears as a single waterfall across both layers. Three fields tie spans to the Agents dashboard: an agent name (the logical implementation), an agent ID (the instance), and a conversation ID. Cloudflare explicitly warns against deriving the agent name from a request or user identifier, which would fragment the view by multiplying distinct agent entries.

One documented constraint applies to the approval span: it records a lifecycle event within a Worker invocation, not the elapsed time a human takes to respond between invocations. Human-in-the-loop latency does not appear in the span record.

Payload Defaults Are Not Consistent Across Harnesses

Session replay reassembles recorded conversations across turns, covering messages, reasoning, tool calls with arguments and results, and subagent activity. Cloudflare is explicit that this replays stored data rather than re-executing the agent. What that data contains depends on which harness a team is using, and the defaults differ in opposing directions.

Agents SDK does not record message or tool payloads unless storeMessages and storeTools are explicitly set on the agent class; wrapAISDK() follows the same opt-in behaviour. Flue stores messages, system instructions, tool definitions, arguments, and results by default, requiring content: false to suppress them. The security implication is direct: message payloads routinely carry personal data or credentials, and teams migrating between harnesses need to audit which default applies. This concern is not hypothetical — poorly reviewed defaults in agent toolchains have already exposed sensitive material.

Cloudflare also documents three explicit limitations: traces are not a complete or lossless record of a conversation; payload data is subject to span size limits, meaning long messages, reasoning chains, tool arguments, and results may be truncated; and session replay does not render images. Teams intending to use replay as a compliance or audit trail will find it does not satisfy that use case.

Instrumentation and Pricing

Setup varies by stack. Agents SDK and Flue v2 or later instrument turns automatically. Direct AI SDK calls require wrapAISDK(), which supports SDK versions 6 and 7, and need identity fields supplied on each call since there is no Agent instance to infer them from. Custom harnesses use the Workers custom spans API following OpenTelemetry's GenAI reference implementations, because Workers does not yet support the OpenTelemetry API directly — Cloudflare states it is working to add that. Span attributes follow the OpenTelemetry Generative AI semantic conventions, and traces export to any OTLP endpoint.

The metered unit under billing is the observability event, not the agent span, and every span counts — including those generated by SDK internals and other Worker-level operations that the Agents dashboard view does not surface. Retention windows are short for pattern-hunting workloads:

A verbose harness with SDK internals generating spans at each step will consume the allowance faster than the dashboard view implies, since users see agent-layer spans but pay for all spans emitted beneath them.

Context

Cloudflare's release follows a pattern across infrastructure vendors: the agent runtime needs its own telemetry layer, and infrastructure spans alone cannot reconstruct what an agent decided or why. Cloudflare frames tracing as groundwork for an agent development lifecycle that eventually feeds trace data into evaluations — that remains a stated direction rather than a shipped capability. What ships today is structured visibility into which model a turn called, how many tokens it consumed, which tool was selected, and where wall-clock time went. For teams already running agents that interact with external systems and corpora, that is a meaningful baseline — provided they audit their harness's payload defaults before enabling session replay in any environment handling sensitive data.