@mastra/memory 1.28.1 → 1.28.2-alpha.1

package/dist/docs/SKILL.md

@@ -3,7 +3,7 @@ name: mastra-memory
 description: Documentation for @mastra/memory. Use when working with @mastra/memory APIs, configuration, or implementation.
 metadata:
   package: "@mastra/memory"
-  version: "1.28.1"
+  version: "1.28.2-alpha.1"
 ---
 
 ## When to use
@@ -16,59 +16,59 @@ Read the individual reference documents for detailed explanations and code examp
 
 ### Docs
 
-- [Human-in-the-loop](references/docs-agents-human-in-the-loop.md) - Learn how to require approvals and suspend tool execution, plus automatically resume suspended tools while keeping humans in control of agent workflows.
-- [Agent networks](references/docs-agents-networks.md) - Coordinate multiple agents, workflows, and tools using agent networks for complex, non-deterministic task execution.
-- [Evals with memory](references/docs-evals-evals-with-memory.md) - Run scorers against memory-enabled agents, including observational memory in thread scope, using runEvals and dataset experiments.
-- [Context engineering](references/docs-guides-context-engineering.md) - Learn how to choose, retrieve, persist, and control the context a Mastra agent receives.
-- [Background tasks](references/docs-harness-background-tasks.md) - Learn how to dispatch long-running tool calls in the background and keep the stream open until they complete, plus orchestrate subagents asynchronously.
-- [Goals](references/docs-harness-goals.md) - Learn how to set a durable objective on an agent that's judged in the execution loop, so the agent keeps working until the goal is complete or the run budget is exhausted.
-- [Memory processors](references/docs-memory-memory-processors.md) - Learn how to use memory processors in Mastra to filter, trim, and transform messages before they're sent to the language model to manage context window limits.
-- [Message history](references/docs-memory-message-history.md) - Learn how to configure message history in Mastra to store recent messages from the current conversation.
-- [Multi-user threads](references/docs-memory-multi-user-threads.md) - Share one Mastra thread between multiple users by carrying speaker identity in the message body.
-- [Observational Memory](references/docs-memory-observational-memory.md) - Learn how Observational Memory keeps your agent's context window small while preserving long-term memory across conversations.
-- [Memory](references/docs-memory-overview.md) - Learn how Mastra's memory system works with working memory, message history, semantic recall, and observational memory.
-- [Semantic recall](references/docs-memory-semantic-recall.md) - Learn how to use semantic recall in Mastra to retrieve relevant messages from past conversations using vector search and embeddings.
-- [Working memory](references/docs-memory-working-memory.md) - Learn how to configure working memory in Mastra to store persistent user data, preferences.
-- [Storage](references/docs-storage.md) - Configure storage for Mastra to persist runtime state across agents, workflows, observability, evals, schedules, and memory.
-- [Subagents](references/docs-subagents.md) - Learn how to coordinate multiple agents with delegation hooks, iteration monitoring, message filtering, and task completion scoring.
+- [Human-in-the-loop](references/docs-agents-human-in-the-loop.md) - Add human-in-the-loop controls to Mastra agents with tool approval and suspended execution, so people can provide input before a run resumes or stops.
+- [Agent networks](references/docs-agents-networks.md) - Understand deprecated Mastra agent networks, including multi-agent routing, structured output, tool approvals, and migration to supervisor agents.
+- [Evals with memory](references/docs-evals-evals-with-memory.md) - Run Mastra evals against memory-enabled agents using shared or per-item threads, observational memory, runEvals, and dataset experiments.
+- [Context engineering](references/docs-guides-context-engineering.md) - Engineer the context Mastra agents receive by combining instructions, inline data, tools, RAG, filesystems, memory, and observational memory.
+- [Background tasks](references/docs-harness-background-tasks.md) - Run long-lived Mastra tool calls and subagents as background tasks while streams remain open, with configurable LLM behavior and completion events.
+- [Goals](references/docs-harness-goals.md) - Set a durable goal for a Mastra agent so an execution loop evaluates progress and continues working until the objective completes or its run budget ends.
+- [Memory processors](references/docs-memory-memory-processors.md) - Configure Mastra memory processors to filter, trim, transform, and deduplicate messages before they reach the model while managing context limits.
+- [Message history](references/docs-memory-message-history.md) - Store and retrieve recent Mastra conversation messages, configure history limits and thread titles, and query threads for chat interfaces.
+- [Multi-user threads](references/docs-memory-multi-user-threads.md) - Share one Mastra memory thread across multiple users by preserving speaker identity in messages and combining history with observational or working memory.
+- [Observational Memory](references/docs-memory-observational-memory.md) - Configure Mastra Observational Memory to compress long conversations into durable observations while preserving context across threads and sessions.
+- [Memory](references/docs-memory-overview.md) - Add memory to Mastra agents with message history, semantic recall, working memory, and observational memory across threads and multi-agent delegation.
+- [Semantic recall](references/docs-memory-semantic-recall.md) - Retrieve relevant messages from past Mastra conversations with semantic recall, vector search, embeddings, metadata filters, and configurable storage.
+- [Working memory](references/docs-memory-working-memory.md) - Persist user profiles, preferences, and application data with Mastra working memory using resource- or thread-scoped templates and storage adapters.
+- [Storage](references/docs-storage.md) - Configure Mastra storage to persist memory, workflow state, observability data, evals, schedules, and long-running agent state across restarts.
+- [Subagents](references/docs-subagents.md) - Build Mastra supervisor agents that delegate work to specialized subagents with hooks, request context, message filtering, and completion scoring.
 
 ### Integrations
 
