If you're looking at Mastra and Flue, I wouldn't start with a feature checklist. Both can run TypeScript agents. The more important thing is where you want the agent to stop and the rest of your application to begin.
When we built Mastra, we made agents one primitive in the system, not the container for everything else. Workflows, memory, retrieval, evals, observability, and deployment all have their own place. Flue, on the other hand, centers much more of the application around the durable agent session, which fits particularly well with Cloudflare's infrastructure model.
TL;DR
- Choose Flue when one durable agent session is the center of the application. Persistent state can change which tools the agent gets on the next turn, and on Cloudflare, Durable Objects supply its persistent storage.
- Choose Mastra when you want workflows in the agent framework. Workflows can suspend for approval and resume from saved state. Flue 2 removed its native workflow API; use ordinary TypeScript for orchestration or compose Flue with a durable workflow engine when needed.
- Flue is conservative about interrupted ordinary tools. When it cannot tell whether a call finished before a crash, it records an unknown outcome instead of rerunning it. Explicitly durable tools use checkpointed steps and have different replay behavior.
- Mastra brings its own RAG stack and eval tooling. Its datasets and experiments compare versions of an agent or workflow, while Flue runs evals as Vitest tests and leaves retrieval to tools or MCP.
- Both run on Node.js and Cloudflare. Flue integrates directly with Durable Objects. Moving either framework between hosts requires checking storage, execution, and recovery configuration.
Mastra vs Flue: At a glance
Flue gives you a durable agent whose behavior and available capabilities can change with state. Mastra gives you the agent runtime too, but the rest of the application doesn't have to live inside it.
| Area | Mastra | Flue |
|---|---|---|
| Core model | Agents alongside workflows, memory, RAG, evals, and observability | Durable agent session is the main abstraction |
| Workflows | Framework workflow engine | No native workflow primitive in Flue 2.0; compose with other engines |
| Human approval | Suspend and resume a workflow | Usually modeled through agent state or an external orchestrator |
| Memory | History, working memory, semantic recall, and Observational Memory | Conversation history, context compaction, and persistent application state |
| Recovery | Agents and workflows recover according to configured storage, checkpoints, and engine | Durable agent requests, with different recovery rules for ordinary and durable tools |
| Retrieval | First-party RAG stack | Usually added through tools or MCP |
| Evaluation | Datasets, experiments, scorers, Studio, and CI | Vitest-based evals, judges, reports, a local viewer, and CI |
| Deployment | Multiple runtime and storage choices | Node.js and Cloudflare, with the closest fit on Cloudflare |
If your application is basically one durable agent session, Flue's model is easy to understand. If the agent sits inside a larger product, Mastra gives more of that product an explicit place to live.
The difference shows up in what each framework keeps inside the agent and what it leaves to the rest of your app.
1. Agent behavior and conditional tools
Flue's dynamic agent model lets persistent state change the agent's capabilities. Its hooks can change available tools and skills on subsequent model calls; model settings apply at the start of the next submission. Sandbox access can also be conditional. This keeps capability-selection logic close to the agent.
Mastra supports conditional tool access as well, but we made a distinction between what an agent can do and how a process moves forward. An agent can handle reasoning and tool use while a workflow owns the sequence around it.
| Mastra | Flue | |
|---|---|---|
| Changing which tools an agent can use | Supported | A central part of how Flue works |
| Where process state lives | Can live outside the agent in a workflow | Often kept with the agent |
| Reusing the same agent | The same agent can be used in different workflows | Usually organized around the agent session |
| Better fit when... | Your agent is one part of a larger application | Most of your application revolves around the agent |
2. Workflows and human approval
This is probably the sharpest difference between Mastra and Flue.
Mastra has a workflow engine with typed steps, branching, loops, shared state, and suspend/resume. With persistent storage configured, an approval pause saves a snapshot that survives a restart. Approval resumes the suspended step with resumeData; after that step completes, the workflow advances.
Mastra workflows can also run on Temporal when you want that execution engine. Flue 2 removed its native workflow API. Its orchestration guide uses ordinary scripts for simple sequences and Cloudflare Workflows, Inngest, or Temporal for durable multi-step work. An external engine does not necessarily mean another deployment: the Cloudflare example hosts the workflow and Flue app in the same Worker.
| Mastra | Flue | |
|---|---|---|
| Multi-step workflows | Framework workflow API, with optional external engines | TypeScript orchestration or a separate workflow engine |
| Branching and loops | Workflow control-flow primitives | Ordinary TypeScript or the selected engine's primitives |
| Pause for human approval | Persist a workflow snapshot and resume the suspended step | Agent state or a composed workflow engine |
| Durable process spanning requests | Workflow snapshots and the configured execution engine | Compose with a durable workflow engine, which may be co-hosted |
Flue's approach keeps the framework smaller. But if your application already has processes that matter independently of a model turn, you will need somewhere else to model them.
3. Conversation and memory
Both frameworks can preserve a conversation. What changes is how much you want the framework to understand about memory beyond storing that conversation.
Flue keeps conversation history and persistent state attached to the agent. It also provides context compaction that summarizes older messages while retaining recent context. That addresses context-window pressure; application-specific recall and long-term knowledge still need their own implementation.
Mastra's memory system separates different memory jobs. Message history handles recent conversation. Working memory keeps structured information. Semantic recall brings back relevant older messages. Observational Memory turns long-running context into observations instead of endlessly replaying a growing transcript.
You can also control the memory lifecycle with memory hooks. The Observational Memory research goes deeper into why we treat long-running context as a separate problem from ordinary retrieval.
| Mastra | Flue | |
|---|---|---|
| Keep conversation history | Yes | Yes |
| Save structured information | Working memory | Persistent agent state |
| Bring back relevant older messages | Semantic recall | Application-defined retrieval |
| Manage very long conversations | Observational Memory compresses older context into observations | Context compaction summarizes older messages; custom recall can use tools |
| Control how memory is stored or changed | Memory options and hooks | Agent state hooks and application logic |
Choose between these models by specifying what must persist as application state, what belongs in the conversation, and what the agent should retrieve later. Mastra supplies separate memory strategies; Flue combines state and history with compaction and application-defined retrieval.
4. Durability and recovery
One thing Flue gets right is being conservative about interrupted tools.
Its durability contract records accepted requests before execution starts. An unresolved ordinary tool call is not automatically rerun after a crash; Flue records an unknown outcome. Explicitly durable tools behave differently: a durable: true tool can re-execute while step.do() replays recorded completed steps.
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.
Workflow snapshots preserve saved progress, but recovery is bounded by what was persisted and how the engine restarts it. Reconnecting a client, recovering a crashed process, and deduplicating an external payment are separate requirements. Recovery can repeat work, so external actions need idempotency in both frameworks.
| Mastra | Flue | |
|---|---|---|
| An agent response was interrupted | Reconnect to a live run or recover execution from saved checkpoints using the configured recovery path | Recover the accepted request according to its storage and runtime contract |
| A multi-step workflow stopped halfway through | Recover from persisted snapshots according to the workflow engine | Use the composed workflow engine's recovery model |
| A tool may have completed before the crash | Deduplicate external effects that recovery might repeat | Ordinary unresolved calls become unknown; durable tools replay recorded steps and need safe retries |
| You need a dedicated workflow engine | Mastra workflows can run on Temporal | You connect a separate workflow system |
5. Document retrieval
Flue mostly stays out of the retrieval business. You expose your existing search or knowledge system to the agent through a tool or an MCP service. That is perfectly reasonable if you already have retrieval infrastructure you like.
Mastra includes a first-party RAG system for document processing, chunking, embeddings, vector storage, retrieval, and reranking. You can use the same retrieval layer from an agent or from a workflow.
The rest of the tooling connects to it as well. Mastra's RAG guidance covers the application side of retrieval, while semantic recall for agent memory stays separate from document RAG.
| Mastra | Flue | |
|---|---|---|
| Process and split documents | Document-processing primitives | Connect or implement a processing pipeline |
| Create embeddings and search vectors | Embedding and vector-store integrations | Connect a library or service through tools |
| Connect an existing search system | Yes | Yes |
| Connect retrieval through MCP | Yes | Yes |
| Use retrieval inside a workflow | Call retrieval from workflow steps | Call retrieval from the composed workflow engine |
If retrieval is already somebody else's problem in your stack, Flue doesn't get in the way. If retrieval is part of the application you're building, Mastra saves you from assembling quite as much around the agent.
6. Evaluation
Flue's eval approach will feel familiar if you already think of evals as tests. Its evaluation guide uses Vitest, so you can run cases against the same agent interface your application uses. For a lot of projects, that's a sensible starting point.
Flue's guide also covers vitest-evals judges, normalized reports, a local report viewer, and CI reporting. Mastra organizes this work around persisted datasets, experiments, agent/workflow/scorer targets, and scorers.
Mastra Studio provides a UI for inspecting experiment runs and scores.
Flue also provides runtime observability, including runtime events and Sentry, Braintrust, and OpenTelemetry integrations.
| Mastra | Flue | |
|---|---|---|
| Write evals in code | Yes | Yes |
| Run evals automatically during development or deployment | Yes | Yes |
| Save and reuse test cases | Persisted datasets | Cases in the test setup |
| Compare different versions of an agent or workflow | Persisted experiments | Comparisons through test tooling and reports |
| Score outputs | Scorers | Eval assertions and judges |
| Review results visually | Mastra Studio experiment results | Local eval report viewer and test reports |
Flue fits teams that want eval definitions, judges, and reports in their Vitest workflow. Mastra fits teams that want persisted datasets and experiment history across agents, workflows, and scorers, with inspection in Studio.
7. Deployment targets and durable storage
Flue runs on Node.js as well as Cloudflare. On Cloudflare, its deployment model maps each agent conversation onto a Durable Object, with persistent SQLite storage supplied by the platform.
On the Node target, a production build without db.ts uses in-memory SQLite. Configure durable storage for restart survival. Flue's database adapters support file-backed SQLite and external databases. A conversation still needs one live Node owner; sharing a database does not make it safe for multiple replicas to execute the same conversation concurrently.
Mastra also gives you runtime and storage choices. You can self-host, run on Mastra Platform, deploy through providers such as Netlify, or use Cloudflare with a Durable Objects storage adapter. Each target still needs compatible persistence and recovery configuration.
| Mastra | Flue | |
|---|---|---|
| Run on Node.js | Yes | Yes |
| Run on Cloudflare | Yes | Yes, and Cloudflare fits Flue's design particularly well |
| Managed deployment path | Mastra Platform | Cloudflare runtime services |
| Choose where saved state lives | Supported Mastra storage adapters | Durable Object SQLite on Cloudflare; configurable database adapters on Node |
| Move to a different hosting provider later | Verify runtime support, storage, sandbox, and recovery setup | Verify runtime support, storage, sandbox, and request ownership/recovery setup |
Compare the runtime and storage combination you plan to deploy. Cloudflare supplies ownership and wake-up facilities that a Node deployment must account for.
8. Sandbox and workspace persistence
Conversation state and files are different durability problems.
Mastra makes that separation explicit through sandboxes and filesystems. A sandbox controls where code executes. A filesystem controls what survives.
Mastra Workspaces bring file access, command execution, search, skills, and approval controls together around the agent. You can add managed persistent filesystems, control the sandbox lifecycle, attach filesystem mounts, or use remote sandbox providers.
Flue's sandbox guide also separates conversation state from workspace files. Providers can reconnect to a durable workspace using the agent instance ID. Scratch files in just-bash are ephemeral; local or remote providers determine how files persist.
If the agent edits repositories or creates artifacts, compare each provider's filesystem lifetime, isolation, and restore behavior. Mastra exposes filesystem and execution providers separately; Flue exposes persistent workspaces through its sandbox-provider contract. Both require a backend that meets the application's retention requirements.
How to pick between Mastra and Flue
| If you need... | Pick |
|---|---|
| A workflow API in the same framework as your agents | Mastra |
| Approval workflows using the framework's own workflow API | Mastra |
| Framework-managed working memory, semantic recall, and Observational Memory | Mastra |
| Document ingestion, RAG, and vector retrieval in the framework | Mastra |
| Persisted datasets, experiment history, and scorer targets in Studio | Mastra |
| Tracing across Mastra agents, tools, workflows, and memory in Studio | Mastra |
| Choosing deployment and storage adapters | Both, after verifying the runtime and recovery combination |
| One durable agent session as the center of the application | Flue |
| Tight integration with Cloudflare Durable Objects | Flue |
| A small agent framework because you already have workflow, retrieval, and eval systems elsewhere | Flue |
For a concrete comparison, implement one approval flow and one eval case, then restart the runtime while approval is pending. Verify the saved state, tool retry behavior, and resulting report. For another session-centered design, see Mastra vs eve.
FAQ
What is Mastra?
Mastra is an open-source TypeScript framework for building AI agents and AI applications. It includes agents, workflows, memory, retrieval, evals, observability, and deployment tooling.
Mastra vs Flue, which framework should you choose?
Choose Mastra if your agent is part of a larger application and you also need workflows, memory, retrieval, evals, or observability. Choose Flue if most of your application can live inside one durable agent session, especially on Cloudflare.
Does Mastra have workflows?
Yes. Mastra workflows support branching, loops, data between steps, and approval pauses. Continuing after a restart requires a saved snapshot in persistent storage; resuming restarts the suspended step with the approval data.
What programming language do Mastra and Flue use?
Mastra and Flue are both TypeScript frameworks. The bigger difference is scope: Mastra includes more of the application around the agent, while Flue stays more focused on the agent runtime.
Is Mastra open source and how much does it cost?
The Mastra core framework is open source and free to use. Mastra also has a hosted platform with free and paid plans, plus enterprise features.
Can Flue run outside Cloudflare?
Yes. Flue runs on both Cloudflare and Node.js. Cloudflare is the closer fit because its Durable Objects provide the persistent agent storage Flue is designed around.
