Cloudflare Agents: Agent Tracing Is the Missing Observability Layer

Cloudflare has been quietly assembling the pieces for AI agents on its developer platform: model access via AI Gateway, durable runtime through Durable Objects, orchestration with Workflows, sandboxed execution, and R2 for storage. Today it's stitching those together under a single banner — Cloudflare Agents — with the first concrete feature being agent tracing.

Agent tracing is the observability layer that traditional application telemetry misses. An agent can return HTTP 200 and still fail: it picks the wrong tool, passes stale context to a subagent, or burns tokens in a retry loop. Standard Workers tracing already instruments infrastructure spans — fetch calls, KV reads, D1 queries — but it doesn't show the agent operations that caused them. Agent tracing fills that gap by adding spans for agent invocations, model calls, tool execution, approval events, and supported subagent calls, all alongside the existing Workers data.

The dashboard now has a dedicated Agents view listing observed agents, traces, sessions, and token usage. Two ways to dig in: replay a session or view a trace. The Messages tab reconstructs the full conversation for a turn — system instructions, user messages, model thinking, tool calls with arguments and results, final response. It's a replay of recorded data, not a re-execution, so you can catch malformed tool arguments or see how an earlier turn influenced a later result. Payload recording is optional; you can turn it off when sensitive data is involved.

The Traces tab shows the execution waterfall, connecting agent operations to Cloudflare infrastructure. In the example, a Travel_Planner agent delegates to an itinerary_builder subagent, which calls a model, runs a tool, hits D1, and writes to KV — all visible in a single view. The parent invocation takes 2.72 minutes, the subagent 1.83, model calls show duration and token usage, and tool executions are measured in milliseconds. That's the kind of granularity that makes debugging agents feasible.

Setup is straightforward: enable tracing in wrangler.jsonc, then use the harness-specific integration. Think and Flue emit telemetry through their tracing integrations; AI SDK gets wrapped with Cloudflare's wrapAISDK() adapter; custom harnesses use the custom spans API following OpenTelemetry's Generative AI semantic conventions. The longer-term goal is to support the OpenTelemetry API directly inside Workers, so any compliant toolkit will just work without a Cloudflare-specific adapter.

Traces can be exported to any OTLP-compatible provider, so your telemetry isn't locked in. And because traces are structured, they double as a feedback loop for evaluations, analytics, and token-usage reporting — not just something you inspect when things break, but a way to continuously improve agent quality, performance, and cost.