@mastra/mcp-docs-server 1.1.49-alpha.1 → 1.1.49-alpha.2

package/.docs/docs/harness/modes.md

@@ -0,0 +1,116 @@
+# Modes
+
+Modes define the different personalities or capability sets available within a Harness. Each mode layers its own instructions and tool overrides on top of a shared backing agent. The Harness ensures only one mode is active at a time and handles transitions between them.
+
+## When to use modes
+
+Use modes when a single conversational session needs to switch between distinct behaviors. For example, a planning mode that reasons about tasks and a build mode that executes them. Modes share the same thread and state, so the agent retains context across switches.
+
+## Quickstart
+
+Import the `Harness` class and create a new instance with your agent and modes:
+
+```typescript
+import { Harness } from '@mastra/core/harness'
+import { myAgent } from './agents'
+
+const harness = new Harness({
+  id: 'multi-mode',
+  agent: myAgent,
+  modes: [
+    {
+      id: 'plan',
+      name: 'Plan',
+      metadata: { default: true },
+      instructions: 'Reason about the task before making changes.',
+    },
+    { id: 'build', name: 'Build', instructions: 'Implement the approved plan.' },
+  ],
+})
+
+await harness.init()
+```
+
+## Defining modes
+
+Each mode requires an `id`. When a top-level `agent` is provided, modes layer instructions and tool overrides on the shared agent. Each mode can also specify a `defaultModelId` to bootstrap model selection:
+
+```typescript
+import { Harness } from '@mastra/core/harness'
+
+const harness = new Harness({
+  id: 'multi-mode',
+  agent: myAgent,
+  modes: [
+    {
+      id: 'plan',
+      name: 'Plan',
+      metadata: { default: true },
+      defaultModelId: 'anthropic/claude-sonnet-4-6',
+      instructions: 'Reason about the task before making changes.',
+    },
+    {
+      id: 'build',
+      name: 'Build',
+      defaultModelId: 'anthropic/claude-sonnet-4-6',
+      instructions: 'Implement the approved plan.',
+    },
+  ],
+})
+```
+
+### Mode tool overrides
+
+Modes support two strategies for tool configuration. Use `tools` to replace the backing agent's tools entirely, or `additionalTools` to layer extra tools on top:
+
+```typescript
+// Replace — agent sees only these tools in plan mode
+const planMode = { id: 'plan', tools: { planTool } }
+
+// Augment — agent keeps its own tools plus these
+const buildMode = { id: 'build', additionalTools: { deployTool } }
+```
+
+You can't set both `tools` and `additionalTools` on the same mode.
+
+### Mode transitions
+
+A mode can declare a `transitionsTo` target. When the `submit_plan` built-in tool runs in that mode, the Harness transitions to the target mode on approval:
+
+```typescript
+const planMode = {
+  id: 'plan',
+  name: 'Plan',
+  transitionsTo: 'build',
+  instructions: 'Reason about the task and submit a plan.',
+}
+```
+
+On plan approval, the Harness automatically switches to `build` mode. On rejection, the agent remains in `plan` mode to revise.
+
+## Switching modes
+
+Call `switchMode()` to change the active mode. The Harness aborts any in-progress generation, saves the current model to the outgoing mode, loads the incoming mode's model, and emits `mode_changed` and `model_changed` events:
+
+```typescript
+await harness.switchMode({ modeId: 'build' })
+```
+
+## Querying modes
+
+```typescript
+// List all configured modes
+const modes = harness.listModes()
+
+// Get the current mode ID
+const modeId = harness.session.mode.get()
+
+// Get the full mode object
+const mode = harness.session.mode.resolve()
+```
+
+## Related
+
+- [Harness overview](https://mastra.ai/docs/harness/overview)
+- [Threads and state](https://mastra.ai/docs/harness/threads-and-state)
+- [API reference](https://mastra.ai/reference/harness/harness-class)

package/.docs/docs/harness/overview.md

@@ -0,0 +1,129 @@
+# Harness overview
+
+> **Alpha:** The `Harness` feature is in alpha stage and subject to breaking changes in minor versions until it graduates from its alpha status.
+
+The Harness is a session controller for building interactive agent applications. It handles the runtime concerns that sit between your UI and the agent loop: managing conversation threads, switching between agent modes, persisting state, gating tool execution with approvals, and coordinating subagents. You can focus on what your agent does rather than how to wire it together.
+
+A Harness exposes a [`Session`](https://mastra.ai/docs/harness/session) — the per-conversation runtime state that tracks the active mode, model, thread binding, permission grants, follow-up queue, and token usage. The Harness is the shared host; the Session is the conversation running inside it. In a multi-user host, the same Harness can back many Sessions at once.
+
+[Mastra Code](https://code.mastra.ai/) is the flagship Harness implementation: A terminal-based coding agent with multi-model support, persistent conversations, and plan-then-execute workflows.
+
+## What you can build
+
+The Harness is designed for applications where a user has an ongoing, interactive session with one or more AI agents:
+
+| Application                    | How the Harness helps                                                                                                                                                                              |
+| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Coding agents** (TUI or IDE) | Plan mode reasons about changes, build mode executes them. Thread persistence resumes conversations across sessions. Tool approvals gate destructive operations like file writes.                  |
+| **Multi-step assistants**      | A research mode gathers information, a drafting mode produces output. Shared state tracks progress. Subagents handle focused subtasks (e.g., web search, code review).                             |
+| **Copilot UIs**                | Model switching lets users pick the right model for the job. Permission policies control which tools run automatically vs. requiring confirmation. Event subscriptions drive real-time UI updates. |
+| **Autonomous task runners**    | Background agents with structured task lists, heartbeat handlers for health checks, and observational memory for learning across threads.                                                          |
+
+## When to use the Harness
+
+Use the Harness when your application needs:
+
+- Multiple agent modes that share one conversation thread (e.g., plan → build → review)
+- A control layer between your UI and the agent loop (model switching, state persistence, thread management)
+- Tool approval flows and permission policies for human-in-the-loop gating
+- Subagent orchestration to delegate focused subtasks with constrained tools
+- Session continuity with persistent threads, state, and observational memory across restarts
+
+For single-shot agent calls or basic request-response patterns, use the [Agent class](https://mastra.ai/docs/agents/overview) directly. The Harness adds value when you need session state, mode switching, or interactive approval flows.
+
+## Key capabilities
+
+- **Session**: Per-conversation state — active thread, mode, model, grants, follow-ups, token usage, and the display snapshot — accessed through `harness.session`. See [Session](https://mastra.ai/docs/harness/session).
+- **Modes**: Define distinct agent personalities (instructions, tools, model) and switch between them without losing conversation context. See [Modes](https://mastra.ai/docs/harness/modes).
+- **Threads and state**: Persist conversations and structured state across sessions, users, and mode switches. See [Threads and state](https://mastra.ai/docs/harness/threads-and-state).
+- **Subagents**: Spawn focused child agents with constrained tools for subtasks, optionally forking the parent conversation. See [Subagents](https://mastra.ai/docs/harness/subagents).
+- **Tool approvals and permissions**: Configure which tools require user confirmation, grant session-wide exceptions, and handle interactive tool suspension. See [Tool approvals](https://mastra.ai/docs/harness/tool-approvals).
+- **Model management**: Switch models per-mode at runtime, track usage, and resolve gateway-backed models.
+- **Follow-ups and steering**: Queue messages while the agent is running, or inject mid-stream instructions to redirect the agent.
+- **Event system**: Subscribe to typed events (message updates, mode changes, tool approvals) or coalesced `HarnessDisplayState` snapshots to drive your UI.
+- **Observational memory**: Automatic summarization and reflection across threads for long-running agent sessions.
+
+## Quickstart
+
+Import the `Harness` class and create a new instance with an agent, storage backend, and modes:
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Harness } from '@mastra/core/harness'
+import { LibSQLStore } from '@mastra/libsql'
+
+const agent = new Agent({
+  name: 'assistant',
+  instructions: 'Help the user plan and complete tasks.',
+  model: 'openai/gpt-5.5',
+})
+
+const harness = new Harness({
+  id: 'my-agent',
+  agent,
+  storage: new LibSQLStore({ url: 'file:./data.db' }),
+  modes: [
+    {
+      id: 'plan',
+      name: 'Plan',
+      metadata: { default: true },
+      instructions: 'Reason about changes before making them.',
+    },
+    { id: 'build', name: 'Build', instructions: 'Implement the approved plan.' },
+  ],
+})
+
+harness.subscribe(event => {
+  if (event.type === 'message_update') {
+    console.log(event.message)
+  }
+})
+
+await harness.init()
+await harness.selectOrCreateThread()
+await harness.sendMessage({ content: 'Hello!' })
+```
+
+> **Note:** Visit the [Harness reference](https://mastra.ai/reference/harness/harness-class) for the full constructor parameters and method signatures.
+
+## Architecture
+
+The Harness sits between your application layer and the underlying agent loop:
+
+```text
+┌──────────────────────────┐
+│   Your App (TUI/Web/API) │
+└────────────┬─────────────┘
+             │ commands (sendMessage, switchMode, approve)
+             │ events (message_update, tool_approval_required)
+┌────────────▼─────────────┐
+│  Harness (shared host)   │
+│  Config · Storage        │
+│  Thread lifecycle        │
+│  Permission policy        │
+│  Subagent spawning        │
+│  Event bus               │
+│  ┌─────────────────────┐ │
+│  │ harness.session      │ │
+│  │ identity · thread    │ │
+│  │ mode · model · run   │ │
+│  │ grants · follow-ups  │ │
+│  │ display state        │ │
+│  └─────────────────────┘ │
+└────────────┬─────────────┘
+             │
+┌────────────▼──────────────┐
+│  Agent + Memory + Tools   │
+└───────────────────────────┘
+```
+
+Your app sends commands (send a message, switch mode, approve a tool call) and receives typed events. The Harness manages the lifecycle internally: persisting threads, routing to the correct mode agent, enforcing permissions, and emitting events as state changes.
+
+## Next steps
+
+- [Session](https://mastra.ai/docs/harness/session): The per-conversation state on a Harness
+- [Modes](https://mastra.ai/docs/harness/modes): Define and switch between agent personalities
+- [Threads and state](https://mastra.ai/docs/harness/threads-and-state): Manage persistent conversations
+- [Subagents](https://mastra.ai/docs/harness/subagents): Delegate focused subtasks
+- [Tool approvals and permissions](https://mastra.ai/docs/harness/tool-approvals): Human-in-the-loop gating
+- [API reference](https://mastra.ai/reference/harness/harness-class): Full constructor and method docs

package/.docs/docs/harness/session.md

@@ -0,0 +1,136 @@
+# Session
+
+A `Session` holds the per-conversation state of a Harness: who the conversation is for, which thread is active, the selected mode and model, permission grants, queued follow-ups, token usage, application state, and the display snapshot. You reach it through `harness.session`.
+
+## Harness vs. Session
+
+The Harness is the shared host. It owns the machinery that doesn't change from one conversation to the next: configuration, storage, the agent registry, the thread lock, the event bus, and permission _policy_. The Session is the per-conversation state that sits on top of that machinery.
+
+A useful way to remember the split: the **Harness** is the application, and the **Session** is the current conversation running inside it. Operations that mutate shared infrastructure or coordinate the event bus stay on the Harness; everything that describes "this conversation right now" lives on the Session.
+
+| Lives on the Harness (shared host)                                                              | Lives on the Session (per-conversation)                                                                     |
+| ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
+| Configuration, storage, and memory                                                              | Resource ID and active thread binding ([`session.identity`](#identity), [`session.thread`](#thread))        |
+| Thread lifecycle: `createThread`, `switchThread`, `cloneThread`, `renameThread`, `deleteThread` | Thread and message reads ([`session.thread.list()`](#thread))                                               |
+| The event bus (`subscribe`, event emission)                                                     | Selected mode and model ([`session.mode`](#mode-and-model), [`session.model`](#mode-and-model))             |
+| Permission _policy_ (`setPermissionForCategory`, `getToolCategory`)                             | Permission _grants_ ([`session.grantCategory`](#permission-grants))                                         |
+| Mode and model _definitions_ (`config.modes`)                                                   | Run state, abort, follow-ups, suspensions ([`session.run`](#run-state), [`session.followUps`](#follow-ups)) |
+| The `stateSchema` definition                                                                    | Application state and its updates ([`session.state`](#state))                                               |
+| The shared agent loop and subagent spawning                                                     | Token usage and the display snapshot ([`session.displayState`](#display-state))                             |
+
+This is why thread _creation_ is `harness.createThread()` (it acquires the shared lock and emits an event) while thread _reads_ are `harness.session.thread.list()` (they describe the current conversation's view).
+
+In single-player apps there is one Harness and one Session, so the split is mostly organizational. In a multi-user host, the same Harness can serve many conversations — each backed by its own Session — without one conversation's mode, grants, or active thread leaking into another.
+
+## Identity
+
+`session.identity` holds the resource ID the conversation belongs to and the currently bound thread ID. Threads are scoped to a resource ID, so this is what groups a conversation's threads together:
+
+```typescript
+const resourceId = harness.session.identity.getResourceId()
+const threadId = harness.session.thread.getId()
+```
+
+To change the resource a conversation operates under, use `harness.setResourceId()` — it lives on the Harness because it also clears the active thread and releases the shared lock.
+
+## Thread
+
+`session.thread` owns the active thread binding and read access to threads and messages. The Harness performs lifecycle transitions; the Session reads the result:
+
+```typescript
+// Lifecycle transitions live on the Harness
+await harness.switchThread({ threadId: 'thread-abc123' })
+
+// Reads live on the Session
+const threads = await harness.session.thread.list()
+const messages = await harness.session.thread.listActiveMessages()
+```
+
+See [Threads and state](https://mastra.ai/docs/harness/threads-and-state) for the full lifecycle.
+
+## Mode and model
+
+The Harness defines the available modes in `config.modes`. The Session tracks which mode and model are _currently_ selected:
+
+```typescript
+// Switch mode (Harness orchestration — aborts the run, emits events)
+await harness.switchMode({ modeId: 'build' })
+
+// Read the current selection (Session state)
+const modeId = harness.session.mode.get()
+const mode = harness.session.mode.resolve()
+const modelId = harness.session.model.get()
+```
+
+See [Modes](https://mastra.ai/docs/harness/modes) for how modes carry their own model.
+
+## Permission grants
+
+The Harness owns permission _policy_ — which categories or tools require approval. The Session owns the _grants_ a user makes during the conversation. A grant lets a tool run for the rest of the session without prompting again:
+
+```typescript
+// Grant a category or tool for the rest of the session
+harness.session.grantCategory('edit')
+harness.session.grantTool('mastra_workspace_execute_command')
+
+// Inspect current grants
+const grants = harness.session.getGrants()
+```
+
+Grants are intentionally in-memory and reset when the session restarts. See [Tool approvals](https://mastra.ai/docs/harness/tool-approvals) for the approval flow.
+
+## Run state
+
+`session.run` tracks the in-flight generation: whether a run is active, its run and trace IDs, and the abort signal. Use it to reflect run status in your UI:
+
+```typescript
+if (harness.session.run.isRunning()) {
+  // show a stop button
+}
+
+// Abort the active run (Harness orchestration clears related state)
+harness.abort()
+```
+
+## Follow-ups
+
+While a run is in progress, queued follow-up messages live on `session.followUps`. They are sent when the current run finishes:
+
+```typescript
+const queued = harness.session.followUps.count()
+```
+
+## State
+
+`session.state` holds the conversation's application state — structured values that agents and the UI share, such as model preferences, feature flags, or progress. The Harness defines the shape with a `stateSchema`; the Session owns the live snapshot, validates updates against the schema, and emits `state_changed` on every write:
+
+```typescript
+const state = harness.session.state.get()
+await harness.session.state.set({ theme: 'light' })
+```
+
+See [Threads and state](https://mastra.ai/docs/harness/threads-and-state) for defining a schema.
+
+## Display state
+
+`session.displayState` is the coalesced `HarnessDisplayState` snapshot — the single object a UI renders from. It folds run status, streaming messages, active tools, tasks, token usage, and pending approvals into one place:
+
+```typescript
+const snapshot = harness.session.displayState.get()
+
+// React to changes
+harness.subscribe(event => {
+  if (event.type === 'display_state_changed') {
+    render(harness.session.displayState.get())
+  }
+})
+```
+
+> **Note:** Visit the [Session reference](https://mastra.ai/reference/harness/session) for the full list of sub-objects and method signatures.
+
+## Related
+
+- [Harness overview](https://mastra.ai/docs/harness/overview)
+- [Threads and state](https://mastra.ai/docs/harness/threads-and-state)
+- [Tool approvals](https://mastra.ai/docs/harness/tool-approvals)
+- [Session reference](https://mastra.ai/reference/harness/session)

package/.docs/docs/harness/subagents.md

@@ -0,0 +1,109 @@
+# Subagents
+
+Subagents let a parent agent delegate focused tasks to child agents with constrained tools and instructions. The Harness auto-generates a `subagent` built-in tool that the parent model can call to spawn any configured subagent type.
+
+## When to use subagents
+
+Use subagents when:
+
+- A task needs a different toolset or instruction set than the parent agent
+- You want to isolate a subtask's messages from the parent thread
+- The parent agent needs to delegate to a cheaper or faster model for specific work
+
+## Quickstart
+
+Define subagent types in the Harness constructor:
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Harness } from '@mastra/core/harness'
+
+const agent = new Agent({
+  name: 'assistant',
+  instructions: 'Use subagents when a focused task needs a narrower toolset.',
+  model: 'openai/gpt-5.5',
+})
+
+const harness = new Harness({
+  id: 'with-subagents',
+  agent,
+  modes: [{ id: 'default', name: 'Default', metadata: { default: true } }],
+  subagents: [
+    {
+      id: 'explore',
+      name: 'Explore',
+      description: 'Reads files and gathers context without making changes.',
+      instructions: 'You are a read-only exploration agent.',
+      allowedWorkspaceTools: ['read_file', 'list_directory', 'grep_search'],
+      defaultModelId: 'anthropic/claude-haiku-4-5',
+      maxSteps: 30,
+    },
+    {
+      id: 'execute',
+      name: 'Execute',
+      description: 'Makes changes to files and runs commands.',
+      instructions: 'You are an execution agent.',
+      allowedWorkspaceTools: ['read_file', 'write_file', 'execute_command'],
+      defaultModelId: 'anthropic/claude-sonnet-4-6',
+    },
+  ],
+})
+```
+
+The parent agent can then call the auto-generated `subagent` tool with a `task` description and optional `agentType`.
+
+For the full list of subagent configuration options, see [`Harness` reference](https://mastra.ai/reference/harness/harness-class).
+
+## Forked subagents
+
+By default, a subagent runs with a fresh context and doesn't see the parent conversation. **Forked subagents** run on a clone of the parent thread and reuse the parent agent's configuration. This preserves prompt-cache prefixes and gives the subagent full conversation context.
+
+Enable forked mode per-type:
+
+```typescript
+const collaborator = {
+  id: 'collaborator',
+  name: 'Collaborator',
+  description: 'Continues the conversation in a fork.',
+  instructions: '...', // Ignored in forked mode
+  forked: true,
+}
+```
+
+Or per-invocation via the `subagent` tool's `forked` input parameter.
+
+### Forked mode semantics
+
+- Memory must be configured on the Harness (forking clones the thread)
+- The parent agent's instructions, tools, model, and `maxSteps` apply
+- The subagent definition's own `instructions`, `tools`, and `defaultModelId` are ignored
+- Fork threads are tagged with `metadata.forkedSubagent === true` and hidden from `session.thread.list()` by default
+- Recursive forks are blocked at runtime to prevent infinite nesting
+
+### When to prefer non-forked mode
+
+Use non-forked subagents when the child needs a strictly smaller toolset, a different system prompt, or a cheaper model. Pass any required context explicitly in the `task` description.
+
+## Subagent model management
+
+Set a global or per-type subagent model at runtime:
+
+```typescript
+// Global subagent model
+await harness.setSubagentModelId({ modelId: 'anthropic/claude-sonnet-4-6' })
+
+// Per-type override
+await harness.setSubagentModelId({
+  modelId: 'anthropic/claude-haiku-4-5',
+  agentType: 'explore',
+})
+
+// Read current model
+const modelId = harness.getSubagentModelId({ agentType: 'explore' })
+```
+
+## Related
+
+- [Harness overview](https://mastra.ai/docs/harness/overview)
+- [Tool approvals and permissions](https://mastra.ai/docs/harness/tool-approvals)
+- [API reference](https://mastra.ai/reference/harness/harness-class)

package/.docs/docs/harness/threads-and-state.md

@@ -0,0 +1,134 @@
+# Threads and state
+
+The Harness manages conversation threads and shared state that persist across mode switches, model changes, and sessions. Threads hold messages while state holds structured data that agents and the UI can read and write.
+
+Thread _lifecycle_ transitions (create, switch, clone, delete) live on the Harness because they coordinate the shared thread lock and emit events. The active thread binding and thread/message _reads_ live on the [`Session`](https://mastra.ai/docs/harness/session) as `harness.session.thread`.
+
+## When to use threads and state
+
+Use threads when your application needs persistent conversation history, multi-session continuity, or when users switch between threads. Use state for structured values (model preferences, feature flags, UI settings) that agents and the UI layer share.
+
+## Threads
+
+### Creating and selecting threads
+
+On startup, call `selectOrCreateThread()` to resume the most recent thread or create a new one:
+
+```typescript
+await harness.init()
+const thread = await harness.selectOrCreateThread()
+```
+
+Create a thread explicitly with a title:
+
+```typescript
+const thread = await harness.createThread({ title: 'New conversation' })
+```
+
+### Switching threads
+
+Switch to an existing thread. The harness aborts any in-progress generation, acquires a lock on the new thread, and emits a `thread_changed` event:
+
+```typescript
+await harness.switchThread({ threadId: 'thread-abc123' })
+```
+
+### Listing threads
+
+List threads for the current resource. Forked subagent threads are hidden by default:
+
+```typescript
+const threads = await harness.session.thread.list()
+
+// Include all resources
+const allThreads = await harness.session.thread.list({ allResources: true })
+```
+
+### Cloning threads
+
+Clone a thread to create a branch of the conversation. The harness copies all messages and switches to the clone:
+
+```typescript
+const cloned = await harness.cloneThread({ title: 'Alternative approach' })
+```
+
+### Thread locking
+
+Pass a `threadLock` to the Harness constructor to prevent concurrent access from multiple processes. The lock is acquired before any thread operation and released on switch or delete:
+
+```typescript
+const harness = new Harness({
+  id: 'my-agent',
+  threadLock: {
+    acquire: async threadId => {
+      /* acquire lock or throw */
+    },
+    release: async threadId => {
+      /* release lock */
+    },
+  },
+})
+```
+
+## State
+
+### Defining a state schema
+
+Pass a `stateSchema` (Standard JSON Schema) to validate state and extract defaults:
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Harness } from '@mastra/core/harness'
+import { z } from 'zod'
+
+const agent = new Agent({
+  name: 'assistant',
+  instructions: 'Help the user manage a stateful session.',
+  model: 'openai/gpt-5.5',
+})
+
+const harness = new Harness({
+  id: 'stateful-agent',
+  agent,
+  modes: [{ id: 'default', name: 'Default', metadata: { default: true } }],
+  stateSchema: z.object({
+    currentModelId: z.string().optional(),
+    theme: z.enum(['light', 'dark']).default('dark'),
+  }),
+})
+```
+
+### Reading and writing state
+
+State is owned by the [`Session`](https://mastra.ai/docs/harness/session) as `harness.session.state`:
+
+```typescript
+// Read the current state snapshot
+const state = harness.session.state.get()
+
+// Update state — validates against schema and emits state_changed
+await harness.session.state.set({ theme: 'light' })
+```
+
+State changes emit a `state_changed` event with the new state and the set of changed keys.
+
+## Resource IDs
+
+Threads are scoped to a resource ID. The resource ID defaults to the harness `id` but can be set explicitly to group threads by project, user, or workspace:
+
+```typescript
+const harness = new Harness({
+  id: 'my-agent',
+  resourceId: 'project-xyz',
+})
+
+// Change resource ID at runtime (clears the current thread)
+harness.setResourceId({ resourceId: 'project-abc' })
+```
+
+## Related
+
+- [Harness overview](https://mastra.ai/docs/harness/overview)
+- [Session](https://mastra.ai/docs/harness/session)
+- [Modes](https://mastra.ai/docs/harness/modes)
+- [API reference](https://mastra.ai/reference/harness/harness-class)