Introducing: Cloudflare Agents

Cloudflare Agents: A Single View for Deployed Agent Sessions

Cloudflare is rolling out Cloudflare Agents, a unified experience for deploying and managing hosted agents on its platform. The goal is to consolidate all deployed agent sessions into one place, surface key performance insights, and give developers a clearer picture of how their agents behave at scale. The launch begins with agent tracing — purpose-built observability that exposes what an agent actually does and what it costs.

For Cloudflare, agents are a natural extension of its existing developer platform. The building blocks — model access via AI Gateway, durable state through Durable Objects, orchestration with Workflows, sandboxed execution, and persistent R2 storage — were already in place. Agents are just another application type, but one that demands visibility into its internal reasoning and tool use.

Agent Tracing Launches with Harness Support

Agent traces mark the first feature in Cloudflare Agents, offering direct insight into agent behavior that traditional infrastructure telemetry misses. An agent can return HTTP 200 and still fail — it might pick the wrong tool, pass stale context to a subagent, or burn tokens in a retry loop. Standard application monitoring can show the API request or database query, but not the agent actions that caused it.

Agent-level telemetry answers different questions:

• Where did 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 has long instrumented the infrastructure layer — fetch calls, KV reads, D1 queries — but traces for agents running on Workers stopped there. Agent tracing fills that gap by adding spans for agent invocations, model calls, tool execution, approval events, and supported subagent calls, all alongside the Workers data already captured. Model and token usage are attached as metadata.

Agent tracing is live today for agents built with Think, Flue, and AI SDK harnesses, all of which send traces to Cloudflare automatically. From the dashboard, you can visualize those traces or export them to any supported OpenTelemetry-compatible destination.

The dashboard now includes a dedicated Agents view that lists observed agents and their traces, along with runs, sessions, instances, and token usage.

Two Ways to Inspect an Agent

Opening an agent in the dashboard provides two complementary views of its behavior: a session replay and a trace waterfall.

Replay a Session

The Messages tab assembles the full conversation for a given turn: system instructions, user messages, the model's reasoning, tool calls with their arguments and results, and the final response. This is a replay of recorded data, not a re-execution of the agent. That distinction matters — it lets you catch a malformed tool argument, see what context existed when a tool was selected, understand handoffs to subagents, or trace how an earlier turn influenced a later result.

In one example, a user asks for a two-day Lisbon itinerary plan. The trace shows the model's reasoning, reveals two attempts at calling destination_researcher (the first retried), displays the tool results, and follows the thinking as it moves to itinerary construction. Bad decisions surface here.

What gets recorded depends on your framework. For Think, Flue, and the AI SDK, the storeMessages and storeTools options control whether message and tool payloads are captured. Payload recording can be turned off when traces may contain personal information, secrets, or other sensitive data.

Check the Trace

The Traces tab renders the execution waterfall, showing how time was spent and connecting agent operations to Workers infrastructure.

In a sample trace, a Travel_Planner agent delegates to an itinerary_builder subagent, which in turn calls a model, executes a tool, queries D1, and writes to KV, all captured in one view:

• invoke_agent TravelPlanner: The parent agent invocation, 2.72 minutes total, with identifiers for agent class, conversation, and Durable Object attached for cross-trace correlation.
• invoke_agent itinerary_builder: The subagent, nested under the parent, taking 1.83 minutes.
• chat @cf/zai-org/glm-4.7-flash: Model calls at each level, with duration and provider-reported token usage. The parent's routing decision took 17.59s; the subagent made its own calls beneath.
• execute_tool record_itinerary_builder_execution: A tool execution at 104ms.
• cloudflare-d1 run d1_run: A D1 query triggered by the tool, also 104ms.
• execute_tool record_respond_ready: Another tool execution, 232ms.
• cloudflare-kv put kv_put: A KV write from a later tool, 232ms.

Because Workers tracing already instruments bindings such as KV, D1, Durable Objects, service bindings, and fetch calls, Cloudflare infrastructure appears under the agent operation that triggered it. Supported subagent calls nest under the parent when child work runs within the active traced context. You can follow a turn from the parent agent through delegated work and down to each Cloudflare resource used.

Enabling Agent Tracing

Setup starts with enabling tracing in wrangler.jsonc, the Worker's project configuration:

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

From there, configuration depends on the specific stack in use:

OpenTelemetry Compliance on the Horizon

Cloudflare is working to support the OpenTelemetry API directly inside Workers. That would let frameworks that already emit Generative AI semantic convention spans visualize them in the Agents view without needing a Cloudflare-specific adapter. When those spans include standard agent and conversation identifiers, the Agents view could group them into agents and sessions just like the built-in integrations do. Cloudflare already exports OpenTelemetry data; this would add the reverse direction by accepting standard telemetry generated within Workers.

Exporting Traces and Pricing

Agent telemetry is not locked into Cloudflare. Traces can be exported to any OTLP-compatible provider by configuring a destination in the Worker's Wrangler configuration file. Since every trace is structured, the same data that helps debug agents can also power evaluations, analytics, and token-usage reporting — turning traces into a feedback loop for improving quality, performance, and cost, not just a debugging tool.

Agent traces are built on Workers tracing, and pricing follows that model. Each span counts as an observability event, including those not visible in the Agents view — the full Worker trace may have extra spans from SDK internals and other Worker-level operations, accessible via "View in Observability." All tracing is free while in beta, with pricing to be absorbed into existing Workers Observability pricing starting October 1, 2026.

Next Steps

Agent tracing is the first piece of Cloudflare Agents. The roadmap extends toward a single place to deploy, observe, and continuously improve every agent you run. For those ready to start, the documentation covers enabling observability, and the Agents dashboard is where you inspect your first trace or replay a session.