@mastra/libsql 0.0.0-error-handler-fix-20251020202607 → 0.0.0-esbuild-bundle-worker-20260807182016

package/dist/docs/references/reference-storage-libsql.md

@@ -0,0 +1,143 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# libSQL storage
+
+[libSQL](https://docs.turso.tech/libsql) is an open-source, SQLite-compatible database that supports both local and remote deployments. It can be used to store message history, workflow snapshots, traces, and eval scores.
+
+For vectors like semantic recall or traditional RAG, use [libSQL Vector](https://mastra.ai/reference/vectors/libsql) which covers embeddings and vector search.
+
+## Installation
+
+Storage providers must be installed as separate packages:
+
+**npm**:
+
+```bash
+npm install @mastra/libsql@latest
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/libsql@latest
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/libsql@latest
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/libsql@latest
+```
+
+## Usage
+
+```typescript
+import { LibSQLStore } from '@mastra/libsql'
+import { Mastra } from '@mastra/core'
+
+const mastra = new Mastra({
+  storage: new LibSQLStore({
+    id: 'libsql-storage',
+    url: 'file:./storage.db',
+  }),
+})
+```
+
+Agent-level file storage:
+
+```typescript
+import { Memory } from '@mastra/memory'
+import { Agent } from '@mastra/core/agent'
+import { LibSQLStore } from '@mastra/libsql'
+
+export const agent = new Agent({
+  id: 'example-agent',
+  memory: new Memory({
+    storage: new LibSQLStore({
+      id: 'libsql-storage',
+      url: 'file:./agent.db',
+    }),
+  }),
+})
+```
+
+> **Warning:** File storage doesn't work with serverless platforms that have ephemeral file systems. For serverless deployments, use [Turso](https://turso.tech) or a different database engine.
+
+Production with remote database:
+
+```typescript
+storage: new LibSQLStore({
+  id: 'libsql-storage',
+  url: 'libsql://your-db-name.aws-ap-northeast-1.turso.io',
+  authToken: process.env.TURSO_AUTH_TOKEN,
+})
+```
+
+For local development and testing, you can store data in memory:
+
+```typescript
+storage: new LibSQLStore({
+  id: 'libsql-storage',
+  url: ':memory:',
+})
+```
+
+> **Warning:** In-memory storage resets when the process changes. Only suitable for development.
+
+## Options
+
+**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.
+
+**authToken** (`string`): Authentication token for remote libSQL databases.
+
+## Managed tables
+
+The storage implementation creates the core storage tables automatically, including `mastra_notifications` for notification inbox records and delivery metadata.
+
+`LibSQLStore` exposes notification storage through `getStore('notifications')`.
+
+## Initialization
+
+When you pass storage to the Mastra class, `init()` is called automatically to create the [core schema](https://mastra.ai/reference/storage/overview):
+
+```typescript
+import { Mastra } from '@mastra/core'
+import { LibSQLStore } from '@mastra/libsql'
+
+const storage = new LibSQLStore({
+  id: 'libsql-storage',
+  url: 'file:./storage.db',
+})
+
+const mastra = new Mastra({
+  storage, // init() called automatically
+})
+```
+
+If using storage directly without Mastra, call `init()` explicitly:
+
+```typescript
+import { LibSQLStore } from '@mastra/libsql'
+
+const storage = new LibSQLStore({
+  id: 'libsql-storage',
+  url: 'file:./storage.db',
+})
+
+await storage.init()
+
+// Access domain-specific stores via getStore()
+const memoryStore = await storage.getStore('memory')
+const thread = await memoryStore?.getThreadById({ threadId: '...' })
+```
+
+## Observability
+
+libSQL supports observability and is ideal for local development. Use the `realtime` [tracing strategy](https://mastra.ai/docs/observability/integrations/exporters/mastra-storage) for immediate visibility while debugging.
+
+For production environments with higher trace volumes, consider using [PostgreSQL](https://mastra.ai/reference/storage/postgresql) or [ClickHouse via composite storage](https://mastra.ai/reference/storage/composite).

package/dist/docs/references/reference-storage-retention.md

@@ -0,0 +1,248 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# Storage retention
+
+Storage grows without bound by default. Retention is an opt-in, age-based cleanup system: you declare per-table `maxAge` policies in the `retention` config, then call `storage.prune()` to delete rows older than their configured age. Anything you don't configure is kept forever, so there is no behavior change until you opt in.
+
+`prune()` deletes rows. It caps growth and is safe to run against large tables (batched, bounded, resumable, cancellable). It never reclaims disk: on SQLite/libSQL the freed pages are reused by future writes so the file stops growing, but handing disk back to the OS (for example a `VACUUM`) is left to the underlying database and the operator to manage.
+
+Retention covers **growth tables** only: tables that accumulate rows unbounded as a side effect of normal operation (conversation history, telemetry, job and run records, schedule fire history, event feeds). User-authored artifacts and config (agents, skills, workspaces, prompt blocks, datasets, schedule definitions, channel installations, and so on) grow with user intent and are edited or deleted explicitly, so they're not valid retention keys.
+
+The reference implementations are [libSQL](https://mastra.ai/reference/storage/libsql), [PostgreSQL](https://mastra.ai/reference/storage/postgresql), and [MongoDB](https://mastra.ai/reference/storage/mongodb). Other adapters keep rows forever until they implement retention.
+
+## Usage example
+
+Declare `retention` on any `MastraCompositeStore` (or an adapter that extends it, such as `LibSQLStore`), then call `prune()` from your own scheduler.
+
+```typescript
+import { LibSQLStore } from '@mastra/libsql'
+
+const storage = new LibSQLStore({
+  id: 'mastra-storage',
+  url: 'file:./mastra.db',
+  retention: {
+    memory: {
+      messages: { maxAge: '30d' },
+      threads: { maxAge: '90d', batchSize: 500 },
+    },
+    observability: {
+      spans: { maxAge: '7d' },
+    },
+  },
+})
+
+// Wire this to your own cron/scheduler: Mastra never runs it for you.
+const results = await storage.prune()
+```
+
+`retention` is fully typed. Keys must be real domain keys, and each table key must be one the domain declares as retention-eligible. Passing the object straight into a store config type-checks it; if you build it standalone, use `satisfies RetentionConfig` so unknown domains or tables are compile errors:
+
+```typescript
+import type { RetentionConfig } from '@mastra/core/storage'
+
+const retention = {
+  memory: {
+    messages: { maxAge: '30d' }, // ok
+    bogus: { maxAge: '30d' }, // Error: not a memory retention table
+  },
+  bogusDomain: {}, // Error: not a storage domain
+} satisfies RetentionConfig
+```
+
+## Retention config
+
+Set the `retention` field on the store config.
+
+**retention** (`RetentionConfig`): Per-domain, per-table age policies. Unset domains and tables are kept forever.
+
+**retention.\[domain]** (`Record<TableKey, TableRetentionPolicy>`): A real storage domain key (e.g. memory, observability). Maps that domain's retention-eligible table keys to their policies.
+
+### TableRetentionPolicy
+
+**maxAge** (`Duration`): Maximum age to keep rows. Rows whose anchor timestamp is strictly older than Date.now() - maxAge are eligible for deletion. A number is milliseconds, or a string with a unit suffix: ms, s, m, h, d, w (e.g. '30d', '12h').
+
+**batchSize** (`number`): Rows deleted per batch. Each batch is its own transaction, which bounds lock duration and WAL growth on large tables. (Default: `1000`)
+
+### Retention-eligible tables
+
+Each domain declares which of its tables can be age-pruned and which timestamp column anchors the comparison. The anchor is chosen so `maxAge` means what you'd expect for that data. Append-only logs use creation time, and live state uses last activity. Jobs and runs use completion time, so in-flight work is never pruned.
+
+| Domain            | Table key          | Anchor column    | `maxAge` measures                                                |
+| ----------------- | ------------------ | ---------------- | ---------------------------------------------------------------- |
+| `memory`          | `threads`          | `createdAt`      | Thread age                                                       |
+| `memory`          | `messages`         | `createdAt`      | Message age                                                      |
+| `memory`          | `resources`        | `createdAt`      | Resource age                                                     |
+| `threadState`     | `threadState`      | `updatedAt`      | Inactivity: state for still-active threads survives              |
+| `observability`   | `spans`            | `startedAt`      | Span age                                                         |
+| `observability`   | `metrics`          | `timestamp`      | Metric event age (v-next only)                                   |
+| `observability`   | `logs`             | `timestamp`      | Log event age (v-next only)                                      |
+| `observability`   | `scores`           | `timestamp`      | Score event age (v-next only)                                    |
+| `observability`   | `feedback`         | `timestamp`      | Feedback event age (v-next only)                                 |
+| `scores`          | `scorers`          | `createdAt`      | Score record age                                                 |
+| `workflows`       | `workflowSnapshot` | `updatedAt`      | Inactivity, suspended or long-running workflows survive          |
+| `backgroundTasks` | `backgroundTasks`  | `completedAt`    | Time since completion, in-flight tasks (`NULL`) are never pruned |
+| `experiments`     | `experiments`      | `completedAt`    | Time since completion, running experiments are never pruned      |
+| `notifications`   | `notifications`    | `createdAt`      | Notification age                                                 |
+| `harness`         | `sessions`         | `createdAt`      | Session record age                                               |
+| `schedules`       | `triggers`         | `actual_fire_at` | Fire-history age (epoch-ms column)                               |
+
+> **Note:**
+>
+> - The memory `observational_memory` table has no timestamp anchor, so it can't be age-pruned and isn't a valid retention key.
+> - Experiments prune as whole units: an aged experiment's result rows are deleted together with it (results cascade with their parent), so a run is never left partially deleted. Retention doesn't have a separate `results` key.
+> - For `schedules`, the growth table is the fire history (`schedule_triggers`, one row per fire): schedule definitions are config and aren't pruned.
+> - On PostgreSQL, timestamp anchors use the timezone-aware mirror columns (for example `createdAtZ`, `completedAtZ`).
+> - LibSQL supports all domains above; PostgreSQL and MongoDB support all except `threadState` and `harness`, which they don't implement.
+> - The v-next PostgreSQL observability domain stores signal events in day-partitioned tables (`spans`, `metrics`, `logs`, `scores`, `feedback`). For it, `prune()` drops whole day partitions (or TimescaleDB chunks) that are entirely older than the cutoff instead of deleting rows: effective level of detail is one day, and a partition is only dropped once its entire day is past `maxAge`. `PruneResult.deleted` reports the number of rows in the dropped partitions.
+
+## Methods
+
+### Retention
+
+#### `prune(options?)`
+
+Deletes rows older than their configured `maxAge` across every domain that has a policy in `retention`. Returns one `PruneResult` per table touched. With no `retention` configured it's a no-op returning `[]`.
+
+`prune()` is designed to be safe on tables with millions of rows. It deletes in bounded, batched chunks (each batch is its own transaction) so it never takes a long lock or bloats the transaction log. It never runs a `VACUUM`.
+
+Pass `options.retention` to replace the configured policies for that call only: for example to skip a domain (keep chat history) or prune more aggressively than the standing config. The store's configured `retention` is unchanged.
+
+Anchor-column indexes are created lazily on the first `prune()` call for each table with a policy (never at `init()`) so deployments that don't configure retention pay no extra index write or disk overhead. The first prune of an existing large table pays a one-time index build. Subsequent prunes reuse the index.
+
+```typescript
+const results = await storage.prune({
+  maxRows: 50_000, // cap work this call
+  pauseMs: 50, // breathe between batches
+})
+
+for (const r of results) {
+  console.log(`${r.domain}.${r.table}: deleted ${r.deleted}, done=${r.done}`)
+}
+
+// One-off pass with different policies (configured retention untouched):
+await storage.prune({
+  retention: {
+    observability: { spans: { maxAge: '1d' } },
+  },
+})
+```
+
+Returns: `Promise<PruneResult[]>`
+
+##### PruneOptions
+
+**maxBatches** (`number`): Maximum delete batches per table per call. When reached, that table's result is returned with done: false.
+
+**maxRows** (`number`): Maximum rows deleted per table per call. When reached, that table's result is returned with done: false.
+
+**pauseMs** (`number`): Delay in milliseconds between batches, to avoid starving live traffic.
+
+**signal** (`AbortSignal`): Cooperative cancellation. The batch loop checks it between batches and stops cleanly, returning partial results with done: false.
+
+**retention** (`RetentionConfig`): Replaces the store's configured retention policies for this call only — e.g. to skip a domain or prune more aggressively. The configured retention is unchanged.
+
+##### PruneResult
+
+Each result describes one table's progress:
+
+```typescript
+interface PruneResult {
+  domain: string // e.g. 'memory'
+  table: string // physical table name, e.g. 'mastra_messages'
+  deleted: number // rows deleted during this call
+  done: boolean // false => eligible rows remain; call prune() again
+}
+```
+
+## Running prune on a schedule
+
+`prune()` has no built-in scheduler: you decide when it runs. Because it's bounded, a single call may not delete everything. When any result has `done: false`, eligible rows remain and you call again on the next tick. This keeps each invocation short and lets a large backlog drain over several runs.
+
+```typescript
+// Runs on your own cron (node-cron, a workflow schedule, an external job, etc.).
+async function retentionTick() {
+  const results = await storage.prune({ maxRows: 100_000, pauseMs: 25 })
+  const incomplete = results.filter(r => !r.done)
+  if (incomplete.length) {
+    // Rows remain; the next scheduled tick will continue where this one stopped.
+    console.log(
+      'retention still draining:',
+      incomplete.map(r => `${r.domain}.${r.table}`),
+    )
+  }
+}
+```
+
+You can also cancel a long-running prune with an `AbortSignal`: the loop stops between batches and returns partial results with `done: false`, so the next run resumes cleanly.
+
+## MongoDB TTL indexes (alternative to prune)
+
+MongoDB offers native [TTL (Time-To-Live) indexes](https://www.mongodb.com/docs/manual/core/index-ttl/) that automatically delete expired documents without requiring manual `prune()` calls. This is a database-level feature that runs as a background thread.
+
+> **When to use TTL vs prune():** **Use MongoDB TTL indexes when:**
+>
+> - You want automated, zero-maintenance deletion
+> - Your retention periods are fixed (e.g., "always 30 days")
+> - You prefer database-native solutions
+>
+> **Use `prune()` when:**
+>
+> - You need fine-grained control over deletion timing
+> - You want to cap deletion rate during business hours
+> - You need resumable, cancellable cleanup operations
+> - You're using composite storage with multiple databases
+>
+> Both approaches are valid. TTL is simpler. `prune()` gives more control.
+
+### Setting up TTL indexes on MongoDB
+
+TTL indexes work on date fields. MongoDB checks the index every 60 seconds and deletes documents where the date field + TTL duration < current time.
+
+```typescript
+import { MongoDBStore } from '@mastra/mongodb'
+
+const storage = new MongoDBStore({
+  id: 'mongodb-storage',
+  uri: process.env.MONGODB_URI!,
+  dbName: process.env.MONGODB_DB_NAME!,
+  indexes: [
+    // Messages expire after 30 days
+    {
+      collection: 'mastra_messages',
+      keys: { createdAt: 1 },
+      options: { expireAfterSeconds: 30 * 24 * 60 * 60 }, // 30 days
+    },
+    // Threads expire after 90 days
+    {
+      collection: 'mastra_threads',
+      keys: { createdAt: 1 },
+      options: { expireAfterSeconds: 90 * 24 * 60 * 60 }, // 90 days
+    },
+    // Spans expire after 7 days
+    {
+      collection: 'mastra_ai_spans',
+      keys: { startedAt: 1 },
+      options: { expireAfterSeconds: 7 * 24 * 60 * 60 }, // 7 days
+    },
+  ],
+})
+```
+
+> **Tip:** TTL indexes delete documents shortly after they expire (background thread runs every \~60 seconds), but the exact timing isn't guaranteed. For precise, immediate cleanup, use `prune()` instead.
+
+## Reclaiming disk
+
+`prune()` deletes rows but doesn't shrink the database file. On SQLite/libSQL the freed pages go on a freelist and are reused by future writes, so the file stops growing: for most users this alone solves the unbounded-growth problem.
+
+Handing that free space back to the OS is a separate concern that Mastra doesn't manage. If you specifically need to shrink the file, run the underlying database's compaction (for example `VACUUM` on self-hosted libSQL) yourself in a maintenance window. A full `VACUUM` locks the file and needs roughly twice the file size in free disk. On PostgreSQL, autovacuum reclaims dead tuples for reuse automatically; a manual `VACUUM FULL` is only needed if you must return disk to the OS.
+
+For MongoDB, deleted documents are reused by future insertions. To reclaim disk space, run [`db.runCommand({ compact: "collection_name" })`](https://www.mongodb.com/docs/manual/reference/command/compact/) during a maintenance window.
+
+> **LibSQL and Turso:** [Turso Cloud](https://mastra.ai/reference/storage/libsql) manages storage compaction for you, so there's nothing to reclaim manually. This applies only to self-hosted libSQL files.
+
+## Related
+
+- [libSQL storage](https://mastra.ai/reference/storage/libsql)
+- [PostgreSQL storage](https://mastra.ai/reference/storage/postgresql)
+- [Composite storage](https://mastra.ai/reference/storage/composite)
+- [Storage overview](https://mastra.ai/reference/storage/overview)

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

@@ -0,0 +1,307 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# libSQL vector store
+
+The libSQL storage implementation provides a SQLite-compatible vector search [libSQL](https://github.com/tursodatabase/libsql), a fork of SQLite with vector extensions, and [Turso](https://turso.tech/) with vector extensions, offering a lightweight and efficient vector database solution. It's part of the `@mastra/libsql` package and offers efficient vector similarity search with metadata filtering.
+
+## Installation
+
+**npm**:
+
+```bash
+npm install @mastra/libsql@latest
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/libsql@latest
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/libsql@latest
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/libsql@latest
+```
+
+## Usage
+
+```typescript
+import { LibSQLVector } from "@mastra/libsql";
+
+// Create a new vector store instance
+const store = new LibSQLVector({
+  id: 'libsql-vector',
+  url: process.env.DATABASE_URL,
+  // Optional: for Turso cloud databases
+  authToken: process.env.DATABASE_AUTH_TOKEN,
+});
+
+// Create an index
+await store.createIndex({
+  indexName: "myCollection",
+  dimension: 1536,
+});
+
+// Add vectors with metadata
+const vectors = [[0.1, 0.2, ...], [0.3, 0.4, ...]];
+const metadata = [
+  { text: "first document", category: "A" },
+  { text: "second document", category: "B" }
+];
+await store.upsert({
+  indexName: "myCollection",
+  vectors,
+  metadata,
+});
+
+// Query similar vectors
+const queryVector = [0.1, 0.2, ...];
+const results = await store.query({
+  indexName: "myCollection",
+  queryVector,
+  topK: 10, // top K results
+  filter: { category: "A" } // optional metadata filter
+});
+```
+
+## Constructor options
+
+**url** (`string`): libSQL database URL. Use ':memory:' for in-memory database, 'file:dbname.db' for local file, or a libSQL-compatible connection string like 'libsql://your-database.turso.io'.
+
+**authToken** (`string`): Authentication token for Turso cloud databases
+
+**syncUrl** (`string`): URL for database replication (Turso specific)
+
+**syncInterval** (`number`): Interval in milliseconds for database sync (Turso specific)
+
+## Methods
+
+### `createIndex()`
+
+Creates a new vector collection. The index name must start with a letter or underscore and can only contain letters, numbers, and underscore characters. The dimension must be a positive integer.
+
+**indexName** (`string`): Name of the index to create
+
+**dimension** (`number`): Vector dimension size (must match your embedding model)
+
+**metric** (`'cosine' | 'euclidean' | 'dotproduct'`): Distance metric for similarity search. Note: Currently only cosine similarity is supported by libSQL. (Default: `cosine`)
+
+### `upsert()`
+
+Adds or updates vectors and their metadata in the index. Uses a transaction to ensure all vectors are inserted atomically - if any insert fails, the entire operation is rolled back.
+
+**indexName** (`string`): Name of the index to insert into
+
+**vectors** (`number[][]`): Array of embedding vectors
+
+**metadata** (`Record<string, any>[]`): Metadata for each vector
+
+**ids** (`string[]`): Optional vector IDs (auto-generated if not provided)
+
+### `query()`
+
+Searches for similar vectors with optional metadata filtering.
+
+**indexName** (`string`): Name of the index to search in
+
+**queryVector** (`number[]`): Query vector to find similar vectors for
+
+**topK** (`number`): Number of results to return (Default: `10`)
+
+**filter** (`Filter`): Metadata filters
+
+**includeVector** (`boolean`): Whether to include vector data in results (Default: `false`)
+
+**minScore** (`number`): Minimum similarity score threshold (Default: `0`)
+
+### `describeIndex()`
+
+Gets information about an index.
+
+**indexName** (`string`): Name of the index to describe
+
+Returns:
+
+```typescript
+interface IndexStats {
+  dimension: number
+  count: number
+  metric: 'cosine' | 'euclidean' | 'dotproduct'
+}
+```
+
+### `deleteIndex()`
+
+Deletes an index and all its data.
+
+**indexName** (`string`): Name of the index to delete
+
+### `listIndexes()`
+
+Lists all vector indexes in the database.
+
+Returns: `Promise<string[]>`
+
+### `truncateIndex()`
+
+Removes all vectors from an index while keeping the index structure.
+
+**indexName** (`string`): Name of the index to truncate
+
+### `updateVector()`
+
+Update a single vector by ID or by metadata filter. Either `id` or `filter` must be provided, but not both.
+
+**indexName** (`string`): Name of the index containing the vector
+
+**id** (`string`): ID of the vector entry to update (mutually exclusive with filter)
+
+**filter** (`Record<string, any>`): Metadata filter to identify vector(s) to update (mutually exclusive with id)
+
+**update** (`object`): Update data containing vector and/or metadata
+
+**update.vector** (`number[]`): New vector data to update
+
+**update.metadata** (`Record<string, any>`): New metadata to update
+
+### `deleteVector()`
+
+Deletes a specific vector entry from an index by its ID.
+
+**indexName** (`string`): Name of the index containing the vector
+
+**id** (`string`): ID of the vector entry to delete
+
+### `deleteVectors()`
+
+Delete multiple vectors by IDs or by metadata filter. Either `ids` or `filter` must be provided, but not both.
+
+**indexName** (`string`): Name of the index containing the vectors to delete
+
+**ids** (`string[]`): Array of vector IDs to delete (mutually exclusive with filter)
+
+**filter** (`Record<string, any>`): Metadata filter to identify vectors to delete (mutually exclusive with ids)
+
+## Response types
+
+Query results are returned in this format:
+
+```typescript
+interface QueryResult {
+  id: string
+  score: number
+  metadata: Record<string, any>
+  vector?: number[] // Only included if includeVector is true
+}
+```
+
+## Error handling
+
+The store throws specific errors for different failure cases:
+
+```typescript
+try {
+  await store.query({
+    indexName: 'my-collection',
+    queryVector: queryVector,
+  })
+} catch (error) {
+  // Handle specific error cases
+  if (error.message.includes('Invalid index name format')) {
+    console.error(
+      'Index name must start with a letter/underscore and contain only alphanumeric characters',
+    )
+  } else if (error.message.includes('Table not found')) {
+    console.error('The specified index does not exist')
+  } else {
+    console.error('Vector store error:', error.message)
+  }
+}
+```
+
+Common error cases include:
+
+- Invalid index name format
+- Invalid vector dimensions
+- Table/index not found
+- Database connection issues
+- Transaction failures during upsert
+
+## Usage example
+
+### Local embeddings with fastembed
+
+Embeddings are numeric vectors used by memory's `semanticRecall` to retrieve related messages by meaning (not keywords). This setup uses `@mastra/fastembed` to generate vector embeddings.
+
+Install `fastembed` to get started:
+
+**npm**:
+
+```bash
+npm install @mastra/fastembed@latest
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/fastembed@latest
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/fastembed@latest
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/fastembed@latest
+```
+
+Add the following to your agent:
+
+```typescript
+import { Memory } from '@mastra/memory'
+import { Agent } from '@mastra/core/agent'
+import { LibSQLStore, LibSQLVector } from '@mastra/libsql'
+import { fastembed } from '@mastra/fastembed'
+
+export const libsqlAgent = new Agent({
+  id: 'libsql-agent',
+  name: 'libSQL Agent',
+  instructions:
+    'You are an AI agent with the ability to automatically recall memories from previous interactions.',
+  model: 'openai/gpt-5.6-sol',
+  memory: new Memory({
+    storage: new LibSQLStore({
+      id: 'libsql-agent-storage',
+      url: 'file:libsql-agent.db',
+    }),
+    vector: new LibSQLVector({
+      id: 'libsql-agent-vector',
+      url: 'file:libsql-agent.db',
+    }),
+    embedder: fastembed,
+    options: {
+      lastMessages: 10,
+      semanticRecall: {
+        topK: 3,
+        messageRange: 2,
+      },
+      generateTitle: true, // Explicitly enable automatic title generation
+    },
+  }),
+})
+```
+
+## Related
+
+- [Metadata Filters](https://mastra.ai/reference/rag/metadata-filters)