TypeScript agents and workflows
How to use
Mastra.
Building TypeScript agents for open-ended tasks and typed, resumable workflows for controlled multistep processes, with shared memory, tracing, and evaluation.
Mastra is a Open-source TypeScript framework for AI agents, typed tools, graph workflows, memory, retrieval, evaluation, and observability. Building TypeScript agents for open-ended tasks and typed, resumable workflows for controlled multistep processes, with shared memory, tracing, and evaluation. This guide covers the whole path in one place: official access, a first session that produces something reviewable, the checks that make output trustworthy, and the permissions worth limiting before you connect real work.
AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.
Access & setup
Find, install, and sign in to Mastra
Get into the official Mastra experience with the right account and a setup you understand.
- 01
Start at https://mastra.ai/ and confirm the domain before entering account or payment information.
- 02
Availability: Mastra is installed into a Node.js or TypeScript project and includes a local Studio for testing and inspection; it is not a standalone consumer desktop application.
- 03
A supported Node.js development environment, model-provider credentials, versioned source control, secure storage and secrets, approved tools and data, representative eval cases, and a deployment and observability plan.
- 04
Sign in with the account you intend to keep using, then review plan, data, notification, and permission settings.
- 05
Run one low-risk test task before connecting sensitive files, repositories, or workspace data.
- Use official download pages.
- Review permissions during setup.
- Keep installers and applications updated.
First session
Your first useful Mastra session
Learn the interaction loop using a small task with a clear outcome.
- 01
Define the user task, autonomy boundary, data class, model, tools, output schema, memory, workflow states, approvals, quality, safety, latency, cost, and rollback requirements.
- 02
Start with one narrowly scoped agent for open-ended reasoning or a deterministic workflow when steps and control flow are known, registering only the minimum typed tools.
- 03
Run locally in Studio with server-side secrets, representative and adversarial cases, bounded steps and tokens, observable tool calls, validated outputs, and no automatic consequential actions.
- 04
Review traces, eval scores, permissions, memory isolation, failures, resume behavior, latency, and cost, then pin dependencies, canary deployment, and retain a tested fallback.
- State the outcome before the background.
- Provide the real source material.
- Review the result before expanding the task.
Quality control
Check the quality of Mastra output
Establish that an autonomous run did the right thing, not merely that it finished.
- 01
Define what the run should achieve and what it must never touch before granting it a single tool.
- 02
Read the full execution trace: which tools were called, with what arguments, and in what order.
- 03
Verify the side effects directly in the target system rather than trusting the agent's own report of success.
- 04
Confirm failures surfaced as failures — a silent retry loop or a swallowed error is more dangerous than a crash.
- 05
Re-run the same task and compare: an agent that behaves differently across identical runs is not yet production-ready.
- Verify side effects in the system of record, not in the agent's summary.
- Require human approval for any irreversible or outward-facing action.
- Log every tool call so a run can be reconstructed afterwards.
Privacy & permissions
Use Mastra safely
Bound what an autonomous system can reach before you let it run unattended.
- 01
Enumerate every tool, credential, and system the agent can reach, and remove the ones it does not need.
- 02
Require explicit human approval for irreversible actions: sending, publishing, paying, deleting, or deploying.
- 03
Run against non-production data until behaviour is predictable across repeated runs.
- 04
Set hard limits on spend, iterations, and runtime so a failure loop cannot run unbounded.
- 05
Treat anything the agent reads from the web or a document as data, never as instructions it may follow.
- Typed schemas validate structure, not truth, authorization, or safe intent. Agents can loop or misuse tools, and workflows can replay or resume with stale state. Treat prompts, memory, MCP content, tool arguments, and resume payloads as untrusted; authorize outside the model, make side effects idempotent, cap requests and cost, isolate tenants, protect snapshots and traces, and require approval for consequential actions.
- Follow your organisation's approved-use policy.
- Never treat fluent output as authorization to act.
Core workflows
Step-by-step ways to use Mastra for the work it does best.
Each workflow below has its own outcome, steps and review checkpoints.
Give one agent a narrow goal and typed tools while keeping identity, authorization, validation, and side effects outside model control.
↓ 02 WorkflowRun a resumable Mastra approval workflowUse explicit steps, durable snapshots, idempotent effects, authenticated resume payloads, and observability for long-running work.
↓Workflow 01
Build a least-privilege Mastra tool agent
Give one agent a narrow goal and typed tools while keeping identity, authorization, validation, and side effects outside model control.
Outcome: Deliver useful open-ended assistance without enabling prompt injection, tenant crossover, uncontrolled loops, or autonomous consequential actions.
- 01
Define the user task, model, data classes, allowed tools, user roles, tenant boundaries, output schema, stop conditions, request and token budgets, approvals, and audit fields.
- 02
Create typed read-only tools first, validate and canonicalize inputs, fetch current authorization inside each executor, use scoped service accounts, and never expose secrets in descriptions or results.
- 03
Register the smallest toolset, quote retrieved and MCP content as untrusted data, constrain model and steps, validate structured output, and require explicit approval before any side effect.
- 04
Test prompt injection, unknown tools, forged arguments, cross-tenant IDs, data exfiltration, duplicate calls, loops, malformed output, timeouts, provider failure, denial, and cancellation.
- 05
Inspect Studio traces and evals, redact sensitive fields, canary behind rate and cost limits, monitor tool and model changes, and keep an immediate tool-disable and rollback path.
What good use looks like
- Authorize inside every tool.
- Start with read-only capabilities.
- Require approval for side effects.
Workflow 02
Run a resumable Mastra approval workflow
Use explicit steps, durable snapshots, idempotent effects, authenticated resume payloads, and observability for long-running work.
Outcome: Pause and resume a business process without duplicate actions, stale authorization, corrupted state, or abandoned executions.
- 01
Map deterministic steps, schemas, state, owners, approval rules, deadlines, retry and compensation policy, data retention, side effects, SLO, cost, and terminal states.
- 02
Implement typed steps with small state references, stable idempotency keys, bounded retries and timeouts, explicit failure paths, and no irreversible effect before its authorization gate.
- 03
Suspend with minimal metadata, encrypt and restrict snapshot storage, issue an authenticated approval request, and recheck approver role, workflow version, amount, expiry, and current business state on resume.
- 04
Test crash and restart, repeated resume, stale and forged payloads, denial, timeout, changed permissions, step failure, provider outage, compensation, cancellation, and snapshot deletion.
- 05
Trace every transition and approver, alert on stuck runs, canary workflow revisions, preserve compatible rollback, and expire or reconcile abandoned snapshots and pending effects.
What good use looks like
- Make every side effect idempotent.
- Reauthorize when resuming.
- Alert on suspended workflows.
Official references
Check the current product documentation.
Features, plan limits, availability, and data controls change. These official pages are the starting points used for this guide.