Mastra 'Memory requires a storage provider to function': fixing it in tests, evals and CI

Disclosure: I work on MemorySync (I'm Mohammed, the founder). I drafted this page with AI assistance and checked it against the source thread and the official docs listed under Sources on Oct 28, 2026. I read the issue and the Mastra docs; I didn't run Mastra for this page.

The question

mastra-ai/mastra#12882, "Running evals on CI with Agent Memory" (Feb 10, 2026, synced from Mastra's Discord), asks what to do when an agent has memory but storage is configured at the Mastra instance level. The agent uses:

memory: new Memory({
  options: {
    lastMessages: 20,
  },
}),

and the test case fails with:

Error: Memory requires a storage provider to function. Add a storage configuration to Memory or to your Mastra instance.

"Do I need to mock the storage or what's the recommended solution?"

Status (re-checked Oct 29, 2026): closed as completed on Feb 18, 2026, with "handled on discord". The synced Discord reply from a Mastra team member suggested having "a different Mastra instance for your CI/evals which would have your CI storage, agents, etc attached to it."

Skip the memory plumbing around this fix. Once the fix below is in, the MemorySync Mastra guide shows how to add per-user memory with MemorySync. MemorySync doesn't fix this error itself. When you're ready, sign up and try MemorySync. Founding offer: use code FOUNDING30 for 30% off Starter for your first 3 months (Settings → Billing).

Why it happens

The error text gives the two places storage can come from. Per Mastra's storage docs:

• Instance-level storage is set on new Mastra({ storage }) and shared by runtime domains.
• Agent-level storage is set on a Memory instance and "overrides instance-level storage for that agent's memory data only."

The issue's Memory has no storage, so it relies on the instance. A test or eval that imports and runs the agent without the Mastra instance that holds the storage leaves Memory with neither, which matches the error. (That's my reading of the error and docs; the issue thread doesn't spell it out.)

Fix 1: a separate Mastra instance for CI and evals

The Mastra team's suggestion. Build a test instance with its own storage and the agents attached, and run the agent through it. The docs show libSQL with a file-backed database for local development, with no separate database server:

import { Mastra } from '@mastra/core'
import { LibSQLStore } from '@mastra/libsql'
import { supportAgent } from '../src/mastra/agents/support'

export const testMastra = new Mastra({
  agents: { supportAgent },
  storage: new LibSQLStore({ id: 'ci-storage', url: 'file:./ci-mastra.db' }),
})

Get the agent from that instance in your test, not from the bare import, so it picks up the instance's storage. Delete the file between runs if each run should start clean.

Fix 2: give Memory its own storage

If the agent must run standalone, set storage on the Memory itself (agent-level storage):

memory: new Memory({
  storage: new LibSQLStore({ id: 'agent-storage', url: 'file:./agent-mastra.db' }),
  options: { lastMessages: 20 },
}),

The docs recommend agent-level storage "when an agent needs an isolated memory boundary or a different memory backend". In production you'd point it at the same backend you use elsewhere, or keep relying on instance storage and only override in tests.

What not to do

Removing memory from the agent in tests hides the error, but your evals then run without the conversation history the agent has in production, so they test a different agent.

Common questions

Can't I just use the default in-memory store?
Per the storage docs, the default in-memory store "is useful for tests and short local experiments, but it loses data when the process exits." The error means no storage reached Memory, so set one explicitly as above.

Does it matter which instance the agent is registered on?
Yes: instance-level storage comes from the Mastra instance, so the agent needs to run through the instance that has it, or carry its own.

Skip the plumbing with MemorySync

The MemorySync Mastra guide documents createMemorySyncProcessors: an input processor that injects recalled context as a system message before the model call, and an output processor that sends the user's message to MemorySync after it, where only durable facts are stored (assistant replies aren't). There's also a withMemorySync wrapper and agent tools. It's a separate layer from Mastra Memory, so it doesn't remove the need for storage when you use Memory for thread history. Read the guide first. To see save and recall in your browser, try the MemorySync playground.

From the guide:

npm install memorysync-mastra @mastra/core

import { Agent } from "@mastra/core/agent";
import { openai } from "@ai-sdk/openai";
import { createMemorySyncProcessors } from "memorysync-mastra";

const { inputProcessor, outputProcessor } = createMemorySyncProcessors({
  userId: "customer-7",     // per-end-user scoping
  sessionId: "thread-42",   // groups the stored facts by thread
});

const agent = new Agent({
  id: "assistant",
  name: "Assistant",
  instructions: "You are a helpful assistant.",
  model: openai("your-model"),
  inputProcessors: [inputProcessor],
  outputProcessors: [outputProcessor],
});

// First conversation
await agent.generate("I'm vegetarian and I fly aisle.");

// Any later call — same user, any thread, any model
const { text } = await agent.generate(
  "Book my trip: flight plus a dinner spot.",
);
// The model already saw: vegetarian, aisle seat — injected from memory.

Snippet adapted from the MemorySync Mastra guide; I haven't run it for this page.

Sources

• mastra-ai/mastra#12882 (closed 2026-02-18, completed; re-checked 2026-10-29)
• mastra.ai/docs/memory/storage (instance-level and agent-level storage, libSQL example, read 2026-10-28)
• MemorySync docs: docs.memorysync.io/guides/mastra

Next step: read the MemorySync Mastra guide, then sign up and try MemorySync. Founding offer: use code FOUNDING30 for 30% off Starter for your first 3 months (Settings → Billing).