-- [GitHub](references/integrations-channels-github.md) - Notify a Mastra agent when subscribed GitHub pull requests change.
-- [Aurora DSQL](references/integrations-databases-aurora-dsql.md) - Documentation for the Amazon Aurora DSQL storage implementation in Mastra.
-- [DynamoDB](references/integrations-databases-dynamodb.md) - Documentation for the DynamoDB storage implementation in Mastra, using a single-table design with ElectroDB.
-- [Elasticsearch](references/integrations-databases-elasticsearch.md) - Documentation for the Elasticsearch storage implementation in Mastra.
-- [libSQL](references/integrations-databases-libsql.md) - Documentation for the libSQL storage implementation in Mastra.
-- [MongoDB](references/integrations-databases-mongodb.md) - Documentation for the MongoDB storage implementation in Mastra.
-- [OracleDB](references/integrations-databases-oracledb.md) - Documentation for the Oracle Database storage provider in Mastra.
-- [PostgreSQL](references/integrations-databases-postgresql.md) - Documentation for the PostgreSQL storage implementation in Mastra.
-- [Redis](references/integrations-databases-redis.md) - Documentation for the Redis storage implementation in Mastra.
-- [Upstash](references/integrations-databases-upstash.md) - Documentation for the Upstash storage implementation in Mastra.
-- [Valkey](references/integrations-databases-valkey.md) - Documentation for the GLIDE-backed Valkey storage implementation in Mastra.
+- [GitHub](references/integrations-channels-github.md) - Subscribe Mastra agents to GitHub pull requests with @mastra/github-signals, polling modes, notification signals, and subscription management tools.
+- [Aurora DSQL](references/integrations-databases-aurora-dsql.md) - Store Mastra application data in Amazon Aurora DSQL with IAM authentication, configurable credentials, schema initialization, and connection options.
+- [DynamoDB](references/integrations-databases-dynamodb.md) - Persist Mastra data in Amazon DynamoDB with a single-table ElectroDB design, configurable indexes, TTL support, credentials, and table initialization.
+- [Elasticsearch](references/integrations-databases-elasticsearch.md) - Store Mastra agent memory, workflow snapshots, and scores in Elasticsearch with URL, authentication, or shared client connection configuration.
+- [libSQL](references/integrations-databases-libsql.md) - Persist Mastra messages, workflow snapshots, traces, and eval scores in local or remote libSQL with managed tables and initialization options.
+- [MongoDB](references/integrations-databases-mongodb.md) - Store Mastra application data and vectors in MongoDB, configure connections and collections, initialize schemas, and add persistent agent memory.
+- [OracleDB](references/integrations-databases-oracledb.md) - Persist Mastra memory, workflows, observability, scores, MCP metadata, and agent registry data in Oracle Database with OracleStore.
+- [PostgreSQL](references/integrations-databases-postgresql.md) - Persist Mastra application data in PostgreSQL with PostgresStore, configure connections and pools, initialize schemas, and enable observability.
+- [Redis](references/integrations-databases-redis.md) - Store Mastra application data in Redis using connection strings, host settings, or custom clients, including Sentinel and Cluster deployments.
+- [Upstash](references/integrations-databases-upstash.md) - Use Upstash Redis as serverless Mastra storage with REST credentials, namespaced keys, durable persistence, and deployment-friendly connections.
+- [Valkey](references/integrations-databases-valkey.md) - Configure Valkey storage and caching for Mastra through the GLIDE client, including authentication, connection options, persistence, and cleanup.
 
 ### Reference
 
