In June 2023, OpenAI added function calling to the Chat Completions API. That made it much easier for models to choose actions, but developers still had to handle state, retries, approvals, memory, and evaluation around those actions.
We ran into those problems while building Kepler, an AI-powered CRM, in 2024. We tried several frameworks, then kept removing framework code as we made the pipelines more reliable. That experience is what led to building Mastra.
Vercel introduced eve in June 2026 with a focus on durable agent sessions, and it's still in preview. This comparison uses a support-agent example to examine how the two TypeScript frameworks organize workflows, memory, evaluation, and deployment.
TL;DR
- Choose eve when the durable agent session is the right abstraction for your product. eve defines each agent as a directory of files and makes the session itself durable. Its runtime fits naturally into Vercel.
- Choose Mastra when agents are one part of a larger TypeScript application. Workflows run independently of agents, and tools can be reused outside the agent that calls them.
- Both frameworks support durable multi-step work and human approval. eve integrates workflow tools with sessions; Mastra registers workflows independently of agents. Recovery in either framework depends on its storage and execution setup.
- Mastra includes first-party RAG and several memory strategies. eve brings retrieval in through tools or services and has scoped memory providers, including its own file memory.
Mastra vs eve: Which TypeScript agent framework fits your workflows and requirements better?
Both are TypeScript frameworks for building agents. But the main architectural unit is different.
| Area | Mastra | eve |
|---|---|---|
| Agent definition | Explicit TypeScript agents with instructions, models, and tools | Files under an agent directory define instructions, tools, memory, schedules, and other capabilities |
| Workflow model | Independent workflows with typed steps and explicit control flow | The session itself is durable, with durable workflow tools inside it |
| Human approval | Tool approval plus workflow suspension and resumption | Tool approval plus workflow tools that can wait for human input |
| Long-term memory | Message history, working memory, semantic recall, and Observational Memory | Scoped memory slots with file memory or external providers |
| Product retrieval | First-party RAG primitives for processing, retrieval, and reranking | Retrieval usually comes through a tool, provider, or external service |
| Evaluation | Datasets and experiments for agents, workflows, and scorers | Repository-based eval cases run against the agent |
| Deployment | Self-host with supported runtime and storage adapters or use Mastra Platform | Vercel or a self-hosted Node service, with portable agent definitions |
Suppose we're building a support agent. It needs to:
- search current product documentation before answering
- remember stable customer preferences
- request human approval before issuing a refund
- survive a restart while that approval is pending
- turn an incorrect answer into a regression test
That gives us something more useful than a feature checklist. We can look at where each framework puts responsibility when the agent becomes part of a real application.
1. Agent definitions and tools
We designed Mastra agents as explicit TypeScript objects because we wanted the important application behavior visible in code. Models, instructions, tools, memory, and other capabilities can be configured on the agent, while those same tools can also be reused outside it.
eve makes the filesystem do more of that organizational work. Its agent file structure uses predictable directories for instructions, tools, memory, skills, connections, and other capabilities.
eve's approach makes one agent easy to inspect as a self-contained unit. Open its directory and you can quickly see what it can do. That fits you if the agent itself is your product boundary.
Mastra is more explicit about composition across the rest of the application. A search tool might be used by an agent, called directly from application code, and reused inside a workflow without belonging conceptually to one agent.
So both approaches give developers structure. They just put that structure in different places.
Verdict: eve's filesystem model is compelling when agents are the primary units your team builds and maintains. We prefer Mastra when agents are one part of a larger TypeScript application and capabilities need to move freely between agents, workflows, and application code.
2. Workflows and human approval
Both Mastra and eve support durable multi-step work and human approval. The difference is how each framework organizes it.
We built Mastra workflows as independent application primitives. A workflow can call agents, tools, or regular code. It can branch, loop, suspend, and resume without requiring an agent conversation to own the process.
So our refund example can exist as a standalone workflow.
The support agent, an internal dashboard, or an API can start the same workflow. To preserve an approval pause across a restart, configure persistent storage for its suspend/resume snapshots. Resuming restarts the suspended step with resumeData, so that step must handle the approval before continuing.
eve organizes long-running tool work around the durable session. A workflow tool can wait for a person, webhook, timer, or subagent without holding compute. It uses the same Workflow SDK as the session. eve also exposes start() through eve/workflow/api for workflow functions included in the agent bundle, so workflow execution is not limited to model-initiated tool calls.
That is a strong design when the process naturally belongs to what the agent is doing.
Verdict: This is mostly about ownership. eve fits agent-centric products where long-running work grows out of the session. Mastra fits applications where workflows are business processes in their own right and agents are one way to enter or participate in them.
3. Customer memory
Both frameworks distinguish long-term memory from the state of the current execution.
Mastra's memory system has several strategies for different jobs.
- Message history preserves the conversation.
- Working memory can hold stable facts.
- Semantic recall can retrieve relevant past messages.
- Observational Memory compresses longer-running context into useful observations.
External memory services can be exposed through a provider SDK in a Mastra tool or through MCP. The old @mastra/mem0 wrapper was deprecated and removed; it is not a current Mastra 1.x integration.
eve takes a provider-oriented approach. A memory slot defines who the memory belongs to, while its provider controls storage, retrieval, and capture. Its fileMemory() provider keeps a bounded document per scope and lets the model save or remove facts. Local development needs no external memory service; Vercel deployments can use configured Vercel Blob storage. External semantic-memory providers can use the same slot interface.
Verdict: If one bounded document per customer is enough, eve's file memory is the shortest path. If the agent has to recall specific past conversations or run for months, Mastra's semantic recall and Observational Memory are built for that.
4. Product document retrieval
Both frameworks can give an agent access to product knowledge. They differ in how much of the retrieval stack the framework itself provides.
Mastra includes first-party primitives for document processing, embeddings, vector retrieval, and reranking. Our RAG tutorial shows the full path from source documents to retrieved context. You can also integrate Mastra with your existing RAG setup if you do not want to migrate out of it.
So if we're building a support system from scratch, we can keep product knowledge separate from customer memory and build the retrieval layer within the same framework.
eve is more integration-oriented here. Its tools, connections, files, and context surfaces can bring external information into the session. If a company already has an internal documentation-search API, the agent can call it rather than rebuilding retrieval inside eve.
Verdict: If your docs already sit behind a search API, either framework can call it. If you're starting from a folder of markdown, Mastra handles chunking, embedding, and retrieval for you.
5. Evaluation and observability
Both Mastra and eve support OpenTelemetry-based observability, and both have real evaluation systems. So neither one wins this comparison simply because it has tracing or evals.
The difference is what the development loop revolves around.
With Mastra Experiments, a production failure can be added to a dataset. We can rerun it after a prompt, model, tool, or workflow change and compare the result with earlier experiments. Those results include execution metadata such as trace IDs, which connects evaluation back to the run that produced it.
And Mastra Observability traces agents, model calls, tools, memory operations, and workflows. Mastra can export to OpenTelemetry-compatible platforms, or you can use our hosted logs, traces, and metrics.
eve also instruments its runtime and can export telemetry to external systems. On Vercel, Agent Runs (in beta) shows sessions, turns, tool calls, timing, and token usage. Its repository-based evals assert tool usage, content, or model-judged behavior. Reporters send results to Braintrust or Datadog experiments, or JUnit XML, so teams can also compare results outside the CLI.
| Team workflow | Natural fit |
|---|---|
| Trace behavior across application primitives, then turn failures into comparable experiments | Mastra |
| Operate, inspect, and test durable agent sessions as the primary runtime object | eve |
Verdict: Both have serious observability and eval stories. Mastra organizes the loop around the wider agent application. eve organizes it particularly well around the durable session.
6. Recovery and durable execution
In eve, the session is the durable unit. Its execution model uses Workflow checkpoints and replay. Vercel supplies the managed runtime; self-hosted deployments must retain Workflow storage and select a world appropriate to their process and replica setup.
And eve's workflow tools extend the same model when part of the session needs to wait for a person, timer, or webhook.
Mastra's Durable Agents (beta) run the agent loop inside a workflow, so a client can reconnect to a live stream and a crashed run can pick up from its last checkpoint. Crash recovery is opt-in and needs persistent storage. Recovery can replay model and tool calls, so make external actions idempotent.
| Problem | Mastra approach |
|---|---|
| Workflow waiting for approval | Restore a saved snapshot and resume the suspended step |
| Long-running distributed workflow | Temporal integration, with Temporal providing the execution engine |
| Agent disconnect or process crash | Reconnect to a live stream; recover crashed execution from saved checkpoints using the configured engine/recovery path |
That separation adds more concepts, but it also lets you choose the durability boundary that matches the failure.
And neither framework removes the need for idempotent external actions. If a payment succeeds before a crash, the payment API still needs a mechanism that makes a retry safe.
Verdict: eve centers recovery on sessions and their workflow tools. Mastra has both durable agent loops and independently registered workflows. For either framework, test a restart while the refund approval is pending and verify that the eventual payment cannot be duplicated.
7. Deployment
Both frameworks can run on managed infrastructure or be self-hosted.
eve's deployment guide describes Vercel and self-hosted Node targets. Vercel operates the web runtime, Workflow execution, Sandbox, schedules, and deployment observability together. Self-hosting uses a local or custom Workflow world and a matching sandbox backend; multi-replica deployments need a world designed for shared queue delivery.
Mastra is similarly not tied to one deployment target. You can run the framework on your own infrastructure or use Mastra Platform.
eve's Vercel path is intentionally cohesive. If your company is already building on Vercel, that can remove a meaningful amount of infrastructure work.
eve explicitly keeps its filesystem-based agent configuration portable between its deployment strategies. Mastra has supported storage and deployment adapters.
eve integrates with Vercel Sandbox and supports other sandbox backends when self-hosted. Mastra supports remote sandbox providers and keeps the filesystem and execution environment as separate workspace concerns.
Verdict: If you're already on Vercel, eve is the least work. If you're not, or you want to pick your own database and sandbox vendor, Mastra gives you more of those choices.
How to pick between Mastra and eve
| Area | Mastra | eve |
|---|---|---|
| Agents | Agents with reusable tools, memory, model configuration, structured output, and application-level composition | Filesystem-defined agents with tools, instructions, skills, connections, and subagents |
| Workflows | Workflows that can run independently of agents, suspend and resume, call agents or tools, and optionally run on Temporal | Durable sessions plus workflow tools for waits, retries, webhooks, timers, and subagent work |
| Durable execution | Workflow snapshots and Durable Agents with configured persistent storage and recovery; optional external execution engines | Durable agent sessions and workflow tools built on the Workflow SDK and the selected world's storage |
| Memory | Message history, working memory, semantic recall, Observational Memory, Observational Memory hooks, and the hosted Mastra Memory Gateway | Scoped memory slots with file memory or external providers controlling storage and retrieval |
| Retrieval | Document processing, embeddings, vector storage integrations, retrieval, and reranking | Usually composed through tools, connections, files, or an existing retrieval service |
| Evaluation | Persisted datasets and experiments across agents, workflows, and scorers, with Studio, API, CLI, and CI surfaces | Repository-based evals with deterministic assertions, model judges, mocks, and external reporters |
| Observability | OpenTelemetry-compatible tracing plus logs, metrics, feedback, Studio inspection, and hosted Mastra Observability across agents and workflows | OpenTelemetry instrumentation, local traces, external exporters, and session inspection through Vercel Agent Runs |
| Sandboxes | Pluggable remote sandbox and filesystem providers, including isolated environments from multiple vendors | Vercel Sandbox on Vercel; Docker, microsandbox, or just-bash locally; Docker or a custom adapter when self-hosted |
| Deployment | Self-host with supported runtime/storage adapters or use Mastra Platform | Portable agent configuration across self-hosted Node and integrated Vercel deployments |
| Best fit | You're building AI as part of a broader application and want one framework for the surrounding agent infrastructure | You're building around a durable agent session, especially when Vercel is already the runtime |
Our take:
Choose eve when the durable agent session is already the right abstraction for your product and you want a runtime that fits naturally into Vercel.
Choose Mastra when you want the agent session plus the infrastructure around it: independent workflows, retrieval, memory strategies, experiments, observability, and deployment choices that can be composed across a larger application.
