@mastra/libsql 1.6.1 → 1.6.2

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

@@ -0,0 +1,299 @@
+# Agent Networks
+
+> **Supervisor Pattern Recommended:** 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:
+>
+> - **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
+
+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.
+
+## Core principles
+
+Mastra agent networks operate using these principles:
+
+- 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.
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+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'
+
+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.`,
+  model: 'openai/gpt-5.1',
+  agents: {
+    researchAgent,
+    writingAgent,
+  },
+  workflows: {
+    cityWorkflow,
+  },
+  tools: {
+    weatherTool,
+  },
+  memory: new Memory({
+    storage: new LibSQLStore({
+      id: 'mastra-storage',
+      url: 'file:../mastra.db',
+    }),
+  }),
+})
+```
+
+### 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.
+
+### Agent example
+
+In this example, the network interprets the message and would route the request to both the `researchAgent` and `writingAgent` to generate a complete response.
+
+```typescript
+const result = await routingAgent.network('Tell me three cool ways to use Mastra')
+
+for await (const chunk of result) {
+  console.log(chunk.type)
+  if (chunk.type === 'network-execution-event-step-finish') {
+    console.log(chunk.payload.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
+
+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.
+
+```typescript
+const result = await routingAgent.network('Tell me some historical facts about London')
+
+for await (const chunk of result) {
+  console.log(chunk.type)
+  if (chunk.type === 'network-execution-event-step-finish') {
+    console.log(chunk.payload.result)
+  }
+}
+```
+
+### Workflow output
+
+The following `chunk.type` events are emitted during this request:
+
+```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
+```
+
+### Tool example
+
+In this example, the routing agent skips the `researchAgent`, `writingAgent`, and `cityWorkflow`, and calls the `weatherTool` directly to complete the task.
+
+```typescript
+const result = await routingAgent.network("What's the weather in London?")
+
+for await (const chunk of result) {
+  console.log(chunk.type)
+  if (chunk.type === 'network-execution-event-step-finish') {
+    console.log(chunk.payload.result)
+  }
+}
+```
+
+#### Tool output
+
+The following `chunk.type` events are emitted during this request:
+
+```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.
+
+```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,
+  },
+})
+
+// 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)
+  }
+}
+
+// Get the typed result
+const result = await stream.object
+console.log(result?.summary)
+console.log(result?.recommendations)
+console.log(result?.confidence)
+```
+
+### Streaming partial objects
+
+For real-time updates during structured output generation, use `objectStream`:
+
+```typescript
+const stream = await routingAgent.network('Analyze market data', {
+  structuredOutput: { schema: resultSchema },
+})
+
+// Stream partial objects as they're generated
+for await (const partial of stream.objectStream) {
+  console.log('Building result:', partial)
+}
+
+// Get the final typed result
+const final = await stream.object
+```
+
+## 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)

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

