Who owns the work when a Cloudflare agent goes offline?

A customer asks for a refund. An agent checks the order, reads the policy, and begins to prepare the request. Then the connection drops. When the customer returns, should the agent run the checks again? Has the refund already been submitted? Can a support specialist tell which step was completed? These questions matter more in production than whether the first response sounded fluent.

By Cloudflare OS here, I mean Cloudflare’s open-source Agents SDK, Think, and the platform services around them, not a separate operating-system product. The SDK supplies persistent execution primitives. Think supplies an opinionated model-and-tools loop for conversational agents. Treating the two as interchangeable can obscure where a process is actually durable and where you still need application logic.

Separate the loop from the place it runs

A single model request can answer a simple question. An agent task often has several steps: inspect data, call a tool, interpret the result, perhaps call another tool, and decide whether to continue. The harness organizes that loop. But the loop also needs somewhere to run, a place to store state, and a recovery plan if execution is interrupted.

In the Cloudflare Agents SDK, an Agent runs on a Durable Object. Each instance has an addressable identity, its own storage, and a lifecycle. A product team might choose one agent instance per customer account so conversation state does not mingle across accounts. That mapping does not automatically grant the right person access to the right instance. Authentication, tenant boundaries, and authorization still belong in the application design.

Think sits a layer above the runtime. It brings together persistent messages, the tool-calling chat loop, streaming responses, and resumption after a client disconnect. A chat agent is not the only shape of useful work, though. A process with explicit background steps may be easier to reason about using the SDK with Cloudflare Workflows. The distinction helps a team choose where to put state rather than fitting every task into a conversation.

What happens after an interrupted refund?

Suppose the agent retrieved the order and then lost its client connection. A persistent session helps it recall the conversation. It cannot, by itself, prove whether the external refund system accepted a request whose response was lost. The downstream system may have performed the refund before the network failure. Durable agent state and exactly-once business effects are different problems.

For work inside an agent, Cloudflare documents fibers: runFiber() records a task, stash() preserves intermediate data, and recovery logic can run when the instance is activated again. For independent, multi-step work with step-level retries, Workflows offers another approach. Neither feature removes the need to make external side effects safe to retry.

A refund request should carry a stable operation key derived from the order and the particular request. On a retry, the application can ask for the result of that operation rather than issuing an unrelated second refund. If the external API lacks idempotency support, the application must maintain its own record of what it submitted and reconcile that record against the external system. A harness can help work survive interruption. It cannot decide the refund policy or repair an ambiguous payment outcome for you.

Human approval is a business state

Some requests should pause for a person. A refund approaching a contractual exception limit is one example. While approval is pending, the agent can acknowledge receipt without implying that the money has been returned. Those statements represent different states of the process, even if the customer sees them in the same chat window.

Workflows can support long-running steps with human approval in the middle. But adding an approval button is only the beginning. A team must decide who is allowed to approve, when an approval expires, and what data needs to be checked again after the wait. If the order changed while the request was pending, the agent should not blindly act on its earlier snapshot.

This is a useful distinction: preserving the agent’s state does not preserve the validity of a business decision. A persistent conversation can also preserve stale assumptions. Before a consequential tool call, verify current data and current authority. That applies whether a person or an agent prepared the original recommendation.

Leave a record a colleague can use

When a case moves from an agent to a support specialist, a full transcript of every internal step is not necessarily helpful. A compact operational record usually is: request ID, timestamp of the order data, tool invoked, response from the external system, and whether approval is pending. With those fields, someone can answer the customer’s follow-up without pretending to know what happened.

Cloudflare offers building blocks for state, scheduling, and observability. The application team still chooses the retention policy and what information is appropriate to record. A log should not become an accidental store of personal data. Keeping an order reference and a link to an authorized system may be more useful than copying an entire address into a debugging trace.

Before implementing the agent, write down the path through three failures: a disconnected client, a timed-out external API, and an approval that arrives after the order changes. For each one, identify what can be retried, what must be checked, and who is responsible for resolving an uncertain result. Then choose between an agent-internal task and a separate workflow. These choices make the infrastructure fit the process instead of letting the infrastructure invent the process.

The practical test is not whether an agent can resume a chat; it is whether the team can explain the status of a real request after something goes wrong. Cloudflare’s toolkit helps operate and recover individual agents. Defining their roles and accountability across a company is a different layer: agentic-organization is a self-hosted, file-based platform for managing AI agents as first-class members of an organizational chart.