Vercel adds persistent memory slots to eve agents

Vercel has shipped persistent memory for eve agents, according to a post on the Vercel blog. Agents built on eve can now carry context from one session into the next and draw on it in later conversations, instead of starting every exchange from a blank slate.

How memory slots work

Memory in eve is organized into slots. Developers define named slots in files under agent/memory/, and each slot declares two things: a provider, which handles storing and retrieving memories, and a scope, which determines who or what the memory is shared with. The example Vercel gives is keeping a separate memory for each authenticated user, so one person's saved context never bleeds into someone else's conversation.

The retrieval loop runs automatically. Before each turn, eve fetches memory relevant to the conversation and adds it to the model's context. Writes happen after the turn: depending on the provider, memory can be updated automatically, through tools the agent calls, or through a combination of both.

A built-in file memory provider

Vercel ships a built-in file memory provider that can be wired in with a single command. Running it creates a slot scoped to each authenticated caller, configured along these lines:

ts import { defineMemory } from "eve/memory"; import { fileMemory } from "eve/memory/file"; import { byPrincipal } from "eve/memory/scope";

export default defineMemory({ description: "Remember useful details from previous conversations.", provider: fileMemory(), scope: byPrincipal, });

The byPrincipal scope ties the slot to the authenticated caller, which is what produces per-user isolation out of the box. For agents deployed on Vercel, the file provider is backed by a private Vercel Blob store, so saved memories survive restarts and deployments rather than vanishing with the process.

Providers beyond the default

The provider abstraction is not limited to files. Vercel lists Supermemory, Upstash AgentKit, and Kybernesis Arcana as supported memory providers, and developers who want a different storage system or memory service can implement a custom provider. That keeps the memory layer swappable instead of welded to Vercel's own infrastructure.

Why it matters

Most agents today are amnesiac: when a session ends, everything the model learned about the user, the task, and the conversation disappears unless someone hand-rolled a retrieval layer. By making memory a declared, first-class part of the agent definition, eve turns session-spanning continuity from a custom engineering project into a configuration choice.

Two design choices stand out. First, scoping: because a slot can be bound to an authenticated principal, user isolation is available as a default rather than something bolted on afterwards, which matters for privacy and multi-tenant deployments. Second, the provider split: a team can start with the built-in file store and later move to a dedicated memory service without rewriting the agent itself.

There are trade-offs the announcement leaves open. Injecting memory before every turn consumes context window and adds latency, and automatic post-turn updates raise the question of what gets remembered, what gets overwritten, and how that is governed. The changelog also does not detail how eve decides which memories count as relevant for a given turn. Those questions will matter more as memories accumulate over long periods.

Even so, the feature is a concrete step toward agents that accumulate knowledge about the people and tasks they serve over time, and it gives developers on Vercel's stack a standard place to build that behavior instead of inventing it per project.