@@ -0,0 +1,314 @@
+# Memory Processors
+
+Memory processors transform and filter messages as they pass through an agent with memory enabled. They manage context window limits, remove unnecessary content, and optimize the information sent to the language model.
+
+When memory is enabled on an agent, Mastra adds memory processors to the agent's processor pipeline. These processors retrieve message history, working memory, and semantically relevant messages, then persist new messages after the model responds.
+
+Memory processors are [processors](https://mastra.ai/docs/agents/processors) that operate specifically on memory-related messages and state.
+
+## Built-in Memory Processors
+
+Mastra automatically adds these processors when memory is enabled:
+
+### MessageHistory
+
+Retrieves message history and persists new messages.
+
+**When you configure:**
+
+```typescript
+memory: new Memory({
+  lastMessages: 10,
+})
+```
+
+**Mastra internally:**
+
+1. Creates a `MessageHistory` processor with `limit: 10`
+2. Adds it to the agent's input processors (runs before the LLM)
+3. Adds it to the agent's output processors (runs after the LLM)
+
+**What it does:**
+
+- **Input**: Fetches the last 10 messages from storage and prepends them to the conversation
+- **Output**: Persists new messages to storage after the model responds
+
+**Example:**
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+import { LibSQLStore } from '@mastra/libsql'
+import { openai } from '@ai-sdk/openai'
+
+const agent = new Agent({
+  id: 'test-agent',
+  name: 'Test Agent',
+  instructions: 'You are a helpful assistant',
+  model: 'openai/gpt-4o',
+  memory: new Memory({
+    storage: new LibSQLStore({
+      id: 'memory-store',
+      url: 'file:memory.db',
+    }),
+    lastMessages: 10, // MessageHistory processor automatically added
+  }),
+})
+```
+
+### SemanticRecall
+
+Retrieves semantically relevant messages based on the current input and creates embeddings for new messages.
+
+**When you configure:**
+
+```typescript
+memory: new Memory({
+  semanticRecall: { enabled: true },
+  vector: myVectorStore,
+  embedder: myEmbedder,
+})
+```
+
+**Mastra internally:**
+
+1. Creates a `SemanticRecall` processor
+2. Adds it to the agent's input processors (runs before the LLM)
+3. Adds it to the agent's output processors (runs after the LLM)
+4. Requires both a vector store and embedder to be configured
+
+**What it does:**
+
+- **Input**: Performs vector similarity search to find relevant past messages and prepends them to the conversation
+- **Output**: Creates embeddings for new messages and stores them in the vector store for future retrieval
+
+**Example:**
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+import { LibSQLStore } from '@mastra/libsql'
+import { PineconeVector } from '@mastra/pinecone'
+import { OpenAIEmbedder } from '@mastra/openai'
+import { openai } from '@ai-sdk/openai'
+
+const agent = new Agent({
+  name: 'semantic-agent',
+  instructions: 'You are a helpful assistant with semantic memory',
+  model: 'openai/gpt-4o',
+  memory: new Memory({
+    storage: new LibSQLStore({
+      id: 'memory-store',
+      url: 'file:memory.db',
+    }),
+    vector: new PineconeVector({
+      id: 'memory-vector',
+      apiKey: process.env.PINECONE_API_KEY!,
+    }),
+    embedder: new OpenAIEmbedder({
+      model: 'text-embedding-3-small',
+      apiKey: process.env.OPENAI_API_KEY!,
+    }),
+    semanticRecall: { enabled: true }, // SemanticRecall processor automatically added
+  }),
+})
+```
+
+### WorkingMemory
+
+Manages working memory state across conversations.
+
+**When you configure:**
+
+```typescript
+memory: new Memory({
+  workingMemory: { enabled: true },
+})
+```
+
+**Mastra internally:**
+
+1. Creates a `WorkingMemory` processor
+2. Adds it to the agent's input processors (runs before the LLM)
+3. Requires a storage adapter to be configured
+
+**What it does:**
+
+- **Input**: Retrieves working memory state for the current thread and prepends it to the conversation
+- **Output**: No output processing
+
+**Example:**
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+import { LibSQLStore } from '@mastra/libsql'
+import { openai } from '@ai-sdk/openai'
+
+const agent = new Agent({
+  name: 'working-memory-agent',
+  instructions: 'You are an assistant with working memory',
+  model: 'openai/gpt-4o',
+  memory: new Memory({
+    storage: new LibSQLStore({
+      id: 'memory-store',
+      url: 'file:memory.db',
+    }),
+    workingMemory: { enabled: true }, // WorkingMemory processor automatically added
+  }),
+})
+```
+
+## Manual Control and Deduplication
+
+If you manually add a memory processor to `inputProcessors` or `outputProcessors`, Mastra will **not** automatically add it. This gives you full control over processor ordering:
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+import { MessageHistory } from '@mastra/core/processors'
+import { TokenLimiter } from '@mastra/core/processors'
+import { LibSQLStore } from '@mastra/libsql'
+import { openai } from '@ai-sdk/openai'
+
+// Custom MessageHistory with different configuration
+const customMessageHistory = new MessageHistory({
+  storage: new LibSQLStore({ id: 'memory-store', url: 'file:memory.db' }),
+  lastMessages: 20,
+})
+
+const agent = new Agent({
+  name: 'custom-memory-agent',
+  instructions: 'You are a helpful assistant',
+  model: 'openai/gpt-4o',
+  memory: new Memory({
+    storage: new LibSQLStore({ id: 'memory-store', url: 'file:memory.db' }),
+    lastMessages: 10, // This would normally add MessageHistory(10)
+  }),
+  inputProcessors: [
+    customMessageHistory, // Your custom one is used instead
+    new TokenLimiter({ limit: 4000 }), // Runs after your custom MessageHistory
+  ],
+})
+```
+
+## Processor Execution Order
+
+Understanding the execution order is important when combining guardrails with memory:
+
+### Input Processors
+
+```text
+[Memory Processors] → [Your inputProcessors]
+```
+
+1. **Memory processors run FIRST**: `WorkingMemory`, `MessageHistory`, `SemanticRecall`
+2. **Your input processors run AFTER**: guardrails, filters, validators
+
+This means memory loads message history before your processors can validate or filter the input.
+
+### Output Processors
+
+```text
+[Your outputProcessors] → [Memory Processors]
+```
+
+1. **Your output processors run FIRST**: guardrails, filters, validators
+2. **Memory processors run AFTER**: `SemanticRecall` (embeddings), `MessageHistory` (persistence)
+
+This ordering is designed to be **safe by default**: if your output guardrail calls `abort()`, the memory processors never run and **no messages are saved**.
+
+## Guardrails and Memory
+
+The default execution order provides safe guardrail behavior:
+
+### Output guardrails (recommended)
+
+Output guardrails run **before** memory processors save messages. If a guardrail aborts:
+
+- The tripwire is triggered
+- Memory processors are skipped
+- **No messages are persisted to storage**
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+import { openai } from '@ai-sdk/openai'
+
+// Output guardrail that blocks inappropriate content
+const contentBlocker = {
+  id: 'content-blocker',
+  processOutputResult: async ({ messages, abort }) => {
+    const hasInappropriateContent = messages.some(msg => containsBadContent(msg))
+    if (hasInappropriateContent) {
+      abort('Content blocked by guardrail')
+    }
+    return messages
+  },
+}
+
+const agent = new Agent({
+  name: 'safe-agent',
+  instructions: 'You are a helpful assistant',
+  model: 'openai/gpt-4o',
+  memory: new Memory({ lastMessages: 10 }),
+  // Your guardrail runs BEFORE memory saves
+  outputProcessors: [contentBlocker],
+})
+
+// If the guardrail aborts, nothing is saved to memory
+const result = await agent.generate('Hello')
+if (result.tripwire) {
+  console.log('Blocked:', result.tripwire.reason)
+  // Memory is empty - no messages were persisted
+}
+```
+
+### Input guardrails
+
+Input guardrails run **after** memory processors load history. If a guardrail aborts:
+
+- The tripwire is triggered
+- The LLM is never called
+- Output processors (including memory persistence) are skipped
+- **No messages are persisted to storage**
+
+```typescript
+// Input guardrail that validates user input
+const inputValidator = {
+  id: 'input-validator',
+  processInput: async ({ messages, abort }) => {
+    const lastUserMessage = messages.findLast(m => m.role === 'user')
+    if (isInvalidInput(lastUserMessage)) {
+      abort('Invalid input detected')
+    }
+    return messages
+  },
+}
+
+const agent = new Agent({
+  name: 'validated-agent',
+  instructions: 'You are a helpful assistant',
+  model: 'openai/gpt-4o',
+  memory: new Memory({ lastMessages: 10 }),
+  // Your guardrail runs AFTER memory loads history
+  inputProcessors: [inputValidator],
+})
+```
+
+### Summary
+
+| Guardrail Type | When it runs               | If it aborts                  |
+| -------------- | -------------------------- | ----------------------------- |
+| Input          | After memory loads history | LLM not called, nothing saved |
+| Output         | Before memory saves        | Nothing saved to storage      |
+
+Both scenarios are safe - guardrails prevent inappropriate content from being persisted to memory
+
+## Related documentation
+
+- [Processors](https://mastra.ai/docs/agents/processors) - General processor concepts and custom processor creation
+- [Guardrails](https://mastra.ai/docs/agents/guardrails) - Security and validation processors
+- [Memory Overview](https://mastra.ai/docs/memory/overview) - Memory types and configuration
+
+When creating custom processors avoid mutating the input `messages` array or its objects directly.