@mastra/libsql 1.20.0 → 1.20.1-alpha.0

package/CHANGELOG.md

@@ -1,5 +1,26 @@
 # @mastra/libsql
 
+## 1.20.1-alpha.0
+
+### Patch Changes
+
+- Added a `durable` option to stored agents so agents created through the Agents API can run with durable execution — no code deployment required. ([#21715](https://github.com/mastra-ai/mastra/pull/21715))
+
+  ```typescript
+  await mastraClient.createStoredAgent({
+    id: 'helper',
+    name: 'Helper',
+    instructions: 'You are a helpful assistant.',
+    model: { provider: 'openai', name: 'gpt-5' },
+    durable: true,
+  });
+  ```
+
+  Pass `true` for defaults, or `{ maxSteps, cleanupTimeoutMs }` to tune the durable loop. Cache and pubsub are inherited from the server's Mastra instance, so configure distributed backends there for durability across replicas. Automatic recovery is still configured in code via `recovery.durableAgents`.
+
+- Updated dependencies [[`6223446`](https://github.com/mastra-ai/mastra/commit/6223446ddce6166e96e0ba5e00d628b615dee8ca), [`583e235`](https://github.com/mastra-ai/mastra/commit/583e23519c13af16c1746f9c49722d011216611b), [`a77f8d4`](https://github.com/mastra-ai/mastra/commit/a77f8d4740d2178a74c41e4bf678b4fcd8fa0bb2), [`40d358e`](https://github.com/mastra-ai/mastra/commit/40d358e29d55543803e64b49241122f598ffabc7), [`e80cd7e`](https://github.com/mastra-ai/mastra/commit/e80cd7e7683e7d732e1cc6784bcac1d2640d2ce3), [`20504b2`](https://github.com/mastra-ai/mastra/commit/20504b2ecebd0e077acda3d457ab57480a98ed3e)]:
+  - @mastra/core@1.60.0-alpha.11
+
 ## 1.20.0
 
 ### Minor Changes

package/dist/docs/SKILL.md

@@ -3,7 +3,7 @@ name: mastra-libsql
 description: Documentation for @mastra/libsql. Use when working with @mastra/libsql APIs, configuration, or implementation.
 metadata:
   package: "@mastra/libsql"
-  version: "1.20.0"
+  version: "1.20.1-alpha.0"
 ---
 
 ## When to use
@@ -16,23 +16,19 @@ Read the individual reference documents for detailed explanations and code examp
 
 ### Docs
 
-- [Agent approval](references/docs-agents-agent-approval.md) - Learn how to require approvals and suspend tool execution, plus automatically resume suspended tools while keeping humans in control of agent workflows.
+- [Human-in-the-loop](references/docs-agents-human-in-the-loop.md) - Learn how to require approvals and suspend tool execution, plus automatically resume suspended tools while keeping humans in control of agent workflows.
 - [Agent networks](references/docs-agents-networks.md) - Coordinate multiple agents, workflows, and tools using agent networks for complex, non-deterministic task execution.
 - [Workers](references/docs-deployment-workers.md) - Separate background processing from the API layer by running workflow execution, cron schedules, and background tasks in dedicated worker processes.
-- [Editor](references/docs-editor-overview.md) - Let collaborators update an agent in Studio, test their changes, and publish without editing code.
 - [Memory processors](references/docs-memory-memory-processors.md) - Learn how to use memory processors in Mastra to filter, trim, and transform messages before they're sent to the language model to manage context window limits.
 - [Message history](references/docs-memory-message-history.md) - Learn how to configure message history in Mastra to store recent messages from the current conversation.
 - [Multi-user threads](references/docs-memory-multi-user-threads.md) - Share one Mastra thread between multiple users by carrying speaker identity in the message body.
-- [Memory overview](references/docs-memory-overview.md) - Learn how Mastra's memory system works with working memory, message history, semantic recall, and observational memory.
+- [Memory](references/docs-memory-overview.md) - Learn how Mastra's memory system works with working memory, message history, semantic recall, and observational memory.
 - [Semantic recall](references/docs-memory-semantic-recall.md) - Learn how to use semantic recall in Mastra to retrieve relevant messages from past conversations using vector search and embeddings.
 - [Working memory](references/docs-memory-working-memory.md) - Learn how to configure working memory in Mastra to store persistent user data, preferences.
-- [Storage overview](references/docs-storage-overview.md) - Configure storage for Mastra to persist runtime state across agents, workflows, observability, evals, schedules, and memory.
+- [Storage](references/docs-storage.md) - Configure storage for Mastra to persist runtime state across agents, workflows, observability, evals, schedules, and memory.
+- [Editor](references/docs-studio-editor.md) - Let collaborators update an agent in Studio, test their changes, and publish without editing code.
 - [Snapshots](references/docs-workflows-snapshots.md) - Learn how to save and resume workflow execution state with snapshots in Mastra
 
-### Guides
-
-- [AI SDK](references/guides-agent-frameworks-ai-sdk.md) - Use Mastra processors and memory with the Vercel AI SDK
-
 ### Integrations
 
 - [GitHub](references/integrations-channels-github.md) - Notify a Mastra agent when subscribed GitHub pull requests change.
@@ -41,6 +37,7 @@ Read the individual reference documents for detailed explanations and code examp
 
 ### Reference
 
+- [AI SDK overview](references/reference-ai-sdk-overview.md) - Use Mastra processors and memory with the Vercel AI SDK
 - [Reference: Mastra.getMemory()](references/reference-core-getMemory.md) - Documentation for the `Mastra.getMemory()` method in Mastra, which retrieves a registered memory instance by its registry key.
 - [Reference: Mastra.listMemory()](references/reference-core-listMemory.md) - Documentation for the `Mastra.listMemory()` method in Mastra, which returns all registered memory instances.
 - [Reference: Mastra class](references/reference-core-mastra-class.md) - Documentation for the `Mastra` class in Mastra, the core entry point for managing agents, workflows, MCP servers, and server endpoints.

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.20.0",
+  "version": "1.20.1-alpha.0",
   "package": "@mastra/libsql",
   "exports": {},
   "modules": {}

package/dist/docs/references/{docs-agents-agent-approval.md → docs-agents-human-in-the-loop.md}

@@ -1,10 +1,10 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Agent approval
+# Human-in-the-loop
 
-Agents sometimes require the same [human-in-the-loop](https://mastra.ai/docs/workflows/human-in-the-loop) oversight used in workflows when calling tools that handle sensitive operations, like deleting resources or running long processes. With agent approval you can suspend a tool call before it executes so a human can approve or decline it, or let tools suspend themselves to request additional context from the user.
+Agents sometimes require the same [human-in-the-loop (HITL)](https://mastra.ai/docs/workflows/human-in-the-loop) oversight used in workflows when calling tools that handle sensitive operations, like deleting resources or running long processes. With human-in-the-loop you can suspend a tool call before it executes so a human can approve or decline it, or let tools suspend themselves to request additional context from the user.
 
-## When to use agent approval
+## When to use human-in-the-loop
 
 - **Destructive or irreversible actions** such as deleting records or sending emails, or alternatively processing payments.
 - **Cost-heavy operations** like calling expensive third-party APIs where you want to verify arguments first.
@@ -12,7 +12,7 @@ Agents sometimes require the same [human-in-the-loop](https://mastra.ai/docs/wor
 
 ## Quickstart
 
-Mark a tool with `requireApproval: true`, then check for the `tool-call-approval` chunk in the stream to approve or decline:
+Mark a tool with `requireApproval: true`, then check for the `tool-call-approval` chunk in the stream to approve or decline the action:
 
 ```typescript
 import { Agent } from '@mastra/core/agent'
@@ -48,7 +48,7 @@ for await (const chunk of stream.fullStream) {
 }
 ```
 
-> **Note:** Agent approval uses snapshots to capture request state. Configure a [storage provider](https://mastra.ai/docs/storage/overview) on your Mastra instance or you'll see a "snapshot not found" error.
+> **Note:** Human-in-the-loop uses snapshots to capture request state. Configure a [storage provider](https://mastra.ai/docs/storage) on your Mastra instance or you'll see a "snapshot not found" error.
 >
 > Snapshots for agent runs are minimal resume artifacts: they hold only what's needed to resume the suspended run and are deleted once the run finishes. Use [tracing](https://mastra.ai/docs/observability/overview) for the execution record and [memory](https://mastra.ai/docs/memory/overview) for the conversation history.
 
@@ -391,6 +391,8 @@ const agent = new Agent({
 
 When enabled, the agent detects suspended tools from message history on the next user message. It extracts `resumeData` based on the tool's `resumeSchema`, then automatically resumes the tool.
 
+Automatic resumption applies to data-bearing `suspend()` flows. It doesn't approve tools that use `requireApproval`; those tools remain suspended until an explicit approval or decline is submitted through `approveToolCall()`, `declineToolCall()`, `resumeStream({ approved: boolean })`, or an equivalent UI or API action.
+
 The following example shows a complete conversational flow:
 
 ```typescript
@@ -508,11 +510,11 @@ Each returned run includes the suspended tool calls (`toolCallId`, `toolName`, `
 
 The same discovery is available over HTTP as `GET /agents/:agentId/suspended-runs` and in the client SDK as [`agent.listSuspendedRuns()`](https://mastra.ai/reference/client-js/agents), so browser-based approval UIs can rediscover pending runs directly.
 
-> **Note:** Suspended runs only survive restarts when your Mastra instance is configured with a persistent [storage provider](https://mastra.ai/docs/storage/overview). The default in-memory store loses snapshots when the process exits.
+> **Note:** Suspended runs only survive restarts when your Mastra instance is configured with a persistent [storage provider](https://mastra.ai/docs/storage). The default in-memory store loses snapshots when the process exits.
 
 ## Tool approval: Supervisor agents
 
-A [supervisor agent](https://mastra.ai/docs/capabilities/subagents) coordinates multiple subagents using `.stream()` or `.generate()`. When a subagent calls a tool that requires approval, the request propagates up through the delegation chain and surfaces at the supervisor level:
+A [supervisor agent](https://mastra.ai/docs/subagents) coordinates multiple subagents using `.stream()` or `.generate()`. When a subagent calls a tool that requires approval, the request propagates up through the delegation chain and surfaces at the supervisor level:
 
 1. The supervisor delegates a task to a subagent.
 2. The subagent calls a tool that has `requireApproval: true` or uses `suspend()`.
@@ -671,8 +673,8 @@ if (output.finishReason === 'suspended') {
 
 ## Related
 
-- [Tools](https://mastra.ai/docs/agents/using-tools)
+- [Tools](https://mastra.ai/docs/agents/tools)
 - [Agent overview](https://mastra.ai/docs/agents/overview)
-- [MCP overview](https://mastra.ai/docs/mcp/overview)
+- [MCP overview](https://mastra.ai/docs/connections/mcp)
 - [Memory](https://mastra.ai/docs/memory/overview)
 - [Request context](https://mastra.ai/docs/server/request-context)

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

@@ -2,7 +2,7 @@
 
 # Agent networks
 
-> **Deprecated:** Agent networks are deprecated and will be removed in a future major release. [Supervisor agents](https://mastra.ai/docs/capabilities/subagents) using `agent.stream()` or `agent.generate()` are now the recommended approach. It provides the same multi-agent coordination with better control, a simpler API, and easier debugging.
+> **Deprecated:** Agent networks are deprecated and will be removed in a future major release. [Supervisor agents](https://mastra.ai/docs/subagents) using `agent.stream()` or `agent.generate()` are now the recommended approach. It provides the same multi-agent coordination with better control, a simpler API, and easier debugging.
 >
 > See the [migration guide](https://mastra.ai/reference/migrations/network-to-supervisor) to upgrade.
 
@@ -95,7 +95,7 @@ console.log(final?.summary)
 
 When a primitive requires approval, the stream emits an `agent-execution-approval` or `tool-execution-approval` chunk. Use `approveNetworkToolCall()` or `declineNetworkToolCall()` to respond.
 
-Network approval uses snapshots to capture execution state. Ensure a [storage provider](https://mastra.ai/docs/storage/overview) is enabled in your Mastra instance.
+Network approval uses snapshots to capture execution state. Ensure a [storage provider](https://mastra.ai/docs/storage) is enabled in your Mastra instance.
 
 ```typescript
 const stream = await routingAgent.network('Perform some sensitive action', {
@@ -180,5 +180,5 @@ Requirements for automatic resumption:
 
 ## Related
 
-- [Supervisor agents](https://mastra.ai/docs/capabilities/subagents)
+- [Supervisor agents](https://mastra.ai/docs/subagents)
 - [Migration: `.network()` to supervisor agents](https://mastra.ai/reference/migrations/network-to-supervisor)

package/dist/docs/references/docs-deployment-workers.md

@@ -106,31 +106,277 @@ Run the same build artifact in multiple containers, each with a different [`MAST
 
 Split deployments require a distributed PubSub backend ([`RedisStreamsPubSub`](https://mastra.ai/reference/pubsub/redis-streams) or [`GoogleCloudPubSub`](https://mastra.ai/reference/pubsub/google-cloud-pubsub)), a shared [storage backend](https://mastra.ai/reference/workers/overview), and network connectivity between the orchestration worker and the API.
 
-The [worker deployment guide](https://mastra.ai/guides/deployment/mastra-workers) walks through this setup with Docker Compose and Kubernetes examples.
+### Select workers
+
+Set [`MASTRA_WORKERS`](https://mastra.ai/reference/workers/overview) to control which workers run in each process:
+
+| Value                           | Behavior                                                                       |
+| ------------------------------- | ------------------------------------------------------------------------------ |
+| `false`                         | Disable all workers. Use this for the API process in a fully split deployment. |
+| `orchestration`                 | Start the orchestration worker.                                                |
+| `scheduler`                     | Start the scheduler worker.                                                    |
+| `backgroundTasks`               | Start the background task worker.                                              |
+| `orchestration,backgroundTasks` | Start multiple workers from a comma-separated allowlist.                       |
+
+You can also pass a worker name to the CLI. The command sets `MASTRA_WORKERS` in the spawned process:
+
+```bash
+mastra worker start orchestration
+```
 
 ## Network architecture
 
-Workers are internal infrastructure. They're not exposed to end users and don't need their own subdomain, public URL, or inbound HTTP route.
+Workers are internal infrastructure. They're not exposed to end users and don't need their own subdomain or public URL, including an inbound HTTP route.
 
 In a split deployment:
 
-- **The API server is the only public-facing process**: It serves all client HTTP requests, including REST endpoints, agent interactions, workflow triggers, and any custom routes.
+- **The API server is the only public-facing process**: It serves all client HTTP requests. These requests include REST endpoints and agent interactions, plus workflow triggers and custom routes.
 - **Workers connect outbound only**: They pull events from the distributed PubSub backend and read/write to the shared storage database. They don't accept inbound traffic from clients.
 - **The orchestration worker calls the API internally**: It sends step execution requests to the API over the container network using `MASTRA_STEP_EXECUTION_URL`. This is internal service-to-service communication, not a public endpoint.
 
-All three worker types (orchestration, scheduler, background task) sit behind the API on a private network. They share access to the PubSub backend and storage database but never receive traffic directly from clients. If a worker-related feature needs an HTTP route (for example, token minting for a voice integration), that route runs on the API server, not on the worker process.
+All three worker types (orchestration, scheduler, background task) sit behind the API on a private network. They share access to the PubSub backend and storage database but never receive traffic directly from clients. HTTP routes for worker-related features run on the API server rather than the worker process. One example is token minting for a voice integration.
+
+## Deploy split workers
+
+Build the API and worker artifacts:
+
+```bash
+mastra build
+mastra worker build --output-dir .mastra/worker
+```
+
+`mastra build` creates the API artifact in `.mastra/output/`. [`mastra worker build`](https://mastra.ai/reference/cli/mastra) creates a worker artifact in `.mastra/worker/`. The following Dockerfile accepts either directory:
+
+```dockerfile
+FROM node:22-alpine
+
+ARG MASTRA_OUTPUT=.mastra/output
+
+WORKDIR /app
+
+COPY ${MASTRA_OUTPUT}/package.json ${MASTRA_OUTPUT}/.npmrc* ./
+RUN npm install --omit=dev
+
+COPY ${MASTRA_OUTPUT}/ .
+
+EXPOSE 4111
+CMD ["node", "index.mjs"]
+```
+
+See [Deploy a Mastra server](https://mastra.ai/docs/deployment/mastra-server) for more information about the build output.
+
+### Docker Compose
+
+The following configuration runs PostgreSQL, Redis, the API, and one process for each worker type. Every process uses shared infrastructure, and the worker processes use the worker artifact.
+
+```yaml
+x-worker: &worker
+  build:
+    context: .
+    args:
+      MASTRA_OUTPUT: .mastra/worker
+
+x-mastra-environment: &shared-environment
+  DATABASE_URL: postgres://mastra:${POSTGRES_PASSWORD}@postgres:5432/mastra
+  REDIS_URL: redis://redis:6379
+
+services:
+  postgres:
+    image: postgres:16-alpine
+    environment:
+      POSTGRES_USER: mastra
+      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
+      POSTGRES_DB: mastra
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ['CMD-SHELL', 'pg_isready -U mastra']
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  redis:
+    image: redis:7-alpine
+    healthcheck:
+      test: ['CMD', 'redis-cli', 'ping']
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  api:
+    build:
+      context: .
+      args:
+        MASTRA_OUTPUT: .mastra/output
+    ports:
+      - '4111:4111'
+    environment:
+      <<: *shared-environment
+      WORKER_TOKEN: ${WORKER_TOKEN}
+      MASTRA_WORKERS: 'false'
+    depends_on:
+      postgres:
+        condition: service_healthy
+      redis:
+        condition: service_healthy
+    healthcheck:
+      test: ['CMD', 'wget', '-qO-', 'http://localhost:4111/api/agents']
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  orchestration-worker:
+    <<: *worker
+    environment:
+      <<: *shared-environment
+      MASTRA_WORKERS: orchestration
+      MASTRA_STEP_EXECUTION_URL: http://api:4111/api
+      MASTRA_WORKER_AUTH_TOKEN: ${WORKER_TOKEN}
+    depends_on:
+      api:
+        condition: service_healthy
+
+  scheduler-worker:
+    <<: *worker
+    environment:
+      <<: *shared-environment
+      MASTRA_WORKERS: scheduler
+    depends_on:
+      api:
+        condition: service_healthy
+
+  background-task-worker:
+    <<: *worker
+    environment:
+      <<: *shared-environment
+      MASTRA_WORKERS: backgroundTasks
+    depends_on:
+      api:
+        condition: service_healthy
+
+volumes:
+  pgdata:
+```
+
+Set the secrets next to `docker-compose.yml`, along with any model provider credentials your application needs:
+
+```bash
+POSTGRES_PASSWORD=your-secure-password
+WORKER_TOKEN=your-shared-secret-token
+```
+
+Configure the API auth provider to accept `WORKER_TOKEN` before exposing the deployment. The orchestration worker sends the same value through `MASTRA_WORKER_AUTH_TOKEN`. The scheduler and background task workers don't call the step execution endpoint in this pull-based topology, so they don't need that variable.
+
+Start the stack and verify that the containers and API are available:
+
+```bash
+docker compose up -d
+docker compose ps
+curl http://localhost:4111/api/agents
+```
+
+### Kubernetes
+
+Create separate Deployments for the API, orchestration worker, scheduler worker, and background task worker. Use the same image and Secret for each Deployment. Set only the role-specific environment variables directly on each container.
+
+The orchestration worker Deployment has the following shape:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: orchestration-worker
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: orchestration-worker
+  template:
+    metadata:
+      labels:
+        app: orchestration-worker
+    spec:
+      containers:
+        - name: worker
+          image: your-registry/mastra-workers:latest
+          env:
+            - name: MASTRA_WORKERS
+              value: orchestration
+            - name: MASTRA_STEP_EXECUTION_URL
+              value: http://api:4111/api
+          envFrom:
+            - secretRef:
+                name: mastra-secrets
+          resources:
+            requests:
+              cpu: 250m
+              memory: 256Mi
+```
+
+Use `MASTRA_WORKERS: scheduler` and `MASTRA_WORKERS: backgroundTasks` for the other worker Deployments. Set `MASTRA_WORKERS: 'false'` on the API Deployment and expose the API with a Service. Give every process access to the same database and PubSub backend. Configure the API auth provider with a worker token, then expose that token to the orchestration worker as `MASTRA_WORKER_AUTH_TOKEN`. See [Deploy Mastra to Kubernetes](https://mastra.ai/integrations/deploy/kubernetes) for the base Kubernetes resources.
+
+Apply the manifests, then verify the pods and API:
+
+```bash
+kubectl apply -f k8s/
+kubectl get pods
+kubectl port-forward svc/api 4111:4111
+```
+
+In a separate terminal, request an API route:
+
+```bash
+curl http://localhost:4111/api/agents
+```
+
+### Step execution URL
+
+In a fully split deployment, the orchestration worker delegates workflow step execution to the API over HTTP. Set `MASTRA_STEP_EXECUTION_URL` to the API's internal URL, including the `/api` prefix:
+
+```bash
+MASTRA_STEP_EXECUTION_URL=http://api:4111/api
+```
+
+Without this variable, the orchestration worker attempts to execute steps in its own process, which doesn't have access to the full Mastra runtime in a split deployment.
+
+The endpoint uses the server's normal auth pipeline. If the API has an auth provider, set `MASTRA_WORKER_AUTH_TOKEN` to a bearer token that provider accepts. Mastra forwards the value as an `Authorization: Bearer` credential. The configured auth provider validates the token. See [Worker authentication](https://mastra.ai/docs/auth/workers) for server configuration and other credential formats.
+
+### Scale workers
+
+The orchestration and background task workers can scale horizontally. PubSub consumer groups distribute events across their instances:
+
+```bash
+docker compose up -d --scale orchestration-worker=3
+docker compose up -d --scale background-task-worker=2
+```
+
+For Kubernetes, change the Deployment replica count manually or use a HorizontalPodAutoscaler:
+
+```bash
+kubectl scale deployment/orchestration-worker --replicas=3
+kubectl scale deployment/background-task-worker --replicas=2
+```
+
+Run exactly one scheduler worker. Multiple schedulers polling the same storage can publish duplicate events for a schedule.
+
+### Crash recovery
+
+A distributed PubSub backend persists unacknowledged events, which lets orchestration and background task workers resume after a restart. When the API is unavailable, a failed step-execution request causes the event to be delivered again. Because an event can be processed more than once, handlers should be idempotent when possible.
+
+The scheduler calculates the next fire time from the current time after it restarts. It doesn't replay schedules that elapsed while it was unavailable.
+
+If the API crashes while a step is executing, that work can be lost and the workflow run can remain in a `running` state. See [known limitations](#known-limitations) and [durable agent crash recovery](https://mastra.ai/docs/harness/durable-agents).
 
 ## Known limitations
 
 - **No dead-letter queue**: Failed events are nacked and retried, but there's no DLQ for events that fail after all retries.
 - **No built-in health endpoint**: Workers don't expose an HTTP health check. Use container-level liveness probes or process monitoring.
 - **Scheduler is single-instance**: Running multiple scheduler processes causes duplicate schedule fires.
-- **Runs stuck in "running" after API crash**: If the API process crashes while executing a workflow step, the run remains in `running` status with no automatic retry. For [durable agents](https://mastra.ai/docs/long-running-agents/durable-agents), set `recovery.durableAgents` to `'auto'` in the Mastra config to automatically re-drive orphaned runs on server restart. See [Crash recovery](https://mastra.ai/docs/long-running-agents/durable-agents) for details.
+- **Runs stuck in "running" after API crash**: If the API process crashes while executing a workflow step, the run remains in `running` status with no automatic retry. For [durable agents](https://mastra.ai/docs/harness/durable-agents), set `recovery.durableAgents` to `'auto'` in the Mastra config to automatically re-drive orphaned runs on server restart. See [Crash recovery](https://mastra.ai/docs/harness/durable-agents) for details.
 
 ## Related
 
-- [Worker deployment guide](https://mastra.ai/guides/deployment/mastra-workers): Docker Compose and Kubernetes examples
-- [Worker authentication](https://mastra.ai/docs/server/auth/workers): Secure worker-to-API communication
+- [Worker authentication](https://mastra.ai/docs/auth/workers): Secure worker-to-API communication
 - [Workers reference](https://mastra.ai/reference/workers/overview): Details about worker environment variables and types, with a list of supported storage backends
 - [CLI reference](https://mastra.ai/reference/cli/mastra): `mastra worker build` and `mastra worker start`
 - [PubSub](https://mastra.ai/docs/server/pubsub): Event delivery backends

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

@@ -163,7 +163,7 @@ const agent = new Agent({
 
 ## Manual control and deduplication
 
-If you manually add a memory processor to `inputProcessors` or `outputProcessors`, Mastra **won't** automatically add it. This gives you full control over processor ordering:
+If you manually add a memory processor to `inputProcessors` or `outputProcessors`, Mastra **won't** automatically add it. Manual configuration gives you full control over processor ordering:
 
 ```typescript
 import { Agent } from '@mastra/core/agent'

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

@@ -25,7 +25,7 @@ Studio automatically generates a thread and resource ID for you. When calling `s
 
 ## Getting started
 
-Install the Mastra memory module along with a [storage adapter](https://mastra.ai/docs/storage/overview) for your database. The examples below use `@mastra/libsql`, which stores data locally in a `mastra.db` file.
+Install the Mastra memory module along with a [storage adapter](https://mastra.ai/docs/storage) for your database. The examples below use `@mastra/libsql`, which stores data locally in a `mastra.db` file.
 
 **npm**:
 
@@ -117,7 +117,7 @@ await agent.stream('Hello', {
 
 You can use this history in two ways:
 
-- **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.
+- **Automatic inclusion**: Mastra automatically fetches recent messages and includes them in the context window. By default, the last 10 messages keep agents grounded in the conversation. You can adjust this number with `lastMessages`, but in most cases you don't need to think about it.
 - [**Manual querying**](#querying): For more control, use the `recall()` function to query threads and messages directly. This lets you choose exactly which memories are included in the context window, or fetch messages to render conversation history in your UI.
 
 > **Tip:** When memory is enabled, [Studio](https://mastra.ai/docs/studio/overview) uses message history to display past conversations in the chat sidebar.
@@ -339,7 +339,7 @@ const { thread, clonedMessages } = await memory.cloneThread({
 })
 ```
 
-You can filter which messages get cloned (by count or date range), specify custom thread IDs, and use utility methods to inspect clone relationships.
+You can filter cloned messages by count or date range and specify custom thread IDs. Utility methods are also available to inspect clone relationships.
 
 See [`cloneThread()`](https://mastra.ai/reference/memory/cloneThread) and [clone utilities](https://mastra.ai/reference/memory/clone-utilities) for the full API.
 

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

@@ -13,7 +13,7 @@ Mastra agents can be configured to store [message history](https://mastra.ai/doc
 
 If the combined memory exceeds the model's context limit, [memory processors](https://mastra.ai/docs/memory/memory-processors) can filter, trim, or prioritize content so the most relevant information is preserved.
 
-Memory results will be stored in one or more of your configured [storage providers](https://mastra.ai/docs/storage/overview).
+Memory results will be stored in one or more of your configured [storage providers](https://mastra.ai/docs/storage).
 
 > **📹 Watch:** Watch [Mastra memory concepts](https://www.youtube.com/watch?v=18iIHQtIPmc) for a conceptual overview of the memory layers agents can use.
 
@@ -77,7 +77,7 @@ Use memory when your agent needs to maintain multi-turn conversations that refer
    bun add @mastra/libsql@latest
    ```
 
-   For more details on available providers and how storage works in Mastra, visit the [storage](https://mastra.ai/docs/storage/overview) documentation.
+   For more details on available providers and how storage works in Mastra, visit the [storage](https://mastra.ai/docs/storage) documentation.
 
 3. Add the storage provider to your main Mastra instance to enable memory across all configured agents.
 
@@ -188,7 +188,7 @@ Conversation messages are ordered by timestamp and deduplicated by message ID, s
 
 ## Memory in multi-agent systems
 
-When a [supervisor agent](https://mastra.ai/docs/capabilities/subagents) delegates to a subagent, Mastra isolates subagent memory automatically. No flag enables this as it happens on every delegation. Understanding how this scoping works lets you decide what stays private and what to share intentionally.
+When a [supervisor agent](https://mastra.ai/docs/subagents) delegates to a subagent, Mastra isolates subagent memory automatically. No flag enables this as it happens on every delegation. Understanding how this scoping works lets you decide what stays private and what to share intentionally.
 
 ### How delegation scopes memory
 
@@ -200,7 +200,7 @@ Each delegation creates a fresh `threadId` and a deterministic `resourceId` for
 
 > **Note:** Title generation (`generateTitle`) is a top-level thread concern and **isn't** applied to inherited subagent threads. Because each delegation creates an ephemeral thread that no one sees, running title generation for it would waste an LLM call per delegation. To generate titles for a subagent's own threads, give that subagent its own memory configuration.
 
-The supervisor forwards its conversation context to the subagent so it has enough background to complete the task. Only the delegation prompt and the subagent's response are saved, the full parent conversation isn't stored. You can control which messages reach the subagent with the [`messageFilter`](https://mastra.ai/docs/capabilities/subagents) callback.
+The supervisor forwards its conversation context to the subagent so it has enough background to complete the task. Only the delegation prompt and the subagent's response are saved, the full parent conversation isn't stored. You can control which messages reach the subagent with the [`messageFilter`](https://mastra.ai/docs/subagents) callback.
 
 > **Note:** Subagent resource IDs are always suffixed with the agent name (`{parentResourceId}-{agentName}`). Different subagents under the same supervisor never share a resource ID through delegation.
 

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

@@ -270,7 +270,7 @@ Supported embedding models:
 
 - **OpenAI**: `text-embedding-3-small`, `text-embedding-3-large`, `text-embedding-ada-002`
 - **Google**: `gemini-embedding-001`
-- **OpenRouter**: Access embedding models from various providers
+- **OpenRouter**: Access embedding models from multiple providers
 
 ```ts
 import { Agent } from '@mastra/core/agent'

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

@@ -1,6 +1,6 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Working Memory
+# Working memory
 
 While [message history](https://mastra.ai/docs/memory/message-history) and [semantic recall](https://mastra.ai/docs/memory/semantic-recall) help agents remember conversations, working memory allows them to maintain persistent information about users across interactions.
 
@@ -213,7 +213,7 @@ const paragraphMemory = new Memory({
 
 ## Structured working memory
 
-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 [Standard JSON Schema](https://standardschema.dev/json-schema) ([Zod](https://zod.dev/), [Valibot](https://valibot.dev/), [ArkType](https://arktype.io/), etc.). When using a schema, the agent will see and update working memory as a JSON object matching your schema.
+Working memory can also be defined using a structured schema instead of a Markdown template. A [Standard JSON Schema](https://standardschema.dev/json-schema) ([Zod](https://zod.dev/), [Valibot](https://valibot.dev/), [ArkType](https://arktype.io/), etc.). When using a schema, the agent will see and update working memory as a JSON object matching your schema.
 
 **Requirement:** You must specify either `template` or `schema`, but not both.
 
@@ -400,7 +400,7 @@ const response = await agent.generate('What do you know about me?', {
 
 ## Opt in to state signals (experimental)
 
-By default, working memory reaches the model as part of the system message. You can opt into delivering it as a [state signal](https://mastra.ai/docs/long-running-agents/signals) instead by setting `useStateSignals: true`:
+By default, working memory reaches the model as part of the system message. You can opt into delivering it as a [state signal](https://mastra.ai/docs/harness/signals) instead by setting `useStateSignals: true`:
 
 ```typescript
 const memory = new Memory({

package/dist/docs/references/{docs-storage-overview.md → docs-storage.md}

@@ -1,6 +1,6 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Storage overview
+# Storage
 
 Storage is the persistence layer for the Mastra runtime. It keeps memory, workflow state, observability data, eval results, schedules, and long-running agent state available after a process restarts.
 
@@ -10,7 +10,7 @@ Storage powers:
 - [Workflows](https://mastra.ai/docs/workflows/overview): Durable snapshots for suspended and resumed workflow runs.
 - [Observability](https://mastra.ai/docs/observability/overview): Traces, spans, metrics, logs, and feedback.
 - [Evals](https://mastra.ai/docs/evals/overview): Scores, datasets, experiments, and evaluation results.
-- [Long-running agents](https://mastra.ai/docs/long-running-agents/durable-agents): Background tasks, schedules, goals, and thread state.
+- [Long-running agents](https://mastra.ai/docs/harness/durable-agents): Background tasks, schedules, goals, and thread state.
 
 ## When to configure storage
 
@@ -188,25 +188,26 @@ You can also route `observability` to a dedicated analytics backend. See the [ob
 
 ## Supported providers
 
-Each provider page includes installation instructions, configuration parameters, and usage examples:
+Each provider page includes installation instructions, configuration parameters, and usage examples. libSQL is the fastest path for local development because it doesn't require running a separate database server.
 
+- [Aurora DSQL](https://mastra.ai/integrations/databases/aurora-dsql)
+- [ClickHouse](https://mastra.ai/integrations/databases/clickhouse)
 - [Cloudflare D1](https://mastra.ai/integrations/databases/cloudflare-d1)
-- [Cloudflare KV & Durable Objects](https://mastra.ai/integrations/databases/cloudflare-kv)
+- [Cloudflare KV](https://mastra.ai/integrations/databases/cloudflare-kv)
 - [Convex](https://mastra.ai/integrations/databases/convex)
+- [DuckDB](https://mastra.ai/integrations/databases/duckdb)
 - [DynamoDB](https://mastra.ai/integrations/databases/dynamodb)
 - [Google Cloud Spanner](https://mastra.ai/integrations/databases/spanner)
 - [LanceDB](https://mastra.ai/integrations/databases/lancedb)
 - [libSQL](https://mastra.ai/integrations/databases/libsql)
-- [Microsoft SQL Server](https://mastra.ai/integrations/databases/mssql)
 - [MongoDB](https://mastra.ai/integrations/databases/mongodb)
+- [MSSQL](https://mastra.ai/integrations/databases/mssql)
 - [Neon Postgres](https://mastra.ai/integrations/databases/neon)
 - [OracleDB](https://mastra.ai/integrations/databases/oracledb)
 - [PostgreSQL](https://mastra.ai/integrations/databases/postgresql)
 - [Redis](https://mastra.ai/integrations/databases/redis)
 - [Upstash](https://mastra.ai/integrations/databases/upstash)
 
-> **Tip:** libSQL is the fastest path for local development because it doesn't require running a separate database server.
-
 ## Next steps
 
 - [Composite storage](https://mastra.ai/reference/storage/composite)

package/dist/docs/references/{docs-editor-overview.md → docs-studio-editor.md}

@@ -14,6 +14,8 @@ A [deployed Studio](https://mastra.ai/docs/studio/deployment) makes Editor avail
 
 Use Editor when an agent is defined in code but the people responsible for its behavior shouldn't edit the codebase. It works well when instructions or tools change often and need testing before they reach users. If developers own every change and release agent configuration with the application, keep the [agent configuration in code](https://mastra.ai/docs/agents/overview) instead.
 
+Use [Agent Builder](https://agent-builder.mastra.ai) instead when collaborators need to create and manage fully stored agents in a browser rather than start from agents defined in code.
+
 ## Quickstart
 
 Install `@mastra/editor`. This quickstart uses LibSQL to store Editor changes:
@@ -304,7 +306,7 @@ Version selection supports:
 - Compare two versions in an A/B test.
 - Give a draft to a small group before publishing it for everyone.
 - Keep production on the published version while staging uses the latest draft.
-- Pin a customer to a particular version.
+- Pin a customer to a specific version.
 
 The same version controls work when a supervisor calls sub-agents. Developers can test a draft sub-agent without changing the rest of the system.