Memory processors

Trust: ★★★☆☆ (0.90) · 0 validations · developer_reference

Published: 2026-05-10 · Source: crawler_authoritative

Tình huống

Reference guide for configuring and using memory processors in Mastra agents to transform, filter, and manage message history in the processor pipeline.

Insight

Memory processors are specialized processors that operate on memory-related messages and state within Mastra’s agent architecture. Three built-in processors are automatically added when memory is enabled: MessageHistory retrieves and persists message history based on a configurable limit (e.g., lastMessages: 10); SemanticRecall performs vector similarity search using a configured embedder and vector store to find semantically relevant past messages and creates embeddings for new messages; WorkingMemory manages working memory state across conversations for the current thread. All three are added to both input processors (running before the LLM) and output processors (running after the LLM), except WorkingMemory which only runs input processing. Manual processor configuration in inputProcessors or outputProcessors takes precedence and prevents automatic addition of that processor type. Input processors execute in order: memory processors first (WorkingMemory, MessageHistory, SemanticRecall), then user-defined processors like guardrails. Output processors execute in reverse order: user processors first, then memory processors. This ordering ensures safe guardrail behavior where abort() calls prevent memory persistence.

Hành động

Configure memory processors via the Memory class options: set lastMessages (number) for MessageHistory limit, semanticRecall.enabled with vector and embedder for SemanticRecall, and workingMemory.enabled for WorkingMemory. For manual control, import MessageHistory from @mastra/core/processors and add it to inputProcessors array — this prevents automatic addition. When combining guardrails with memory: output guardrails run before memory saves (abort prevents persistence); input guardrails run after memory loads history (abort prevents LLM call and output processing). Use abort() in guardrails to safely prevent inappropriate content from being persisted.

Kết quả

Memory processors automatically manage context window limits, retrieve relevant message history (recent, semantic, or working memory), and persist new messages after LLM responses. Guardrail abort() calls safely prevent any messages from being saved to storage regardless of guardrail type.

Điều kiện áp dụng

Requires @mastra/memory and @mastra/core packages. SemanticRecall requires both a vector store adapter (e.g., PineconeVector) and an embedder (e.g., OpenAIEmbedder). All memory processors require a storage adapter (e.g., LibSQLStore).

---

Nội dung gốc (Original)

Memory processors

Memory processors transform and filter messages as they pass through an agent with memory enabled. They manage context window limits, remove unnecessary content, and optimize the information sent to the language model.

When memory is enabled on an agent, Mastra adds memory processors to the agent’s processor pipeline. These processors retrieve message history, working memory, and semantically relevant messages, then persist new messages after the model responds.

Memory processors are processors that operate specifically on memory-related messages and state.

Built-in memory processors

Mastra automatically adds these processors when memory is enabled:

MessageHistory

Retrieves message history and persists new messages.

When you configure:

memory: new Memory({
  lastMessages: 10,
})

Mastra internally:

1. Creates a MessageHistory processor with limit: 10
2. Adds it to the agent’s input processors (runs before the LLM)
3. Adds it to the agent’s output processors (runs after the LLM)

What it does:

• Input: Fetches the last 10 messages from storage and prepends them to the conversation
• Output: Persists new messages to storage after the model responds

Example:

import { Agent } from '@mastra/core/agent'
import { Memory } from '@mastra/memory'
import { LibSQLStore } from '@mastra/libsql'
import { openai } from '@ai-sdk/openai'
 
const agent = new Agent({
  id: 'test-agent',
  name: 'Test Agent',
  instructions: 'You are a helpful assistant',
  model: 'openai/gpt-5.4',
  memory: new Memory({
    storage: new LibSQLStore({
      id: 'memory-store',
      url: 'file:memory.db',
    }),
    lastMessages: 10, // MessageHistory processor automatically added
  }),
})

SemanticRecall

Retrieves semantically relevant messages based on the current input and creates embeddings for new messages.

When you configure:

memory: new Memory({
  semanticRecall: { enabled: true },
  vector: myVectorStore,
  embedder: myEmbedder,
})

Mastra internally:

1. Creates a SemanticRecall processor
2. Adds it to the agent’s input processors (runs before the LLM)
3. Adds it to the agent’s output processors (runs after the LLM)
4. Requires both a vector store and embedder to be configured

What it does:

• Input: Performs vector similarity search to find relevant past messages and prepends them to the conversation
• Output: Creates embeddings for new messages and stores them in the vector store for future retrieval

Example:

import { Agent } from '@mastra/core/agent'
import { Memory } from '@mastra/memory'
import { LibSQLStore } from '@mastra/libsql'
import { PineconeVector } from '@mastra/pinecone'
import { OpenAIEmbedder } from '@mastra/openai'
import { openai } from '@ai-sdk/openai'
 
const agent = new Agent({
  name: 'semantic-agent',
  instructions: 'You are a helpful assistant with semantic memory',
  model: 'openai/gpt-5.4',
  memory: new Memory({
    storage: new LibSQLStore({
      id: 'memory-store',
      url: 'file:memory.db',
    }),
    vector: new PineconeVector({
      id: 'memory-vector',
      apiKey: process.env.PINECONE_API_KEY!,
    }),
    embedder: new OpenAIEmbedder({
      model: 'text-embedding-3-small',
      apiKey: process.env.OPENAI_API_KEY!,
    }),
    semanticRecall: { enabled: true }, // SemanticRecall processor automatically added
  }),
})

WorkingMemory

Manages working memory state across conversations.

When you configure:

memory: new Memory({
  workingMemory: { enabled: true },
})

