@mastra/core 1.2.1-alpha.0 → 1.3.0-alpha.2

package/dist/docs/references/docs-agents-agent-memory.md

@@ -2,7 +2,7 @@
 
 Agents use memory to maintain context across interactions. LLMs are stateless and don't retain information between calls, so agents need memory to track message history and recall relevant information.
 
-Mastra agents can be configured to store message history, with optional [working memory](https://mastra.ai/docs/memory/working-memory) to maintain recent context or [semantic recall](https://mastra.ai/docs/memory/semantic-recall) to retrieve past messages based on meaning.
+Mastra agents can be configured to store message history, with optional [working memory](https://mastra.ai/docs/memory/working-memory) to maintain recent context, [semantic recall](https://mastra.ai/docs/memory/semantic-recall) to retrieve past messages based on meaning, or [observational memory](https://mastra.ai/docs/memory/observational-memory) for automatic long-term memory that compresses conversations as they grow.
 
 ## When to use memory
 
@@ -134,6 +134,49 @@ const response = await memoryAgent.generate("What's my favorite color?", {
 
 To learn more about memory see the [Memory](https://mastra.ai/docs/memory/overview) documentation.
 
+## 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,
+    },
+  }),
+});
+```
+
+Setting `observationalMemory: true` uses `google/gemini-2.5-flash` as the default model for the Observer and Reflector. To use a different model or customize thresholds, pass a config object:
+
+```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: {
+        model: "deepseek/deepseek-reasoner",
+        observation: {
+          messageTokens: 20_000,
+        },
+      },
+    },
+  }),
+});
+```
+
+> **Info:** 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.
+
 ## Using `RequestContext`
 
 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.
@@ -162,6 +205,7 @@ export const memoryAgent = new Agent({
 
 ## Related
 
+- [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)
 - [Storage](https://mastra.ai/docs/memory/storage)

package/dist/docs/references/docs-agents-network-approval.md

@@ -1,6 +1,6 @@
 # Network Approval
 
-Agent networks can require the same [human-in-the-loop](https://mastra.ai/docs/workflows/human-in-the-loop) oversight used in individual agents and workflows. When a tool, sub-agent, or workflow within a network requires approval or suspends execution, the network pauses and emits events that allow your application to collect user input before resuming.
+Agent networks can require the same [human-in-the-loop](https://mastra.ai/docs/workflows/human-in-the-loop) oversight used in individual agents and workflows. When a tool, subagent, or workflow within a network requires approval or suspends execution, the network pauses and emits events that allow your application to collect user input before resuming.
 
 ## Storage
 

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

@@ -1,6 +1,6 @@
 # Agent Networks
 
-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 (sub-agents, workflows, or tools) to call, in what order, and with what data.
+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
 
@@ -16,7 +16,7 @@ Mastra agent networks operate using these principles:
 
 ## Creating an agent network
 
-An agent network is built around a top-level routing agent that delegates tasks to agents, 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.
+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";
@@ -64,7 +64,7 @@ When configuring a Mastra agent network, each primitive (agent, workflow, or too
 
 #### Agent descriptions
 
-Each agent in a network should include a clear `description` that explains what the agent does.
+Each subagent in a network should include a clear `description` that explains what the agent does.
 
 ```typescript
 export const researchAgent = new Agent({

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

@@ -119,6 +119,14 @@ export const mastra = new Mastra({
 });
 ```
 
+### Registering subagents
+
+You can register subagents within an agent. They'll be executed as tools from the parent agent. Read the [using agents as tools](https://mastra.ai/docs/agents/using-tools) documentation to learn more.
+
+### Registering subworkflows
+
+You can register subworkflows within an agent. They'll be executed as tools from the parent agent. Read the [using workflows as tools](https://mastra.ai/docs/agents/using-tools) documentation to learn more.
+
 ## Referencing an agent
 
 You can call agents from workflow steps, tools, the Mastra Client, or the command line. Get a reference by calling `.getAgent()` on your `mastra` or `mastraClient` instance, depending on your setup:

package/dist/docs/references/docs-agents-using-tools.md

@@ -57,84 +57,49 @@ export const weatherAgent = new Agent({
 });
 ```
 
-## Controlling `toolName` in stream responses
+## Using multiple tools
 
-The `toolName` in stream responses is determined by the **object key** you use, not the `id` property of the tool, agent, or workflow.
+When multiple tools are available, the agent may choose to use one, several, or none, depending on what's needed to answer the query.
 
 ```typescript
-// Tool defined with id: "weather-tool"
-export const weatherTool = createTool({
-  id: "weather-tool",
-  // ...
-});
-
-// Using the variable name as the key
-tools: { weatherTool }
-// Stream returns: toolName: "weatherTool"
-
-// Using the tool's id as the key
-tools: { [weatherTool.id]: weatherTool }
-// Stream returns: toolName: "weather-tool"
+import { weatherTool } from "../tools/weather-tool";
+import { activitiesTool } from "../tools/activities-tool";
 
-// Using a custom key
-tools: { "my-custom-name": weatherTool }
-// Stream returns: toolName: "my-custom-name"
+export const weatherAgent = new Agent({
+  id: "weather-agent",
+  name: "Weather Agent",
+  tools: { weatherTool, activitiesTool },
+});
 ```
 
-This lets you specify how tools are identified in the stream. If you want the `toolName` to match the tool's `id`, use the tool's `id` as the object key.
-
-### Sub-agents and workflows as tools
-
-Sub-agents and workflows follow the same pattern. They are converted to tools with a prefix followed by your object key:
+## Using agents as tools
 
-| Property    | Prefix      | Example key | `toolName`          |
-| ----------- | ----------- | ----------- | ------------------- |
-| `agents`    | `agent-`    | `weather`   | `agent-weather`     |
-| `workflows` | `workflow-` | `research`  | `workflow-research` |
+Agents can be added to other agents through the `agents` configuration. When you add a subagent, Mastra automatically converts it to a tool that the parent agent can call. The generated tool is named `agent-<agentName>`.
 
 ```typescript
-const orchestrator = new Agent({
-  // ...
+import { Agent } from "@mastra/core/agent";
+
+export const parentAgent = new Agent({
+  id: "parent-agent",
+  name: "Parent Agent",
+  description: "Take care in writing a good description here",
+  instructions: `Instructions`,
+  model: "openai/gpt-5.1",
   agents: {
-    weather: weatherAgent,  // toolName: "agent-weather"
-  },
-  workflows: {
-    research: researchWorkflow,  // toolName: "workflow-research"
+    subAgent,
   },
 });
-```
-
-Note that for sub-agents, you'll see two different identifiers in stream responses:
 
-- `toolName: "agent-weather"` in tool call events — the generated tool wrapper name
-- `id: "weather-agent"` in `data-tool-agent` chunks — the sub-agent's actual `id` property
-
-## Calling an agent
-
-The agent uses the tool's `inputSchema` to infer what data the tool expects. In this case, it extracts `London` as the `location` from the message and passes it to the tool's inputData parameter.
-
-```typescript
-import { mastra } from "./mastra";
-
-const agent = mastra.getAgent("weatherAgent");
-
-const result = await agent.generate("What's the weather in London?");
+const subAgent = new Agent({
+  id: "sub-agent",
+  name: "Sub Agent",
+  description: "Take care in writing a good description here",
+  instructions: `Instructions`,
+  model: "openai/gpt-5.1",
+})
 ```
 
-## Using multiple tools
-
-When multiple tools are available, the agent may choose to use one, several, or none, depending on what's needed to answer the query.
-
-```typescript
-import { weatherTool } from "../tools/weather-tool";
-import { activitiesTool } from "../tools/activities-tool";
-
-export const weatherAgent = new Agent({
-  id: "weather-agent",
-  name: "Weather Agent",
-  tools: { weatherTool, activitiesTool },
-});
-```
+The subagent should include a `description` to help the parent agent understand when to use it. See the [`toolName` docs](#subagents-and-workflows-as-tools) to learn more about the tool naming scheme.
 
 ## Using workflows as tools
 
@@ -169,16 +134,8 @@ import { z } from "zod";
 export const researchWorkflow = createWorkflow({
   id: "research-workflow",
   description: "Gathers information on a topic and compiles a summary report.",
-  inputSchema: z.object({
-    topic: z.string(),
-  }),
-  outputSchema: z.object({
-    summary: z.string(),
-    sources: z.array(z.string()),
-  }),
+  // Rest of the workflow...
 })
-  .then(gatherSourcesStep)
-  .then(compileReportStep)
   .commit();
 ```
 
@@ -191,6 +148,59 @@ When the agent calls the workflow tool, it receives a response containing the wo
 }
 ```
 
+See the [`toolName` docs](#subagents-and-workflows-as-tools) to learn more about the tool naming scheme.
+
+## Controlling `toolName` in stream responses
+
+The `toolName` in stream responses is determined by the **object key** you use, not the `id` property of the tool, agent, or workflow.
+
+```typescript
+// Tool defined with id: "weather-tool"
+export const weatherTool = createTool({
+  id: "weather-tool",
+  // ...
+});
+
+// Using the variable name as the key
+tools: { weatherTool }
+// Stream returns: toolName: "weatherTool"
+
+// Using the tool's id as the key
+tools: { [weatherTool.id]: weatherTool }
+// Stream returns: toolName: "weather-tool"
+
+// Using a custom key
+tools: { "my-custom-name": weatherTool }
+// Stream returns: toolName: "my-custom-name"
+```
+
+This lets you specify how tools are identified in the stream. If you want the `toolName` to match the tool's `id`, use the tool's `id` as the object key.
+
+### Subagents and workflows as tools
+
+Subagents and workflows follow the same pattern. They are converted to tools with a prefix followed by your object key:
+
+| Property    | Prefix      | Example key | `toolName`          |
+| ----------- | ----------- | ----------- | ------------------- |
+| `agents`    | `agent-`    | `weather`   | `agent-weather`     |
+| `workflows` | `workflow-` | `research`  | `workflow-research` |
+
+```typescript
+const orchestrator = new Agent({
+  agents: {
+    weather: weatherAgent,  // toolName: "agent-weather"
+  },
+  workflows: {
+    research: researchWorkflow,  // toolName: "workflow-research"
+  },
+});
+```
+
+Note that for subagents, you'll see two different identifiers in stream responses:
+
+- `toolName: "agent-weather"` in tool call events — the generated tool wrapper name
+- `id: "weather-agent"` in `data-tool-agent` chunks — the subagent's actual `id` property
+
 ## Tools with structured output
 
 When using tools with [structured output](https://mastra.ai/docs/agents/structured-output), some models don't support combining both features in the same API call. If your tools aren't being called when structured output is enabled, or you receive errors about incompatible options, see [Combining tools and structured output](https://mastra.ai/docs/agents/structured-output) for model compatibility information and workarounds.

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

@@ -1,9 +1,13 @@
 # Observational Memory
 
+**Added in:** `@mastra/memory@1.1.0`
+
 Observational Memory (OM) is Mastra's memory system for long-context agentic memory. Two background agents — an **Observer** and a **Reflector** — watch your agent's conversations and maintain a dense observation log that replaces raw message history as it grows.
 
 ## Quick Start
 
+Enable `observationalMemory` in the memory options when creating your agent:
+
 ```typescript
 import { Memory } from "@mastra/memory";
 import { Agent } from "@mastra/core/agent";
@@ -65,9 +69,9 @@ When observations exceed their threshold (default: 40,000 tokens), the Reflector
 
 The result is a three-tier system:
 
-1. **Recent messages** — exact conversation history for the current task
-2. **Observations** — a log of what the Observer has seen
-3. **Reflections** — condensed observations when memory becomes too long
+1. **Recent messages**: Exact conversation history for the current task
+2. **Observations**: A log of what the Observer has seen
+3. **Reflections**: Condensed observations when memory becomes too long
 
 ## Models
 
@@ -149,10 +153,9 @@ Mastra Studio shows OM status in real time in the memory tab: token usage, which
 
 ## Comparing OM with other memory features
 
-- **[Message history](https://mastra.ai/docs/memory/message-history)** — high-fidelity record of the current conversation
-- **[Working memory](https://mastra.ai/docs/memory/working-memory)** — small, structured state (JSON or markdown) for user preferences, names, goals
-- **[Semantic Recall](https://mastra.ai/docs/memory/semantic-recall)** — RAG-based retrieval of relevant past messages
-- **Observational Memory** — long-context agentic memory that compresses extended sessions
+- **[Message history](https://mastra.ai/docs/memory/message-history)**: High-fidelity record of the current conversation
+- **[Working memory](https://mastra.ai/docs/memory/working-memory)**: Small, structured state (JSON or markdown) for user preferences, names, goals
+- **[Semantic Recall](https://mastra.ai/docs/memory/semantic-recall)**: RAG-based retrieval of relevant past messages
 
 If you're using working memory to store conversation summaries or ongoing state that grows over time, OM is a better fit. Working memory is for small, structured data; OM is for long-running event logs. OM also manages message history automatically—the `messageTokens` setting controls how much raw history remains before observation runs.
 
@@ -160,7 +163,7 @@ In practical terms, OM replaces both working memory and message history, and has
 
 ## Related
 
-- [Observational Memory Reference](https://mastra.ai/reference/memory/observational-memory) — configuration options and API
+- [Observational Memory Reference](https://mastra.ai/reference/memory/observational-memory)
 - [Memory Overview](https://mastra.ai/docs/memory/overview)
 - [Message History](https://mastra.ai/docs/memory/message-history)
 - [Memory Processors](https://mastra.ai/docs/memory/memory-processors)

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

@@ -57,7 +57,7 @@ export const mastra = new Mastra({
 });
 ```
 
-> **Serverless environments:** The `file:./mastra.db` storage URL uses the local filesystem, which doesn't work in serverless environments like Vercel, AWS Lambda, or Cloudflare Workers. For serverless deployments, use external storage. See the [Vercel deployment guide](https://mastra.ai/guides/deployment/vercel-deployer) for a complete example.
+> **Serverless environments:** The `file:./mastra.db` storage URL uses the local filesystem, which doesn't work in serverless environments like Vercel, AWS Lambda, or Cloudflare Workers. For serverless deployments, use external storage. See the [Vercel deployment guide](https://mastra.ai/guides/deployment/vercel) for a complete example.
 
 With this basic setup, you will see Traces and Logs in both Studio and in Mastra Cloud.
 

package/dist/docs/references/docs-observability-tracing-exporters-langsmith.md

@@ -126,6 +126,76 @@ new LangSmithExporter({
 
 The `projectName` config option takes precedence over the `LANGCHAIN_PROJECT` environment variable, allowing you to programmatically route traces to different projects.
 
+## Dynamic Configuration
+
+You can dynamically override LangSmith settings per-span using `withLangsmithMetadata`. This is useful for routing traces to different projects based on runtime conditions (e.g., customer, environment, or feature).
+
+### Using the Helper
+
+Use `withLangsmithMetadata` with `buildTracingOptions` to set LangSmith-specific options:
+
+```typescript
+import { Agent } from "@mastra/core/agent";
+import { buildTracingOptions } from "@mastra/observability";
+import { withLangsmithMetadata } from "@mastra/langsmith";
+
+export const supportAgent = new Agent({
+  id: "support-agent",
+  name: "support-agent",
+  instructions: "You are a helpful support agent.",
+  model: "openai/gpt-4o",
+  defaultOptions: {
+    tracingOptions: buildTracingOptions(
+      withLangsmithMetadata({ projectName: "customer-support" }),
+    ),
+  },
+});
+```
+
+### Dynamic Project Routing
+
+Use `requestContext` to route traces to different projects based on runtime conditions.
+
+```typescript
+import { Agent } from "@mastra/core/agent";
+import { buildTracingOptions } from "@mastra/observability";
+import { withLangsmithMetadata } from "@mastra/langsmith";
+
+export const supportAgent = new Agent({
+  id: "support-agent",
+  name: "support-agent",
+  instructions: "You are a helpful support agent.",
+  model: "openai/gpt-4o",
+  defaultOptions: ({ requestContext }) => {
+    const userTier = requestContext?.get("user-tier") as string;
+    const userId = requestContext?.get("user-id") as string;
+
+    return {
+      tracingOptions: buildTracingOptions(
+        withLangsmithMetadata({
+          projectName: userTier === "enterprise"
+            ? "enterprise-traces"
+            : "standard-traces",
+          sessionId: userId,
+        }),
+      ),
+    };
+  },
+});
+```
+
+### Available Fields
+
+The `withLangsmithMetadata` helper accepts these fields:
+
+| Field         | Type   | Description                         |
+| ------------- | ------ | ----------------------------------- |
+| `projectName` | string | Override the project for this trace |
+| `sessionId`   | string | Group related traces by session     |
+| `sessionName` | string | Display name for the session        |
+
+All fields are optional. The helper merges with any existing metadata, so you can call it multiple times or combine with other tracing options.
+
 ## Related
 
 - [Tracing Overview](https://mastra.ai/docs/observability/tracing/overview)

package/dist/docs/references/docs-observability-tracing-overview.md

@@ -1023,7 +1023,7 @@ This creates a single distributed trace that includes both the HTTP request hand
 
 In serverless environments like Vercel's fluid compute, AWS Lambda, or Cloudflare Workers, runtime instances can be reused across multiple requests. The `flush()` method allows you to ensure all buffered spans are exported before the runtime terminates, without shutting down the exporter (which would prevent future exports).
 
-> **Storage requirements:** Serverless environments have ephemeral filesystems. Use external storage instead of local file storage (`file:./mastra.db`). See the [Vercel deployment guide](https://mastra.ai/guides/deployment/vercel-deployer) for a complete setup example.
+> **Storage requirements:** Serverless environments have ephemeral filesystems. Use external storage instead of local file storage (`file:./mastra.db`). See the [Vercel deployment guide](https://mastra.ai/guides/deployment/vercel) for a complete setup example.
 
 ### Using flush()
 

package/dist/docs/references/docs-server-middleware.md

@@ -50,8 +50,6 @@ registerApiRoute("/my-custom-route", {
 });
 ```
 
-***
-
 ## Common examples
 
 ### Using `RequestContext`

package/dist/docs/references/docs-server-request-context.md

@@ -453,6 +453,23 @@ requestContextSchema: z.object({
 
 **Handle tool validation errors**: Since tools return error objects instead of throwing, check for errors in your agent or workflow logic when tool execution is critical.
 
+## Testing with Studio presets
+
+When developing locally, you can define named presets in a JSON file and load them into Studio with the [`--request-context-presets`](https://mastra.ai/reference/cli/mastra) CLI flag. This adds a dropdown to the request context editor in Studio so you can quickly switch between configurations without manually editing JSON each time.
+
+```bash
+mastra dev --request-context-presets ./presets.json
+```
+
+```json
+{
+  "development": { "userId": "dev-user", "env": "development" },
+  "production": { "userId": "prod-user", "env": "production" }
+}
+```
+
+When you select a preset from the dropdown, the JSON editor populates with that preset's values. Editing the JSON manually switches the dropdown back to "Custom".
+
 ## Related
 
 - [Agent Request Context](https://mastra.ai/docs/agents/overview)

package/dist/docs/references/docs-workflows-agents-and-tools.md

@@ -57,7 +57,7 @@ export const testWorkflow = createWorkflow({
   .commit();
 ```
 
-> **Info:** Visit [Input Data Mapping](https://mastra.ai/docs/workflows/input-data-mapping) for more information.
+> **Info:** Visit [Input Data Mapping](https://mastra.ai/docs/workflows/control-flow) for more information.
 
 When no `structuredOutput` option is provided, Mastra agents use a default schema that expects a `prompt` string as input and returns a `text` string as output:
 
@@ -162,7 +162,7 @@ export const testWorkflow = createWorkflow({})
   .commit();
 ```
 
-> **Info:** Visit [Input Data Mapping](https://mastra.ai/docs/workflows/input-data-mapping) for more information.
+> **Info:** Visit [Input Data Mapping](https://mastra.ai/docs/workflows/control-flow) for more information.
 
 ## Related
 

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

@@ -8,7 +8,7 @@ Workflows let you define complex sequences of tasks using clear, structured step
 
 Use workflows for tasks that are clearly defined upfront and involve multiple steps with a specific execution order. They give you fine-grained control over how data flows and transforms between steps, and which primitives are called at each stage.
 
-> **📹 Watch**: → An introduction to workflows, and how they compare to agents [YouTube (7 minutes)](https://youtu.be/0jg2g3sNvgw)
+> **Watch an introduction:** An introduction to workflows, and how they compare to agents [YouTube (7 minutes)](https://youtu.be/0jg2g3sNvgw)
 
 ## Core principles
 

package/dist/docs/references/docs-workspace-filesystem.md

@@ -1,5 +1,7 @@
 # Filesystem
 
+**Added in:** `@mastra/core@1.1.0`
+
 Filesystem providers give agents the ability to read, write, and manage files. When you configure a filesystem on a workspace, agents receive tools for file operations.
 
 A filesystem provider handles all file operations for a workspace:

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

@@ -1,4 +1,6 @@
-# Workspace
+# Workspaces
+
+**Added in:** `@mastra/core@1.1.0`
 
 A Mastra workspace gives agents a persistent environment for storing files and executing commands. Agents use workspace tools to read and write files, run shell commands, and search indexed content.
 

package/dist/docs/references/docs-workspace-sandbox.md

@@ -1,5 +1,7 @@
 # Sandbox
 
+**Added in:** `@mastra/core@1.1.0`
+
 Sandbox providers give agents the ability to execute shell commands. When you configure a sandbox on a workspace, agents can run commands as part of their tasks.
 
 A sandbox provider executes commands in a controlled environment:

package/dist/docs/references/docs-workspace-search.md

@@ -1,5 +1,7 @@
 # Search and Indexing
 
+**Added in:** `@mastra/core@1.1.0`
+
 Search lets agents find relevant content in indexed workspace files. When an agent needs to answer a question or find information, it can search the indexed content instead of reading every file.
 
 ## How it works

package/dist/docs/references/docs-workspace-skills.md

@@ -1,4 +1,6 @@
-# Skills
+# Workspace Skills
+
+**Added in:** `@mastra/core@1.1.0`
 
 Skills are reusable instructions that teach agents how to perform specific tasks. They follow the [Agent Skills specification](https://agentskills.io) - an open standard for packaging agent capabilities.
 

package/dist/docs/references/reference-agents-getTools.md

@@ -26,9 +26,4 @@ await agent.getTools({
 
 ### Options parameters
 
-**requestContext?:** (`RequestContext`): Runtime context for dependency injection and contextual information. (Default: `new RequestContext()`)
-
-## Related
-
-- [Using tools with agents](https://mastra.ai/docs/agents/using-tools)
-- [MCP Overview](https://mastra.ai/docs/mcp/overview)
+**requestContext?:** (`RequestContext`): Runtime context for dependency injection and contextual information. (Default: `new RequestContext()`)

package/dist/docs/references/reference-agents-listAgents.md

@@ -1,6 +1,6 @@
 # Agent.listAgents()
 
-The `.listAgents()` method retrieves the sub-agents configured for an agent, resolving them if they're a function. These sub-agents enable the agent to access other agents and perform complex actions.
+The `.listAgents()` method retrieves the subagents configured for an agent, resolving them if they're a function. These subagents enable the agent to access other agents and perform complex actions.
 
 ## Usage example
 

package/dist/docs/references/reference-agents-network.md

@@ -1,7 +1,5 @@
 # Agent.network()
 
-> **Experimental Feature:** This is an experimental API that may change in future versions. The `network()` method enables multi-agent collaboration and workflow orchestration. Use with caution in production environments.
-
 The `.network()` method enables multi-agent collaboration and routing. This method accepts messages and optional execution options.
 
 ## Usage example