We've released @redis/vercel-ai-sdk, an open-source package that adds Redis Agent Memory to agents built with Vercel's AI SDK.
Most agents start every conversation cold. Users repeat their preferences, and yesterday's context is gone. You can bolt on a vector store and a pile of glue code, or you can hand the problem to a managed memory layer. With this package, a few lines of TypeScript give your agent short-term session memory and long-term personal memories.
What Redis Agent Memory does
Redis Agent Memory, part of Redis Iris, is a managed memory layer for agents. It combines two things: short-term memory for the current session and long-term memory that follows the user across sessions, channels, and agents.
You don't hand-curate any of it. Redis Agent Memory works in the background: it summarizes long sessions so context stays compact, extracts durable memories from the events you record, and promotes them to long-term storage. Later, any conversation can pull them back with semantic search, so an agent can remember that a user prefers aisle seats without being told again. You provision a store in Redis Cloud and talk to it over HTTP. This package is the AI SDK layer on top.
The integration: two ways in
Both approaches come from one server-side factory, createRedisAgentMemory(...), which holds your connection and an optional default model. From there you choose how much control the model gets.
Option 1: Memory without changing your agent
The simplest path is automatic-memory. You configure the connection once, then wrap your model per request:
Before each model call, the wrapper restores the session, recalls the user's long-term memories, and injects them as a bounded context block. Afterward it records the user's message and each successful assistant step.
Option 2: Let the model manage its own memory
If you want explicit control, memory.tools() returns an ordinary AI SDK tool map you pass alongside your model. The model decides when to search, save, update, or forget memories, and you can expose only the tools you want. Session recording can be agent-managed or handled by optional lifecycle hooks.
Rule of thumb: pick the automatic-memory option for continuity with no extra prompting, and tools when you want model-directed memory management. The two can coexist, but don't enable automatic recording and session-write tools for the same interaction, or events may be duplicated.
Built with production in mind
Memory sits on the hot path of every request, so we kept it bounded and predictable:
- Scoped by user and session. Memories are always tied to a userId, and session restore and recording need a sessionId. Resolve both from an authenticated state.
- Bounded context. By default the wrapper recalls up to 5 memories, caps long-term context at 8,000 characters and restored session context at 24,000, and uses one-second read and write deadlines.
- Failures don't break replies. Memory errors surface through an optional onDiagnostic callback and never replace a successful model response. Diagnostics never include prompt, memory, or credential text.
- Recalled context is marked as untrusted and possibly stale, so the model treats it as a hint, not ground truth.
- Best-effort recording. Redis Agent Memory has no append idempotency key, so a timed-out write may still have landed. Use collision-resistant session IDs and serialize requests per session.
Get started
The package is server-side and ESM-only, and requires Node.js 22+, AI SDK 7.x, and Zod 4.x.
Provision a store in Redis Cloud, then set AGENT_MEMORY_URL, AGENT_MEMORY_API_KEY and AGENT_MEMORY_STORE_ID in your server environment.
For a step-by-step walkthrough on how to use the library, check out the Build a Meal-Planning Agent with Redis Memory guide.
The GitHub repo includes two runnable demos, one for the automatic-memory model and one for tools. It's MIT-licensed, and we'd love your feedback and contributions. Tell us what you build.
