Mastra class
The Mastra class is the central orchestrator in any Mastra application, managing agents, workflows, storage, logging, observability, and more. Typically, you create a single instance of Mastra to coordinate your application.
Think of Mastra as a top-level registry where you register agents, workflows, tools, and other components that need to be accessible throughout your application.
Usage exampleDirect link to Usage example
import { Mastra } from '@mastra/core'
import { PinoLogger } from '@mastra/loggers'
import { LibSQLStore } from '@mastra/libsql'
import { weatherWorkflow } from './workflows/weather-workflow'
import { weatherAgent } from './agents/weather-agent'
export const mastra = new Mastra({
workflows: { weatherWorkflow },
agents: { weatherAgent },
storage: new LibSQLStore({
id: 'mastra-storage',
url: ':memory:',
}),
logger: new PinoLogger({
name: 'Mastra',
level: 'info',
}),
})
Enable scheduled notification dispatch when deferred notification records and notification summaries should be delivered automatically through the workflow scheduler:
export const mastra = new Mastra({
agents: { supportAgent },
storage,
notifications: {
dispatch: {
enabled: true,
cron: '*/1 * * * *',
batchSize: 100,
},
},
})
notifications.dispatch.enabled allows an internal dispatcher workflow to run with the default cron */1 * * * *. The dispatcher reads due notification records from storage, groups summaries by agentId, resourceId, and threadId, and emits signals through the agent thread runtime. It isn't a user-facing entrypoint. The dispatch schedule (and the workflow scheduler backing it) activates lazily on the first deferred or summarized notification, so apps that never defer notifications don't run a scheduler at all.
Constructor parametersDirect link to Constructor parameters
Visit the Configuration reference for detailed documentation on all available configuration options.
agents?:
tools?:
storage?:
vectors?:
logger?:
idGenerator?:
workflows?:
tts?:
observability?:
environment?:
production, staging, development). When set, automatically attached to all observability signals so they can be filtered by environment without passing tracingOptions.metadata.environment on each call. Falls back to process.env.NODE_ENV when unset; left undefined if neither is set. Per-call tracingOptions.metadata.environment always takes precedence.deployer?:
server?:
mcpServers?:
bundler?:
scorers?:
processors?:
gateways?:
memory?:
notifications?:
dispatch?:
enabled?:
false to opt out of automatic scheduled notification dispatch.cron?:
batchSize?:
versions?:
agents?:
versionId?:
status?:
workers?:
false to disable all event processing (useful when running standalone workers separately). Pass a MastraWorker[] to add custom workers — they are merged with the auto-created defaults, and a custom worker with the same name as a default replaces it.backgroundTasks?:
enabled?:
globalConcurrency?:
perAgentConcurrency?:
backpressure?:
defaultTimeoutMs?:
defaultRetries?:
scheduler?:
schedule. See Scheduled workflows.enabled?:
recovery?:
durableAgents?:
'auto' to automatically re-drive orphaned RUNNING durable agent runs on server boot. Recovery re-issues LLM calls and re-executes tool calls, so tools must be idempotent. See Crash recovery.MethodsDirect link to Methods
recoverAllDurableAgents()Direct link to recoveralldurableagents
Re-drives every orphaned running durable-agent run across all registered durable agents. Called automatically on boot when recovery.durableAgents is 'auto'. You can also call it directly for manual recovery or from a scheduled task.
Requires persistent storage. With an in-memory store, there's nothing to recover after a process restart.
const result = await mastra.recoverAllDurableAgents()
// { agents: 2, recovered: 3, succeeded: 3, failed: 0 }
Returns: