Vercel AI SDK memory without stuffing the transcript

What does memory mean in the Vercel AI SDK?

The AI SDK gives TypeScript applications a consistent interface for models, tools, agents, streaming, and UI integration. It supports several memory patterns, including provider-defined memory tools, external memory providers, and a custom tool that calls your own storage layer. The SDK does not remove the product decision about which facts should persist, who may retrieve them, or when they must be deleted.

In a Next.js app, an AI SDK request usually contains current messages and execution state. Durable memory is a separate contract: send an event after it happens, extract the useful facts, merge changes, enforce user and tenant scope, then retrieve only the context needed for the next call.

How should an AI SDK app separate session history from durable memory?

Keep the active transcript for request execution and keep durable memory for facts that remain useful after the transcript is gone. The split prevents a long chat from becoming the only source of personalization and gives the application a clear place to correct or delete what the agent has learned.

Treat the AI SDK message history as working context. Do not infer that a fact is safe to preserve forever merely because it appeared in the prompt.

How do you retrieve memory before a Vercel AI SDK model call?

Resolve the user, agent, and tenant from the authenticated server session, retrieve a small context block, then pass that block to the model with a clear boundary. Never accept a user ID or tenant ID from the browser as the authorization source for the memory query.

import { generateText } from 'ai';
import { openai } from '@ai-sdk/openai';
import { Memory } from '@aimemory/sdk';

const memory = new Memory({ apiKey: process.env.AI_MEMORY_KEY });

export async function answer(input: {
  prompt: string;
  userId: string;
  tenantId: string;
}) {
  const context = await memory.search({
    query: input.prompt,
    userId: input.userId,
    agentId: 'web-assistant',
    metadata: { tenant: input.tenantId },
    limit: 6,
  });

  const contextText = context.memories
    .map((item) => `- ${item.text}`)
    .join('\n');

  return generateText({
    model: openai(process.env.AI_MODEL!),
    system: [
      'You are a product assistant.',
      'Use the memory below only as user context.',
      '<memory>',
      contextText,
      '</memory>',
    ].join('\n'),
    prompt: input.prompt,
  });
}

How should streaming AI SDK responses write memory?

Write after the response is available, not before the model has done the work. With streaming, place the write in the SDK finish callback, await it when the deployment permits, and use application-level error handling so a failed memory write does not pretend the stream failed too.

Store the meaningful event rather than the entire visible response. A support run might produce a confirmed plan change, a delivery constraint, and a customer preference. Most of the remaining prose is disposable.

• Pass the same authenticated user and tenant IDs used for retrieval.
• Record the route or integration as metadata so failures can be traced.
• Do not write credentials, raw payment data, or hidden system prompts.
• Make retries idempotent when the stream finish callback can be retried.

import { streamText } from 'ai';

const result = streamText({
  model: openai(process.env.AI_MODEL!),
  system: systemPrompt,
  prompt: userMessage,
  onFinish: async ({ text }) => {
    await memory.add({
      messages: [
        { role: 'user', content: userMessage },
        { role: 'assistant', content: text },
      ],
      userId,
      agentId: 'web-assistant',
      metadata: { tenant: tenantId, route: '/chat' },
    });
  },
});

What belongs in Vercel AI SDK memory?

Remember information that changes a future answer or action. Do not remember everything simply because the AI SDK makes it easy to send messages to another endpoint.

How should serverless AI SDK deployments protect memory scopes?

Keep the memory API key on the server and derive scopes from trusted authentication and tenant routing. A serverless function should be stateless about authorization even when the memory layer is stateful. Every write and read should carry the same tenant boundary, and failed scope resolution should stop the request rather than fall back to a shared identity.

Use short cache lifetimes for retrieved memory and never cache one user’s context under a route-level key. If a plan changes, invalidate the relevant source-of-truth data and write a correction instead of relying on prompt instructions to ignore the old fact.

How do you test Vercel AI SDK memory before production?

Test the route handler as an authorization boundary, not only as a model wrapper. The useful cases prove that session context and durable memory remain separate, that two users cannot share memories, and that a corrected fact wins on the next request.

What is the recommended Vercel AI SDK memory architecture?

Use the AI SDK for model orchestration and streaming. Use authenticated server code to build scopes and retrieve context. Use a model-neutral memory service for extraction, merging, compression, correction, and deletion. Return the answer through the SDK without making memory availability a hidden prerequisite for every response.