Mastra internally:

1. Creates a WorkingMemory processor
2. Adds it to the agent’s input processors (runs before the LLM)
3. Requires a storage adapter to be configured

What it does:

• Input: Retrieves working memory state for the current thread and prepends it to the conversation
• Output: No output processing

Example:

import { Agent } from '@mastra/core/agent'
import { Memory } from '@mastra/memory'
import { LibSQLStore } from '@mastra/libsql'
import { openai } from '@ai-sdk/openai'
 
const agent = new Agent({
  name: 'working-memory-agent',
  instructions: 'You are an assistant with working memory',
  model: 'openai/gpt-5.4',
  memory: new Memory({
    storage: new LibSQLStore({
      id: 'memory-store',
      url: 'file:memory.db',
    }),
    workingMemory: { enabled: true }, // WorkingMemory processor automatically added
  }),
})

Manual control and deduplication

If you manually add a memory processor to inputProcessors or outputProcessors, Mastra won’t automatically add it. This gives you full control over processor ordering:

import { Agent } from '@mastra/core/agent'
import { Memory } from '@mastra/memory'
import { MessageHistory } from '@mastra/core/processors'
import { TokenLimiter } from '@mastra/core/processors'
import { LibSQLStore } from '@mastra/libsql'
import { openai } from '@ai-sdk/openai'
 
// Custom MessageHistory with different configuration
const customMessageHistory = new MessageHistory({
  storage: new LibSQLStore({ id: 'memory-store', url: 'file:memory.db' }),
  lastMessages: 20,
})
 
const agent = new Agent({
  name: 'custom-memory-agent',
  instructions: 'You are a helpful assistant',
  model: 'openai/gpt-5.4',
  memory: new Memory({
    storage: new LibSQLStore({ id: 'memory-store', url: 'file:memory.db' }),
    lastMessages: 10, // This would normally add MessageHistory(10)
  }),
  inputProcessors: [
    customMessageHistory, // Your custom one is used instead
    new TokenLimiter({ limit: 4000 }), // Runs after your custom MessageHistory
  ],
})

Processor execution order

Understanding the execution order is important when combining guardrails with memory:

Input Processors

[Memory Processors] → [Your inputProcessors]

1. Memory processors run FIRST: WorkingMemory, MessageHistory, SemanticRecall
2. Your input processors run AFTER: guardrails, filters, validators

This means memory loads message history before your processors can validate or filter the input.

Output Processors

[Your outputProcessors] → [Memory Processors]

1. Your output processors run FIRST: guardrails, filters, validators
2. Memory processors run AFTER: SemanticRecall (embeddings), MessageHistory (persistence)

This ordering is designed to be safe by default: if your output guardrail calls abort(), the memory processors never run and no messages are saved.

Guardrails and memory

The default execution order provides safe guardrail behavior:

Output guardrails (recommended)

Output guardrails run before memory processors save messages. If a guardrail aborts:

• The tripwire is triggered
• Memory processors are skipped
• No messages are persisted to storage

import { Agent } from '@mastra/core/agent'
import { Memory } from '@mastra/memory'
import { openai } from '@ai-sdk/openai'
 
// Output guardrail that blocks inappropriate content
const contentBlocker = {
  id: 'content-blocker',
  processOutputResult: async ({ messages, abort }) => {
    const hasInappropriateContent = messages.some(msg => containsBadContent(msg))
    if (hasInappropriateContent) {
      abort('Content blocked by guardrail')
    }
    return messages
  },
}
 
const agent = new Agent({
  name: 'safe-agent',
  instructions: 'You are a helpful assistant',
  model: 'openai/gpt-5.4',
  memory: new Memory({ lastMessages: 10 }),
  // Your guardrail runs BEFORE memory saves
  outputProcessors: [contentBlocker],
})
 
// If the guardrail aborts, nothing is saved to memory
const result = await agent.generate('Hello')
if (result.tripwire) {
  console.log('Blocked:', result.tripwire.reason)
  // Memory is empty - no messages were persisted
}

Input guardrails

Input guardrails run after memory processors load history. If a guardrail aborts:

• The tripwire is triggered
• The LLM is never called
• Output processors (including memory persistence) are skipped
• No messages are persisted to storage

// Input guardrail that validates user input
const inputValidator = {
  id: 'input-validator',
  processInput: async ({ messages, abort }) => {
    const lastUserMessage = messages.findLast(m => m.role === 'user')
    if (isInvalidInput(lastUserMessage)) {
      abort('Invalid input detected')
    }
    return messages
  },
}
 
const agent = new Agent({
  name: 'validated-agent',
  instructions: 'You are a helpful assistant',
  model: 'openai/gpt-5.4',
  memory: new Memory({ lastMessages: 10 }),
  // Your guardrail runs AFTER memory loads history
  inputProcessors: [inputValidator],
})

Summary

Guardrail Type	When it runs	If it aborts
Input	After memory loads history	LLM not called, nothing saved
Output	Before memory saves	Nothing saved to storage

Both scenarios are safe - guardrails prevent inappropriate content from being persisted to memory

Related documentation

• Processors: General processor concepts and custom processor creation
• Guardrails: Security and validation processors
• Memory Overview: Memory types and configuration

When creating custom processors avoid mutating the input messages array or its objects directly.

Liên kết

• Nền tảng: Dev Framework · Mastra
• Nguồn: https://mastra.ai/docs/memory/memory-processors

Xem thêm:

• Message history
• Mastra Memory Overview
• Observational Memory
• Semantic recall
• Working Memory - Mastra Agent Persistence