Agents are becoming production infrastructure — and their stacks are splitting into three layers

Agent harnesses — the systems that govern how a model interacts with the world, such as Codex, Claude Code, OpenCode, Pi, and Project Think — have matured enough that teams are now running them as real infrastructure rather than prototypes. But moving agents into production surfaces a consistent set of distributed systems problems that every agent hits once it runs in the cloud.

Those problems are not solvable by the harness alone. Graceful resumption after an interruption, secure execution of untrusted code, and proper tool use all depend on state, storage, and compute — which is to say, on the platform underneath. Cloudflare is taking the lessons from hardening its first-party harness, Project Think, and baking them into the Cloudflare Agents SDK as a base layer. Durable execution, dynamic code execution, a durable filesystem, and dynamic workflows are now available to any harness built on the SDK.

Above the harness, another layer has emerged. Frameworks such as Flue wrap a harness with the project structures, conventions, integrations, and developer experience that make agents practical to build. The emerging stack for production-grade AI looks like this:

  • The framework (Flue) — project structure, conventions, integrations, CLI, and developer experience.
  • The harness (Pi, Project Think) — the agentic loop that calls tools, reads results, manages context, and continues until completion.
  • The runtime/platform (Cloudflare Agents SDK) — the compute, state, and storage primitives everything else depends on.

The Agents SDK occupies that bottom layer, exposing durable execution to any harness or framework above it. Flue, an open-source framework from the team behind Astro, is the first to build on it.

Flue: declarative agents, not orchestration scripts

Flue shipped 1.0 Beta this week, built on the Pi harness — the same one underpinning OpenClaw. Its defining approach is declarative: rather than scripting what an agent does, you describe what it knows. Define its model, skills, sandbox, and instructions, and it autonomously handles whatever task you give it. No orchestration loop to write.

That declarative model keeps agent code compact. A triage agent that intercepts a bug report, reproduces it in a sandbox, and diagnoses the issue fits in under 25 lines.

BLOG-3336 2

Built for where users already work

Flue agents are designed to live where teams already collaborate, integrating with existing tooling:

  • Anywhere agents: Drop agents into Slack, GitHub, Linear, or Discord with pre-configured Channels that automatically handle event verification and dispatch boilerplate.
  • Headless, but UI-ready: Agents can run fully headlessly for background tasks, but @flue/react provides native frontend hooks that stream an agent's state, tool execution, and live messages directly into a frontend application — no custom real-time plumbing required.
  • Ecosystem-ready: Commands like flue add channel slack generate a Markdown blueprint that a coding agent can read, modify, and integrate cleanly into the codebase.

Durable Streams for production resilience

Production environments bring classic distributed systems failures: host crashes, LLM provider timeouts, unexpected restarts — all of which can wipe the short-term memory of a running agent turn. Flue addresses this with Durable Streams. Every event in the execution history is appended to an append-only log. Processing each prompt, tool response, and model choice as an immutable ledger keeps agent state non-volatile. If a process dies, another picks up the log and resumes from the exact step where it stopped.

Deploying on Cloudflare: agents as Durable Objects

Flue is multi-cloud. On Node.js, each agent runs as a long-lived process that can be deployed to any VM or container, run in GitHub Actions, or embedded in an existing server. When targeting Cloudflare, each agent becomes a Durable Object — automatically scaling to as many agents as needed, each with isolated storage and compute, without provisioning servers, managing sticky sessions, or worrying about noisy neighbors.

On Cloudflare, Flue agents also gain durable execution via the Agents SDK's runFiber(), stash(), and onFiberRecovered() methods, and use @cloudflare/codemode and @cloudflare/shell for sandboxed code execution against a durable workspace.

What agent harnesses actually require from a platform

Flue’s Cloudflare target maps well to the core primitives of the Agents SDK, and you can inspect the Flue source to see how the underlying harness, Pi, is adapted. That mapping works because the SDK provides the primitives that any modern agent harness needs to run reliably at scale.

Durable execution is non-negotiable

An agent turn is never a single request. The model streams tokens, invokes tools, waits for results, may ask a human for approval, or delegates to subagents. The whole sequence can take minutes, and at any moment the process can crash. Without protection, the in-memory agent state disappears — the streaming connection, pending tool calls, and the turn’s position. The conversation history may persist on disk, but the user sees an unresolved spinner. That is a broken experience.

