Cloudflare Adds Agent Tracing to Track AI Behavior Beyond HTTP Status Codes

Cloudflare has introduced agent tracing, a new observability layer for agents deployed on its Workers platform. The feature creates a dedicated dashboard to consolidate agent sessions alongside existing infrastructure telemetry, offering developers visibility into what happens inside an agent beyond success or failure status codes.

The core problem#

Traditional application monitoring sees only surface-level outcomes: an HTTP 200 response or a database query result. An agent can return 200 while failing internally—picking the wrong tool, passing stale context to a subagent, or burning tokens in a retry loop. Until now, tracing on Cloudflare Workers captured the infrastructure calls agents make (fetch, KV reads, database queries) but left their behavior itself invisible. Agent tracing fills that gap by instrumenting agent invocations, model calls, tool execution, and approval workflows.

What the traces show#

Each agent turn generates a waterfall view showing the call hierarchy: an invoke_agent span contains child spans for chat operations and tool execution, with subagent work nesting naturally beneath the operations that spawned it. Spans carry model and token usage as metadata. Three identifiers tie spans to the dashboard: agent name (the logical implementation), agent ID (the instance), and conversation ID, though Cloudflare cautions against deriving agent names from request or user data, which would fragment the view.

Developers have already signaled strong interest in this structure. A comment on Cloudflare's announcement captured the appeal: "seeing the model call directly above a bad tool argument is the debugging view i want"—exactly the kind of adjacency the waterfall provides.

Session replay and payload storage#

Beyond traces, session replay reconstructs the full conversation across turns, displaying messages, reasoning, tool calls with their arguments and results, and subagent activity. Importantly, Cloudflare replays recorded data rather than re-executing the agent.

Payload recording comes with a critical caveat: defaults are inconsistent across frameworks. Think and wrapAISDK() opt out of storing message and tool payloads by default, requiring explicit flags to enable them. Flue stores messages, system instructions, tool definitions, arguments, and results by default, requiring an explicit flag to disable. Since message payloads often contain personal data or secrets, teams get opposite privacy postures depending on their choice of harness.