@mastra/libsql 1.7.1 → 1.7.2-alpha.0

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

@@ -1,32 +1,16 @@
 # Agent networks
 
-> **Agent Network Deprecated — Supervisor Pattern Recommended:** Agent networks are deprecated and will be removed in a future release. The [supervisor pattern](https://mastra.ai/docs/agents/supervisor-agents) using `agent.stream()` or `agent.generate()` is now the recommended approach for coordinating multiple agents. It provides the same multi-agent coordination capabilities as `.network()` with significant improvements:
+> **Deprecated — Use supervisor agents:** Agent networks are deprecated and will be removed in a future major release. [Supervisor agents](https://mastra.ai/docs/agents/supervisor-agents) 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.
 >
-> - **Better control**: Iteration hooks, delegation hooks, and task completion scoring give you fine-grained control over execution
-> - **Simpler API**: Uses familiar `stream()` and `generate()` methods instead of a separate `.network()` API
-> - **More flexible**: Stop execution early, modify delegations, filter context, and provide feedback to guide the agent
-> - **Type-safe**: Full TypeScript support for all hooks and callbacks
-> - **Easier debugging**: Monitor progress with `onIterationComplete`, track delegations with `onDelegationStart`/`onDelegationComplete`
->
-> See the [migration guide](https://mastra.ai/guides/migrations/network-to-supervisor) to upgrade from `.network()`.
-
-Agent networks in Mastra coordinate multiple agents, workflows, and tools to handle tasks that aren't clearly defined upfront but can be inferred from the user's message or context. A top-level **routing agent** (a Mastra agent with other agents, workflows, and tools configured) uses an LLM to interpret the request and decide which primitives (subagents, workflows, or tools) to call, in what order, and with what data.
-
-## When to use networks
+> See the [migration guide](https://mastra.ai/guides/migrations/network-to-supervisor) to upgrade.
 
-Use networks for complex tasks that require coordination across multiple primitives. Unlike workflows, which follow a predefined sequence, networks rely on LLM reasoning to interpret the request and decide what to run.
+A **routing agent** uses an LLM to interpret a request and decide which primitives (subagents, workflows, or tools) to call, in what order, and with what data.
 
-## Core principles
+## Create an agent network
 
-Mastra agent networks operate using these principles:
+Configure a routing agent with `agents`, `workflows`, and `tools`. Memory is required as `.network()` uses it to store task history and determine when a task is complete.
 
-- Memory is required when using `.network()` and is used to store task history and determine when a task is complete.
-- Primitives are selected based on their descriptions. Clear, specific descriptions improve routing. For workflows and tools, the input schema helps determine the right inputs at runtime.
-- If multiple primitives have overlapping functionality, the agent favors the more specific one, using a combination of schema and descriptions to decide which to run.
-
-## Creating an agent network
-
-An agent network is built around a top-level routing agent that delegates tasks to subagents, workflows, and tools defined in its configuration. Memory is configured on the routing agent using the `memory` option, and `instructions` define the agent's routing behavior.
+Each primitive needs a clear `description` so the routing agent can decide which to use. For workflows and tools, `inputSchema` and `outputSchema` also help the router determine the right inputs.
 
 ```typescript
 import { Agent } from '@mastra/core/agent'
@@ -35,7 +19,6 @@ import { LibSQLStore } from '@mastra/libsql'
 
 import { researchAgent } from './research-agent'
 import { writingAgent } from './writing-agent'
-
 import { cityWorkflow } from '../workflows/city-workflow'
 import { weatherTool } from '../tools/weather-tool'
 
@@ -43,11 +26,7 @@ export const routingAgent = new Agent({
   id: 'routing-agent',
   name: 'Routing Agent',
   instructions: `
-      You are a network of writers and researchers.
-      The user will ask you to research a topic.
-      Always respond with a complete report—no bullet points.
-      Write in full paragraphs, like a blog post.
-      Do not answer with incomplete or uncertain information.`,
+    You are a network of writers and researchers. The user will ask you to research a topic. Always respond with a complete report—no bullet points. Write in full paragraphs, like a blog post. Do not answer with incomplete or uncertain information.`,
   model: 'openai/gpt-5.4',
   agents: {
     researchAgent,
@@ -68,81 +47,11 @@ export const routingAgent = new Agent({
 })
 ```
 
-### Writing descriptions for network primitives
-
-When configuring a Mastra agent network, each primitive (agent, workflow, or tool) needs a clear description to help the routing agent decide which to use. The routing agent uses each primitive's description and schema to determine what it does and how to use it. Clear descriptions and well-defined input and output schemas improve routing accuracy.
-
-#### Agent descriptions
-
-Each subagent in a network should include a clear `description` that explains what the agent does.
-
-```typescript
-export const researchAgent = new Agent({
-  id: 'research-agent',
-  name: 'Research Agent',
-  description: `This agent gathers concise research insights in bullet-point form.
-    It's designed to extract key facts without generating full
-    responses or narrative content.`,
-})
-```
-
-```typescript
-export const writingAgent = new Agent({
-  id: 'writing-agent',
-  name: 'Writing Agent',
-  description: `This agent turns researched material into well-structured
-    written content. It produces full-paragraph reports with no bullet points,
-    suitable for use in articles, summaries, or blog posts.`,
-})
-```
-
-#### Workflow descriptions
-
-Workflows in a network should include a `description` to explain their purpose, along with `inputSchema` and `outputSchema` to describe the expected data.
-
-```typescript
-export const cityWorkflow = createWorkflow({
-  id: 'city-workflow',
-  description: `This workflow handles city-specific research tasks.
-    It first gathers factual information about the city, then synthesizes
-    that research into a full written report. Use it when the user input
-    includes a city to be researched.`,
-  inputSchema: z.object({
-    city: z.string(),
-  }),
-  outputSchema: z.object({
-    text: z.string(),
-  }),
-})
-```
-
-#### Tool descriptions
-
-Tools in a network should include a `description` to explain their purpose, along with `inputSchema` and `outputSchema` to describe the expected data.
-
-```typescript
-export const weatherTool = createTool({
-  id: 'weather-tool',
-  description: ` Retrieves current weather information using the wttr.in API.
-    Accepts a city or location name as input and returns a short weather summary.
-    Use this tool whenever up-to-date weather data is requested.
-  `,
-  inputSchema: z.object({
-    location: z.string(),
-  }),
-  outputSchema: z.object({
-    weather: z.string(),
-  }),
-})
-```
-
-## Calling agent networks
-
-Call a Mastra agent network using `.network()` with a user message. The method returns a stream of events that you can iterate over to track execution progress and retrieve the final result.
+> **Note:** Subagents need a `description` on the `Agent` instance. Workflows and tools need a `description` plus `inputSchema` and `outputSchema` on `createWorkflow()` or `createTool()`.
 
-### Agent example
+## Call the network
 
-In this example, the network interprets the message and would route the request to both the `researchAgent` and `writingAgent` to generate a complete response.
+Call `.network()` with a user message. The method returns a stream of events you can iterate over.
 
 ```typescript
 const result = await routingAgent.network('Tell me three cool ways to use Mastra')
@@ -155,145 +64,119 @@ for await (const chunk of result) {
 }
 ```
 
-#### Agent output
-
-The following `chunk.type` events are emitted during this request:
-
-```text
-routing-agent-start
-routing-agent-end
-agent-execution-start
-agent-execution-event-start
-agent-execution-event-step-start
-agent-execution-event-text-start
-agent-execution-event-text-delta
-agent-execution-event-text-end
-agent-execution-event-step-finish
-agent-execution-event-finish
-agent-execution-end
-network-execution-event-step-finish
-```
-
-## Workflow example
+## Structured output
 
-In this example, the routing agent recognizes the city name in the message and runs the `cityWorkflow`. The workflow defines steps that call the `researchAgent` to gather facts, then the `writingAgent` to generate the final text.
+Pass `structuredOutput` to get typed, validated results. Use `objectStream` for partial objects as they generate.
 
 ```typescript
-const result = await routingAgent.network('Tell me some historical facts about London')
+import { z } from 'zod'
 
-for await (const chunk of result) {
-  console.log(chunk.type)
-  if (chunk.type === 'network-execution-event-step-finish') {
-    console.log(chunk.payload.result)
-  }
-}
-```
+const resultSchema = z.object({
+  summary: z.string().describe('A brief summary of the findings'),
+  recommendations: z.array(z.string()).describe('List of recommendations'),
+  confidence: z.number().min(0).max(1).describe('Confidence score'),
+})
 
-### Workflow output
+const stream = await routingAgent.network('Research AI trends', {
+  structuredOutput: { schema: resultSchema },
+})
 
-The following `chunk.type` events are emitted during this request:
+for await (const partial of stream.objectStream) {
+  console.log('Building result:', partial)
+}
 
-```text
-routing-agent-end
-workflow-execution-start
-workflow-execution-event-workflow-start
-workflow-execution-event-workflow-step-start
-workflow-execution-event-workflow-step-result
-workflow-execution-event-workflow-finish
-workflow-execution-end
-routing-agent-start
-network-execution-event-step-finish
+const final = await stream.object
+console.log(final?.summary)
 ```
 
-### Tool example
+## Approve and decline tool calls
+
+When a primitive requires approval, the stream emits an `agent-execution-approval` or `tool-execution-approval` chunk. Use `approveNetworkToolCall()` or `declineNetworkToolCall()` to respond.
 
-In this example, the routing agent skips the `researchAgent`, `writingAgent`, and `cityWorkflow`, and calls the `weatherTool` directly to complete the task.
+Network approval uses snapshots to capture execution state. Ensure a [storage provider](https://mastra.ai/docs/memory/storage) is enabled in your Mastra instance.
 
 ```typescript
-const result = await routingAgent.network("What's the weather in London?")
+const stream = await routingAgent.network('Perform some sensitive action', {
+  memory: {
+    thread: 'user-123',
+    resource: 'my-app',
+  },
+})
 
-for await (const chunk of result) {
-  console.log(chunk.type)
-  if (chunk.type === 'network-execution-event-step-finish') {
-    console.log(chunk.payload.result)
+for await (const chunk of stream) {
+  if (chunk.type === 'agent-execution-approval' || chunk.type === 'tool-execution-approval') {
+    // Approve
+    const approvedStream = await routingAgent.approveNetworkToolCall(chunk.payload.toolCallId, {
+      runId: stream.runId,
+      memory: { thread: 'user-123', resource: 'my-app' },
+    })
+
+    for await (const c of approvedStream) {
+      if (c.type === 'network-execution-event-step-finish') {
+        console.log(c.payload.result)
+      }
+    }
   }
 }
 ```
 
-#### Tool output
+To decline instead, call `declineNetworkToolCall()` with the same arguments.
 
-The following `chunk.type` events are emitted during this request:
+## Suspend and resume
 
-```text
-routing-agent-start
-routing-agent-end
-tool-execution-start
-tool-execution-end
-network-execution-event-step-finish
-```
-
-## Structured output
-
-When you need typed, validated results from a network, use the `structuredOutput` option. After the network completes its task, it generates a structured response matching your schema.
+When a primitive calls `suspend()`, the stream emits a suspension chunk (e.g., `tool-execution-suspended`). Use `resumeNetwork()` to provide the requested data and continue execution.
 
 ```typescript
-import { z } from 'zod'
-
-const resultSchema = z.object({
-  summary: z.string().describe('A brief summary of the findings'),
-  recommendations: z.array(z.string()).describe('List of recommendations'),
-  confidence: z.number().min(0).max(1).describe('Confidence score'),
-})
-
-const stream = await routingAgent.network('Research AI trends', {
-  structuredOutput: {
-    schema: resultSchema,
-  },
+const stream = await routingAgent.network('Delete the old records', {
+  memory: { thread: 'user-123', resource: 'my-app' },
 })
 
-// Consume the stream
 for await (const chunk of stream) {
-  if (chunk.type === 'network-object') {
-    // Partial object during generation
-    console.log('Partial:', chunk.payload.object)
-  }
-  if (chunk.type === 'network-object-result') {
-    // Final structured object
-    console.log('Final:', chunk.payload.object)
+  if (chunk.type === 'workflow-execution-suspended') {
+    console.log(chunk.payload.suspendPayload)
   }
 }
 
-// Get the typed result
-const result = await stream.object
-console.log(result?.summary)
-console.log(result?.recommendations)
-console.log(result?.confidence)
+// Resume with user confirmation
+const resumedStream = await routingAgent.resumeNetwork(
+  { confirmed: true },
+  {
+    runId: stream.runId,
+    memory: { thread: 'user-123', resource: 'my-app' },
+  },
+)
+
+for await (const chunk of resumedStream) {
+  if (chunk.type === 'network-execution-event-step-finish') {
+    console.log(chunk.payload.result)
+  }
+}
 ```
 
-### Streaming partial objects
+### Automatic resumption
 
-For real-time updates during structured output generation, use `objectStream`:
+Set `autoResumeSuspendedTools` to `true` so the network resumes suspended primitives based on the user's next message. This creates a conversational flow where users provide the required information naturally.
 
 ```typescript
-const stream = await routingAgent.network('Analyze market data', {
-  structuredOutput: { schema: resultSchema },
+const stream = await routingAgent.network('Delete the old records', {
+  autoResumeSuspendedTools: true,
+  memory: { thread: 'user-123', resource: 'my-app' },
 })
+```
 
-// Stream partial objects as they're generated
-for await (const partial of stream.objectStream) {
-  console.log('Building result:', partial)
-}
+Requirements for automatic resumption:
 
-// Get the final typed result
-const final = await stream.object
-```
+- **Memory configured**: The agent needs memory to track suspended tools across messages.
+- **Same thread**: The follow-up message must use the same `thread` and `resource` identifiers.
+- **`resumeSchema` defined**: The tool must define a `resumeSchema` so the network can extract data from the user's message.
+
+|          | Manual (`resumeNetwork`)                       | Automatic (`autoResumeSuspendedTools`)    |
+| -------- | ---------------------------------------------- | ----------------------------------------- |
+| Best for | Custom UIs with approval buttons               | Chat-style interfaces                     |
+| Control  | Full control over resume timing and data       | Network extracts data from user's message |
+| Setup    | Handle suspension chunks, call `resumeNetwork` | Set flag, define `resumeSchema` on tools  |
 
 ## Related
 
-- [Supervisor Agents](https://mastra.ai/docs/agents/supervisor-agents)
-- [Migration: .network() to Supervisor Pattern](https://mastra.ai/guides/migrations/network-to-supervisor)
-- [Guide: Research Coordinator](https://mastra.ai/guides/guide/research-coordinator)
-- [Agent Memory](https://mastra.ai/docs/agents/agent-memory)
-- [Agent Approval](https://mastra.ai/docs/agents/agent-approval)
-- [Workflows Overview](https://mastra.ai/docs/workflows/overview)
-- [Request Context](https://mastra.ai/docs/server/request-context)
+- [Supervisor agents](https://mastra.ai/docs/agents/supervisor-agents)
+- [Migration: `.network()` to supervisor agents](https://mastra.ai/guides/migrations/network-to-supervisor)

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

@@ -2,44 +2,239 @@
 
 Memory enables your agent to remember user messages, agent replies, and tool results across interactions, giving it the context it needs to stay consistent, maintain conversation flow, and produce better answers over time.
 
-Mastra supports four complementary memory types:
+Mastra agents can be configured to store [message history](https://mastra.ai/docs/memory/message-history). Additionally, you can enable:
 
-- [**Message history**](https://mastra.ai/docs/memory/message-history) - keeps recent messages from the current conversation so they can be rendered in the UI and used to maintain short-term continuity within the exchange.
-- [**Observational memory**](https://mastra.ai/docs/memory/observational-memory) - uses background Observer and Reflector agents to maintain a dense observation log that replaces raw message history as it grows, keeping the context window small while preserving long-term memory across conversations.
-- [**Working memory**](https://mastra.ai/docs/memory/working-memory) - stores persistent, structured user data such as names, preferences, and goals.
-- [**Semantic recall**](https://mastra.ai/docs/memory/semantic-recall) - retrieves relevant messages from older conversations based on semantic meaning rather than exact keywords, mirroring how humans recall information by association. Requires a [vector database](https://mastra.ai/docs/memory/semantic-recall) and an [embedding model](https://mastra.ai/docs/memory/semantic-recall).
+- [Observational Memory](https://mastra.ai/docs/memory/observational-memory) (Recommended): Uses background agents to maintain a dense observation log that replaces raw message history as it grows. This keeps the context window small while preserving long-term memory.
+- [Working memory](https://mastra.ai/docs/memory/working-memory): Stores persistent, structured user data such as names, preferences, and goals.
+- [Semantic recall](https://mastra.ai/docs/memory/semantic-recall): Retrieves relevant past messages based on semantic meaning rather than exact keywords.
 
 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.
 
-## Getting started
+Memory results will be stored in one or more of your configured [storage providers](https://mastra.ai/docs/memory/storage).
 
-Choose a memory option to get started:
+## When to use memory
 
-- [Message history](https://mastra.ai/docs/memory/message-history)
-- [Observational memory](https://mastra.ai/docs/memory/observational-memory)
-- [Working memory](https://mastra.ai/docs/memory/working-memory)
-- [Semantic recall](https://mastra.ai/docs/memory/semantic-recall)
+Use memory when your agent needs to maintain multi-turn conversations that reference prior exchanges, recall user preferences or facts from earlier in a session, or build context over time within a conversation thread. Skip memory for single-turn requests where each interaction is independent.
 
-## Storage
+## Quickstart
 
-Before enabling memory, you must first configure a storage adapter. Mastra supports several databases including PostgreSQL, MongoDB, libSQL, and [more](https://mastra.ai/docs/memory/storage).
+1. Install the `@mastra/memory` package.
 
-Storage can be configured at the [instance level](https://mastra.ai/docs/memory/storage) (shared across all agents) or at the [agent level](https://mastra.ai/docs/memory/storage) (dedicated per agent).
+   **npm**:
 
-For semantic recall, you can use a separate vector database like Pinecone alongside your primary storage.
+   ```bash
+   npm install @mastra/memory@latest
+   ```
 
-See the [Storage](https://mastra.ai/docs/memory/storage) documentation for configuration options, supported providers, and examples.
+   **pnpm**:
 
-## Debugging memory
+   ```bash
+   pnpm add @mastra/memory@latest
+   ```
 
-When [tracing](https://mastra.ai/docs/observability/tracing/overview) is enabled, you can inspect exactly which messages the agent uses for context in each request. The trace output shows all memory included in the agent's context window - both recent message history and messages recalled via semantic recall.
+   **Yarn**:
 
-![Trace output showing memory context included in an agent request](https://mastra.ai/_next/image?url=%2Ftracingafter.png\&w=1920\&q=75)
+   ```bash
+   yarn add @mastra/memory@latest
+   ```
 
-This visibility helps you understand why an agent made specific decisions and verify that memory retrieval is working as expected.
+   **Bun**:
 
-## Next steps
+   ```bash
+   bun add @mastra/memory@latest
+   ```
 
-- Learn more about [Storage](https://mastra.ai/docs/memory/storage) providers and configuration options
-- Add [Message history](https://mastra.ai/docs/memory/message-history), [Observational memory](https://mastra.ai/docs/memory/observational-memory), [Working memory](https://mastra.ai/docs/memory/working-memory), or [Semantic recall](https://mastra.ai/docs/memory/semantic-recall)
-- Visit [Memory configuration reference](https://mastra.ai/reference/memory/memory-class) for all available options
+2. Memory **requires** a storage provider to persist message history, including user messages and agent responses.
+
+   For the purposes of this quickstart, use `@mastra/libsql`.
+
+   **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
+   ```
+
+   > **Note:** For more details on available providers and how storage works in Mastra, visit the [storage](https://mastra.ai/docs/memory/storage) documentation.
+
+3. Add the storage provider to your main Mastra instance to enable memory across all configured agents.
+
+   ```typescript
+   import { Mastra } from '@mastra/core'
+   import { LibSQLStore } from '@mastra/libsql'
+
+   export const mastra = new Mastra({
+     storage: new LibSQLStore({
+       id: 'mastra-storage',
+       url: ':memory:',
+     }),
+   })
+   ```
+
+4. Create a `Memory` instance and pass it to the agent's `memory` option.
+
+   ```typescript
+   import { Agent } from '@mastra/core/agent'
+   import { Memory } from '@mastra/memory'
+
+   export const memoryAgent = new Agent({
+     id: 'memory-agent',
+     name: 'Memory Agent',
+     memory: new Memory({
+       options: {
+         lastMessages: 20,
+       },
+     }),
+   })
+   ```
+
+   > **Note:** Visit [Memory Class](https://mastra.ai/reference/memory/memory-class) for a full list of configuration options.
+
+5. Call your agent, for example in [Mastra Studio](https://mastra.ai/docs/getting-started/studio). Inside Studio, start a new chat with your agent and take a look at the right sidebar. It'll now display various memory-related information.
+
+## Message history
+
+Pass a `memory` object with `resource` and `thread` to track message history.
+
+- `resource`: A stable identifier for the user or entity.
+- `thread`: An ID that isolates a specific conversation or session.
+
+```typescript
+const response = await memoryAgent.generate('Remember my favorite color is blue.', {
+  memory: {
+    resource: 'user-123',
+    thread: 'conversation-123',
+  },
+})
+```
+
+To recall information stored in memory, call the agent with the same `resource` and `thread` values used in the original conversation.
+
+```typescript
+const response = await memoryAgent.generate("What's my favorite color?", {
+  memory: {
+    resource: 'user-123',
+    thread: 'conversation-123',
+  },
+})
+
+// Response: "Your favorite color is blue."
+```
+
+> **Warning:** Each thread has an owner (`resourceId`) that can't be changed after creation. Avoid reusing the same thread ID for threads with different owners, as this will cause errors when querying.
+
+To list all threads for a resource, or retrieve a specific thread, [use the memory API directly](https://mastra.ai/docs/memory/message-history).
+
+## Observational Memory
+
+For long-running conversations, raw message history grows until it fills the context window, degrading agent performance. [Observational Memory](https://mastra.ai/docs/memory/observational-memory) solves this by running background agents that compress old messages into dense observations, keeping the context window small while preserving long-term memory.
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+
+export const memoryAgent = new Agent({
+  id: 'memory-agent',
+  name: 'Memory Agent',
+  memory: new Memory({
+    options: {
+      observationalMemory: true,
+    },
+  }),
+})
+```
+
+> **Note:** See [Observational Memory](https://mastra.ai/docs/memory/observational-memory) for details on how observations and reflections work, and [the reference](https://mastra.ai/reference/memory/observational-memory) for all configuration options.
+
+## Memory in multi-agent systems
+
+When a [supervisor agent](https://mastra.ai/docs/agents/supervisor-agents) delegates to a subagent, Mastra isolates subagent memory automatically. There is no flag to enable 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
+
+Each delegation creates a fresh `threadId` and a deterministic `resourceId` for the subagent:
+
+- **Thread ID**: Unique per delegation. The subagent starts with a clean message history every time it's called.
+- **Resource ID**: Derived as `{parentResourceId}-{agentName}`. Because the resource ID is stable across delegations, resource-scoped memory persists between calls. A subagent remembers facts from previous delegations by the same user.
+- **Memory instance**: If a subagent has no memory configured, it inherits the supervisor's `Memory` instance. If the subagent defines its own, that takes precedence.
+
+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 is not stored. You can control which messages reach the subagent with the [`messageFilter`](https://mastra.ai/docs/agents/supervisor-agents) callback.
+
+> **Note:** Subagent resource IDs are always suffixed with the agent name (`{parentResourceId}-{agentName}`). Two different subagents under the same supervisor never share a resource ID through delegation.
+
+To go beyond this default isolation, you can share memory between agents by passing matching identifiers when you call them directly.
+
+### Share memory between agents
+
+When you call agents directly (outside the delegation flow), memory sharing is controlled by two identifiers: `resourceId` and `threadId`. Agents that use the same values read and write to the same data. This is useful when agents collaborate on a shared context — for example, a researcher that saves notes and a writer that reads them.
+
+**Resource-scoped sharing** is the most common pattern. [Working memory](https://mastra.ai/docs/memory/working-memory) and [semantic recall](https://mastra.ai/docs/memory/semantic-recall) default to `scope: 'resource'`. If two agents share a `resourceId`, they share observations, working memory, and embeddings — even across different threads:
+
+```typescript
+// Both agents share the same resource-scoped memory
+await researcher.generate('Find information about quantum computing.', {
+  memory: { resource: 'project-42', thread: 'research-session' },
+})
+
+await writer.generate('Write a summary from the research notes.', {
+  memory: { resource: 'project-42', thread: 'writing-session' },
+})
+```
+
+Because both calls use `resource: 'project-42'`, the writer can access the researcher's observations, working memory, and semantic embeddings. Each agent still has its own thread, so message histories stay separate.
+
+**Thread-scoped sharing** gives tighter coupling. [Observational Memory](https://mastra.ai/docs/memory/observational-memory) uses `scope: 'thread'` by default. If two agents use the same `resource` _and_ `thread`, they share the full message history. Each agent sees every message the other has written. This is useful when agents need to build on each other's exact outputs.
+
+## Observability
+
+Enable [Tracing](https://mastra.ai/docs/observability/tracing/overview) to monitor and debug memory in action. Traces show you exactly which messages and observations the agent included in its context for each request, helping you understand agent behavior and verify that memory retrieval is working as expected.
+
+Open [Mastra Studio](https://mastra.ai/docs/getting-started/studio) and select the **Observability** tab in the sidebar. Open the trace of a recent agent request, then look for spans of LLMs calls.
+
+## Switch memory per request
+
+Use [`RequestContext`](https://mastra.ai/docs/server/request-context) to access request-specific values. This lets you conditionally select different memory or storage configurations based on the context of the request.
+
+```typescript
+export type UserTier = {
+  'user-tier': 'enterprise' | 'pro'
+}
+
+const premiumMemory = new Memory()
+const standardMemory = new Memory()
+
+export const memoryAgent = new Agent({
+  id: 'memory-agent',
+  name: 'Memory Agent',
+  memory: ({ requestContext }) => {
+    const userTier = requestContext.get('user-tier') as UserTier['user-tier']
+
+    return userTier === 'enterprise' ? premiumMemory : standardMemory
+  },
+})
+```
+
+> **Note:** Visit [Request Context](https://mastra.ai/docs/server/request-context) for more information.
+
+## Related
+
+- [`Memory` reference](https://mastra.ai/reference/memory/memory-class)
+- [Tracing](https://mastra.ai/docs/observability/tracing/overview)
+- [Request Context](https://mastra.ai/docs/server/request-context)

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

@@ -16,7 +16,7 @@ When it's enabled, new messages are used to query a vector DB for semantically s
 
 After getting a response from the LLM, all new messages (user, assistant, and tool calls/results) are inserted into the vector DB to be recalled in later interactions.
 
-## Quick start
+## Quickstart
 
 Semantic recall is enabled by default, so if you give your agent memory it will be included: