@mastra/memory 1.6.2-alpha.0 → 1.6.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +26 -0
- package/dist/docs/SKILL.md +24 -24
- package/dist/docs/assets/SOURCE_MAP.json +1 -1
- package/dist/docs/references/docs-agents-agent-approval.md +3 -3
- package/dist/docs/references/docs-agents-agent-memory.md +1 -1
- package/dist/docs/references/docs-agents-network-approval.md +1 -1
- package/dist/docs/references/docs-agents-networks.md +1 -1
- package/dist/docs/references/docs-agents-supervisor-agents.md +3 -3
- package/dist/docs/references/docs-memory-memory-processors.md +8 -8
- package/dist/docs/references/docs-memory-message-history.md +2 -2
- package/dist/docs/references/docs-memory-observational-memory.md +5 -5
- package/dist/docs/references/docs-memory-semantic-recall.md +7 -7
- package/dist/docs/references/docs-memory-working-memory.md +14 -14
- package/dist/docs/references/reference-core-getMemory.md +1 -1
- package/dist/docs/references/reference-core-listMemory.md +1 -1
- package/dist/docs/references/reference-memory-clone-utilities.md +7 -7
- package/dist/docs/references/reference-memory-cloneThread.md +4 -4
- package/dist/docs/references/reference-memory-createThread.md +1 -1
- package/dist/docs/references/reference-memory-getThreadById.md +1 -1
- package/dist/docs/references/reference-memory-listThreads.md +3 -3
- package/dist/docs/references/reference-memory-memory-class.md +1 -1
- package/dist/docs/references/reference-memory-observational-memory.md +1 -1
- package/dist/docs/references/reference-storage-dynamodb.md +5 -5
- package/dist/docs/references/reference-storage-libsql.md +1 -1
- package/dist/docs/references/reference-storage-mongodb.md +5 -5
- package/dist/docs/references/reference-storage-postgresql.md +5 -5
- package/dist/docs/references/reference-storage-upstash.md +3 -3
- package/dist/docs/references/reference-vectors-libsql.md +15 -15
- package/dist/docs/references/reference-vectors-mongodb.md +18 -18
- package/dist/docs/references/reference-vectors-pg.md +21 -21
- package/dist/docs/references/reference-vectors-upstash.md +15 -15
- package/package.json +8 -8
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,31 @@
|
|
|
1
1
|
# @mastra/memory
|
|
2
2
|
|
|
3
|
+
## 1.6.2
|
|
4
|
+
|
|
5
|
+
### Patch Changes
|
|
6
|
+
|
|
7
|
+
- Add image and file attachment support to Observational Memory. The observer can now see and reason about images and files in conversation history, and attachment token counts are included in observation thresholds. Provider-backed token counting is used when available, with results cached for faster subsequent runs. ([#13953](https://github.com/mastra-ai/mastra/pull/13953))
|
|
8
|
+
|
|
9
|
+
- Added observational memory repro tooling for recording, analyzing, and sanitizing captures before sharing them. ([#13877](https://github.com/mastra-ai/mastra/pull/13877))
|
|
10
|
+
|
|
11
|
+
- fix: respect `lastMessages: false` in `recall()` to disable conversation history ([#12951](https://github.com/mastra-ai/mastra/pull/12951))
|
|
12
|
+
|
|
13
|
+
Setting `lastMessages: false` in Memory options now correctly prevents `recall()` from returning previous messages. Previously, the agent would retain the full conversation history despite this setting being disabled.
|
|
14
|
+
|
|
15
|
+
Callers can still pass `perPage: false` explicitly to `recall()` to retrieve all messages (e.g., for displaying thread history in a UI).
|
|
16
|
+
|
|
17
|
+
- fix(memory): handle dynamic functions returning ModelWithRetries[] in observational memory model resolution ([#13902](https://github.com/mastra-ai/mastra/pull/13902))
|
|
18
|
+
|
|
19
|
+
- Fixed observational memory activation using outdated buffered observations in some long-running threads. Activation now uses the latest thread state so the correct observations are promoted. ([#13955](https://github.com/mastra-ai/mastra/pull/13955))
|
|
20
|
+
|
|
21
|
+
- Fixed message loss when saving certain messages so text content is preserved. ([#13918](https://github.com/mastra-ai/mastra/pull/13918))
|
|
22
|
+
|
|
23
|
+
- Added a compatibility guard so observational memory now fails fast when @mastra/core does not support request-response-id-rotation. ([#13887](https://github.com/mastra-ai/mastra/pull/13887))
|
|
24
|
+
|
|
25
|
+
- Updated dependencies [[`4f71b43`](https://github.com/mastra-ai/mastra/commit/4f71b436a4a6b8839842d8da47b57b84509af56c), [`a070277`](https://github.com/mastra-ai/mastra/commit/a07027766ce195ba74d0783116d894cbab25d44c), [`b628b91`](https://github.com/mastra-ai/mastra/commit/b628b9128b372c0f54214d902b07279f03443900), [`332c014`](https://github.com/mastra-ai/mastra/commit/332c014e076b81edf7fe45b58205882726415e90), [`6b63153`](https://github.com/mastra-ai/mastra/commit/6b63153878ea841c0f4ce632ba66bb33e57e9c1b), [`4246e34`](https://github.com/mastra-ai/mastra/commit/4246e34cec9c26636d0965942268e6d07c346671), [`b8837ee`](https://github.com/mastra-ai/mastra/commit/b8837ee77e2e84197609762bfabd8b3da326d30c), [`866cc2c`](https://github.com/mastra-ai/mastra/commit/866cc2cb1f0e3b314afab5194f69477fada745d1), [`fb58ce1`](https://github.com/mastra-ai/mastra/commit/fb58ce1de85d57f142005c4b3b7559f909167a3f), [`5d950f7`](https://github.com/mastra-ai/mastra/commit/5d950f7bf426a215a1808f0abef7de5c8336ba1c), [`28c85b1`](https://github.com/mastra-ai/mastra/commit/28c85b184fc32b40f7f160483c982da6d388ecbd), [`e9a08fb`](https://github.com/mastra-ai/mastra/commit/e9a08fbef1ada7e50e961e2f54f55e8c10b4a45c), [`1d0a8a8`](https://github.com/mastra-ai/mastra/commit/1d0a8a8acf33203d5744fc429b090ad8598aa8ed), [`631ffd8`](https://github.com/mastra-ai/mastra/commit/631ffd82fed108648b448b28e6a90e38c5f53bf5), [`6bcbf8a`](https://github.com/mastra-ai/mastra/commit/6bcbf8a6774d5a53b21d61db8a45ce2593ca1616), [`aae2295`](https://github.com/mastra-ai/mastra/commit/aae2295838a2d329ad6640829e87934790ffe5b8), [`aa61f29`](https://github.com/mastra-ai/mastra/commit/aa61f29ff8095ce46a4ae16e46c4d8c79b2b685b), [`7ff3714`](https://github.com/mastra-ai/mastra/commit/7ff37148515439bb3be009a60e02c3e363299760), [`18c3a90`](https://github.com/mastra-ai/mastra/commit/18c3a90c9e48cf69500e308affeb8eba5860b2af), [`41d79a1`](https://github.com/mastra-ai/mastra/commit/41d79a14bd8cb6de1e2565fd0a04786bae2f211b), [`f35487b`](https://github.com/mastra-ai/mastra/commit/f35487bb2d46c636e22aa71d90025613ae38235a), [`6dc2192`](https://github.com/mastra-ai/mastra/commit/6dc21921aef0f0efab15cd0805fa3d18f277a76f), [`eeb3a3f`](https://github.com/mastra-ai/mastra/commit/eeb3a3f43aca10cf49479eed2a84b7d9ecea02ba), [`e673376`](https://github.com/mastra-ai/mastra/commit/e6733763ad1321aa7e5ae15096b9c2104f93b1f3), [`05f8d90`](https://github.com/mastra-ai/mastra/commit/05f8d9009290ce6aa03428b3add635268615db85), [`b2204c9`](https://github.com/mastra-ai/mastra/commit/b2204c98a42848bbfb6f0440f005dc2b6354f1cd), [`a1bf1e3`](https://github.com/mastra-ai/mastra/commit/a1bf1e385ed4c0ef6f11b56c5887442970d127f2), [`b6f647a`](https://github.com/mastra-ai/mastra/commit/b6f647ae2388e091f366581595feb957e37d5b40), [`0c57b8b`](https://github.com/mastra-ai/mastra/commit/0c57b8b0a69a97b5a4ae3f79be6c610f29f3cf7b), [`b081f27`](https://github.com/mastra-ai/mastra/commit/b081f272cf411716e1d6bd72ceac4bcee2657b19), [`4b8da97`](https://github.com/mastra-ai/mastra/commit/4b8da97a5ce306e97869df6c39535d9069e563db), [`0c09eac`](https://github.com/mastra-ai/mastra/commit/0c09eacb1926f64cfdc9ae5c6d63385cf8c9f72c), [`6b9b93d`](https://github.com/mastra-ai/mastra/commit/6b9b93d6f459d1ba6e36f163abf62a085ddb3d64), [`31b6067`](https://github.com/mastra-ai/mastra/commit/31b6067d0cc3ab10e1b29c36147f3b5266bc714a), [`797ac42`](https://github.com/mastra-ai/mastra/commit/797ac4276de231ad2d694d9aeca75980f6cd0419), [`aae2295`](https://github.com/mastra-ai/mastra/commit/aae2295838a2d329ad6640829e87934790ffe5b8), [`0bc289e`](https://github.com/mastra-ai/mastra/commit/0bc289e2d476bf46c5b91c21969e8d0c6864691c), [`9b75a06`](https://github.com/mastra-ai/mastra/commit/9b75a06e53ebb0b950ba7c1e83a0142047185f46), [`4c3a1b1`](https://github.com/mastra-ai/mastra/commit/4c3a1b122ea083e003d71092f30f3b31680b01c0), [`256df35`](https://github.com/mastra-ai/mastra/commit/256df3571d62beb3ad4971faa432927cc140e603), [`85cc3b3`](https://github.com/mastra-ai/mastra/commit/85cc3b3b6f32ae4b083c26498f50d5b250ba944b), [`97ea28c`](https://github.com/mastra-ai/mastra/commit/97ea28c746e9e4147d56047bbb1c4a92417a3fec), [`d567299`](https://github.com/mastra-ai/mastra/commit/d567299cf81e02bd9d5221d4bc05967d6c224161), [`716ffe6`](https://github.com/mastra-ai/mastra/commit/716ffe68bed81f7c2690bc8581b9e140f7bf1c3d), [`8296332`](https://github.com/mastra-ai/mastra/commit/8296332de21c16e3dfc3d0b2d615720a6dc88f2f), [`4df2116`](https://github.com/mastra-ai/mastra/commit/4df211619dd922c047d396ca41cd7027c8c4c8e7), [`2219c1a`](https://github.com/mastra-ai/mastra/commit/2219c1acbd21da116da877f0036ffb985a9dd5a3), [`17c4145`](https://github.com/mastra-ai/mastra/commit/17c4145166099354545582335b5252bdfdfd908b)]:
|
|
26
|
+
- @mastra/core@1.11.0
|
|
27
|
+
- @mastra/schema-compat@1.2.0
|
|
28
|
+
|
|
3
29
|
## 1.6.2-alpha.0
|
|
4
30
|
|
|
5
31
|
### Patch Changes
|
package/dist/docs/SKILL.md
CHANGED
|
@@ -3,7 +3,7 @@ name: mastra-memory
|
|
|
3
3
|
description: Documentation for @mastra/memory. Use when working with @mastra/memory APIs, configuration, or implementation.
|
|
4
4
|
metadata:
|
|
5
5
|
package: "@mastra/memory"
|
|
6
|
-
version: "1.6.2
|
|
6
|
+
version: "1.6.2"
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
## When to use
|
|
@@ -16,40 +16,40 @@ Read the individual reference documents for detailed explanations and code examp
|
|
|
16
16
|
|
|
17
17
|
### Docs
|
|
18
18
|
|
|
19
|
-
- [Agent
|
|
20
|
-
- [Agent
|
|
21
|
-
- [Network
|
|
22
|
-
- [Agent
|
|
23
|
-
- [Supervisor
|
|
24
|
-
- [Memory
|
|
25
|
-
- [Message
|
|
26
|
-
- [Observational
|
|
19
|
+
- [Agent approval](references/docs-agents-agent-approval.md) - Learn how to require approvals, suspend tool execution, and automatically resume suspended tools while keeping humans in control of agent workflows.
|
|
20
|
+
- [Agent memory](references/docs-agents-agent-memory.md) - Learn how to add memory to agents to store message history and maintain context across interactions.
|
|
21
|
+
- [Network approval](references/docs-agents-network-approval.md) - Learn how to require approvals, suspend execution, and resume suspended networks while keeping humans in control of agent network workflows.
|
|
22
|
+
- [Agent networks](references/docs-agents-networks.md) - Learn how to coordinate multiple agents, workflows, and tools using agent networks for complex, non-deterministic task execution.
|
|
23
|
+
- [Supervisor agents](references/docs-agents-supervisor-agents.md) - Learn how to coordinate multiple agents using the supervisor pattern with delegation hooks, iteration monitoring, message filtering, and task completion scoring.
|
|
24
|
+
- [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.
|
|
25
|
+
- [Message history](references/docs-memory-message-history.md) - Learn how to configure message history in Mastra to store recent messages from the current conversation.
|
|
26
|
+
- [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.
|
|
27
27
|
- [Memory overview](references/docs-memory-overview.md) - Learn how Mastra's memory system works with working memory, message history, semantic recall, and observational memory.
|
|
28
|
-
- [Semantic
|
|
28
|
+
- [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.
|
|
29
29
|
- [Storage](references/docs-memory-storage.md) - Configure storage for Mastra's memory system to persist conversations, workflows, and traces.
|
|
30
|
-
- [Working
|
|
30
|
+
- [Working memory](references/docs-memory-working-memory.md) - Learn how to configure working memory in Mastra to store persistent user data, preferences.
|
|
31
31
|
|
|
32
32
|
### Reference
|
|
33
33
|
|
|
34
34
|
- [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.
|
|
35
35
|
- [Reference: Mastra.listMemory()](references/reference-core-listMemory.md) - Documentation for the `Mastra.listMemory()` method in Mastra, which returns all registered memory instances.
|
|
36
|
-
- [Reference: Cloned
|
|
36
|
+
- [Reference: Cloned thread utilities](references/reference-memory-clone-utilities.md) - Documentation for utility methods to work with cloned threads in Mastra Memory.
|
|
37
37
|
- [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.
|
|
38
38
|
- [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.
|
|
39
39
|
- [Reference: Memory.getThreadById()](references/reference-memory-getThreadById.md) - Documentation for the `Memory.getThreadById()` method in Mastra, which retrieves a specific thread by its ID.
|
|
40
40
|
- [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.
|
|
41
|
-
- [Reference: Memory
|
|
42
|
-
- [Reference: Observational
|
|
43
|
-
- [Reference:
|
|
44
|
-
- [Reference: DynamoDB
|
|
45
|
-
- [Reference: libSQL
|
|
46
|
-
- [Reference: MongoDB
|
|
47
|
-
- [Reference: PostgreSQL
|
|
48
|
-
- [Reference: Upstash
|
|
49
|
-
- [Reference: libSQL
|
|
50
|
-
- [Reference: MongoDB
|
|
51
|
-
- [Reference: PG
|
|
52
|
-
- [Reference: Upstash
|
|
41
|
+
- [Reference: Memory class](references/reference-memory-memory-class.md) - Documentation for the `Memory` class in Mastra, which provides a robust system for managing conversation history and thread-based message storage.
|
|
42
|
+
- [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.
|
|
43
|
+
- [Reference: TokenLimiterProcessor](references/reference-processors-token-limiter-processor.md) - Documentation for the TokenLimiterProcessor in Mastra, which limits the number of tokens in messages.
|
|
44
|
+
- [Reference: DynamoDB storage](references/reference-storage-dynamodb.md) - Documentation for the DynamoDB storage implementation in Mastra, using a single-table design with ElectroDB.
|
|
45
|
+
- [Reference: libSQL storage](references/reference-storage-libsql.md) - Documentation for the libSQL storage implementation in Mastra.
|
|
46
|
+
- [Reference: MongoDB storage](references/reference-storage-mongodb.md) - Documentation for the MongoDB storage implementation in Mastra.
|
|
47
|
+
- [Reference: PostgreSQL storage](references/reference-storage-postgresql.md) - Documentation for the PostgreSQL storage implementation in Mastra.
|
|
48
|
+
- [Reference: Upstash storage](references/reference-storage-upstash.md) - Documentation for the Upstash storage implementation in Mastra.
|
|
49
|
+
- [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.
|
|
50
|
+
- [Reference: MongoDB vector store](references/reference-vectors-mongodb.md) - Documentation for the MongoDBVector class in Mastra, which provides vector search using MongoDB Atlas and Atlas Vector Search.
|
|
51
|
+
- [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.
|
|
52
|
+
- [Reference: Upstash vector store](references/reference-vectors-upstash.md) - Documentation for the UpstashVector class in Mastra, which provides vector search using Upstash Vector.
|
|
53
53
|
|
|
54
54
|
|
|
55
55
|
Read [assets/SOURCE_MAP.json](assets/SOURCE_MAP.json) for source code references.
|
|
@@ -92,7 +92,7 @@ const handleDecline = async () => {
|
|
|
92
92
|
}
|
|
93
93
|
```
|
|
94
94
|
|
|
95
|
-
## Tool approval with generate()
|
|
95
|
+
## Tool approval with `generate()`
|
|
96
96
|
|
|
97
97
|
Tool approval also works with the `generate()` method for non-streaming use cases. When a tool requires approval during a `generate()` call, the method returns immediately instead of executing the tool.
|
|
98
98
|
|
|
@@ -504,7 +504,7 @@ for await (const chunk of stream.fullStream) {
|
|
|
504
504
|
}
|
|
505
505
|
```
|
|
506
506
|
|
|
507
|
-
### Using suspend() in supervisor pattern
|
|
507
|
+
### Using `suspend()` in supervisor pattern
|
|
508
508
|
|
|
509
509
|
Tools can also use [`suspend()`](#approval-using-suspend) to pause execution and return context to the user. This approach works through the supervisor delegation chain the same way `requireApproval` does — the suspension surfaces at the supervisor level:
|
|
510
510
|
|
|
@@ -553,7 +553,7 @@ for await (const chunk of stream.fullStream) {
|
|
|
553
553
|
}
|
|
554
554
|
```
|
|
555
555
|
|
|
556
|
-
### Tool approval with generate()
|
|
556
|
+
### Tool approval with `generate()`
|
|
557
557
|
|
|
558
558
|
Tool approval propagation also works with `generate()` in supervisor pattern:
|
|
559
559
|
|
|
@@ -131,7 +131,7 @@ const response = await memoryAgent.generate("What's my favorite color?", {
|
|
|
131
131
|
|
|
132
132
|
To learn more about memory see the [Memory](https://mastra.ai/docs/memory/overview) documentation.
|
|
133
133
|
|
|
134
|
-
## Observational
|
|
134
|
+
## Observational memory
|
|
135
135
|
|
|
136
136
|
For long-running conversations, raw message history grows until it fills the context window, degrading agent performance. [Observational Memory](https://mastra.ai/docs/memory/observational-memory) solves this by running background agents that compress old messages into dense observations, keeping the context window small while preserving long-term memory.
|
|
137
137
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Network
|
|
1
|
+
# Network approval
|
|
2
2
|
|
|
3
3
|
> **Deprecated:** Agent networks are deprecated and will be removed in a future release. Use the [supervisor pattern](https://mastra.ai/docs/agents/supervisor-agents) instead. See the [migration guide](https://mastra.ai/guides/migrations/network-to-supervisor) to upgrade.
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Agent
|
|
1
|
+
# Agent networks
|
|
2
2
|
|
|
3
3
|
> **Agent Network Deprecated — Supervisor Pattern Recommended:** Agent networks are deprecated and will be removed in a future release. The [supervisor pattern](https://mastra.ai/docs/agents/supervisor-agents) using `agent.stream()` or `agent.generate()` is now the recommended approach for coordinating multiple agents. It provides the same multi-agent coordination capabilities as `.network()` with significant improvements:
|
|
4
4
|
>
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Supervisor
|
|
1
|
+
# Supervisor agents
|
|
2
2
|
|
|
3
3
|
A supervisor agent coordinates multiple subagents using `agent.stream()` or `agent.generate()`. You configure subagents on the supervisor's `agents` property, and the supervisor uses its instructions and each subagent's `description` to decide when and how to delegate tasks.
|
|
4
4
|
|
|
@@ -57,7 +57,7 @@ for await (const chunk of stream.textStream) {
|
|
|
57
57
|
|
|
58
58
|
Delegation hooks let you intercept, modify, or reject delegations as they happen. Configure them under the `delegation` option, either in the agent's `defaultOptions` or per-call.
|
|
59
59
|
|
|
60
|
-
### onDelegationStart
|
|
60
|
+
### `onDelegationStart`
|
|
61
61
|
|
|
62
62
|
Called before the supervisor delegates to a subagent. Return an object to control the delegation:
|
|
63
63
|
|
|
@@ -104,7 +104,7 @@ The `context` object includes:
|
|
|
104
104
|
| `prompt` | The prompt the supervisor is sending |
|
|
105
105
|
| `iteration` | Current iteration number |
|
|
106
106
|
|
|
107
|
-
### onDelegationComplete
|
|
107
|
+
### `onDelegationComplete`
|
|
108
108
|
|
|
109
109
|
Called after a delegation finishes. Use it to inspect results, provide feedback, or stop execution:
|
|
110
110
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Memory
|
|
1
|
+
# Memory processors
|
|
2
2
|
|
|
3
3
|
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.
|
|
4
4
|
|
|
@@ -6,11 +6,11 @@ When memory is enabled on an agent, Mastra adds memory processors to the agent's
|
|
|
6
6
|
|
|
7
7
|
Memory processors are [processors](https://mastra.ai/docs/agents/processors) that operate specifically on memory-related messages and state.
|
|
8
8
|
|
|
9
|
-
## Built-in
|
|
9
|
+
## Built-in memory processors
|
|
10
10
|
|
|
11
11
|
Mastra automatically adds these processors when memory is enabled:
|
|
12
12
|
|
|
13
|
-
### MessageHistory
|
|
13
|
+
### `MessageHistory`
|
|
14
14
|
|
|
15
15
|
Retrieves message history and persists new messages.
|
|
16
16
|
|
|
@@ -56,7 +56,7 @@ const agent = new Agent({
|
|
|
56
56
|
})
|
|
57
57
|
```
|
|
58
58
|
|
|
59
|
-
### SemanticRecall
|
|
59
|
+
### `SemanticRecall`
|
|
60
60
|
|
|
61
61
|
Retrieves semantically relevant messages based on the current input and creates embeddings for new messages.
|
|
62
62
|
|
|
@@ -114,7 +114,7 @@ const agent = new Agent({
|
|
|
114
114
|
})
|
|
115
115
|
```
|
|
116
116
|
|
|
117
|
-
### WorkingMemory
|
|
117
|
+
### `WorkingMemory`
|
|
118
118
|
|
|
119
119
|
Manages working memory state across conversations.
|
|
120
120
|
|
|
@@ -159,7 +159,7 @@ const agent = new Agent({
|
|
|
159
159
|
})
|
|
160
160
|
```
|
|
161
161
|
|
|
162
|
-
## Manual
|
|
162
|
+
## Manual control and deduplication
|
|
163
163
|
|
|
164
164
|
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:
|
|
165
165
|
|
|
@@ -192,7 +192,7 @@ const agent = new Agent({
|
|
|
192
192
|
})
|
|
193
193
|
```
|
|
194
194
|
|
|
195
|
-
## Processor
|
|
195
|
+
## Processor execution order
|
|
196
196
|
|
|
197
197
|
Understanding the execution order is important when combining guardrails with memory:
|
|
198
198
|
|
|
@@ -218,7 +218,7 @@ This means memory loads message history before your processors can validate or f
|
|
|
218
218
|
|
|
219
219
|
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**.
|
|
220
220
|
|
|
221
|
-
## Guardrails and
|
|
221
|
+
## Guardrails and memory
|
|
222
222
|
|
|
223
223
|
The default execution order provides safe guardrail behavior:
|
|
224
224
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Message
|
|
1
|
+
# Message history
|
|
2
2
|
|
|
3
3
|
Message history is the most basic and important form of memory. It gives the LLM a view of recent messages in the context window, enabling your agent to reference earlier exchanges and respond coherently.
|
|
4
4
|
|
|
@@ -103,7 +103,7 @@ You can use this history in two ways:
|
|
|
103
103
|
- **Automatic inclusion** - Mastra automatically fetches and includes recent messages in the context window. By default, it includes the last 10 messages, keeping agents grounded in the conversation. You can adjust this number with `lastMessages`, but in most cases you don't need to think about it.
|
|
104
104
|
- [**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.
|
|
105
105
|
|
|
106
|
-
## Accessing
|
|
106
|
+
## Accessing memory
|
|
107
107
|
|
|
108
108
|
To access memory functions for querying, cloning, or deleting threads and messages, call `getMemory()` on an agent:
|
|
109
109
|
|
|
@@ -1,10 +1,10 @@
|
|
|
1
|
-
# Observational
|
|
1
|
+
# Observational memory
|
|
2
2
|
|
|
3
3
|
**Added in:** `@mastra/memory@1.1.0`
|
|
4
4
|
|
|
5
5
|
Observational Memory (OM) is Mastra's memory system for long-context agentic memory. Two background agents — an **Observer** and a **Reflector** — watch your agent's conversations and maintain a dense observation log that replaces raw message history as it grows.
|
|
6
6
|
|
|
7
|
-
## Quick
|
|
7
|
+
## Quick start
|
|
8
8
|
|
|
9
9
|
Enable `observationalMemory` in the memory options when creating your agent:
|
|
10
10
|
|
|
@@ -46,7 +46,7 @@ See [configuration options](https://mastra.ai/reference/memory/observational-mem
|
|
|
46
46
|
- **Compression**: Raw message history and tool results get compressed into a dense observation log. Smaller context means faster responses and longer coherent conversations.
|
|
47
47
|
- **Zero context rot**: The agent sees relevant information instead of noisy tool calls and irrelevant tokens, so the agent stays on task over long sessions.
|
|
48
48
|
|
|
49
|
-
## How
|
|
49
|
+
## How it works
|
|
50
50
|
|
|
51
51
|
You don't remember every word of every conversation you've ever had. You observe what happened subconsciously, then your brain reflects — reorganizing, combining, and condensing into long-term memory. OM works the same way.
|
|
52
52
|
|
|
@@ -149,7 +149,7 @@ For your use-case this may not be a problem, so your mileage may vary.
|
|
|
149
149
|
|
|
150
150
|
> **Warning:** In resource scope, unobserved messages across _all_ threads are processed together. For users with many existing threads, this can be slow. Use thread scope for existing apps.
|
|
151
151
|
|
|
152
|
-
## Token
|
|
152
|
+
## Token budgets
|
|
153
153
|
|
|
154
154
|
OM uses token thresholds to decide when to observe and reflect. See [token budget configuration](https://mastra.ai/reference/memory/observational-memory) for details.
|
|
155
155
|
|
|
@@ -183,7 +183,7 @@ OM caches tiktoken part estimates in message metadata to reduce repeat counting
|
|
|
183
183
|
- Message and conversation overhead are still recalculated on every pass. The cache only stores payload estimates, so counting semantics stay the same.
|
|
184
184
|
- `data-*` and `reasoning` parts are still skipped and aren't cached.
|
|
185
185
|
|
|
186
|
-
## Async
|
|
186
|
+
## Async buffering
|
|
187
187
|
|
|
188
188
|
Without async buffering, the Observer runs synchronously when the message threshold is reached — the agent pauses mid-conversation while the Observer LLM call completes. With async buffering (enabled by default), observations are pre-computed in the background as the conversation grows. When the threshold is hit, buffered observations activate instantly with no pause.
|
|
189
189
|
|
|
@@ -1,10 +1,10 @@
|
|
|
1
|
-
# Semantic
|
|
1
|
+
# Semantic recall
|
|
2
2
|
|
|
3
3
|
If you ask your friend what they did last weekend, they will search in their memory for events associated with "last weekend" and then tell you what they did. That's sort of like how semantic recall works in Mastra.
|
|
4
4
|
|
|
5
5
|
> **Watch 📹:** What semantic recall is, how it works, and how to configure it in Mastra → [YouTube (5 minutes)](https://youtu.be/UVZtK8cK8xQ)
|
|
6
6
|
|
|
7
|
-
## How
|
|
7
|
+
## How semantic recall works
|
|
8
8
|
|
|
9
9
|
Semantic recall is RAG-based search that helps agents maintain context across longer interactions when messages are no longer within [recent message history](https://mastra.ai/docs/memory/message-history).
|
|
10
10
|
|
|
@@ -16,7 +16,7 @@ When it's enabled, new messages are used to query a vector DB for semantically s
|
|
|
16
16
|
|
|
17
17
|
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.
|
|
18
18
|
|
|
19
|
-
## Quick
|
|
19
|
+
## Quick start
|
|
20
20
|
|
|
21
21
|
Semantic recall is enabled by default, so if you give your agent memory it will be included:
|
|
22
22
|
|
|
@@ -33,7 +33,7 @@ const agent = new Agent({
|
|
|
33
33
|
})
|
|
34
34
|
```
|
|
35
35
|
|
|
36
|
-
## Using the recall()
|
|
36
|
+
## Using the `recall()` method
|
|
37
37
|
|
|
38
38
|
While `listMessages` retrieves messages by thread ID with basic pagination, [`recall()`](https://mastra.ai/reference/memory/recall) adds support for **semantic search**. When you need to find messages by meaning rather than recency, use `recall()` with a `vectorSearchString`:
|
|
39
39
|
|
|
@@ -182,7 +182,7 @@ const agent = new Agent({
|
|
|
182
182
|
})
|
|
183
183
|
```
|
|
184
184
|
|
|
185
|
-
### Using FastEmbed (
|
|
185
|
+
### Using FastEmbed (local)
|
|
186
186
|
|
|
187
187
|
To use FastEmbed (a local embedding model), install `@mastra/fastembed`:
|
|
188
188
|
|
|
@@ -224,7 +224,7 @@ const agent = new Agent({
|
|
|
224
224
|
})
|
|
225
225
|
```
|
|
226
226
|
|
|
227
|
-
## PostgreSQL
|
|
227
|
+
## PostgreSQL index optimization
|
|
228
228
|
|
|
229
229
|
When using PostgreSQL as your vector store, you can optimize semantic recall performance by configuring the vector index. This is particularly important for large-scale deployments with thousands of messages.
|
|
230
230
|
|
|
@@ -283,6 +283,6 @@ You might want to disable semantic recall in scenarios like:
|
|
|
283
283
|
- When message history provides sufficient context for the current conversation.
|
|
284
284
|
- In performance-sensitive applications, like realtime two-way audio, where the added latency of creating embeddings and running vector queries is noticeable.
|
|
285
285
|
|
|
286
|
-
## Viewing
|
|
286
|
+
## Viewing recalled messages
|
|
287
287
|
|
|
288
288
|
When tracing is enabled, any messages retrieved via semantic recall will appear in the agent's trace output, alongside recent message history (if configured).
|
|
@@ -13,7 +13,7 @@ Working memory can persist at two different scopes:
|
|
|
13
13
|
|
|
14
14
|
**Important:** Switching between scopes means the agent won't see memory from the other scope - thread-scoped memory is completely separate from resource-scoped memory.
|
|
15
15
|
|
|
16
|
-
## Quick
|
|
16
|
+
## Quick start
|
|
17
17
|
|
|
18
18
|
Here's a minimal example of setting up an agent with working memory:
|
|
19
19
|
|
|
@@ -37,13 +37,13 @@ const agent = new Agent({
|
|
|
37
37
|
})
|
|
38
38
|
```
|
|
39
39
|
|
|
40
|
-
## How it
|
|
40
|
+
## How it works
|
|
41
41
|
|
|
42
42
|
Working memory is a block of Markdown text that the agent is able to update over time to store continuously relevant information:
|
|
43
43
|
|
|
44
44
|
[YouTube video player](https://www.youtube-nocookie.com/embed/UMy_JHLf1n8)
|
|
45
45
|
|
|
46
|
-
## Memory
|
|
46
|
+
## Memory persistence scopes
|
|
47
47
|
|
|
48
48
|
Working memory can operate in two different scopes, allowing you to choose how memory persists across conversations:
|
|
49
49
|
|
|
@@ -117,7 +117,7 @@ const memory = new Memory({
|
|
|
117
117
|
- Temporary or session-specific information
|
|
118
118
|
- Workflows where each thread needs working memory but threads are ephemeral and not related to each other
|
|
119
119
|
|
|
120
|
-
## Storage
|
|
120
|
+
## Storage adapter support
|
|
121
121
|
|
|
122
122
|
Resource-scoped working memory requires specific storage adapters that support the `mastra_resources` table:
|
|
123
123
|
|
|
@@ -128,7 +128,7 @@ Resource-scoped working memory requires specific storage adapters that support t
|
|
|
128
128
|
- **Upstash** (`@mastra/upstash`)
|
|
129
129
|
- **MongoDB** (`@mastra/mongodb`)
|
|
130
130
|
|
|
131
|
-
## Custom
|
|
131
|
+
## Custom templates
|
|
132
132
|
|
|
133
133
|
Templates guide the agent on what information to track and update in working memory. While a default template is used if none is provided, you'll typically want to define a custom template tailored to your agent's specific use case to ensure it remembers the most relevant information.
|
|
134
134
|
|
|
@@ -142,7 +142,7 @@ const memory = new Memory({
|
|
|
142
142
|
template: `
|
|
143
143
|
# User Profile
|
|
144
144
|
|
|
145
|
-
## Personal
|
|
145
|
+
## Personal info
|
|
146
146
|
|
|
147
147
|
- Name:
|
|
148
148
|
- Location:
|
|
@@ -156,7 +156,7 @@ const memory = new Memory({
|
|
|
156
156
|
- [Deadline 1]: [Date]
|
|
157
157
|
- [Deadline 2]: [Date]
|
|
158
158
|
|
|
159
|
-
## Session
|
|
159
|
+
## Session state
|
|
160
160
|
|
|
161
161
|
- Last Task Discussed:
|
|
162
162
|
- Open Questions:
|
|
@@ -168,7 +168,7 @@ const memory = new Memory({
|
|
|
168
168
|
})
|
|
169
169
|
```
|
|
170
170
|
|
|
171
|
-
## Designing
|
|
171
|
+
## Designing effective templates
|
|
172
172
|
|
|
173
173
|
A well-structured template keeps the information straightforward for the agent to parse and update. Treat the template as a short form that you want the assistant to keep up to date.
|
|
174
174
|
|
|
@@ -206,7 +206,7 @@ const paragraphMemory = new Memory({
|
|
|
206
206
|
})
|
|
207
207
|
```
|
|
208
208
|
|
|
209
|
-
## Structured
|
|
209
|
+
## Structured working memory
|
|
210
210
|
|
|
211
211
|
Working memory can also be defined using a structured schema instead of a Markdown template. This allows you to specify the exact fields and types that should be tracked, using a [Zod](https://zod.dev/) schema. When using a schema, the agent will see and update working memory as a JSON object matching your schema.
|
|
212
212
|
|
|
@@ -265,20 +265,20 @@ Schema-based working memory uses **merge semantics**, meaning the agent only nee
|
|
|
265
265
|
- **Set a field to `null` to delete it:** This explicitly removes the field from memory
|
|
266
266
|
- **Arrays are replaced entirely:** When an array field is provided, it replaces the existing array (arrays aren't merged element-by-element)
|
|
267
267
|
|
|
268
|
-
## Choosing
|
|
268
|
+
## Choosing between template and schema
|
|
269
269
|
|
|
270
270
|
- 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.
|
|
271
271
|
- Use a **schema** if you need structured, type-safe data that can be validated and programmatically accessed as JSON. Schemas use **merge semantics** — the agent only provides fields to update, and existing fields are preserved.
|
|
272
272
|
- Only one mode can be active at a time: setting both `template` and `schema` isn't supported.
|
|
273
273
|
|
|
274
|
-
## Example: Multi-step
|
|
274
|
+
## Example: Multi-step retention
|
|
275
275
|
|
|
276
276
|
Below is a simplified view of how the `User Profile` template updates across a short user conversation:
|
|
277
277
|
|
|
278
278
|
```nohighlight
|
|
279
279
|
# User Profile
|
|
280
280
|
|
|
281
|
-
## Personal
|
|
281
|
+
## Personal info
|
|
282
282
|
|
|
283
283
|
- Name:
|
|
284
284
|
- Location:
|
|
@@ -303,7 +303,7 @@ The agent can now refer to `Sam` or `Berlin` in later responses without requesti
|
|
|
303
303
|
|
|
304
304
|
If your agent isn't properly updating working memory when you expect it to, you can add system instructions on _how_ and _when_ to use this template in your agent's `instructions` setting.
|
|
305
305
|
|
|
306
|
-
## Setting
|
|
306
|
+
## Setting initial working memory
|
|
307
307
|
|
|
308
308
|
While agents typically update working memory through the `updateWorkingMemory` tool, you can also set initial working memory programmatically when creating or updating threads. This is useful for injecting user data (like their name, preferences, or other info) that you want available to the agent without passing it in every request.
|
|
309
309
|
|
|
@@ -372,7 +372,7 @@ await memory.updateWorkingMemory({
|
|
|
372
372
|
})
|
|
373
373
|
```
|
|
374
374
|
|
|
375
|
-
## Read-
|
|
375
|
+
## Read-only working memory
|
|
376
376
|
|
|
377
377
|
In some scenarios, you may want an agent to have access to working memory data without the ability to modify it. This is useful for:
|
|
378
378
|
|
|
@@ -22,7 +22,7 @@ const thread = await memory.createThread({
|
|
|
22
22
|
|
|
23
23
|
**memory** (`TMemory[TMemoryKey]`): The memory instance with the specified key. Throws an error if the memory is not found.
|
|
24
24
|
|
|
25
|
-
## Example: Registering and
|
|
25
|
+
## Example: Registering and retrieving memory
|
|
26
26
|
|
|
27
27
|
```typescript
|
|
28
28
|
import { Mastra } from '@mastra/core'
|
|
@@ -20,7 +20,7 @@ This method takes no parameters.
|
|
|
20
20
|
|
|
21
21
|
**memory** (`Record<string, MastraMemory>`): An object containing all registered memory instances, keyed by their registry keys.
|
|
22
22
|
|
|
23
|
-
## Example: Checking
|
|
23
|
+
## Example: Checking registered memory
|
|
24
24
|
|
|
25
25
|
```typescript
|
|
26
26
|
import { Mastra } from '@mastra/core'
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
# Cloned
|
|
1
|
+
# Cloned thread utilities
|
|
2
2
|
|
|
3
3
|
The Memory class provides utility methods for working with cloned threads. These methods help you check clone status, retrieve clone metadata, navigate clone relationships, and track clone history.
|
|
4
4
|
|
|
5
|
-
## isClone()
|
|
5
|
+
## `isClone()`
|
|
6
6
|
|
|
7
7
|
Checks whether a thread is a clone of another thread.
|
|
8
8
|
|
|
@@ -28,7 +28,7 @@ if (memory.isClone(thread)) {
|
|
|
28
28
|
}
|
|
29
29
|
```
|
|
30
30
|
|
|
31
|
-
## getCloneMetadata()
|
|
31
|
+
## `getCloneMetadata()`
|
|
32
32
|
|
|
33
33
|
Retrieves the clone metadata from a thread if it exists.
|
|
34
34
|
|
|
@@ -54,7 +54,7 @@ if (cloneInfo) {
|
|
|
54
54
|
}
|
|
55
55
|
```
|
|
56
56
|
|
|
57
|
-
## getSourceThread()
|
|
57
|
+
## `getSourceThread()`
|
|
58
58
|
|
|
59
59
|
Retrieves the original source thread that a cloned thread was created from.
|
|
60
60
|
|
|
@@ -79,7 +79,7 @@ if (sourceThread) {
|
|
|
79
79
|
}
|
|
80
80
|
```
|
|
81
81
|
|
|
82
|
-
## listClones()
|
|
82
|
+
## `listClones()`
|
|
83
83
|
|
|
84
84
|
Lists all threads that were cloned from a specific source thread.
|
|
85
85
|
|
|
@@ -104,7 +104,7 @@ for (const clone of clones) {
|
|
|
104
104
|
}
|
|
105
105
|
```
|
|
106
106
|
|
|
107
|
-
## getCloneHistory()
|
|
107
|
+
## `getCloneHistory()`
|
|
108
108
|
|
|
109
109
|
Retrieves the full clone history chain for a thread, tracing back to the original.
|
|
110
110
|
|
|
@@ -136,7 +136,7 @@ for (let i = 0; i < history.length; i++) {
|
|
|
136
136
|
}
|
|
137
137
|
```
|
|
138
138
|
|
|
139
|
-
## Complete
|
|
139
|
+
## Complete example
|
|
140
140
|
|
|
141
141
|
```typescript
|
|
142
142
|
import { mastra } from './mastra'
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
The `.cloneThread()` method creates a copy of an existing conversation thread, including all its messages. This enables creating divergent conversation paths from a specific point in a conversation. When semantic recall is enabled, the method also creates vector embeddings for the cloned messages.
|
|
4
4
|
|
|
5
|
-
## Usage
|
|
5
|
+
## Usage example
|
|
6
6
|
|
|
7
7
|
```typescript
|
|
8
8
|
const { thread, clonedMessages } = await memory.cloneThread({
|
|
@@ -52,7 +52,7 @@ The cloned thread's metadata includes a `clone` property with:
|
|
|
52
52
|
|
|
53
53
|
**lastMessageId** (`string`): The ID of the last message in the source thread at the time of cloning.
|
|
54
54
|
|
|
55
|
-
## Extended
|
|
55
|
+
## Extended usage example
|
|
56
56
|
|
|
57
57
|
```typescript
|
|
58
58
|
import { mastra } from './mastra'
|
|
@@ -98,7 +98,7 @@ const response = await agent.generate("Let's try a different approach", {
|
|
|
98
98
|
})
|
|
99
99
|
```
|
|
100
100
|
|
|
101
|
-
## Vector
|
|
101
|
+
## Vector embeddings
|
|
102
102
|
|
|
103
103
|
When the Memory instance has semantic recall enabled (with a vector store and embedder configured), `cloneThread()` automatically creates vector embeddings for all cloned messages. This ensures that semantic search works correctly on the cloned thread.
|
|
104
104
|
|
|
@@ -127,7 +127,7 @@ const results = await memory.recall({
|
|
|
127
127
|
})
|
|
128
128
|
```
|
|
129
129
|
|
|
130
|
-
## Observational
|
|
130
|
+
## Observational memory
|
|
131
131
|
|
|
132
132
|
When [Observational Memory](https://mastra.ai/docs/memory/observational-memory) is enabled, `cloneThread()` automatically clones the OM records associated with the source thread. The behavior depends on the OM scope:
|
|
133
133
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
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.
|
|
4
4
|
|
|
5
|
-
## Usage
|
|
5
|
+
## Usage example
|
|
6
6
|
|
|
7
7
|
```typescript
|
|
8
8
|
await memory?.createThread({ resourceId: 'user-123' })
|