Introducing Cloudflare Agents: Agent Tracing and Observability

We're bringing together everything you need to deploy and manage hosted agents on Cloudflare, starting with observability.

We've spent the last nine years building a developer platform, and agents are the perfect use case. They're really just another type of application, but what you need to build them — model access, durable runtime, orchestration, sandboxed execution, persistent storage — happens to be exactly what we've already built.

Now, we’re making it even easier to deploy and manage your agents on Cloudflare. Cloudflare Agents brings all of your deployed agent sessions into a single experience, surfacing key information and insights into how your agents perform at scale.

We are launching agent tracing for more direct visibility and insight into agent behavior. With agent-aware traces, you can now understand exactly what your agent is doing and what it costs: every model call, tool execution, and token is measured and presented here. Agent tracing launches today with support for OpenTelemetry-compatible agent harnesses including Think, Flue, and AI SDK, and more.

Agent traces are just the beginning. Once you have observability into your agent’s thought process and real-world behavior, you can start to analyze this data and make real improvements. Plug this data into your agent development lifecycle, and you suddenly have autonomous, self-improving agents. This is the vision for Cloudflare Agents: one place to deploy, observe, and continuously improve every agent you run.

An agent can return HTTP 200 and still fail. It may choose the wrong tool, pass stale context to a subagent, or spend tokens in a retry loop. Traditional application telemetry might show the API request or database query, but not the agent behavior that caused it.

Agent-level telemetry should answer questions such as:

• Where did the time go: the model, the tool, or the infrastructure?
• Did the turn pause for approval?
• Which model did the agent call, and how many tokens did the turn use?
• Did the agent choose the right tool?
• When the tool called an external API, did it receive a successful response or time out?
• Which subagent performed the work, and how did that work affect the final response?

Workers tracing already covers the infrastructure layer, including fetch calls, KV reads, and D1 queries, but until now, traces for agents running on Workers contained those infrastructure spans without the agent operations surrounding them. Agent tracing closes that gap, adding spans for agent invocations, model calls, tool execution, approval events, and supported subagent calls alongside the Workers data already captured. You also get context such as the model and token usage attached as metadata.

Starting today, agents built with Think, Flue, and AI SDK will send agent traces to Cloudflare, letting you visualize them in the dashboard or export them to a supported OpenTelemetry-compatible destination.

The Cloudflare dashboard now has a dedicated Agents view that lists observed agents and their traces alongside runs, sessions, instances, and reported token usage.

When you open an agent, you can visualize, understand, and debug what it’s doing in two ways:

Replay a session to review captured context across all turns

View a trace to inspect the execution of each turn

The Messages tab assembles the full conversation for a given turn: system instructions, user messages, the model's thinking, tool calls with their arguments and results, and the final response. It's a replay of recorded data, not a re-execution of the agent. This lets you catch a malformed tool argument, see the context available when a tool was selected, understand handoff to subagents, or identify how an earlier turn influenced a later result.

In this example, a user asks to plan a two-day trip to Lisbon. You can see the model's reasoning, watch it call destination_researcher twice (it retried), read the tool results, and follow its thinking as it moves on to building the itinerary. If the agent made a bad decision, this is where you find it.

Exactly what gets recorded depends on your harness or framework. For Think, Flue, and the AI SDK, storeMessages and storeTools control whether message and tool payloads are captured. You can turn payload recording off when that data may contain personal information, secrets, or other sensitive data.

The Traces tab shows the execution waterfall, where you can determine how time was spent and connect agent operations to Workers infrastructure.

In this trace, 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 waterfall:

• invoke_agent TravelPlanner: The parent agent invocation, 2.72 minutes total. Identifiers for the agent class, conversation, and Durable Object are attached so you can correlate across traces.
• invoke_agent itinerary_builder: The subagent, nested under the parent, taking 1.83 minutes of that time.
• chat @cf/zai-org/glm-4.7-flash: Model calls at each level, with duration and provider-reported token usage attached. The first call (17.59s) was the parent's routing decision; the subagent made its own calls underneath.
• execute_tool record_itinerary_builder_execution: The tool execution, 104ms.
• cloudflare-d1 run d1_run: A D1 query triggered by the tool, also 104ms.
• execute_tool record_respond_ready: The tool execution, 232ms.
• cloudflare-kv put kv_put: A KV write from a later tool, 232ms.

Workers tracing already instruments bindings such as KV, D1, Durable Object, service-binding, and fetch calls, so the Cloudflare infrastructure used by a tool appears under the agent operation that triggered it. Supported subagent calls nest under the parent when child work runs within the active traced context. That lets you follow a turn from the parent agent, through delegated work, to the Cloudflare resources each agent used.

First, enable tracing in wrangler.jsonc, the Worker's project configuration:

{
  "observability": {
    "traces": {
      "enabled": true,
    }
  }
}

Setup after that depends on the stack.

We’re working to support the OpenTelemetry API directly inside Workers. This means frameworks that already emit OpenTelemetry Generative AI semantic conventions spans will be able to visualize them in the Agents view without waiting for a Cloudflare-specific adapter. When those spans include standard agent and conversation identifiers, the Agents view can group them into agents and sessions just like our built-in integrations. Cloudflare can already export OpenTelemetry data; this adds the other direction by accepting standard telemetry generated inside Workers.

Your agent telemetry isn’t locked into Cloudflare. You can export traces to any OTLP-compatible provider by configuring a destination in your Worker’s Wrangler configuration file. Because every trace is structured, the same data that helps you debug agents can also power evaluations, analytics, and token-usage reporting. This means traces aren’t just something you inspect when things break, but also a feedback loop for improving your agent’s quality, performance, and cost.

Agent traces are built on Workers tracing, so pricing is straightforward. The Agents view shows your agent's operations, but the full Worker trace may include additional spans from SDK internals and other Worker-level operations. To see the full trace, click “View in Observability”.

Every span counts as an observability event, not just the ones visible in the Agents view. All tracing is currently free while in beta. Starting October 1, 2026, tracing pricing will be included as part of existing Workers Observability pricing:

Tracing is the first piece as we keep building out Cloudflare Agents into the place where you easily deploy, observe, and continuously improve every agent you run.

Ready to see what your agents are doing? Check out our documentation to enable observability on your agent and head over to the Agents dashboard to inspect your first trace or replay a session.