Cloudflare Agent Memory: Persist State Across Sessions

Agent memory on Cloudflare persists when you write it to a durable store before the Worker finishes. A Cloudflare Worker is a short-lived function that exits when a request completes, so any in-memory variable is gone by the time the next request arrives.

Choosing the right store depends on the shape of the memory: a session history looks different from a graph of facts, and a coordination log has different access patterns from a key-value cache. Tools like fenbs keep the shared project brief and human-approved decisions outside the runtime entirely, so the agent always has that context no matter which edge node handles its next request.

Why Cloudflare Workers lose state between requests

Each Worker invocation starts cold. Variables declared at the module level may be reused within a single isolate, but Cloudflare makes no guarantee across requests, and the isolate can be evicted at any time. An agent that stores a conversation buffer in a module-level variable will find it intact on the next request from the same isolate, but gone after an eviction, a deployment, or a request routed to a different edge location.

The practical test is simple: send a request that writes memory, wait for the isolate to be recycled (a few seconds of idle time usually does it), then send a request that reads it back. If the read returns the stored value, the agent is using a durable store. If it returns nothing, the memory was in-process.

KV for session memory and short-term recall

Workers KV is a globally distributed key-value store with eventually consistent reads. It suits agent session history: write the serialized conversation under a session key, read it at the start of the next request, and overwrite it when the session ends. KV values can be up to 25 MB, which is large enough for most conversation buffers.

KV is not suitable for memory that multiple Workers must update at the same time. Because KV is eventually consistent, two Workers writing to the same key at the same millisecond may each read a stale value before writing. If your agent needs coordinated writes, Durable Objects are the right layer.

Durable Objects for stateful agent coordination

A Durable Object is a single-instance class with its own transactional storage. Every request for the same object is routed to the same instance, which means you can hold a mutex, maintain a queue, or accumulate state without worrying about concurrent writes from different Workers. An agent that needs to coordinate with other agents, or that must guarantee an ordered write log, should model its shared memory as a Durable Object.

The tradeoff is that Durable Objects add latency when the client and the object instance are in different regions. For a solo agent reading its own context, KV or D1 is usually faster. Use Durable Objects when the coordination guarantee is worth the latency.

D1 for structured memory with SQL queries

D1 is Cloudflare's serverless SQLite database. It suits agents that need to query memory by attribute rather than by key: find all facts about a particular topic, retrieve the three most recent decisions, or join a task table against a context table. Write your memory as rows with typed columns, and query them with standard SQL from the Worker.

D1 is strongly consistent within a single write, which makes it safer than KV for memory that must be accurate. The tradeoff is that it requires a schema and migration management. Start with KV for quick experiments, then migrate to D1 once you know the shape of your memory. See how to build agent memory for a broader look at storage design.

Testing that memory survives across sessions

Run a three-step check after wiring up your store. Write a known value, wait for the isolate to be recycled, then read it back. The isolate recycles quickly when you pause requests for ten to twenty seconds.

• Write: send a request that stores a unique string under a known key.
• Recycle: stop sending requests for fifteen seconds or redeploy the Worker.
• Read: send a request that retrieves the key and logs the value.
• Check: verify the logged value matches what you wrote, not a default or an empty result.

Repeat the test after a redeployment. A redeploy evicts all isolates, so any in-process state is gone. If the read still returns the correct value after a redeploy, you have confirmed that the store is truly durable. For a wider look at memory persistence design, see what is agent memory and agent memory vs RAG.

Access boundaries for agent memory on Cloudflare

KV namespaces, D1 databases, and Durable Object bindings are scoped to the Worker that declares them. A Worker in one project cannot read the KV namespace of a Worker in another project unless you build an explicit API between them. This is useful security: it prevents an agent from reading memory it was not given access to.

When multiple Workers need to share memory, bind the same KV namespace or D1 database to each one, or expose a Durable Object over fetch. Design access boundaries deliberately: read access, write access, and delete access are separate permissions you grant at the binding level. For a closer look at the security implications of shared agent memory, see agent memory security.

How to do this with fenbs

Use Cloudflare's durable stores for the agent's operational memory. Use fenbs for the shared project context that the agent needs at the start of each session: the current tasks, the rules, and where the work was left.

1. Create a free account and add your project to fenbs. Write the rules your agent must follow as Decisions and rules.
2. Connect your assistant from /integrations. Ask it to call fenbs at the start of each Worker invocation to read Rules and Where we left off.
3. Choose a Cloudflare store for operational memory: KV for simple session buffers, D1 for structured recall, Durable Objects for coordinated writes.
4. Run the three-step persistence test after every change to your storage binding.
5. Before each session ends, ask the assistant to save progress in fenbs so the next session has an accurate starting point.