Fibers solve this with native checkpointing inside the agent’s underlying Durable Object. runFiber() records progress to the Durable Object’s SQLite storage before work begins and checkpoints with stash() as the turn advances. If a fresh instance boots after an interruption, onFiberRecovered() delivers the last checkpoint so the harness knows a turn was interrupted, where it stopped, and how to resume.

Flue calls runFiber() in its Cloudflare target for this reason. The onFiberRecovered() hook lets the harness choose its recovery strategy — either a full reconstruction model like Project Think, which repairs the turn state, or a partial replay of the turn.

Please protect source block number for code shown here

Code execution beats ever-growing tool lists

Agent harnesses normally expose the outside world through tools, but tool surfaces expand quickly and models degrade at tool selection as the list and context window grow. A stronger pattern is a single code-execution tool: the model writes a TypeScript function that calls the APIs it needs, and the harness runs it. Cloudflare introduced this idea with Code Mode.

The key question is where that code runs. LLM-generated code needs a sandbox, but traditional sandboxes are too slow and costly for per-call use. The Agents SDK therefore ships @cloudflare/codemode, built on Dynamic Workers, which executes generated code inside its own Worker isolate with only the bindings you provide.

Code Mode creates a Dynamic Worker per snippet, runs it, and discards it. Isolates boot in under 10ms at $0.002 per load — far faster and cheaper than spinning up a container per tool call. Flue’s Cloudflare target uses @cloudflare/codemode to power its code tool: the model writes JavaScript against the workspace and executes it there.

Containers are overkill for most filesystem work

Harnesses often require a filesystem for reading files, writing outputs, searching code, and understanding diffs — coding agents in particular live in the filesystem. But in a serverless environment, that filesystem must persist across executions, and the usual answer — a container — is expensive for what agents actually do. Most filesystem operations in a turn are text-based: reading files, grepping source, or writing a patch. None of that needs a full Linux boot.

@cloudflare/shell provides a durable virtual filesystem inside the Durable Object, backed by SQLite, with typed operations — read, write, edit, search, grep, diff — that harnesses can use directly as tools.

A Flue agent on the Cloudflare target writes JavaScript against this virtual filesystem API instead of invoking individual tools. Running operations inside the Durable Object pushes more work into the efficient isolate model and avoids container overhead entirely:

Please protect source block number for code shown here

The result is a faster, cheaper sandbox for agents whose work consists mostly of shell and filesystem operations. For tasks that genuinely require a full OS — npm install, git, compilers — Cloudflare Containers covers that. Cloudflare is also building @cloudflare/workspace to keep a Durable Object’s virtual filesystem in sync with a container’s, allowing seamless transitions from lightweight Workers to a full Linux environment only when needed.

Let agents write their own repeatable workflows

Some agents must orchestrate large, multi-step pipelines that repeat reliably — a code review that consistently resolves bugs, or a research workflow producing solid results. A harness alone cannot provide durable multi-step execution; the platform must persist each step, retry failures, and resume after interruptions.

This pattern is gaining traction. Claude Code’s dynamic workflows, for example, have the model write a JavaScript script at runtime to hand work to dozens of subagents, and the runtime executes it durably. @cloudflare/dynamic-workflows brings the same capability to any harness on the Agents SDK. The model generates a workflow at runtime; the Workflows engine persists each step, retries failures, and can sleep for hours or wait for external events such as human approval.

The Agent class’s runWorkflow() connects the agent to the Workflows engine. The agent starts a workflow and can go idle. The workflow calls back into the agent via RPC for progress updates, state changes, or approval requests, and when the workflow finishes, the agent wakes with the result.

Ecosystem access without credential exposure

Beyond compute and storage, harnesses need external capabilities: web browsing, email, memory, search, and inference. A harness should not integrate each individually, manage separate API keys, or risk leaking credentials through generated code.

The Agent class exposes the rest of Cloudflare through bindings: AI Gateway for per-agent spend tracking and limits, Browser Run for automation, Email Service for inbox workflows, Agent Memory for persistent recall, AI Search for retrieval, Containers for full-OS workloads, and inference across 14+ model providers. Bindings confer capabilities without exposing secrets — the harness uses them, but keys never enter model-generated code.

Target the Agents SDK, get the platform for free

This architecture is the foundation Cloudflare used to build Project Think, its first-party harness. While Project Think remains the optimized default for native Cloudflare agents, the Agents SDK ensures the open-source ecosystem can use the same battle-tested primitives, Flue included.

Flue users can deploy to Cloudflare in a few clicks. Those building their own harness or framework should target the Agents SDK to inherit the platform integration automatically.