Does Cloudflare Agents Remember Between Sessions?

Yes, inside one agent instance. A Cloudflare Agents SDK agent is a Durable Object, so it keeps its state and its message history in storage that survives restarts, deploys, and hibernation. A new session routed to the same agent instance picks up where the last one left off. A different agent instance, or a different tool entirely, does not see that state unless you share it.

That distinction is the whole answer. Cloudflare Agents gives an agent a durable home. It does not give every agent you run a shared memory.

What is a Cloudflare Agents SDK agent, exactly?

Cloudflare's Agents SDK is a JavaScript framework for building stateful agents on Cloudflare's network. Each agent is built on a Durable Object, which Cloudflare describes as a persistent object with identity, state, and built-in concurrency control.

In practice, that means one agent instance is one addressable, single-writer object. Requests for that agent always route to the same instance. The instance carries its own storage, its own WebSocket connections, and its own scheduler, so it can wake itself up for periodic work.

This is the opposite of a plain serverless function. A function starts cold, runs, and forgets. A Durable Object instance stays addressable, and its storage stays put between requests.

What does an agent instance keep between sessions?

Two things, and both belong to that instance.

First, state. The Agent class exposes a state object that is persisted, with setState to update it and onStateChanged called when it changes. Put a user's preference, a task's progress, or a ticket's status in state, and it is still there the next time that agent instance wakes up.

Second, messages. The SDK persists conversation messages to the agent's embedded SQLite database, so the conversation history for that agent survives inactivity and restarts. The agent also exposes sql for direct queries against that embedded database, which is the right place for structured records the agent needs to look up fast.

While a session is live, this is plenty. The agent follows a conversation, remembers what was said earlier in it, and uses what it stored in earlier sessions with the same instance.

What happens when a new session starts?

It depends on which instance the session reaches.

Cloudflare routes a session to an agent instance by name or id. If you route the returning user to the same instance, the agent loads its persisted state and messages and continues from there. That is the design Cloudflare's own OpenAI Agents SDK example relies on: the agent lives inside a Durable Object, state is persisted, and the agent's memory is hydrated before a run and saved after it.

If you route the session to a new instance, that instance starts with its own empty state. Nothing is shared between instances by default. Two agent instances are two separate homes, even if they run the same code.

This is where builders get surprised. The framework remembers, but it remembers per instance. A user who gets a fresh instance looks like a stranger, and an agent that runs on a schedule with a new instance each run wakes up blank every time.

What does Cloudflare Agents not remember on its own?

It does not turn stored state into long-term memory across agents, tools, or platforms.

State is what you put in it. If you never save a fact, it is not there to recall. If you save everything, the agent has to sift through it, because raw state is not the same as retrieved context. And state keyed to one Durable Object does not travel to your n8n workflow, your coding assistant, or a second agent built with a different framework.

The same boundary applies to scheduled work. An agent that wakes itself up on a schedule can read its own persisted state before it acts, which is a real advantage over a stateless function. But that state still lives inside that one agent instance, on one platform.

How do you give a Cloudflare agent memory that travels?

1. Route by stable identity, not by accident. Resolve the user, customer, or job to one agent instance name before the session starts, and use that same name every time. If the routing key changes, the memory is orphaned in the old instance.
2. Decide what state is for, and what history is for. Keep task progress and current status in state. Keep the conversation record in the message store. When the two disagree, the message record is the evidence and state is the summary.
3. Write back at the end of every session, not just when something interesting happens. A session that ends without a save leaves the next session reading stale state. Make the save part of the session lifecycle, not an optional step.
4. Put memory that must cross agents and tools in a layer outside any single instance. A built agent connects to Vilix AI with an API key as a Bearer header to https://api.vilix.ai/mcp and gets full memory with zero memory infrastructure to run. Retrieval is semantic as well as keyword-based, so it finds what was meant, not just what was typed, and it stores the full conversation history, not just extracted facts.
5. Test the second session, not just the first. Talk to the agent, state a fact, end the session, and start a new one routed to the same instance. If it greets you as a stranger, the routing key is wrong. If it remembers the old value but not the new one, the write-back is missing.

The short answer

Cloudflare Agents remembers between sessions when the session returns to the same agent instance, because that instance is a Durable Object with persisted state and message storage. It does not share memory between instances, tools, or platforms on its own. Keep the routing key stable, save state at the end of every session, and move memory that must travel into a store that outlives any single instance.