-- [Reference: Mastra.getMemory()](references/reference-core-getMemory.md) - Documentation for the `Mastra.getMemory()` method in Mastra, which retrieves a registered memory instance by its registry key.
-- [Reference: Mastra.listMemory()](references/reference-core-listMemory.md) - Documentation for the `Mastra.listMemory()` method in Mastra, which returns all registered memory instances.
-- [Memory](references/reference-file-based-agents-memory.md) - Give a file-based agent persistent memory with a memory.ts module.
-- [Reference: Cloned thread utilities](references/reference-memory-clone-utilities.md) - Documentation for utility methods to work with cloned threads in Mastra Memory.
-- [Reference: Memory.cloneThread()](references/reference-memory-cloneThread.md) - Documentation for the `Memory.cloneThread()` method in Mastra, which creates a copy of a conversation thread with all its messages.
-- [Reference: Memory.createThread()](references/reference-memory-createThread.md) - Documentation for the `Memory.createThread()` method in Mastra, which creates a new conversation thread in the memory system.
-- [Reference: Memory.getThreadById()](references/reference-memory-getThreadById.md) - Documentation for the `Memory.getThreadById()` method in Mastra, which retrieves a specific thread by its ID.
-- [Reference: Memory.listThreads()](references/reference-memory-listThreads.md) - Documentation for the `Memory.listThreads()` method in Mastra, which retrieves threads with optional filtering by resourceId and/or metadata.
-- [Reference: Memory class](references/reference-memory-memory-class.md) - Documentation for the `Memory` class in Mastra, which provides a reliable system for managing conversation history and thread-based message storage.
-- [Reference: Observational Memory](references/reference-memory-observational-memory.md) - API reference for Observational Memory in Mastra: a three-tier memory system that uses Observer and Reflector agents to maintain long-term memory across conversations.
-- [Reference: Memory.settled()](references/reference-memory-settled.md) - Documentation for the `Memory.settled()` method in Mastra, which waits for background memory work to finish before you close the storage connection.
-- [Reference: summarizeConversation()](references/reference-memory-summarizeConversation.md) - Documentation for the standalone `summarizeConversation()` function in Mastra, which summarizes messages you pass in and extracts structured values from them.
-- [Reference: Memory.summarizeThread()](references/reference-memory-summarizeThread.md) - Documentation for the `Memory.summarizeThread()` method in Mastra, which summarizes a thread's conversation in one shot and extracts structured values from it.
-- [Migration: AgentNetwork to .network()](references/reference-migrations-agentnetwork.md) - Learn how to migrate from AgentNetwork primitives to .network() in Mastra.
-- [Memory](references/reference-migrations-upgrade-to-v1-memory.md) - Learn how to migrate memory-related changes when upgrading to v1.
-- [Reference: TokenLimiterProcessor](references/reference-processors-token-limiter-processor.md) - Documentation for the TokenLimiterProcessor in Mastra, which limits the number of tokens in messages.
-- [Reference: libSQL vector store](references/reference-vectors-libsql.md) - Documentation for the LibSQLVector class in Mastra, which provides vector search using libSQL with vector extensions.
-- [Reference: MongoDB vector store](references/reference-vectors-mongodb.md) - Documentation for the MongoDBVector class in Mastra, which provides vector search using MongoDB Atlas and Vector Search.
-- [Reference: OracleDB vector store](references/reference-vectors-oracledb.md) - Documentation for the Oracle Database vector provider in Mastra.
-- [Reference: PG vector store](references/reference-vectors-pg.md) - Documentation for the PgVector class in Mastra, which provides vector search using PostgreSQL with pgvector extension.
-- [Reference: Upstash vector store](references/reference-vectors-upstash.md) - Documentation for the UpstashVector class in Mastra, which provides vector search using Upstash Vector.
+- [Reference: Mastra.getMemory()](references/reference-core-getMemory.md) - The .getMemory() method retrieves a memory instance from the Mastra registry by its key.
+- [Reference: Mastra.listMemory()](references/reference-core-listMemory.md) - The .listMemory() method returns all memory instances registered with the Mastra instance.
+- [Memory](references/reference-file-based-agents-memory.md) - A file-based agent gets memory from a memory.ts file that default-exports a Memory instance.
+- [Reference: Cloned thread utilities](references/reference-memory-clone-utilities.md) - Use Mastra Memory clone utilities to create threads derived from an existing conversation, then inspect clone relationships and manage their messages.
+- [Reference: Memory.cloneThread()](references/reference-memory-cloneThread.md) - The .cloneThread() method creates a copy of an existing conversation thread, including all its messages.
+- [Reference: Memory.createThread()](references/reference-memory-createThread.md) - The .createThread() method creates a new conversation thread in the memory system. Each thread represents a distinct conversation or context and can contain multiple messages.
+- [Reference: Memory.getThreadById()](references/reference-memory-getThreadById.md) - Use Memory.getThreadById() to retrieve a conversation thread by ID, including its resource association, metadata, and stored properties.
+- [Reference: Memory.listThreads()](references/reference-memory-listThreads.md) - The listThreads() method retrieves threads with pagination support and optional filtering by resourceId, metadata, or both.
+- [Reference: Memory class](references/reference-memory-memory-class.md) - The Memory class provides a reliable system for managing conversation history and thread-based message storage in Mastra.
+- [Reference: Observational Memory](references/reference-memory-observational-memory.md) - Observational Memory (OM) is Mastra's memory system for long-context agentic memory. An Observer watches conversations and creates observations.
+- [Reference: Memory.settled()](references/reference-memory-settled.md) - Use Memory.settled() to wait for asynchronous memory work, including working-memory updates and observational memory, before closing storage.
+- [Reference: summarizeConversation()](references/reference-memory-summarizeConversation.md) - The standalone summarizeConversation() function summarizes a conversation in one shot.
+- [Reference: Memory.summarizeThread()](references/reference-memory-summarizeThread.md) - Call Memory.summarizeThread() to produce a thread summary in one operation and extract configured structured values from its messages.
+- [Migration: AgentNetwork to .network()](references/reference-migrations-agentnetwork.md) - Migrate deprecated AgentNetwork usage to supervisor agents and the standard Agent.generate() or Agent.stream() APIs in current Mastra releases.
+- [Memory](references/reference-migrations-upgrade-to-v1-memory.md) - Memory configuration now requires explicit parameters, and default settings have been updated for better performance and predictability.
+- [Reference: TokenLimiterProcessor](references/reference-processors-token-limiter-processor.md) - Use TokenLimiterProcessor to constrain message tokens during input, per-step input, or output processing with configurable limits and strategies.
+- [Reference: libSQL vector store](references/reference-vectors-libsql.md) - Configure LibSQLVector for similarity search and metadata filtering with local libSQL, SQLite-compatible vector extensions, or Turso databases.
+- [Reference: MongoDB vector store](references/reference-vectors-mongodb.md) - The MongoDBVector class provides vector search using MongoDB Vector Search. It enables efficient similarity search and metadata filtering within your MongoDB collections.
+- [Reference: OracleDB vector store](references/reference-vectors-oracledb.md) - OracleVector stores embeddings in Oracle Database VECTOR columns and exposes them through Mastra's vector interface.
+- [Reference: PG vector store](references/reference-vectors-pg.md) - The PgVector class provides vector search using PostgreSQL with pgvector extension. It provides reliable vector similarity search capabilities within your existing PostgreSQL database.
+- [Reference: Upstash vector store](references/reference-vectors-upstash.md) - Configure UpstashVector for serverless similarity and hybrid search, metadata filtering, index management, and vector operations with Upstash Vector.
 
 
 Read [assets/SOURCE_MAP.json](assets/SOURCE_MAP.json) for source code references.

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.28.1",
+  "version": "1.28.2-alpha.1",
   "package": "@mastra/memory",
   "exports": {},
   "modules": {

package/dist/docs/references/docs-agents-human-in-the-loop.md

@@ -508,7 +508,7 @@ if (run && toolCall) {
 
 Each returned run includes the suspended tool calls (`toolCallId`, `toolName`, `args`, and `requiresApproval`). Approval suspensions (`requiresApproval: true`) are answered with `approveToolCall()` / `declineToolCall()`, while `suspend()`-based suspensions carry their `suspendPayload` and expect `resumeStream()` with resume data, so you can rebuild the right UI for either flow without keeping any state in memory.
 
-`sendToolApproval()` uses the same storage-backed discovery automatically: when no active run is found in memory for the thread, it looks up the suspended run in storage before failing. If several suspended runs match the thread, pass a `toolCallId` to disambiguate.
+`sendToolApproval()` automatically uses the same storage-backed discovery. If memory contains no active run for the thread, it searches storage for a suspended run before failing. Pass a `toolCallId` when several suspended runs match the thread.
 
 The same discovery is available over HTTP as `GET /agents/:agentId/suspended-runs` and in the client SDK as [`agent.listSuspendedRuns()`](https://mastra.ai/reference/client-js/agents), so browser-based approval UIs can rediscover pending runs directly.
 

package/dist/docs/references/docs-agents-networks.md

@@ -4,7 +4,7 @@
 
 # Agent networks
 
-> **Deprecated:** Agent networks are deprecated and will be removed in a future major release. [Supervisor agents](https://mastra.ai/docs/subagents) using `agent.stream()` or `agent.generate()` are now the recommended approach. It provides the same multi-agent coordination with better control, a simpler API, and easier debugging.
+> **Deprecated:** Agent networks are deprecated and will be removed in a future major release. Replace them with [supervisor agents](https://mastra.ai/docs/subagents) that use `agent.stream()` or `agent.generate()`. Supervisor agents provide the same multi-agent coordination through a simpler API that improves control and debugging.
 >
 > See the [migration guide](https://mastra.ai/reference/migrations/network-to-supervisor) to upgrade.
 

package/dist/docs/references/docs-guides-context-engineering.md

@@ -243,7 +243,7 @@ await result.accepted
 
 A processor can send a reactive signal during `processInputStep()`. This is useful for guidance that depends on the current step or a recent tool result. Set `transient: true` when the signal should reach only the current model call. Re-send it when needed instead of storing repeated reminders in conversation history.
 
-State signals represent context that changes over time. Mastra tracks snapshots and deltas for each state lane and can reinsert a fresh snapshot after the previous one leaves the active context window. Use `computeStateSignal()` when a processor owns the state. Working memory, browser context, and task lists can use this lane to stay available even after history or Observational Memory removes older messages.
+State signals represent context that changes over time. For each state lane, Mastra tracks snapshots and deltas so it can reinsert a fresh snapshot after the previous one leaves the active context window. Use `computeStateSignal()` when a processor owns the state. This lane can keep working memory and browser context available alongside task lists, even after history or Observational Memory removes older messages.
 
 Signals append changing context near the current turn instead of rewriting the agent's base instructions. Transient and state signals can therefore preserve a more stable prompt prefix while keeping current guidance and state visible to the model.
 

package/dist/docs/references/docs-harness-background-tasks.md

@@ -275,7 +275,7 @@ await mastra.backgroundTaskManager?.resume(taskId, {
 
 ### What happens to the agent loop
 
-When a task suspends mid-`stream()` with `untilIdle`, the wrapper treats it as terminal for the current iteration and closes. To continue the agent immediately when the resume payload is in hand, call `agent.resumeStream(resumeData, { runId, toolCallId, memory, untilIdle: true })`: the resumed bg task runs to completion and adds its result to the message list. The agent then runs a follow-up turn, all on the same SSE connection. If you'd rather drive the resume out-of-band, call `mastra.backgroundTaskManager.resume(taskId, resumeData)` directly and the result still writes into the thread for the next user turn to pick up.
+When a task suspends mid-`stream()` with `untilIdle`, the wrapper treats it as terminal for the current iteration and closes. Once the resume payload is available, call `agent.resumeStream(resumeData, { runId, toolCallId, memory, untilIdle: true })` to continue immediately. The resumed background task completes and adds its result to the message list before the agent runs a follow-up turn on the same SSE connection. To drive the resume out of band, call `mastra.backgroundTaskManager.resume(taskId, resumeData)` directly. Its result is still written into the thread for the next user turn.
 
 ### Re-registering the executor on resume
 

package/dist/docs/references/docs-memory-message-history.md

@@ -119,8 +119,8 @@ await agent.stream('Hello', {
 
 You can use this history in two ways:
 
-- **Automatic inclusion**: Mastra automatically fetches recent messages and includes them in the context window. By default, the last 10 messages keep agents grounded in the conversation. You can adjust this number with `lastMessages`, but in most cases you don't need to think about it.
-- [**Manual querying**](#querying): For more control, use the `recall()` function to query threads and messages directly. This lets you choose exactly which memories are included in the context window, or fetch messages to render conversation history in your UI.
+- **Automatic inclusion**: Mastra automatically includes recent messages in the context window. The default of 10 messages keeps agents grounded in the conversation. Adjust it with `lastMessages` when needed.
+- [**Manual querying**](#querying): For more control, query threads and messages directly with `recall()`. Use the results to choose which memories enter the context window or to render conversation history in your UI.
 
 > **Tip:** When memory is enabled, [Studio](https://mastra.ai/docs/studio/overview) uses message history to display past conversations in the chat sidebar.
 
@@ -230,7 +230,7 @@ const thread = await memory.getThreadById({ threadId: 'thread-123' })
 
 ### Messages
 
-Once you have a thread, use [`recall()`](https://mastra.ai/reference/memory/recall) to retrieve its messages. It supports pagination, date filtering, and [semantic search](https://mastra.ai/docs/memory/semantic-recall).
+Once you have a thread, use [`recall()`](https://mastra.ai/reference/memory/recall) to retrieve its messages. It supports pagination and [semantic search](https://mastra.ai/docs/memory/semantic-recall), with optional date filtering.
 
 Basic recall returns all messages from a thread:
 

package/dist/docs/references/docs-memory-observational-memory.md

@@ -31,7 +31,7 @@ export const agent = new Agent({
 
 **For AI agents:** Using Observational Memory requires a storage provider! You either need to set it on the Mastra instance at `src/mastra/index.ts` or pass it to the Agent constructor.
 
-The following script creates a local LibSQL database, enables Observational Memory, and uses one resource and thread across two agent calls:
+The following script creates a local LibSQL database and enables Observational Memory before using one resource and thread across two agent calls:
 
 ```typescript
 import { Agent } from '@mastra/core/agent'
@@ -214,11 +214,11 @@ When message history tokens exceed a threshold (default: 30,000), the Observer c
 
 OM uses fast local token estimation for this thresholding work. Text is estimated with `tokenx`, while image parts use provider-aware heuristics so multimodal conversations still trigger observation at the right time. The same applies to image-like `file` parts when a transport normalizes an uploaded image as a file instead of an image part. For example, OpenAI image detail settings can materially change when OM decides to observe.
 
-The Observer can also see attachments in the history it reviews. OM keeps readable placeholders like `[Image #1: reference-board.png]` or `[File #1: floorplan.pdf]` in the transcript for readability, and forwards the actual attachment parts alongside the text. Image-like `file` parts are upgraded to image inputs for the Observer when possible, while non-image attachments are forwarded as file parts with normalized token counting. This applies to both normal thread observation and batched resource-scope observation.
+The Observer can also see attachments in the history it reviews. For readability, OM keeps placeholders such as `[Image #1: reference-board.png]` or `[File #1: floorplan.pdf]` in the transcript while forwarding the actual attachments beside the text. When possible, image-like `file` parts become image inputs for the Observer. Other attachments remain file parts and use normalized token counting. This applies to both normal thread observation and batched resource-scope observation.
 
 ### Extractors
 
-Use extractors when you want OM to persist specific values alongside observations. Built-in values such as **current task**, **suggested response**, and **thread title** use the same extraction pipeline as custom values.
+Use extractors when you want OM to persist specific values alongside observations. Built-in values use the same extraction pipeline as custom values. They include **current task** and **suggested response**, along with **thread title**.
 
 The following example extracts a compact user profile from observations:
 
@@ -380,7 +380,7 @@ new Agent({
 })
 ```
 
-You can also pass an allowlist of mimeType globs (for example `['image/*']`) to forward only the kinds the Observer can handle. Alternatively, set `observeAttachments: 'auto'` to let Mastra decide from the provider capabilities registry: attachments are forwarded when the Observer model supports multimodal input and dropped otherwise, falling back to `true` when no capability data is available for the model.
+You can also pass an allowlist of mimeType globs (for example `['image/*']`) to forward only the kinds the Observer can handle. Alternatively, set `observeAttachments: 'auto'` so Mastra consults the provider capabilities registry. It forwards attachments when the Observer model supports multimodal input and drops them otherwise. If capability data is unavailable for the model, the setting falls back to `true`.
 
 ```md
 Date: 2026-01-15
@@ -426,7 +426,7 @@ With [`shareTokenBudget`](https://mastra.ai/reference/memory/observational-memor
 
 ### Retrieval mode
 
-Normal OM compresses messages into observations, which is great for staying on task, but the original wording is gone. Retrieval mode fixes this by keeping each observation group linked to the raw messages that produced it. When the agent needs exact wording, tool output, or chronology that the summary compressed away, it can call a `recall` tool to page through the source messages.
+Normal OM compresses messages into observations, which is great for staying on task, but the original wording is gone. Retrieval mode fixes this by keeping each observation group linked to the raw messages that produced it. The agent can call a `recall` tool to recover source details compressed by the summary, including exact wording and tool output as well as chronology.
 
 #### Browsing only
 
@@ -716,23 +716,23 @@ When message tokens reach the `messageTokens` threshold, buffered chunks activat
 
 Buffered observations also include continuation hints, a suggested next response and the current task, so the main agent maintains conversational continuity after activation shrinks the context window.
 
-If the agent produces messages faster than the Observer can process them, the `blockAfter` safety threshold lets activation overshoot the retention target instead of activating fewer chunks. It never activates more chunks than are needed to reach that target, and with the default settings it changes nothing. A synchronous observation runs when the `messageTokens` threshold is reached and buffered activation didn't happen. Buffered activation usually preserves a minimum remaining context (the smaller of \~1k tokens or the configured retention floor), but a single buffered chunk that covers the whole pending window still activates and can leave less.
+When message production outpaces the Observer, the `blockAfter` safety threshold allows activation to overshoot the retention target instead of using fewer chunks. Activation still uses no more chunks than needed to reach the target, and the default settings remain unaffected. A synchronous observation runs when the `messageTokens` threshold is reached and buffered activation didn't happen. Buffered activation usually preserves a minimum remaining context (the smaller of \~1k tokens or the configured retention floor), but a single buffered chunk that covers the whole pending window still activates and can leave less.
 
 Reflection works similarly, the Reflector runs in the background when observations reach a fraction of the reflection threshold.
 
 ### Settings
 
-| Setting                               | Default | What it controls                                                                                                                                                                                                                                                                                                                                                      |
-| ------------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `observation.bufferTokens`            | `0.2`   | How often to buffer. `0.2` means every 20% of `messageTokens`. With the default 30k threshold, that's roughly every 6k tokens. Can also be an absolute token count (e.g. `5000`).                                                                                                                                                                                     |
-| `observation.bufferActivation`        | `0.8`   | How aggressively to clear the message window on activation. `0.8` means remove enough messages to keep only 20% of `messageTokens` remaining. Lower values keep more message history.                                                                                                                                                                                 |
-| `observation.blockAfter`              | `1.2`   | Safety net if buffering can't keep up. Values from 1 up to (but not including) 100 multiply `messageTokens`: at `1.2`, the threshold is 36k tokens (1.2 × 30k). Above it, activation may overshoot the retention target instead of activating fewer chunks. Values of 100 or more are absolute token counts (e.g. `50_000`) and must be greater than `messageTokens`. |
-| `activateAfterIdle`                   | none    | Forces buffered observations to activate after a period of inactivity, even before `observation.messageTokens` is reached. Accepts a numeric millisecond value such as `300_000`, duration strings like `"5m"` or `"1hr"`, or `"auto"` for a provider-aware prompt cache TTL.                                                                                         |
-| `activateOnProviderChange`            | `false` | Forces buffered observations to activate when the next step uses a different `provider/model` than the one that produced the latest assistant step. Use this when switching providers or models would invalidate prompt cache reuse.                                                                                                                                  |
-| `reflection.bufferActivation`         | `0.5`   | When to start background reflection. `0.5` means reflection begins when observations reach 50% of the `observationTokens` threshold.                                                                                                                                                                                                                                  |
-| `reflection.activateAfterIdle`        | none    | Opts buffered reflections into idle activation. Reflections don't inherit top-level `activateAfterIdle`.                                                                                                                                                                                                                                                              |
-| `reflection.activateOnProviderChange` | `false` | Opts buffered reflections into provider-change activation. Reflections don't inherit top-level `activateOnProviderChange`.                                                                                                                                                                                                                                            |
-| `reflection.blockAfter`               | `1.2`   | Safety threshold for reflection. Same value format as observation (absolute values must be greater than `observationTokens`), but above it reflection runs synchronously when no buffered reflection is ready to activate.                                                                                                                                            |
+| Setting                               | Default | What it controls                                                                                                                                                                                                                                                                                                                                                                 |
+| ------------------------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `observation.bufferTokens`            | `0.2`   | How often to buffer. `0.2` means every 20% of `messageTokens`. With the default 30k threshold, that's roughly every 6k tokens. Can also be an absolute token count (e.g. `5000`).                                                                                                                                                                                                |
+| `observation.bufferActivation`        | `0.8`   | How aggressively to clear the message window on activation. `0.8` means remove enough messages to keep only 20% of `messageTokens` remaining. Lower values keep more message history.                                                                                                                                                                                            |
+| `observation.blockAfter`              | `1.2`   | Safety net if buffering can't keep up. Values from 1 up to (but not including) 100 multiply `messageTokens`. For example, `1.2` creates a threshold of 36k tokens (1.2 × 30k), above which activation may overshoot the retention target rather than use fewer chunks. Values of 100 or more are absolute token counts (e.g. `50_000`) and must be greater than `messageTokens`. |
+| `activateAfterIdle`                   | none    | Forces buffered observations to activate after a period of inactivity, even before `observation.messageTokens` is reached. Accepts a numeric millisecond value such as `300_000`, duration strings like `"5m"` or `"1hr"`, or `"auto"` for a provider-aware prompt cache TTL.                                                                                                    |
+| `activateOnProviderChange`            | `false` | Forces buffered observations to activate when the next step uses a different `provider/model` than the one that produced the latest assistant step. Use this when switching providers or models would invalidate prompt cache reuse.                                                                                                                                             |
+| `reflection.bufferActivation`         | `0.5`   | When to start background reflection. `0.5` means reflection begins when observations reach 50% of the `observationTokens` threshold.                                                                                                                                                                                                                                             |
+| `reflection.activateAfterIdle`        | none    | Opts buffered reflections into idle activation. Reflections don't inherit top-level `activateAfterIdle`.                                                                                                                                                                                                                                                                         |
+| `reflection.activateOnProviderChange` | `false` | Opts buffered reflections into provider-change activation. Reflections don't inherit top-level `activateOnProviderChange`.                                                                                                                                                                                                                                                       |
+| `reflection.blockAfter`               | `1.2`   | Safety threshold for reflection. Same value format as observation (absolute values must be greater than `observationTokens`), but above it reflection runs synchronously when no buffered reflection is ready to activate.                                                                                                                                                       |
 
 If you're relying on prompt caching, set `activateAfterIdle` to `"auto"` or to a specific cache TTL. That way, once a thread has been idle long enough for the cache to expire, the next request can activate buffered observations first and send a smaller compressed context window.
 
@@ -784,7 +784,7 @@ const memory = new Memory({
 
 Setting `bufferTokens: false` disables both observation and reflection async buffering. See [async buffering configuration](https://mastra.ai/reference/memory/observational-memory) for the full API.
 
-> **Note:** Async buffering isn't supported with `scope: 'resource'`. It's automatically disabled in resource scope.
+> **Note:** Resource scope automatically disables async buffering.
 
 ## Observer Context Optimization
 

package/dist/docs/references/docs-memory-overview.md

@@ -116,7 +116,7 @@ Use memory when your agent needs to maintain multi-turn conversations that refer
 
    Visit [Memory Class](https://mastra.ai/reference/memory/memory-class) for a full list of configuration options.
 
-5. Call your agent, for example in [Studio](https://mastra.ai/docs/studio/overview). Inside Studio, start a new chat with your agent and take a look at the right sidebar. It'll now display various memory-related information.
+5. Call your agent, for example in [Studio](https://mastra.ai/docs/studio/overview). Inside Studio, start a new chat with your agent and take a look at the right sidebar. It'll now display memory details.
 
 ## Message history
 

package/dist/docs/references/docs-memory-semantic-recall.md

@@ -14,8 +14,6 @@ Semantic recall is RAG-based search that helps agents maintain context across lo
 
 It uses vector embeddings of messages for similarity search and integrates with vector stores, plus has configurable context windows around retrieved messages.
 
-![Diagram showing Mastra Memory semantic recall](/assets/images/semantic-recall-fd7b9336a6d0d18019216cb6d3dbe710.png)
-
 When it's enabled, new messages are used to query a vector DB for semantically similar messages.
 
 After getting a response from the LLM, all new messages (user, assistant, and tool calls/results) are inserted into the vector DB to be recalled in later interactions.

package/dist/docs/references/docs-memory-working-memory.md

@@ -275,7 +275,7 @@ Schema-based working memory uses **merge semantics**, meaning the agent only nee
 ## Choosing between template and schema
 
 - Use a **template** (Markdown) if you want the agent to maintain memory as a free-form text block, such as a user profile or scratchpad. Templates use **replace semantics**: the agent must provide the complete memory content on each update.
-- Use a **schema** if you need structured, type-safe data that can be validated and programmatically accessed as JSON. The `workingMemory.schema` field accepts any `PublicSchema`-compatible schema (including Zod v3, Zod v4, JSON Schema, or already-standard schemas). Schemas use **merge semantics**: the agent only provides fields to update, and existing fields are preserved.
+- Use a **schema** for structured, type-safe JSON data that supports validation and programmatic access. The `workingMemory.schema` field accepts any `PublicSchema`-compatible schema, such as Zod v3 or v4. JSON Schema and already-standard schemas are also supported. **Merge semantics** preserve existing fields when the agent provides only the fields to update.
 - Only one mode can be active at a time: setting both `template` and `schema` isn't supported.
 
 ## Example: Multi-step retention

package/dist/docs/references/docs-subagents.md

@@ -138,7 +138,7 @@ Called after a delegation finishes. Use it to inspect results or provide feedbac
 - Return `{ feedback: '...' }`: Add feedback that gets saved to the parent agent's memory and is visible to subsequent iterations
 - Return `{ resultText: '...' }`: Replace the tool result text the parent model sees for this delegation, within the current run
 
-Use `resultText` when the subagent's own result would mislead the parent immediately. For example, a subagent that stops on a tool-calls step returns empty text. The parent model reads this as a successful but empty delegation. Unlike `feedback`, which only reaches the model on the next turn, `resultText` changes what the parent reasons on right away.
+Set `resultText` when the subagent's own result would give the parent a misleading signal. For example, empty text from a subagent stopped on a tool-calls step looks like a successful but empty delegation to the parent model. Unlike `feedback` on the next turn, `resultText` affects the parent's reasoning immediately.
 
 ```typescript
 const stream = await parentAgent.stream('Research AI trends', {
@@ -196,7 +196,7 @@ await parentAgent.generate('Research AI trends', { maxSteps: 10, requestContext
 const hookErrors = requestContext.get('__mastra_delegationHookErrors') ?? []
 ```
 
-When `hookErrorStrategy` is `'throw'`, a throwing `onDelegationStart` blocks the subagent from running at all, and a throwing `messageFilter` or `onDelegationComplete` surfaces to the parent as a failed tool call. If `onDelegationComplete` throws while handling a failed delegation, the original delegation error is still what surfaces, and the hook is never re-invoked for its own failure.
+When `hookErrorStrategy` is `'throw'`, a throwing `onDelegationStart` blocks the subagent from running at all, and a throwing `messageFilter` or `onDelegationComplete` surfaces to the parent as a failed tool call. If `onDelegationComplete` throws while handling a failed delegation, the original delegation error remains the surfaced error. The hook isn't invoked again for its own failure.
 
 ## Message filtering
 

package/dist/docs/references/reference-memory-observational-memory.md

@@ -6,7 +6,7 @@
 
 **Added in:** `@mastra/memory@1.1.0`
 
-Observational Memory (OM) is Mastra's memory system for long-context agentic memory. An **Observer** watches conversations and creates observations. A **Reflector** restructures those observations by combining related items and condensing overarching patterns. Together, they maintain an observation log that replaces raw message history as it grows.
+Observational Memory (OM) is Mastra's memory system for long-context agentic memory. An **Observer** watches conversations and creates observations, which a **Reflector** restructures by combining related items and condensing overarching patterns. Together, they maintain an observation log that replaces raw message history as it grows.
 
 ## Usage
 
@@ -245,7 +245,7 @@ export const agent = new Agent({
 
 ### Shared token budget
 
-When `shareTokenBudget` is enabled, the total budget is `observation.messageTokens + reflection.observationTokens` (100k in this example). If observations only use 30k tokens, messages can expand to use up to 70k. If messages are short, observations have more room before triggering reflection.
+When `shareTokenBudget` is enabled, the total budget is `observation.messageTokens + reflection.observationTokens`, which is 100k in this example. Observations that use only 30k tokens leave up to 70k for messages, while short messages give observations more room before reflection starts.
 
 ```typescript
 import { Memory } from '@mastra/memory'
@@ -359,7 +359,7 @@ export const agent = new Agent({
 
 Async buffering is **enabled by default**. It pre-computes observations in the background as the conversation grows: when the `messageTokens` threshold is reached, buffered observations activate instantly with no blocking LLM call.
 
-The lifecycle follows **buffer → activate → remove messages → repeat**. Background Observer calls run at `bufferTokens` intervals, each producing a chunk of observations. At threshold, chunks activate: observations move into the log, raw messages are removed from context. Above the `blockAfter` threshold, activation may overshoot the retention target instead of activating fewer chunks. If the threshold is reached and no buffered chunk activates, a synchronous observation runs instead.
+The lifecycle follows **buffer → activate → remove messages → repeat**. Background Observer calls run at `bufferTokens` intervals and produce chunks of observations. At the threshold, activation moves observations into the log and removes raw messages from context. Above `blockAfter`, activation may overshoot the retention target instead of activating fewer chunks. A synchronous observation runs if the threshold is reached without activating a buffered chunk.
 
 Default settings:
 
@@ -765,7 +765,7 @@ The standalone `ObservationalMemory` class accepts all the same options as the `
 
 ## Recall tool
 
-When `retrieval` is set (any truthy value), a `recall` tool is registered so the agent can page through raw messages behind observation group ranges. By default (scope `'resource'`), the tool supports listing threads (`mode: "threads"`), browsing other threads (`threadId`), and cross-thread search. With `retrieval: { vector: true }`, semantic search is available (`mode: "search"`). Set `scope: 'thread'` to restrict the tool to the current thread only. The tool is automatically added to the agent's tool list.
+When `retrieval` is truthy, Mastra registers a `recall` tool that pages through raw messages behind observation group ranges. With the default resource scope, the tool can list threads (`mode: "threads"`) and browse another thread through `threadId`. It also supports cross-thread search. Set `retrieval: { vector: true }` for semantic search (`mode: "search"`), or use `scope: 'thread'` to restrict the tool to the current thread. The tool is automatically added to the agent.
 
 Mastra also injects scope-aware usage instructions into the agent's context. For resource scope with `vector: true`, these cover routing between `search`, `threads`, and `messages`, including fallback to thread discovery when search results are unsuitable. Without `vector: true`, the instructions only cover `threads` and `messages` browsing, so the agent isn't steered toward a search mode that isn't configured. Resource-scoped instructions are injected even before any observation group exists, so the agent can browse other threads from the first message. Use `retrieval: { instructions: '...' }` to append application-specific guidance after the built-in instructions.
 

package/dist/docs/references/reference-memory-settled.md

@@ -50,7 +50,7 @@ await memory.settled()
 await store.close()
 ```
 
-> **Note:** `settled()` joins the work that had started by the time you called it, plus any work that work enqueues. It does not prevent new work from starting afterwards, so call it once the agent runs you care about have returned.
+> **Note:** `settled()` joins the work that had started by the time you called it, plus any work that work enqueues. It doesn't prevent new work from starting afterwards, so call it once the agent runs you care about have returned.
 
 ## Related
 

package/dist/docs/references/reference-processors-token-limiter-processor.md

@@ -68,7 +68,7 @@ for await (const part of stream.fullStream) {
 
 ## Media token counting
 
-Images and file attachments are estimated rather than tokenized. This applies to `file` message parts and to tool results shaped like `{ data, mediaType }`. Images use a flat per-image estimate, other media is estimated from its decoded byte size, and remote URLs or provider file ids use a flat fallback because their size isn't known locally. Encoded payloads such as base64 data are never counted as text, which would otherwise inflate the count by an order of magnitude and truncate history unnecessarily.
+Images and file attachments are estimated instead of tokenized, including `file` message parts and tool results shaped like `{ data, mediaType }`. Images use a flat per-image estimate; other media uses decoded byte size, while remote URLs and provider file ids use a flat fallback because their size isn't known locally. Encoded payloads such as base64 data are never counted as text, avoiding an inflated count that could truncate history unnecessarily.
 
 ## Error behavior
 

package/dist/docs/references/reference-vectors-mongodb.md

@@ -222,7 +222,7 @@ const results = await store.textQuery({
 
 ### `hybridQuery()`
 
-Runs a hybrid search that fuses vector similarity and full-text results using MongoDB's server-side `$rankFusion`. It requires MongoDB >= 8.0 and is generally available from 8.1. On 8.0.x, it may require a MongoDB support case for enablement. It runs where enabled, including MongoDB Atlas 8.0.x. A full-text search index must exist: it's auto-created for managed indexes, but for a bring-your-own collection you must call `createSearchIndex()` first (opt-in).
+Runs a hybrid search that fuses vector similarity with full-text results through MongoDB's server-side `$rankFusion`. The feature requires MongoDB 8.0 or later and is generally available from 8.1. MongoDB Atlas 8.0.x supports it where enabled, although enablement may require a support case. A full-text search index must exist. Managed indexes create one automatically, while bring-your-own collections require an explicit `createSearchIndex()` call.
 
 **indexName** (`string`): Name of the Mastra index to search
 
@@ -255,7 +255,7 @@ const results = await store.hybridQuery({
 })
 ```
 
-`hybridQuery()` requires MongoDB >= 8.0 for the `$rankFusion` stage. The stage is generally available from 8.1. On 8.0.x, it may need a MongoDB support case to enable and runs where enabled, such as MongoDB Atlas 8.0.x. If you're running an older version, or `$rankFusion` isn't enabled on your 8.0.x deployment, use `query()` and `textQuery()` separately and merge the results client-side.
+`hybridQuery()` requires MongoDB 8.0 or later for the `$rankFusion` stage, which is generally available from 8.1. On 8.0.x, the stage runs where enabled, including MongoDB Atlas, but enablement may require a support case. If your deployment is older or lacks `$rankFusion`, run `query()` and `textQuery()` separately before merging the results client-side.
 
 ### `describeIndex()`
 

package/dist/index.cjs

@@ -1,5 +1,5 @@
 Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
-const require_src = require("./src-Br56ncef.cjs");
+const require_src = require("./src-Bq1Ng-3M.cjs");
 let _mastra_core_processors = require("@mastra/core/processors");
 exports.Extractor = require_src.Extractor;
 exports.KnowledgeSemanticIndexCoordinator = require_src.KnowledgeSemanticIndexCoordinator;

package/dist/index.js

@@ -1,2 +1,2 @@
-import { C as SUMMARIZE_THREAD_DEFAULTS, G as ModelByInputTokens, H as KnowledgeSemanticIndexCoordinator, Q as Extractor, S as WorkingMemoryExtractor, U as StaleKnowledgeSemanticIndexError, V as Subconscious, a as extractWorkingMemoryContent, b as WorkingMemoryStateProcessor, c as getObservationsAsOf, i as WorkingMemory, n as MessageHistory, o as extractWorkingMemoryTags, r as SemanticRecall, s as removeWorkingMemoryTags, t as Memory, v as WORKING_MEMORY_STATE_ID, w as summarizeConversation, x as deepMergeWorkingMemory, y as WORKING_MEMORY_STATE_PROCESSOR_ID } from "./src-BNtoxIHL.js";
+import { C as SUMMARIZE_THREAD_DEFAULTS, G as ModelByInputTokens, H as KnowledgeSemanticIndexCoordinator, Q as Extractor, S as WorkingMemoryExtractor, U as StaleKnowledgeSemanticIndexError, V as Subconscious, a as extractWorkingMemoryContent, b as WorkingMemoryStateProcessor, c as getObservationsAsOf, i as WorkingMemory, n as MessageHistory, o as extractWorkingMemoryTags, r as SemanticRecall, s as removeWorkingMemoryTags, t as Memory, v as WORKING_MEMORY_STATE_ID, w as summarizeConversation, x as deepMergeWorkingMemory, y as WORKING_MEMORY_STATE_PROCESSOR_ID } from "./src-Br1yJXN1.js";
 export { Extractor, KnowledgeSemanticIndexCoordinator, Memory, MessageHistory, ModelByInputTokens, SUMMARIZE_THREAD_DEFAULTS, SemanticRecall, StaleKnowledgeSemanticIndexError, Subconscious, WORKING_MEMORY_STATE_ID, WORKING_MEMORY_STATE_PROCESSOR_ID, WorkingMemory, WorkingMemoryExtractor, WorkingMemoryStateProcessor, deepMergeWorkingMemory, extractWorkingMemoryContent, extractWorkingMemoryTags, getObservationsAsOf, removeWorkingMemoryTags, summarizeConversation };

package/dist/processors/index.cjs

@@ -1,5 +1,5 @@
 Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
-const require_src = require("../src-Br56ncef.cjs");
+const require_src = require("../src-Bq1Ng-3M.cjs");
 exports.Extractor = require_src.Extractor;
 exports.KnowledgeSemanticIndexCoordinator = require_src.KnowledgeSemanticIndexCoordinator;
 exports.ModelByInputTokens = require_src.ModelByInputTokens;

package/dist/processors/index.js

@@ -1,2 +1,2 @@
-import { A as formatMessagesForObserver, B as OBSERVATION_CONTINUATION_HINT, D as buildObserverPrompt, E as OBSERVER_SYSTEM_PROMPT, F as parseAnchorId, G as ModelByInputTokens, H as KnowledgeSemanticIndexCoordinator, I as stripEphemeralAnchorIds, J as SUBCONSCIOUS_ACTIVITY_STATE_ID, K as SubconsciousCaptureExtractor, L as OBSERVATIONAL_MEMORY_DEFAULTS, M as optimizeObservationsForContext, N as parseObserverOutput, O as buildObserverSystemPrompt, P as injectAnchorIds, Q as Extractor, R as OBSERVATION_CONTEXT_INSTRUCTIONS, S as WorkingMemoryExtractor, T as TokenCounter, U as StaleKnowledgeSemanticIndexError, V as Subconscious, W as SubconsciousRemindExtractor, X as publishSubconsciousActivity, Y as buildSubconsciousActivitySnapshot, Z as renderSubconsciousActivity, _ as wrapInObservationGroup, c as getObservationsAsOf, d as combineObservationGroupRanges, f as deriveObservationGroupProvenance, g as stripObservationGroups, h as renderObservationGroupsForReflection, j as hasCurrentTaskSection, k as extractCurrentTask, l as ObservationalMemoryProcessor, m as reconcileObservationGroupsFromReflection, p as parseObservationGroups, q as subconsciousCaptureSchema, u as ObservationalMemory, w as summarizeConversation, z as OBSERVATION_CONTEXT_PROMPT } from "../src-BNtoxIHL.js";
+import { A as formatMessagesForObserver, B as OBSERVATION_CONTINUATION_HINT, D as buildObserverPrompt, E as OBSERVER_SYSTEM_PROMPT, F as parseAnchorId, G as ModelByInputTokens, H as KnowledgeSemanticIndexCoordinator, I as stripEphemeralAnchorIds, J as SUBCONSCIOUS_ACTIVITY_STATE_ID, K as SubconsciousCaptureExtractor, L as OBSERVATIONAL_MEMORY_DEFAULTS, M as optimizeObservationsForContext, N as parseObserverOutput, O as buildObserverSystemPrompt, P as injectAnchorIds, Q as Extractor, R as OBSERVATION_CONTEXT_INSTRUCTIONS, S as WorkingMemoryExtractor, T as TokenCounter, U as StaleKnowledgeSemanticIndexError, V as Subconscious, W as SubconsciousRemindExtractor, X as publishSubconsciousActivity, Y as buildSubconsciousActivitySnapshot, Z as renderSubconsciousActivity, _ as wrapInObservationGroup, c as getObservationsAsOf, d as combineObservationGroupRanges, f as deriveObservationGroupProvenance, g as stripObservationGroups, h as renderObservationGroupsForReflection, j as hasCurrentTaskSection, k as extractCurrentTask, l as ObservationalMemoryProcessor, m as reconcileObservationGroupsFromReflection, p as parseObservationGroups, q as subconsciousCaptureSchema, u as ObservationalMemory, w as summarizeConversation, z as OBSERVATION_CONTEXT_PROMPT } from "../src-Br1yJXN1.js";
 export { Extractor, KnowledgeSemanticIndexCoordinator, ModelByInputTokens, OBSERVATIONAL_MEMORY_DEFAULTS, OBSERVATION_CONTEXT_INSTRUCTIONS, OBSERVATION_CONTEXT_PROMPT, OBSERVATION_CONTINUATION_HINT, OBSERVER_SYSTEM_PROMPT, ObservationalMemory, ObservationalMemoryProcessor, SUBCONSCIOUS_ACTIVITY_STATE_ID, StaleKnowledgeSemanticIndexError, Subconscious, SubconsciousCaptureExtractor, SubconsciousRemindExtractor, TokenCounter, WorkingMemoryExtractor, buildObserverPrompt, buildObserverSystemPrompt, buildSubconsciousActivitySnapshot, combineObservationGroupRanges, deriveObservationGroupProvenance, extractCurrentTask, formatMessagesForObserver, getObservationsAsOf, hasCurrentTaskSection, injectAnchorIds, optimizeObservationsForContext, parseAnchorId, parseObservationGroups, parseObserverOutput, publishSubconsciousActivity, reconcileObservationGroupsFromReflection, renderObservationGroupsForReflection, renderSubconsciousActivity, stripEphemeralAnchorIds, stripObservationGroups, subconsciousCaptureSchema, summarizeConversation, wrapInObservationGroup };

package/dist/processors/observational-memory/message-utils.d.ts

@@ -34,14 +34,14 @@ export declare function isMessageAtOrBeforeCursor(msg: MastraDBMessage, cursor:
 /**
  * Get the messages Observational Memory is allowed to work with.
  *
- * Messages supplied through the `context` option are per-run ephemeral input. Core's
- * persistence contract already treats them as never-persist: `MessageStateManager` routes
- * them into `userContextMessages`, and `drainUnsavedMessages` only drains input/response.
+ * Messages supplied through the `context` option and the synthetic `om-continuation`
+ * message are prompt-only input. Core's persistence contract already treats context as
+ * never-persist, while the continuation remains memory-sourced so it can stay in the live
+ * actor prompt.
  *
- * OM builds its windows from `get.all.db()`, which includes context messages, and then
- * seals and persists candidates directly — turning ephemeral context into durable user
- * messages. Excluding them here keeps OM's window, sealing, persistence and token
- * accounting consistent with that contract.
+ * OM builds its windows from `get.all.db()`, which includes both categories, and then seals
+ * and persists candidates directly. Excluding them here keeps OM's observation, buffering,
+ * persistence, and token accounting consistent with their ephemeral contract.
  */
 export declare function getObservableMessages(messageList: MessageList): MastraDBMessage[];
 /**

package/dist/processors/observational-memory/observation-utils.d.ts

@@ -1,3 +1,4 @@
+export declare const BOUNDARY_WITH_DATE_RE: RegExp;
 /**
  * Given a raw `activeObservations` string (from an `ObservationalMemoryRecord`),
  * return only the observation text that would have been visible at `asOf`.

package/dist/processors/observational-memory/observation-utils.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"observation-utils.d.ts","sourceRoot":"","sources":["../../../src/processors/observational-memory/observation-utils.ts"],"names":[],"mappings":"AAIA;;;;;;;;;;;;;GAaG;AACH,wBAAgB,mBAAmB,CAAC,kBAAkB,EAAE,MAAM,EAAE,IAAI,EAAE,IAAI,GAAG,MAAM,CA6BlF"}
+{"version":3,"file":"observation-utils.d.ts","sourceRoot":"","sources":["../../../src/processors/observational-memory/observation-utils.ts"],"names":[],"mappings":"AACA,eAAO,MAAM,qBAAqB,QAC2D,CAAC;AAE9F;;;;;;;;;;;;;GAaG;AACH,wBAAgB,mBAAmB,CAAC,kBAAkB,EAAE,MAAM,EAAE,IAAI,EAAE,IAAI,GAAG,MAAM,CA6BlF"}

package/dist/processors/observational-memory/subconscious/knowledge-write-tools.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"knowledge-write-tools.d.ts","sourceRoot":"","sources":["../../../../src/processors/observational-memory/subconscious/knowledge-write-tools.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,cAAc,EAAE,mBAAmB,EAAE,gBAAgB,EAAE,MAAM,sBAAsB,CAAC;AAQlG,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,oBAAoB,CAAC;AAQrD,KAAK,yBAAyB,GAAG;IAC/B,OAAO,EAAE;QACP,QAAQ,CAAC,IAAI,EAAE,WAAW,GAAG,OAAO,CAAC,gBAAgB,GAAG,SAAS,CAAC,CAAC;KACpE,CAAC;CACH,CAAC;AAEF,MAAM,WAAW,0BAA0B;IACzC,KAAK,EAAE,cAAc,CAAC;IACtB,cAAc,EAAE,MAAM,CAAC;IACvB,YAAY,EAAE,mBAAmB,CAAC;IAClC,QAAQ,CAAC,EAAE,mBAAmB,CAAC;CAChC;AAoBD,wBAAgB,yBAAyB,CACvC,MAAM,EAAE,yBAAyB,EACjC,OAAO,EAAE,0BAA0B,GAClC,MAAM,CAAC,MAAM,EAAE,UAAU,CAAC,GAAG,EAAE,GAAG,EAAE,GAAG,CAAC,CAAC,CA+N3C"}
+{"version":3,"file":"knowledge-write-tools.d.ts","sourceRoot":"","sources":["../../../../src/processors/observational-memory/subconscious/knowledge-write-tools.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,cAAc,EAAE,mBAAmB,EAAE,gBAAgB,EAAE,MAAM,sBAAsB,CAAC;AAQlG,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,oBAAoB,CAAC;AAQrD,KAAK,yBAAyB,GAAG;IAC/B,OAAO,EAAE;QACP,QAAQ,CAAC,IAAI,EAAE,WAAW,GAAG,OAAO,CAAC,gBAAgB,GAAG,SAAS,CAAC,CAAC;KACpE,CAAC;CACH,CAAC;AAEF,MAAM,WAAW,0BAA0B;IACzC,KAAK,EAAE,cAAc,CAAC;IACtB,cAAc,EAAE,MAAM,CAAC;IACvB,YAAY,EAAE,mBAAmB,CAAC;IAClC,QAAQ,CAAC,EAAE,mBAAmB,CAAC;CAChC;AAoBD,wBAAgB,yBAAyB,CACvC,MAAM,EAAE,yBAAyB,EACjC,OAAO,EAAE,0BAA0B,GAClC,MAAM,CAAC,MAAM,EAAE,UAAU,CAAC,GAAG,EAAE,GAAG,EAAE,GAAG,CAAC,CAAC,CAoR3C"}