Cloudflare Durable Objects for AI: State and Recovery

Cloudflare Durable Objects for AI are useful when an assistant needs a stable place to coordinate a session or task. The difficult design question is what that state means. A conversation transcript, a running task and an approved business change should not become the same record simply because they belong to one assistant.

Use Durable Objects to coordinate clearly identified application state, then distinguish conversation history, task status and external business outcomes. Reconstruct work from persisted records after interruption, check current permissions on reconnect and keep model context separate from authoritative state. Durable storage is a building block, not a complete recovery policy.

Imagine a maintenance assistant preparing a service report. It gathers notes, drafts a recommendation and waits for a supervisor. The browser may disconnect during that wait. The supervisor may open the task elsewhere, and the underlying equipment record may change before approval.

This guide explains a proposed state design for that situation. It does not claim that retaining every conversation message is necessary or that an object’s identity automatically matches your organization’s access boundaries.

Cloudflare Durable Objects for AI need an identity model

Cloudflare describes Durable Objects as a platform for coordinating stateful applications. Before assigning an object to an AI feature, define what it represents: a conversation, an accepted task, a shared resource or another bounded unit.

An object per conversation can be convenient for interaction. A service report may need an identity that survives that conversation. If several colleagues collaborate on the same report, tying the report exclusively to the first browser session makes later access and handover confusing.

Derive routing identifiers from trusted application context. A caller who guesses another task identifier should not gain access to its content. Object routing and application authorization are separate responsibilities.

Keep authoritative facts outside conversational summaries

A model-generated summary can help the assistant continue a conversation, but it should not become the sole evidence that a supervisor approved a recommendation. Store the approval event against the report version and authenticated reviewer.

Likewise, keep the current task stage explicit. “Waiting for review” should be a recorded application state, not a sentence the assistant remembers from an earlier exchange. A later model response must not invent a transition because the transcript suggests that work probably finished.

Cloudflare’s conversation state and memory guide distinguishes persisted conversation history from the context supplied to a model. That is an important implementation distinction: stored information need not all be placed in the next prompt.

For the report, the assistant might receive a compact task summary and selected permitted evidence. The application can retain the authoritative source and event records separately, under their own access and retention rules.

Design transitions that reject stale decisions

Give each reviewable report a revision. A supervisor’s approval should identify that revision. If new notes arrive after the review page opens, the application must decide whether they invalidate the proposal or can be handled separately.

Check the current task state when an action arrives. A stale browser tab should not approve a cancelled report, and a repeated click should not create a second business operation. Return an established result where an action has already been accepted.

These are application rules. The state platform provides a place to implement them; it cannot decide whether a changed maintenance note is commercially significant or which supervisor has authority.

Recover from records rather than process memory

Treat in-memory values as temporary working state. Record the facts needed to resume the task and identify any external request already made. A restart should reconstruct the current stage without replaying the whole conversation through a model.

For the maintenance report, retain the source revisions, draft revision, approval state and destination operation reference. If the destination accepted the report but its response was lost, that reference is more useful than another generated explanation.

Differentiate work that never started from work whose outcome is unknown. Only the former is obviously safe to start. For the latter, inspect the destination or use its supported duplicate-prevention mechanism before another submission.

Test recovery by interrupting the application between meaningful stages. Then ask another engineer to identify the task and determine the next action from stored evidence. This exposes missing state that a normal success-path demonstration will not reveal.

Reconnect under current authority

When a colleague reconnects, authenticate them again under the application’s session rules and check their current task permissions. Do not assume that possession of an old conversation identifier preserves access indefinitely.

Load the task’s recorded status and observation time. Explain whether the system is waiting, processing, failed or awaiting reconciliation. If progress cannot be established, show that uncertainty rather than asking the model to supply a comforting answer.

Decide what memory is useful and what should expire

Conversation history, source documents and operational evidence can have different retention needs. Define those needs before adding automatic memory. Keeping every input forever makes later deletion and access review harder.

Separate reusable preferences from task facts. A preferred report format may remain useful across sessions. A temporary access token or a withdrawn customer detail should not become a permanent assistant memory.

When a source record is deleted or access is revoked, consider derived state as well as the original. A summary can contain the same sensitive fact as the source. The application needs a policy for stored drafts, retrieved passages and model-facing context.

For retrieval-heavy memory, our RAG data freshness guide covers updates and removals across an index. Do not treat a vector search result as an authoritative statement of the task’s current stage.

Choose state boundaries you can operate

Avoid making every concern a separate object before the workload justifies it. Too many boundaries can make a simple task harder to trace. Equally, placing every customer and task into an undifferentiated shared state creates access and ownership problems.

Start with a diagram showing how an authenticated request reaches a task, which records are authoritative and where an external business effect occurs. Identify the component that can explain each failure.

Cloudflare’s Agents overview provides the broader runtime context. Use the documented APIs appropriate to your selected version, and test experimental interfaces before making them part of a support promise.

The acceptance set should include concurrent reviewers, repeated actions, a source revision change, a reconnect and an unavailable destination. The useful outcome is not merely that state persists; it is that the application resumes the right work under the right authority.

Estimate state design and handover work

Implementation cost depends on task transitions, collaboration, source relationships and recovery requirements. A transcript store is much smaller scope than a coordinated task system with approvals and destination reconciliation.

Request a GBP proposal with explicit state ownership, access rules, retention behaviour and recovery tests. Include a plan for evolving stored records when application code changes. Existing tasks should not become unreadable after a deployment.

A bounded AI integration pilot can establish those contracts around a single useful task. Request a stateful assistant proposal with the task lifecycle, reviewers and connected systems. That brief makes the storage design follow your work instead of allowing a chat transcript to define it accidentally.

Frequently Asked Questions

Is AI memory the same as persistent storage? No. Persistent storage retains application information; model context is the information supplied for a particular inference. Decide which stored facts are authoritative and which are selected or summarized for the assistant.

Should every conversation have its own task? Only if that matches the business process. A conversation may discuss several possible tasks, while an accepted task may continue across several conversations. Give accepted work an identity that survives the interface where it started.

Does an object identifier prove the caller owns the data? No. Check authenticated identity and current permissions before returning state or accepting actions. A guessed or reused routing identifier must not widen access.

What should survive a restart? Persist the facts needed to establish the task stage, source and draft revisions, approval and external operation references. Temporary process memory should not be the only evidence of accepted work.

Can a conversation summary record an approval? It can describe one, but keep the authoritative approval as an authenticated application event tied to the exact proposal version. A model-generated sentence should not authorize a business change.

What should happen to stale browser actions? Check them against current state and revision. Reject or refresh obsolete decisions, and return the recorded result for an already accepted action where appropriate. Do not create another effect simply because the user clicked again.

What makes a stateful-assistant pilot useful? It should demonstrate identity boundaries, concurrent actions, interruption, reconnect and destination uncertainty. Another engineer should be able to recover the task from stored evidence without asking the model to reconstruct what happened.