Your Vercel AI SDK Agent Forgets Everything Between Sessions. Here Is the Fix.

You deploy an agent built on the Vercel AI SDK and it feels sharp. In the chat window it holds the thread, calls tools, finishes the job. Then the tab closes. The serverless function freezes. You ship a redeploy. The next session starts and the agent asks for context you already gave it, re-derives decisions it already made, and burns a fresh pile of tokens getting back to where it was yesterday.

This is the question every AI SDK builder runs into sooner or later: does the Vercel AI SDK remember between sessions?

The short answer is no. The longer answer is that forgetting is the design, and memory is a layer you add on top. Here is what the SDK actually persists, why statelessness breaks scheduled and recurring agents, and five concrete ways to fix it.

What the AI SDK actually remembers

Nothing, once the session ends. Every generateText or streamText call is a fresh prompt: the model sees exactly the messages array you hand it and nothing else. The useChat hook keeps conversation state in the browser, which dies with the tab. On the server, your route handler runs in an ephemeral function. Cold starts, crashes, and redeploys wipe anything held in process memory.

This is not a bug or a missing feature. The AI SDK is the interaction layer: streaming responses, tool calling, multi-step agent loops. It was never meant to be the database. Persistence is deliberately your job, and the sooner you treat it that way, the fewer surprises you get.

Why statelessness hurts scheduled agents

A chat widget forgives amnesia because the human re-briefs the agent every session. A scheduled agent has no human in the loop to do that.

Picture a daily lead-enrichment agent triggered by cron. Monday it researches a lead, decides the company is a bad fit, and moves on. Tuesday the endpoint fires again and the agent wakes up blank. It re-researches the same lead, burns the same tokens, and sometimes reaches a different verdict, because nothing from Monday survived. Multiply that by hundreds of leads and the agent is not just forgetful, it is expensive and inconsistent.

The same pattern shows up in support triage bots that forget a customer's open ticket between conversations, and research agents that re-read the same source documents every morning. The failure mode is always the same: the agent re-derives knowledge it already earned.

Five ways to give your agent memory

1. Persist the message history in your own database.

The standard pattern: save every turn to Postgres, Supabase, Upstash Redis, or Vercel KV, then reload the relevant history when a session starts. It is simple, it preserves full fidelity, and you control the schema.

The cost is everything around the storage. Raw transcripts grow without bound, so you end up building summarization, retention windows, and retrieval yourself. And a transcript is not memory: dumping three weeks of chat logs into the prompt is how you burn a context window without the agent actually learning anything. This approach works, but you are now maintaining a memory system as a side project.

2. Use Vercel Drives for sandbox agents.

Vercel's Drives give agents persistent file storage: create a drive once, mount it into each new sandbox, and everything the agent wrote under the mount survives. Checkpoints, datasets, generated artifacts, and cloned repos are all still there on the next run. Drives are now generally available for Vercel Sandbox, which makes this the path of least resistance for coding agents and long-running sandbox work.

The limit is what files can express. A drive is durable storage, not semantic memory. The agent has to know which file to open, and a folder of markdown checkpoints will not answer "what did we decide about Acme last month" without the agent reading and reasoning over all of it. Files persist; recall is still manual.

3. Reach for durable workflow execution.

Newer durability pieces in the ecosystem, like durable workflow agents, solve a adjacent problem: surviving crashes and restarts mid-run. State checkpoints as the workflow progresses, approvals can wait hours for a human, and the run resumes instead of restarting. If your pain is agents dying halfway through long jobs, this is the fix.

It is not a memory system, though. Durable execution remembers where the run stopped. It does not remember what the agent learned last Tuesday.

4. Wire in a memory provider built for the SDK.

This is where purpose-built memory services come in. Providers like the Letta provider for the AI SDK, Synap, or Maximem plug persistent, per-user memory into the agent loop: entity resolution across sessions, automatic compaction that preserves critical facts, scoped retrieval so tenant A never sees tenant B's memories. The agent gets real recall without you building the storage layer from scratch.

The tradeoff is operational: it is one more service to run, configure, and pay for, and its memory lives inside that provider's walls.

5. Put one hosted memory layer behind every tool, over MCP.

There is a fifth option that changes the shape of the problem. Instead of each agent owning its own memory store, you run one memory service and let every tool read it over MCP: the Vercel agent, your n8n workflows, Claude Code, Cursor, all of them.

This is the approach Vilix AI takes. It is cloud-hosted, so there is zero infrastructure to run and nothing to maintain on your side. The same memory follows the agent across every tool and device over MCP, instead of living in one provider's silo. It keeps full conversation history, not just extracted facts, so the agent can revisit what was actually said. There is a free plan that stays free forever, a 7-day Pro trial with no credit card, and you can export or delete everything at any time.

The reason this matters for scheduled agents specifically: the memory outlives any single runtime. Your Vercel cron job, your n8n workflow, and your IDE assistant can all read and extend the same recall, so knowledge earned in one place is available everywhere else.

Which one should you pick

Match the fix to the pain. A single chat widget with short sessions: persist message history in your own database and add summarization when transcripts get long. Sandbox coding agents doing multi-day work: Vercel Drives for durable files. Long jobs that die halfway: durable workflow execution. A per-user assistant that must remember people and preferences across weeks: a memory provider or a hosted layer. Multiple tools and agents that should share what they learn: one hosted memory layer over MCP, so nothing is trapped in a single runtime.

Watch: Liam and Stella break this down on Agentic Pod, with the full technical guide on GitHub.

The pattern that scales

Stateless compute plus stateful memory. The AI SDK handles the thinking: streaming, tools, the agent loop. A memory layer handles the remembering: what happened, what was decided, what to carry into the next run. Vercel keeps shipping the compute side of that equation. Pick the memory side deliberately, before your agent's amnesia becomes your users' problem.