Mastra
Mastra separates two things that get conflated in most agent frameworks: an agent (an LLM given tools and let loose to decide what to call, in what order) and a workflow (a typed, deterministic step graph you control, with branching, suspend/resume, and retries). Both can call tools and both can be composed with each other — a workflow step can invoke an agent, and an agent can be handed a workflow as a callable tool. The mistake worth avoiding is using an agent where you actually want guaranteed ordering and durability, or a workflow where you actually want the model to decide the next action; both compile and run, only one gives you the reliability you meant to build.
Storage is a foundational choice, not a config detail
Agent memory, workflow snapshots, vector embeddings, and eval traces all sit on the same storage abstraction. The default local backend is a file-based LibSQL database — fine for development, wrong for anything with concurrent writers or that needs to survive a redeploy. Because workflow suspend/resume persists serialized state through this same layer, swapping storage later means migrating live snapshots, not just changing a connection string. Decide the production backend (Postgres, Turso, or another supported store) before shipping a workflow that suspends, not after.
Memory and RAG are not the same subsystem
Conversation memory (working memory, message history, semantic recall over past turns) and RAG (retrieval over an external knowledge base) both use a vector store, and both get lumped together as "give the agent context." They have different freshness, ownership, and eviction concerns — memory belongs to a thread/user, a knowledge base belongs to the document corpus. Treating one config as the other tends to leak unrelated conversation history into document retrieval or vice versa.
Deployment target shapes what a workflow can do
A Mastra app can run as a standalone Node server or be built for a specific serverless deployer (Vercel, Cloudflare, Netlify, and others). Serverless targets impose execution-time and statefulness limits that a long-running workflow with suspend/resume can violate silently until it hits them in production.
What to verify rather than recall
This framework ships fast. Treat these as unverified until checked against
the mirrored corpus: exact @mastra/* package and CLI versions, the deployer
package name and its platform-specific constraints, which vector-store
adapters are currently supported, and the Mastra constructor / config keys
in use — these have moved across recent releases.