@mastra/memory 1.27.0 → 1.28.0-alpha.3
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 +63 -0
- package/dist/docs/SKILL.md +5 -2
- package/dist/docs/assets/SOURCE_MAP.json +1 -1
- package/dist/docs/references/docs-guides-context-engineering.md +297 -0
- package/dist/docs/references/docs-storage.md +2 -0
- package/dist/docs/references/integrations-databases-elasticsearch.md +156 -0
- package/dist/docs/references/integrations-databases-libsql.md +16 -0
- package/dist/docs/references/integrations-databases-mongodb.md +1 -1
- package/dist/docs/references/integrations-databases-postgresql.md +26 -0
- package/dist/docs/references/integrations-databases-valkey.md +99 -0
- package/dist/docs/references/reference-vectors-mongodb.md +11 -11
- package/dist/docs/references/reference-vectors-pg.md +2 -0
- package/dist/index.cjs +1 -1
- package/dist/index.d.ts +6 -3
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +1 -1
- package/dist/processors/index.cjs +1 -1
- package/dist/processors/index.js +1 -1
- package/dist/processors/observational-memory/observation-turn/load-memory-context.d.ts +3 -1
- package/dist/processors/observational-memory/observation-turn/load-memory-context.d.ts.map +1 -1
- package/dist/processors/observational-memory/observation-turn/turn.d.ts +2 -1
- package/dist/processors/observational-memory/observation-turn/turn.d.ts.map +1 -1
- package/dist/processors/observational-memory/observational-memory.d.ts +6 -12
- package/dist/processors/observational-memory/observational-memory.d.ts.map +1 -1
- package/dist/processors/observational-memory/observer-agent.d.ts.map +1 -1
- package/dist/processors/observational-memory/processor.d.ts +2 -0
- package/dist/processors/observational-memory/processor.d.ts.map +1 -1
- package/dist/processors/observational-memory/reflector-runner.d.ts +15 -0
- package/dist/processors/observational-memory/reflector-runner.d.ts.map +1 -1
- package/dist/processors/observational-memory/tracing.d.ts.map +1 -1
- package/dist/processors/observational-memory/types.d.ts +23 -13
- package/dist/processors/observational-memory/types.d.ts.map +1 -1
- package/dist/{src-aTfbkxBl.js → src-BTHCV1ov.js} +314 -164
- package/dist/src-BTHCV1ov.js.map +1 -0
- package/dist/{src-CxkQ-ICG.cjs → src-D8byb8Ge.cjs} +314 -164
- package/dist/src-D8byb8Ge.cjs.map +1 -0
- package/package.json +7 -7
- package/dist/src-CxkQ-ICG.cjs.map +0 -1
- package/dist/src-aTfbkxBl.js.map +0 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,68 @@
|
|
|
1
1
|
# @mastra/memory
|
|
2
2
|
|
|
3
|
+
## 1.28.0-alpha.3
|
|
4
|
+
|
|
5
|
+
### Patch Changes
|
|
6
|
+
|
|
7
|
+
- Fixed observational memory being silently wiped when every reflection attempt produced empty or degenerate output. Failed reflections now throw and leave existing observations intact. ([#22074](https://github.com/mastra-ai/mastra/pull/22074))
|
|
8
|
+
|
|
9
|
+
Threshold-triggered synchronous reflections are no longer re-run against unchanged observations after an attempt that failed or finished still over the reflection threshold. Reflection retries as soon as observations change.
|
|
10
|
+
|
|
11
|
+
- Fix `continuationHints` being silently dropped when Observational Memory is configured through `Memory`. `Memory._initOMEngine` forwards the `observation`/`reflection` configs to the OM engine via explicit field lists, and `continuationHints` (added in #21302) was missing from both — so `continuationHints: { suggestedResponse: false }` had no effect unless `ObservationalMemory` was constructed directly. The Observer/Reflector prompts kept requesting the disabled sections and the injection gate kept admitting them. ([#22235](https://github.com/mastra-ai/mastra/pull/22235))
|
|
12
|
+
|
|
13
|
+
- Updated dependencies [[`aa3a85d`](https://github.com/mastra-ai/mastra/commit/aa3a85daf094c683bb97efdf4b6a696d2e474af5), [`d29d06f`](https://github.com/mastra-ai/mastra/commit/d29d06fe00bbd35b4571150ea04c59d2ed783c71), [`e6516df`](https://github.com/mastra-ai/mastra/commit/e6516dfcdae4f4ac0e7971d84359a81385ee602f), [`0b2a3d1`](https://github.com/mastra-ai/mastra/commit/0b2a3d1783875c5b97b7b36ab3d03d7360e0dde7), [`6bb5d71`](https://github.com/mastra-ai/mastra/commit/6bb5d7193fe9166b219f0fccae17db7a5ae86e65), [`57de7d6`](https://github.com/mastra-ai/mastra/commit/57de7d644ba7146edb4e9e6111ec4fa98c3a59e9), [`e8e299c`](https://github.com/mastra-ai/mastra/commit/e8e299cc6abdfc39947e2fec25803493015d3882), [`edfc548`](https://github.com/mastra-ai/mastra/commit/edfc548886bc7bae17b681f8b6b41a47eb32bcd2), [`a8a4871`](https://github.com/mastra-ai/mastra/commit/a8a4871215f51da95c47129602157ce5372f634a), [`5165cdc`](https://github.com/mastra-ai/mastra/commit/5165cdcdcf50e144bb8113278535196cc9b07065), [`6bb5d71`](https://github.com/mastra-ai/mastra/commit/6bb5d7193fe9166b219f0fccae17db7a5ae86e65), [`9ee8120`](https://github.com/mastra-ai/mastra/commit/9ee8120ce17f76b9f617489e05a283353742690a), [`d975e92`](https://github.com/mastra-ai/mastra/commit/d975e924d4936f46c386bd3dee39c671720289f6), [`1cfa878`](https://github.com/mastra-ai/mastra/commit/1cfa8784d8da0dfaa0317e5048bc48b6084a5ea5), [`c118318`](https://github.com/mastra-ai/mastra/commit/c1183181c9804303db4b511c2e2648f8b714712b), [`fc07c64`](https://github.com/mastra-ai/mastra/commit/fc07c6465043e08e99193a6751a01c56ffc2e7a1), [`542dee2`](https://github.com/mastra-ai/mastra/commit/542dee254167f974ff8cbbbfc0ce10f9a2616a7b), [`a58483c`](https://github.com/mastra-ai/mastra/commit/a58483cff1a9d41fce7c931843f48cb0ac450f64), [`a58483c`](https://github.com/mastra-ai/mastra/commit/a58483cff1a9d41fce7c931843f48cb0ac450f64), [`895e9df`](https://github.com/mastra-ai/mastra/commit/895e9dfc17d6f34299eca64e317ded9e5f5e5ef8)]:
|
|
14
|
+
- @mastra/core@1.62.0-alpha.8
|
|
15
|
+
|
|
16
|
+
## 1.28.0-alpha.2
|
|
17
|
+
|
|
18
|
+
### Patch Changes
|
|
19
|
+
|
|
20
|
+
- Observational memory now detects observer/reflector output where a multi-line block repeats many times (a model repetition loop). Previously such output could slip past the degenerate-output check and balloon stored observations, causing constant synchronous reflection churn; it is now rejected and retried like other degenerate output. ([#22072](https://github.com/mastra-ai/mastra/pull/22072))
|
|
21
|
+
|
|
22
|
+
- Fixed observational memory reflection to keep retrying with stronger compression when a result remains above the token threshold. ([#22232](https://github.com/mastra-ai/mastra/pull/22232))
|
|
23
|
+
|
|
24
|
+
- Updated dependencies [[`ae8790c`](https://github.com/mastra-ai/mastra/commit/ae8790c4bfaa088d2ab279d1dcc06f326b9fd109), [`04a815f`](https://github.com/mastra-ai/mastra/commit/04a815fc8971d29e97fcdcc5008a1eb472fc00ff), [`cced745`](https://github.com/mastra-ai/mastra/commit/cced745a056ec2225c5bc702e32d848847aa8b65)]:
|
|
25
|
+
- @mastra/core@1.62.0-alpha.7
|
|
26
|
+
|
|
27
|
+
## 1.28.0-alpha.1
|
|
28
|
+
|
|
29
|
+
### Minor Changes
|
|
30
|
+
|
|
31
|
+
- Added opt-in awaited Observational Memory hooks for synchronous cycles. ([#22147](https://github.com/mastra-ai/mastra/pull/22147))
|
|
32
|
+
|
|
33
|
+
Set `hookExecution: "await"` to await lifecycle hooks, stop the observer or reflector when a start hook fails, and receive one paired end callback after cleanup. Async-buffer cycles remain fire-and-forget.
|
|
34
|
+
|
|
35
|
+
```ts
|
|
36
|
+
const memory = new Memory({
|
|
37
|
+
options: {
|
|
38
|
+
observationalMemory: {
|
|
39
|
+
hookExecution: 'await',
|
|
40
|
+
hooks: {
|
|
41
|
+
onObservationStart: async context => {
|
|
42
|
+
await authorizeObservation(context);
|
|
43
|
+
},
|
|
44
|
+
},
|
|
45
|
+
},
|
|
46
|
+
},
|
|
47
|
+
});
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
### Patch Changes
|
|
51
|
+
|
|
52
|
+
- Updated dependencies [[`65edab1`](https://github.com/mastra-ai/mastra/commit/65edab1c233d17b8f163bad12fca410d0e6f16b1), [`ab20a38`](https://github.com/mastra-ai/mastra/commit/ab20a38d0275f8d85e0f3833bd87ef487bcc609f), [`dbbfeb8`](https://github.com/mastra-ai/mastra/commit/dbbfeb85ec949dc9ebc0755e1ad262e4f5eba8db), [`3cc9d00`](https://github.com/mastra-ai/mastra/commit/3cc9d00b2b4333e0377a5e9df5eff92c17ce7630), [`733a537`](https://github.com/mastra-ai/mastra/commit/733a537489a858b5880b2e98809334fba895a221), [`9207dfa`](https://github.com/mastra-ai/mastra/commit/9207dfab8062e5fc68b751684797ff86fe0b4e70), [`12c61d2`](https://github.com/mastra-ai/mastra/commit/12c61d280c8cb208bc3c8dbcbe5dcc60cf9d1cd0), [`9a12ef3`](https://github.com/mastra-ai/mastra/commit/9a12ef3fccf3f4186db0f294f4ee1f02cf4d8db2)]:
|
|
53
|
+
- @mastra/core@1.62.0-alpha.5
|
|
54
|
+
|
|
55
|
+
## 1.27.1-alpha.0
|
|
56
|
+
|
|
57
|
+
### Patch Changes
|
|
58
|
+
|
|
59
|
+
- Fixed Observational Memory tracing spans (`om.observer`, `om.observer.multi-thread`, `om.reflector`) never being ended. Unended spans kept their traces retained in exporters that hold a trace open until every span in it finishes — a memory leak with the Datadog bridge, which retains full LLM Observability payloads — and meant Observational Memory tracing never reached any exporter. The spans now end when the observer/reflector run completes, and record the error before ending when it fails. ([#22117](https://github.com/mastra-ai/mastra/pull/22117))
|
|
60
|
+
|
|
61
|
+
- Improved agent turn latency by reusing run-scoped memory reads ([#22076](https://github.com/mastra-ai/mastra/pull/22076))
|
|
62
|
+
|
|
63
|
+
- Updated dependencies [[`2c85f42`](https://github.com/mastra-ai/mastra/commit/2c85f428e04ccd63ea31a7ec80b5b327afdad555), [`11bbeb9`](https://github.com/mastra-ai/mastra/commit/11bbeb9b108ef2264e05acefc6dafb9cbb342921), [`1a485f3`](https://github.com/mastra-ai/mastra/commit/1a485f3538f5ec64d58bd8b5e1e99de0c695c87b), [`0d37487`](https://github.com/mastra-ai/mastra/commit/0d37487d9f349388a3f1cef6a536cf9dcc4b6273), [`8661d7d`](https://github.com/mastra-ai/mastra/commit/8661d7d7179f0a024456aabdd8679bcecd09ac28), [`575e343`](https://github.com/mastra-ai/mastra/commit/575e343900451021d96110916497d334af7bc252), [`cacb839`](https://github.com/mastra-ai/mastra/commit/cacb8392d9e74189b56d857290b0615f98a2683d), [`b47b26e`](https://github.com/mastra-ai/mastra/commit/b47b26e6fe95cb8a3482be2c5e52de157fe59d0b), [`0d37487`](https://github.com/mastra-ai/mastra/commit/0d37487d9f349388a3f1cef6a536cf9dcc4b6273), [`c46eb09`](https://github.com/mastra-ai/mastra/commit/c46eb09ce4987509af57a0ac582c61241a6dd2f1), [`30ed33e`](https://github.com/mastra-ai/mastra/commit/30ed33ee14084a26019aba15fceadda6d6ddefaf), [`91ad69d`](https://github.com/mastra-ai/mastra/commit/91ad69d64994c89199b0c55399e64ed91c61df2f), [`8dc408d`](https://github.com/mastra-ai/mastra/commit/8dc408d34438f9e13297f792c11a5cfd6cf952e1), [`c92def1`](https://github.com/mastra-ai/mastra/commit/c92def10a13c822972c96f0a4ca6ffc1f4258aed), [`c5eaec5`](https://github.com/mastra-ai/mastra/commit/c5eaec5a860d80d0e3805e67db0414b87ac8cbed), [`e66b2ba`](https://github.com/mastra-ai/mastra/commit/e66b2ba100db63eaeab6e21e1ea34b113f2ec781)]:
|
|
64
|
+
- @mastra/core@1.62.0-alpha.3
|
|
65
|
+
|
|
3
66
|
## 1.27.0
|
|
4
67
|
|
|
5
68
|
### Minor 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
|
+
version: "1.28.0-alpha.3"
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
## When to use
|
|
@@ -19,6 +19,7 @@ Read the individual reference documents for detailed explanations and code examp
|
|
|
19
19
|
- [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.
|
|
20
20
|
- [Agent networks](references/docs-agents-networks.md) - Coordinate multiple agents, workflows, and tools using agent networks for complex, non-deterministic task execution.
|
|
21
21
|
- [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.
|
|
22
|
+
- [Context engineering](references/docs-guides-context-engineering.md) - Learn how to choose, retrieve, persist, and control the context a Mastra agent receives.
|
|
22
23
|
- [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.
|
|
23
24
|
- [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.
|
|
24
25
|
- [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.
|
|
@@ -36,12 +37,14 @@ Read the individual reference documents for detailed explanations and code examp
|
|
|
36
37
|
- [GitHub](references/integrations-channels-github.md) - Notify a Mastra agent when subscribed GitHub pull requests change.
|
|
37
38
|
- [Aurora DSQL](references/integrations-databases-aurora-dsql.md) - Documentation for the Amazon Aurora DSQL storage implementation in Mastra.
|
|
38
39
|
- [DynamoDB](references/integrations-databases-dynamodb.md) - Documentation for the DynamoDB storage implementation in Mastra, using a single-table design with ElectroDB.
|
|
40
|
+
- [Elasticsearch](references/integrations-databases-elasticsearch.md) - Documentation for the Elasticsearch storage implementation in Mastra.
|
|
39
41
|
- [libSQL](references/integrations-databases-libsql.md) - Documentation for the libSQL storage implementation in Mastra.
|
|
40
42
|
- [MongoDB](references/integrations-databases-mongodb.md) - Documentation for the MongoDB storage implementation in Mastra.
|
|
41
43
|
- [OracleDB](references/integrations-databases-oracledb.md) - Documentation for the Oracle Database storage provider in Mastra.
|
|
42
44
|
- [PostgreSQL](references/integrations-databases-postgresql.md) - Documentation for the PostgreSQL storage implementation in Mastra.
|
|
43
45
|
- [Redis](references/integrations-databases-redis.md) - Documentation for the Redis storage implementation in Mastra.
|
|
44
46
|
- [Upstash](references/integrations-databases-upstash.md) - Documentation for the Upstash storage implementation in Mastra.
|
|
47
|
+
- [Valkey](references/integrations-databases-valkey.md) - Documentation for the GLIDE-backed Valkey storage implementation in Mastra.
|
|
45
48
|
|
|
46
49
|
### Reference
|
|
47
50
|
|
|
@@ -62,7 +65,7 @@ Read the individual reference documents for detailed explanations and code examp
|
|
|
62
65
|
- [Memory](references/reference-migrations-upgrade-to-v1-memory.md) - Learn how to migrate memory-related changes when upgrading to v1.
|
|
63
66
|
- [Reference: TokenLimiterProcessor](references/reference-processors-token-limiter-processor.md) - Documentation for the TokenLimiterProcessor in Mastra, which limits the number of tokens in messages.
|
|
64
67
|
- [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.
|
|
65
|
-
- [Reference: MongoDB vector store](references/reference-vectors-mongodb.md) - Documentation for the MongoDBVector class in Mastra, which provides vector search using MongoDB Atlas and
|
|
68
|
+
- [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.
|
|
66
69
|
- [Reference: OracleDB vector store](references/reference-vectors-oracledb.md) - Documentation for the Oracle Database vector provider in Mastra.
|
|
67
70
|
- [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.
|
|
68
71
|
- [Reference: Upstash vector store](references/reference-vectors-upstash.md) - Documentation for the UpstashVector class in Mastra, which provides vector search using Upstash Vector.
|
|
@@ -0,0 +1,297 @@
|
|
|
1
|
+
> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
|
|
2
|
+
|
|
3
|
+
# Context engineering
|
|
4
|
+
|
|
5
|
+
A model can only work with the information available in its context window. That might include the current conversation, remembered details, application data, tool results, or relevant passages from a knowledge base.
|
|
6
|
+
|
|
7
|
+
Context engineering is the practice of deciding what information the model should see and when. The goal isn't to provide as much as possible, but to keep the context relevant and current. Too little context leaves the model without information it needs; too much can make important details harder to find, increase cost, and reduce the quality of the response long before the model reaches its context limit.
|
|
8
|
+
|
|
9
|
+
Mastra provides different ways to bring information into context, keep it available over time, retrieve it when needed, and reduce or isolate it as a task grows. This guide explains when to use each mechanism and how they fit together.
|
|
10
|
+
|
|
11
|
+
| Need | Start with | What the model sees |
|
|
12
|
+
| ----------------------------------------- | --------------------------------------------- | -------------------------------------------------------- |
|
|
13
|
+
| Stable identity, rules, or constraints | [Instructions](#instructions) | System context on each model call |
|
|
14
|
+
| Data from a database or API | [Tools](#tools) | Tool definitions followed by selected results |
|
|
15
|
+
| Current customer or application data | [Inline context](#inline-context) | Data interpolated into the user message |
|
|
16
|
+
| A large, stable knowledge base | [RAG](#rag) | Semantically relevant chunks from an index |
|
|
17
|
+
| User- or organization-managed documents | [Filesystems](#filesystems) | Files selected through read or search tools |
|
|
18
|
+
| Recent conversation or durable facts | [Memory](#memory) | History, observations, or retrieved memories |
|
|
19
|
+
| A long-running conversation | [Observational Memory](#observational-memory) | Dense observations plus recent unobserved messages |
|
|
20
|
+
| New events or changing state during a run | [Signals](#signals) | User, reactive, notification, or state messages |
|
|
21
|
+
| Instructions needed only for some tasks | [Dynamic skills](#dynamic-skills) | Skill metadata followed by instructions loaded on demand |
|
|
22
|
+
|
|
23
|
+
## Instructions
|
|
24
|
+
|
|
25
|
+
An agent's [`instructions`](https://mastra.ai/reference/agents/agent) define its stable identity, behavior, and constraints. They're system messages and appear before conversation messages in the model request.
|
|
26
|
+
|
|
27
|
+
```typescript
|
|
28
|
+
import { Agent } from '@mastra/core/agent'
|
|
29
|
+
|
|
30
|
+
export const supportAgent = new Agent({
|
|
31
|
+
id: 'support-agent',
|
|
32
|
+
name: 'Support Agent',
|
|
33
|
+
instructions: `You help customers understand their account.
|
|
34
|
+
Today is ${new Date().toDateString()}.
|
|
35
|
+
Use plain language and don't invent account details.`,
|
|
36
|
+
model: 'openai/gpt-5.6-sol',
|
|
37
|
+
})
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
Keep instructions focused on behavior that applies to most calls. Adding current account data, retrieved documents, or task-specific details makes the base prompt larger and harder to reuse.
|
|
41
|
+
|
|
42
|
+
Instructions can also be resolved at runtime from [`RequestContext`](https://mastra.ai/docs/server/request-context):
|
|
43
|
+
|
|
44
|
+
```typescript
|
|
45
|
+
instructions: ({ requestContext }) => {
|
|
46
|
+
const name = requestContext.get('name')
|
|
47
|
+
|
|
48
|
+
return `You help ${name} understand their account.`
|
|
49
|
+
}
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
Use `RequestContext` when instructions depend on data that changes with each request, such as the current user, tenant, locale, role, or feature flags. Values that don't come from the request, such as the current date, can be interpolated directly as shown in the first example.
|
|
53
|
+
|
|
54
|
+
> **Tip:** If the resolved instructions change often, the model provider may not be able to reuse the same prompt cache prefix. Keep the stable part first, and pass frequently changing background through messages or signals instead.
|
|
55
|
+
>
|
|
56
|
+
> Watch [this short video on prompt caching](https://youtu.be/eBB0dBqfvuQ) to learn how cacheable prompt prefixes reduce latency and cost.
|
|
57
|
+
|
|
58
|
+
## Inline context
|
|
59
|
+
|
|
60
|
+
Most applications pass runtime context by interpolating relevant values into the current message. This works well when your code has already loaded customer or application data:
|
|
61
|
+
|
|
62
|
+
```typescript
|
|
63
|
+
const customer = await db.customer.findById(customerId)
|
|
64
|
+
|
|
65
|
+
await supportAgent.generate(`
|
|
66
|
+
Customer: ${customer.name}
|
|
67
|
+
Plan: ${customer.plan}
|
|
68
|
+
Question: ${question}
|
|
69
|
+
`)
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
Select and label the fields the model needs instead of serializing an entire database record. This keeps the prompt smaller and makes the meaning of each value clear.
|
|
73
|
+
|
|
74
|
+
When memory is enabled, Mastra saves the current user message. Don't interpolate sensitive or temporary data that shouldn't appear in conversation history.
|
|
75
|
+
|
|
76
|
+
For the less common case where background should affect one response without being saved as conversation history, pass a [`context`](https://mastra.ai/reference/agents/generate) message:
|
|
77
|
+
|
|
78
|
+
```typescript
|
|
79
|
+
await supportAgent.generate('Recommend the next action.', {
|
|
80
|
+
context: [{ role: 'user', content: 'The customer has an unresolved billing dispute.' }],
|
|
81
|
+
})
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
The model sees this background for the current execution, but Mastra doesn't save it to memory. Use `context` when persisting the background would pollute the conversation or expose temporary application state on later turns.
|
|
85
|
+
|
|
86
|
+
## Tools
|
|
87
|
+
|
|
88
|
+
[Tools](https://mastra.ai/docs/agents/tools) are the recommended way to fetch current data from a database, API, or service. The model decides when it needs the data and supplies the tool arguments, while your application controls the query and returned fields.
|
|
89
|
+
|
|
90
|
+
```typescript
|
|
91
|
+
import { createTool } from '@mastra/core/tools'
|
|
92
|
+
import { z } from 'zod'
|
|
93
|
+
|
|
94
|
+
export const getCustomer = createTool({
|
|
95
|
+
id: 'get-customer',
|
|
96
|
+
description: 'Gets the current profile and plan for a customer',
|
|
97
|
+
inputSchema: z.object({ customerId: z.string() }),
|
|
98
|
+
execute: async ({ customerId }) => {
|
|
99
|
+
const customer = await db.customer.findById(customerId)
|
|
100
|
+
return { name: customer.name, plan: customer.plan, status: customer.status }
|
|
101
|
+
},
|
|
102
|
+
})
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
Use [`toModelOutput`](https://mastra.ai/docs/agents/tools) when application code needs the full result but the model needs a smaller representation.
|
|
106
|
+
|
|
107
|
+
## RAG
|
|
108
|
+
|
|
109
|
+
[Retrieval-Augmented Generation (RAG)](https://mastra.ai/reference/rag/overview) retrieves semantically relevant chunks from an indexed corpus. It still fits large, stable knowledge bases where users ask open-ended questions that don't map cleanly to structured database queries.
|
|
110
|
+
|
|
111
|
+
```typescript
|
|
112
|
+
import { ModelRouterEmbeddingModel } from '@mastra/core/llm'
|
|
113
|
+
import { createVectorQueryTool } from '@mastra/rag'
|
|
114
|
+
|
|
115
|
+
const knowledgeBase = createVectorQueryTool({
|
|
116
|
+
vectorStoreName: 'knowledgeBase',
|
|
117
|
+
indexName: 'support-docs',
|
|
118
|
+
model: new ModelRouterEmbeddingModel('openai/text-embedding-3-small'),
|
|
119
|
+
})
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
Register the vector store referenced by `vectorStoreName` on the same Mastra instance as the agent. Mastra supports [multiple vector databases](https://mastra.ai/reference/rag/vector-databases). RAG is often exposed through a tool, as in this example. The design choice is whether the agent needs semantic retrieval or can query the source directly.
|
|
123
|
+
|
|
124
|
+
Many applications now start with direct, source-specific tools. Models have become better at selecting them, and a direct query is often simpler and cheaper because it doesn't require a chunking, embedding, and vector-index pipeline. Choose RAG when semantic search over unstructured content is the actual requirement, then constrain the returned context with metadata filters, reranking, and a conservative `topK`.
|
|
125
|
+
|
|
126
|
+
## Filesystems
|
|
127
|
+
|
|
128
|
+
A [filesystem](https://mastra.ai/docs/sandbox/filesystem) gives an agent persistent access to documents and other files. Files can live in a local directory or in providers such as Amazon S3, AgentFS, or Google Drive. The agent receives built-in tools to list, read, and search them.
|
|
129
|
+
|
|
130
|
+
```typescript
|
|
131
|
+
import { LocalFilesystem, Workspace } from '@mastra/core/workspace'
|
|
132
|
+
|
|
133
|
+
export const workspace = new Workspace({
|
|
134
|
+
filesystem: new LocalFilesystem({ basePath: './knowledge-base' }),
|
|
135
|
+
bm25: true,
|
|
136
|
+
autoIndexPaths: ['**/*.md'],
|
|
137
|
+
})
|
|
138
|
+
|
|
139
|
+
// Agents receive tools including read_file, list_files, grep,
|
|
140
|
+
// mastra_workspace_search, and mastra_workspace_index.
|
|
141
|
+
await workspace.init()
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
[Workspace search](https://mastra.ai/docs/sandbox/search) supports BM25 keyword search, vector semantic search, or a hybrid of both. Use a filesystem for a personal assistant that works with a user's files or an organization knowledge base that teammates update in a service such as Google Drive. Search runs against the workspace index, so changed files must be indexed before the agent can retrieve their latest contents.
|
|
145
|
+
|
|
146
|
+
> **Tip:** Filesystem search can also use vectors, so it overlaps with RAG. Choose a filesystem when the source of truth is a set of files that the agent may need to list, read, or update. Choose a standalone RAG pipeline when retrieval is the main requirement and the source content doesn't need to behave like files.
|
|
147
|
+
|
|
148
|
+
## Memory
|
|
149
|
+
|
|
150
|
+
[Memory](https://mastra.ai/docs/memory/overview) gives an agent conversational coherence across turns. It brings recent messages and remembered details into context without requiring the application to resend the full transcript on every turn.
|
|
151
|
+
|
|
152
|
+
Memory requires a storage provider. Each call also identifies a `resource` that owns the memory and a `thread` that identifies the conversation. Reuse both values to continue the same conversation:
|
|
153
|
+
|
|
154
|
+
```typescript
|
|
155
|
+
import { Agent } from '@mastra/core/agent'
|
|
156
|
+
import { Memory } from '@mastra/memory'
|
|
157
|
+
|
|
158
|
+
export const assistant = new Agent({
|
|
159
|
+
id: 'assistant',
|
|
160
|
+
name: 'Assistant',
|
|
161
|
+
model: 'openai/gpt-5.6-sol',
|
|
162
|
+
memory: new Memory({
|
|
163
|
+
options: {
|
|
164
|
+
lastMessages: 20,
|
|
165
|
+
},
|
|
166
|
+
}),
|
|
167
|
+
})
|
|
168
|
+
|
|
169
|
+
await assistant.generate('Help me plan the next project milestone.', {
|
|
170
|
+
memory: {
|
|
171
|
+
resource: 'user-123',
|
|
172
|
+
thread: 'project-456',
|
|
173
|
+
},
|
|
174
|
+
})
|
|
175
|
+
```
|
|
176
|
+
|
|
177
|
+
The example assumes storage is configured on the registered Mastra instance or directly on `Memory`. `lastMessages` controls how many recent messages Mastra loads from the thread. The default is 10.
|
|
178
|
+
|
|
179
|
+
Message history works well for shorter conversations where recent turns contain the context the agent needs. For long-running conversations, Mastra recommends [Observational Memory](https://mastra.ai/docs/memory/observational-memory), which keeps recent conversation available and turns older history into a dense observation log.
|
|
180
|
+
|
|
181
|
+
## Observational Memory
|
|
182
|
+
|
|
183
|
+
Conversation history grows with every user message, response, and tool call. Even before it reaches the model's hard context limit, a long transcript can increase cost and make relevant details harder for the model to find. Compression replaces old, verbose history with a smaller representation.
|
|
184
|
+
|
|
185
|
+
[Observational Memory](https://mastra.ai/docs/memory/observational-memory) handles this continuously. An Observer turns older messages and tool interactions into dense observations, while periodic reflection reorganizes and compresses those observations.
|
|
186
|
+
|
|
187
|
+
You don't need to configure `lastMessages` when Observational Memory is enabled. Observational Memory manages history itself, keeping recent unobserved messages in context and replacing older messages with observations.
|
|
188
|
+
|
|
189
|
+
```typescript
|
|
190
|
+
import { Agent } from '@mastra/core/agent'
|
|
191
|
+
import { Memory } from '@mastra/memory'
|
|
192
|
+
|
|
193
|
+
export const assistant = new Agent({
|
|
194
|
+
id: 'assistant',
|
|
195
|
+
name: 'Assistant',
|
|
196
|
+
model: 'openai/gpt-5.6-sol',
|
|
197
|
+
memory: new Memory({
|
|
198
|
+
options: {
|
|
199
|
+
observationalMemory: true,
|
|
200
|
+
},
|
|
201
|
+
}),
|
|
202
|
+
})
|
|
203
|
+
```
|
|
204
|
+
|
|
205
|
+
After messages are observed, the model receives the observation log, recent messages that haven't been observed, and a continuation reminder. The raw messages remain stored but no longer occupy the active model context.
|
|
206
|
+
|
|
207
|
+
Observations are added in stable chunks, which helps providers reuse the existing prompt prefix. Observational Memory can also activate buffered observations after a prompt cache is likely to expire or before the agent changes providers.
|
|
208
|
+
|
|
209
|
+
## Signals
|
|
210
|
+
|
|
211
|
+
> **Beta:** Signals may change without a major version bump until the API is stable.
|
|
212
|
+
|
|
213
|
+
[Signals](https://mastra.ai/docs/harness/signals) add messages or system-generated context to a memory-backed thread. Delivery depends on the thread's state: a signal can wake an idle agent or enter an active loop. It can also wait for the next turn or persist without waking the agent.
|
|
214
|
+
|
|
215
|
+
State signals require memory and an existing thread. Notification inbox signals require a storage adapter with notification support.
|
|
216
|
+
|
|
217
|
+
| API | Use | Context behavior |
|
|
218
|
+
| ------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------- |
|
|
219
|
+
| `sendMessage()` | User input that the active agent should see now | Enters the active loop or wakes an idle thread |
|
|
220
|
+
| `queueMessage()` | User input that should wait for the next turn | Starts after the current run finishes |
|
|
221
|
+
| `sendSignal()` | Background results, policy reminders, or external events | Adds reactive or notification context according to its delivery options |
|
|
222
|
+
| `sendStateSignal()` | Browser state, editor state, task state, or another changing value | Maintains a thread-scoped state lane with snapshots and deltas |
|
|
223
|
+
|
|
224
|
+
Use `sendSignal()` for context produced by the system rather than the user:
|
|
225
|
+
|
|
226
|
+
```typescript
|
|
227
|
+
const result = agent.sendSignal(
|
|
228
|
+
{
|
|
229
|
+
type: 'notification',
|
|
230
|
+
contents: 'CI failed on pull request 123: three tests failed.',
|
|
231
|
+
attributes: { source: 'github', pullRequest: 123 },
|
|
232
|
+
},
|
|
233
|
+
{
|
|
234
|
+
resourceId: 'user-123',
|
|
235
|
+
threadId: 'project-456',
|
|
236
|
+
},
|
|
237
|
+
)
|
|
238
|
+
|
|
239
|
+
await result.accepted
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
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.
|
|
243
|
+
|
|
244
|
+
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.
|
|
245
|
+
|
|
246
|
+
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.
|
|
247
|
+
|
|
248
|
+
## Dynamic skills
|
|
249
|
+
|
|
250
|
+
[Agent skills](https://mastra.ai/docs/skills) let an agent load task-specific instructions only when needed instead of carrying every procedure in its base instructions. Use them for specialized guidance that applies to some requests and keep the default context smaller.
|
|
251
|
+
|
|
252
|
+
## Context control
|
|
253
|
+
|
|
254
|
+
Context control limits what the model sees as a task grows. Compaction and processors reduce context within one agent, while subagent boundaries control what moves between agents.
|
|
255
|
+
|
|
256
|
+
### Compaction
|
|
257
|
+
|
|
258
|
+
If you've used Claude Code, you may have seen compaction happen during a long session. The Mastra team likes to joke, "Friends don't let friends do compaction."
|
|
259
|
+
|
|
260
|
+
Compaction waits until a conversation reaches a token threshold. It then summarizes the transcript and replaces earlier messages. It's a blunt fallback. The compaction turn adds latency, and a single summary has to represent everything that came before. Repeated summaries can flatten chronology or lose details that later become important.
|
|
261
|
+
|
|
262
|
+
Prefer [Observational Memory](#observational-memory) for long-running conversations. It can process history asynchronously in the background while preserving temporal context. Reflection revisits accumulated memories and naturally prunes details that no longer matter. Mastra doesn't provide compaction out of the box, though you could implement it with a custom [processor](https://mastra.ai/docs/agents/processors).
|
|
263
|
+
|
|
264
|
+
### Processors
|
|
265
|
+
|
|
266
|
+
[Processors](https://mastra.ai/docs/agents/processors) control what enters model context and can rewrite content before a model call. Use them when information should remain in stored history or application output but doesn't need to be sent back to the model on every step.
|
|
267
|
+
|
|
268
|
+
For example, `ToolCallFilter` removes old tool arguments and results from the next model request without deleting those messages from storage. The model gets a smaller prompt, while your application can still display or inspect the complete interaction.
|
|
269
|
+
|
|
270
|
+
Use `processInput()` or `processInputStep()` to change the active message list. Those changes may later be saved to memory. Use `processLLMRequest()` when a rewrite should apply only to the current provider call and leave memory untouched.
|
|
271
|
+
|
|
272
|
+
Mastra includes several controls for common sources of context bloat:
|
|
273
|
+
|
|
274
|
+
- [`toModelOutput`](https://mastra.ai/docs/agents/tools): Replace a verbose tool result with a smaller model-facing representation.
|
|
275
|
+
- [`ToolCallFilter`](https://mastra.ai/reference/processors/tool-call-filter): Remove old tool calls and results from model input while retaining them in memory and the UI.
|
|
276
|
+
- [`ToolSearchProcessor`](https://mastra.ai/reference/processors/tool-search-processor): Replace a large tool catalog with search and load tools.
|
|
277
|
+
- [`TokenLimiter`](https://mastra.ai/reference/processors/token-limiter-processor): Prune non-system messages until the prompt fits a token budget.
|
|
278
|
+
|
|
279
|
+
Start with [`toModelOutput`](https://mastra.ai/docs/agents/tools) for verbose tool results and `ToolCallFilter` for old tool interactions. Add `TokenLimiter` as a final budget guard rather than relying on the model's maximum context window.
|
|
280
|
+
|
|
281
|
+
### Subagents
|
|
282
|
+
|
|
283
|
+
A common source of context bloat is passing too much information to and from [subagents](https://mastra.ai/docs/subagents). A subagent gets a separate model context for its delegated task, but the boundary still needs deliberate controls.
|
|
284
|
+
|
|
285
|
+
By default, Mastra forwards the parent's conversation to the subagent. Use `messageFilter` to pass only the messages that specialist needs:
|
|
286
|
+
|
|
287
|
+
```typescript
|
|
288
|
+
await supervisor.generate('Investigate the failed deployment.', {
|
|
289
|
+
delegation: {
|
|
290
|
+
messageFilter: ({ messages }) => messages.slice(-10),
|
|
291
|
+
},
|
|
292
|
+
})
|
|
293
|
+
```
|
|
294
|
+
|
|
295
|
+
In the other direction, Mastra returns the subagent's text to the parent model by default while keeping nested tool calls and metadata available to application code. Leave `includeSubAgentToolResultsInModelContext` disabled unless the parent must reason over those details. Use `onDelegationStart` to refine the child prompt and `onDelegationComplete` to reduce or replace the text returned to the parent.
|
|
296
|
+
|
|
297
|
+
See [Subagents](https://mastra.ai/docs/subagents) for delegation hooks, memory isolation, iteration monitoring, and result controls.
|
|
@@ -197,6 +197,7 @@ Each provider page includes installation instructions, configuration parameters,
|
|
|
197
197
|
- [Convex](https://mastra.ai/integrations/databases/convex)
|
|
198
198
|
- [DuckDB](https://mastra.ai/integrations/databases/duckdb)
|
|
199
199
|
- [DynamoDB](https://mastra.ai/integrations/databases/dynamodb)
|
|
200
|
+
- [Elasticsearch](https://mastra.ai/integrations/databases/elasticsearch)
|
|
200
201
|
- [Google Cloud Spanner](https://mastra.ai/integrations/databases/spanner)
|
|
201
202
|
- [LanceDB](https://mastra.ai/integrations/databases/lancedb)
|
|
202
203
|
- [libSQL](https://mastra.ai/integrations/databases/libsql)
|
|
@@ -207,6 +208,7 @@ Each provider page includes installation instructions, configuration parameters,
|
|
|
207
208
|
- [OracleDB](https://mastra.ai/integrations/databases/oracledb)
|
|
208
209
|
- [PostgreSQL](https://mastra.ai/integrations/databases/postgresql)
|
|
209
210
|
- [Redis](https://mastra.ai/integrations/databases/redis)
|
|
211
|
+
- [Valkey](https://mastra.ai/integrations/databases/valkey)
|
|
210
212
|
- [Upstash](https://mastra.ai/integrations/databases/upstash)
|
|
211
213
|
|
|
212
214
|
## Next steps
|
|
@@ -0,0 +1,156 @@
|
|
|
1
|
+
> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
|
|
2
|
+
|
|
3
|
+
# Elasticsearch
|
|
4
|
+
|
|
5
|
+
The Elasticsearch storage implementation provides agent memory, workflow snapshot, and score storage on top of an Elasticsearch cluster using the official [`@elastic/elasticsearch`](https://github.com/elastic/elasticsearch-js) client. It shares the same connection configuration as `ElasticSearchVector`, so a single cluster (and even a single client instance) can serve both agent memory and semantic recall.
|
|
6
|
+
|
|
7
|
+
`ElasticSearchStore` currently implements the `memory`, `workflows`, and `scores` storage domains.
|
|
8
|
+
|
|
9
|
+
## Installation
|
|
10
|
+
|
|
11
|
+
```bash
|
|
12
|
+
npm install @mastra/elasticsearch
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
## Usage
|
|
16
|
+
|
|
17
|
+
### Using a URL
|
|
18
|
+
|
|
19
|
+
```typescript
|
|
20
|
+
import { ElasticSearchStore } from '@mastra/elasticsearch'
|
|
21
|
+
|
|
22
|
+
const storage = new ElasticSearchStore({
|
|
23
|
+
id: 'elasticsearch-storage',
|
|
24
|
+
url: 'http://localhost:9200',
|
|
25
|
+
})
|
|
26
|
+
|
|
27
|
+
await storage.init()
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
### Using authentication
|
|
31
|
+
|
|
32
|
+
```typescript
|
|
33
|
+
import { ElasticSearchStore } from '@mastra/elasticsearch'
|
|
34
|
+
|
|
35
|
+
const storage = new ElasticSearchStore({
|
|
36
|
+
id: 'elasticsearch-storage',
|
|
37
|
+
url: 'https://my-cluster.example.com:9200',
|
|
38
|
+
auth: { apiKey: process.env.ELASTICSEARCH_API_KEY! },
|
|
39
|
+
})
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
`auth` also accepts `{ username, password }` or `{ bearer }`.
|
|
43
|
+
|
|
44
|
+
### Using a pre-configured client
|
|
45
|
+
|
|
46
|
+
For advanced configurations (cloud IDs, TLS options, custom transport), pass a pre-configured client. The same client can be shared with `ElasticSearchVector`:
|
|
47
|
+
|
|
48
|
+
```typescript
|
|
49
|
+
import { Client } from '@elastic/elasticsearch'
|
|
50
|
+
import { ElasticSearchStore, ElasticSearchVector } from '@mastra/elasticsearch'
|
|
51
|
+
|
|
52
|
+
const client = new Client({
|
|
53
|
+
node: 'https://my-cluster.example.com:9200',
|
|
54
|
+
auth: { apiKey: process.env.ELASTICSEARCH_API_KEY! },
|
|
55
|
+
})
|
|
56
|
+
|
|
57
|
+
const storage = new ElasticSearchStore({ id: 'elasticsearch-storage', client })
|
|
58
|
+
const vector = new ElasticSearchVector({ id: 'elasticsearch-vector', client })
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
When you provide your own client, `storage.close()` does not close it — you remain responsible for its lifecycle.
|
|
62
|
+
|
|
63
|
+
## Parameters
|
|
64
|
+
|
|
65
|
+
**id** (`string`): Unique identifier for the storage instance
|
|
66
|
+
|
|
67
|
+
**url** (`string`): Elasticsearch node URL (e.g., http\://localhost:9200)
|
|
68
|
+
|
|
69
|
+
**auth** (`ElasticSearchAuth`): Authentication options: { apiKey }, { username, password }, or { bearer }
|
|
70
|
+
|
|
71
|
+
**client** (`Client`): Pre-configured Elasticsearch client (from @elastic/elasticsearch) for advanced setups
|
|
72
|
+
|
|
73
|
+
**disableInit** (`boolean`): Disable automatic initialization; call storage.init() explicitly before use
|
|
74
|
+
|
|
75
|
+
> **Note:** You must provide either `url` or `client`. These options are mutually exclusive.
|
|
76
|
+
|
|
77
|
+
## Additional Notes
|
|
78
|
+
|
|
79
|
+
### Index Structure
|
|
80
|
+
|
|
81
|
+
Each Mastra storage table maps to one Elasticsearch index of the same name (for example `mastra_threads`, `mastra_messages`, `mastra_workflow_snapshot`, `mastra_scorers`). Records are stored as opaque JSON documents with a keyword `key` field, so no index mappings need to be managed manually — indexes are created on first use.
|
|
82
|
+
|
|
83
|
+
### Consistency
|
|
84
|
+
|
|
85
|
+
Elasticsearch search is near-real-time. All writes are performed with an immediate refresh so subsequent reads and searches observe them, and point reads use real-time get-by-ID lookups.
|
|
86
|
+
|
|
87
|
+
### Closing Connections
|
|
88
|
+
|
|
89
|
+
When shutting down your application, close the connection:
|
|
90
|
+
|
|
91
|
+
```typescript
|
|
92
|
+
await storage.close()
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
This only closes clients created by `ElasticSearchStore` from a `url`; user-provided clients are left open.
|
|
96
|
+
|
|
97
|
+
## Usage Example
|
|
98
|
+
|
|
99
|
+
### Adding memory to an agent
|
|
100
|
+
|
|
101
|
+
```typescript
|
|
102
|
+
import { Memory } from '@mastra/memory'
|
|
103
|
+
import { Agent } from '@mastra/core/agent'
|
|
104
|
+
import { ElasticSearchStore } from '@mastra/elasticsearch'
|
|
105
|
+
|
|
106
|
+
export const elasticsearchAgent = new Agent({
|
|
107
|
+
id: 'elasticsearch-agent',
|
|
108
|
+
name: 'Elasticsearch Agent',
|
|
109
|
+
instructions:
|
|
110
|
+
'You are an AI agent with the ability to automatically recall memories from previous interactions.',
|
|
111
|
+
model: 'openai/gpt-5.6-sol',
|
|
112
|
+
memory: new Memory({
|
|
113
|
+
storage: new ElasticSearchStore({
|
|
114
|
+
id: 'elasticsearch-agent-storage',
|
|
115
|
+
url: process.env.ELASTICSEARCH_URL!,
|
|
116
|
+
auth: { apiKey: process.env.ELASTICSEARCH_API_KEY! },
|
|
117
|
+
}),
|
|
118
|
+
options: {
|
|
119
|
+
lastMessages: 10,
|
|
120
|
+
},
|
|
121
|
+
}),
|
|
122
|
+
})
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
### Using with Mastra instance
|
|
126
|
+
|
|
127
|
+
```typescript
|
|
128
|
+
import { Mastra } from '@mastra/core'
|
|
129
|
+
import { ElasticSearchStore } from '@mastra/elasticsearch'
|
|
130
|
+
|
|
131
|
+
const storage = new ElasticSearchStore({
|
|
132
|
+
id: 'mastra-storage',
|
|
133
|
+
url: 'http://localhost:9200',
|
|
134
|
+
})
|
|
135
|
+
|
|
136
|
+
const mastra = new Mastra({
|
|
137
|
+
storage, // init() called automatically
|
|
138
|
+
})
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
If using storage directly without Mastra, call `init()` explicitly:
|
|
142
|
+
|
|
143
|
+
```typescript
|
|
144
|
+
import { ElasticSearchStore } from '@mastra/elasticsearch'
|
|
145
|
+
|
|
146
|
+
const storage = new ElasticSearchStore({
|
|
147
|
+
id: 'elasticsearch-storage',
|
|
148
|
+
url: 'http://localhost:9200',
|
|
149
|
+
})
|
|
150
|
+
|
|
151
|
+
await storage.init()
|
|
152
|
+
|
|
153
|
+
// Access domain-specific stores via getStore()
|
|
154
|
+
const memoryStore = await storage.getStore('memory')
|
|
155
|
+
const thread = await memoryStore?.getThreadById({ threadId: '...' })
|
|
156
|
+
```
|
|
@@ -89,12 +89,28 @@ storage: new LibSQLStore({
|
|
|
89
89
|
|
|
90
90
|
> **Warning:** In-memory storage resets when the process changes. Only suitable for development.
|
|
91
91
|
|
|
92
|
+
Embedded replica synced with a remote primary (for example Turso):
|
|
93
|
+
|
|
94
|
+
```typescript
|
|
95
|
+
storage: new LibSQLStore({
|
|
96
|
+
id: 'libsql-storage',
|
|
97
|
+
url: 'file:./replica.db',
|
|
98
|
+
syncUrl: 'libsql://your-db-name.aws-ap-northeast-1.turso.io',
|
|
99
|
+
authToken: process.env.TURSO_AUTH_TOKEN,
|
|
100
|
+
syncInterval: 60,
|
|
101
|
+
})
|
|
102
|
+
```
|
|
103
|
+
|
|
92
104
|
## Options
|
|
93
105
|
|
|
94
106
|
**url** (`string`): Database URL. Use :memory: for in-memory database, file:filename.db for a file database, or a libSQL connection string (e.g., libsql://your-database.turso.io) for remote storage.
|
|
95
107
|
|
|
96
108
|
**authToken** (`string`): Authentication token for remote libSQL databases.
|
|
97
109
|
|
|
110
|
+
**syncUrl** (`string`): URL of the remote primary database to sync from, enabling an embedded replica. Requires a local file: url.
|
|
111
|
+
|
|
112
|
+
**syncInterval** (`number`): Interval in seconds for automatic sync with the remote primary. Only applies when syncUrl is set.
|
|
113
|
+
|
|
98
114
|
## Managed tables
|
|
99
115
|
|
|
100
116
|
The storage implementation creates the core storage tables automatically, including `mastra_notifications` for notification inbox records and delivery metadata.
|
|
@@ -32,7 +32,7 @@ bun add @mastra/mongodb@latest
|
|
|
32
32
|
|
|
33
33
|
## Usage
|
|
34
34
|
|
|
35
|
-
Ensure you have a [MongoDB Atlas Local (via Docker)](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-deploy-docker/) or [MongoDB Atlas Cloud](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-getting-started/) instance with
|
|
35
|
+
Ensure you have a [MongoDB Atlas Local (via Docker)](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-deploy-docker/) or [MongoDB Atlas Cloud](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-getting-started/) instance with MongoDB Search enabled. MongoDB 7.0+ is recommended.
|
|
36
36
|
|
|
37
37
|
```typescript
|
|
38
38
|
import { MongoDBStore } from '@mastra/mongodb'
|