Mastra vs Flue 2.0: Choosing a TypeScript Agent Framework Without the Hype

If you are new to agentic AI and TypeScript is your home turf, the framework landscape is confusing in a specific way: every project says the same things ("durable", "production-ready", "model-agnostic"), and most tutorials were written last quarter and are already wrong. I am a software architect, full-stack developer, and system administrator who has run servers far longer than I have built agents, so I went into this skeptical and came out with a cleaner picture than I expected.

This post compares Mastra (at @mastra/core@1.55.0) and Flue 2.0 (at 2.0.3) as of August 5, 2026. I read the official documentation, GitHub repositories, release notes, changelogs, license files, and launch announcements. Where I cite a third party or an estimate, I say so. This is not a benchmark and I am not an AI expert - it is an architectural reading by someone who ships TypeScript backends for a living and wants to know which framework to bet a project on.

The short version:

• Mastra is an application framework: agents, workflows, memory, RAG, evals, observability, Studio, channels - a batteries-included platform around a TypeScript core, from the company behind Gatsby (backed with $35M in funding).
• Flue 2.0 is a durable agent harness: fewer primitives, more runtime. Agents are functions, hooks give them dynamic capabilities, durability is the architecture, and sandboxes are a first-class concept. Built by the Astro team.
• They overlap more than either side's marketing suggests, and "workflows vs agents" is the wrong axis. The real differences are where control lives, how much runtime you get, and what you are allowed to build on top.

What Each Framework Actually Is

Mastra: the application framework

Mastra is a TypeScript framework for AI-powered applications and agents - the "modern TypeScript stack" answer to LangChain (github.com/mastra-ai/mastra, roughly 26.9k stars at the time of writing). It started as an open-source layer on Vercel's AI SDK (Show HN, Feb 19, 2025) and has grown into a large surface: agents, graph-based workflows, four memory tiers, RAG, evals with dozens of built-in scorers, channels (Slack, Teams, Discord, Telegram, WhatsApp, iMessage), browser tooling, MCP client and server support, a local Studio UI, and a paid hosted platform.

The company - Kepler Software, Inc., founded by Sam Bhagwat (ex-Gatsby) - raised a $13M seed (March 2025) and a $22M Series A led by Spark Capital (April 9, 2026), for $35M total, and launched the Mastra Platform the same day (seed round, Series A). Publicly named customers include Brex, Sanity, Factorial, Indeed, Marsh McLennan, MongoDB, Workday, Salesforce, and Replit.

The developer experience centers on a Mastra instance you register agents, workflows, tools, storage, and vector stores on. Agents are new Agent({ ... }) config objects with model: 'openai/gpt-5.6-sol'-style strings resolved by Mastra's model router (agents docs); tools must be built with createTool() and Zod or Standard JSON Schema. Then mastra dev gives you Studio at localhost:4111.

Flue 2.0: the durable agent harness

Flue is the "agent harness" framework from the Astro team (github.com/withastro/flue, roughly 7.7k stars, Apache-2.0). Its pitch: Claude Code-style agents, headless and programmable. Where Mastra hands you application primitives, Flue hands you a runtime - sessions, tools, skills, sandboxes, and durability - wrapped in a TypeScript harness that any model can drive.

Version 2.0 (announced July 31, 2026) was a total rewrite of the 1.0 beta (which launched around May 2026). The headline change is Agent Hooks: the agent is a plain exported function that re-renders before every model turn, declaring model, tools, skills, subagents, MCP connections, sandbox, and durable state with React-style hooks (useModel, useTool, useSkill, useSubagent, useMcpConnection, usePersistentState, and more). Because the render runs each turn, capabilities can appear and disappear at runtime - the model can earn a tool, swap to a bigger model, or upgrade its sandbox mid-conversation.

Flue 2.0 also deleted its own surface wherever the ecosystem has something better: flue dev and flue build are gone (Vite owns the build, Hono owns routing, Pi owns model providers - the release notes say this explicitly), file-based routing is gone (you mount routes explicitly in app.ts), and workflows were removed entirely. Durability now lives in the conversation runtime itself, with init() handles and durable tools as the replacement.

Getting a feel for both, the way a sysadmin would:

$ npm create mastra@latest
$ cd my-mastra-app && npx mastra dev
# Mastra Studio: http://localhost:4111
$ npx flue init --target node
$ npx flue run
# Flue: local agent run in your terminal, no server

Versions, Releases, and Maturity

Both projects move fast. Mastra ships weekly and has a company behind it; Flue went from beta to 2.0 in about two months and was on its third patch release five days after the stable launch. Two things to internalize:

1. Any tutorial about either project older than roughly three months is suspect. Mastra's 2025-era posts describe the pre-1.0 API; Flue's 2025-era posts describe a framework that no longer exists.
2. Flue 1.0 beta to 2.0 was a breaking rewrite with a persisted-state reset. The migration guide states the storage schema went from version 5 to version 8 with no in-place migration - the runtime rejects pre-2.0 databases outright. If you shipped on the beta, the recommended path is a drained deployment, not an upgrade.

An early HN thread about Flue (May 2026) also drew real skepticism - "a meaningless wrapper for Anthropic or OpenAI SDKs" and questions about test coverage (thread). The 2.0 changelog documents deep durability fixes since, and the repo now ships contract test suites for storage adapters (@flue/runtime/test-utils), but I have not audited coverage myself. Treat the young-project risk as real.

The Two Mental Models

Mastra's model is configuration and graphs. You declare agents as config objects and workflows as typed step graphs (.then(), .branch(), .parallel()), and the framework executes and persists them. Static by default; dynamic via processors, guardrails, signals, and request context.

Flue 2.0's model is render-with-hooks - "React for agents", their words. The agent function runs fresh before every model call, its return string is the instruction document, and hooks declare everything else. Conditional declarations are the point: if (userIsVerified) useTool(adminTools). The framework's own blog shows a support agent that earns new tools and a bigger model once a customer is verified, purely through usePersistentState plus conditional hooks.

Now the "workflows vs agents" cliché: it is misleading. Mastra has both as first-class primitives, plus a serious workflow suite - suspend and resume, human-in-the-loop, snapshots, time travel, error handling, scheduled workflows, and Inngest/Temporal workflow runners. Flue 2.0 deleted its workflow primitive, yet still supports deterministic multi-step processes: as persistent state plus conditional tools (the docs show a triage agent advancing step-by-step by calling a tool that updates state), as durable tools with step.do() checkpoints, or by delegating to your own orchestrator (Cloudflare Workflows, Inngest, Temporal). Both frameworks can do both things; the difference is where control lives - an explicit graph with framework-managed state, versus agent-owned state with runtime-level durability.

Memory and RAG

Mastra's memory is the strongest out-of-the-box story here: message history, working memory (structured user data), semantic recall (vector retrieval across threads), and observational memory, where background agents compress old history into dense observations so long conversations do not fill the context window - plus memory processors to trim when you exceed limits (memory docs). RAG is built in too: chunking, embeddings, vector database integrations, retrieval, and GraphRAG (RAG guide).

Flue 2.0 has no memory or RAG guide in its documentation as of this writing. What it has is durable per-instance state (usePersistentState) and automatic context compaction, and the docs' honest stance is that everything else is yours: hook up a vector store through a tool or an MCP server. If your project is "chat with my documents", Mastra saves you real work; if you already own a retrieval stack, Flue does not get in your way.

Tools, skills, and MCP

Both frameworks have typed tools, skill support based on the open Agent Skills / SKILL.md format, and MCP. The differences: Mastra is the only one of the two that also lets you author MCP servers (exposing your agents and tools to other systems over MCP). Flue consumes remote MCP servers via useMcpConnection with genuinely useful details - connections can be marked optional so a flaky server degrades gracefully, tool allowlists are per-server, and auth can be a per-request resolver. Flue's durable: true tools, which record step.do() progress so recovery replays recorded values instead of re-running side effects, have no direct Mastra equivalent outside workflow steps.

Sandboxing: the part you should not skim

Mastra ships a workspace model (filesystem, sandbox, LSP inspection) plus Code Mode for model-authored programs, and @mastra/isolated-vm (released July 30, 2026) runs those programs in an in-process V8 isolate with no filesystem, network, or process access.

Flue made sandboxes opt-in in 2.0 - an agent without useSandbox() has no shell and no file tools, which is a good default. But pay attention to what each sandbox is: local() runs commands on your host machine; Cloudflare Sandbox runs them in a container; just-bash is an in-memory TypeScript reimplementation of bash; the cloudflare-computer blueprint provides a durable SQLite-backed workspace; Daytona gives remote containers. For a coding agent pointed at real infrastructure, local() is a security decision, not a convenience.

Human-in-the-loop

Mastra treats human approval as a first-class primitive: agents can suspend and await approval, workflows support suspend/resume, and channel approvals exist for chat platforms. Flue 2.0 has no approval primitive in its docs - interactive input happens through channels and the SDK. If your workflow legally or operationally requires a human gate, Mastra is the easier default, though you can build the same gate in Flue yourself.

Local Tooling vs Hosted Services

This is where the two projects diverge hardest, and where I suspect most teams actually feel the difference.

Mastra local (open source): mastra dev runs Studio at localhost:4111 - a chat playground with model switching and tool-call inspection, traces and logs, workflow graph visualization with time travel, a scorers/datasets/experiments UI, a workspace file browser, an MCP server browser, and a standalone tool runner (Studio docs). There is also an agent Editor aimed at non-technical teammates, with versioning. All of this is part of the open-source repo, not the ee/ paths listed in the license.

Mastra hosted (paid): the Mastra Platform (launched April 9, 2026) - shared Studio, Server, Observability (metrics, logs, traces, Trace Intelligence), Agent Builder, Memory Gateway (usable with other frameworks), a model Gateway, and managed databases.

Enterprise is custom (RBAC, audit logs, SLAs, on-prem/VPC). There is also a separate paid Enterprise license for self-hosting the ee/-licensed features. Full numbers on the pricing page.

Flue local (open source): a CLI (flue run for local and CI runs, flue init, flue add blueprints for channels/tooling/databases, offline docs) and Vitest-based evals with the vitest-evals integration, which includes a local report server (vitest-evals serve). There is no first-party UI - 2.0 removed the beta's dev-console run UI along with workflows.

Flue hosted: none from the project itself. Observability goes to Cloudflare Workers Logs/Traces (zero-config on the Cloudflare target, with OTel-GenAI-named spans), Braintrust, Sentry, or any OpenTelemetry backend (observability docs). You assemble the stack.

Licenses in Plain Terms

Mastra is dual-licensed. The core is Apache-2.0. Code in directories named ee/ - currently packages/core/src/auth/ee/ and packages/server/src/server/auth/ee/ - is source-available under the Mastra Enterprise License: free for development and testing, but requiring a valid enterprise license for production use (LICENSE.md, copyright Kepler Software, Inc.). In practical terms: building proprietary SaaS or internal tools on the Apache-2.0 core is fine (preserve the notices); the ee/ code is not yours to vendor into a white-label product; and "open source" on the Mastra website means "the core", with an enterprise boundary you should check before you depend on anything auth-shaped.

Flue is Apache-2.0, single license, no `ee/` directory (LICENSE). That is the friendliest option for proprietary SaaS, internal tooling, redistribution, modified versions, and white-label products - Apache-2.0 has no copyleft and no network clause (unlike AGPL), so running a hosted service on it is unproblematic. Keep the license and NOTICE text, mark modified files, and you are done.

One structural difference worth naming: Mastra's Apache core exists alongside a commercial platform, so expect the company to keep growing the paid surface. Flue has no hosted product at all that I could verify - you self-host everything, and the project's only commercial angle is being the Astro team's open-source offering. "Mastra is a business, this seems to be a helpful lib" is how one HN commenter put it, and that asymmetry is exactly what the licensing pages tell you.

Ten Use Cases, Ten Picks

For each of these, my pick is the framework I would start with, the reason, and the caveat. Your mileage will differ - that is the point of the exercise.

• Simple tool-using chatbot: Either. Both handle this in an afternoon. Mastra edges ahead if you want the chat UI and the Studio debugging loop; Flue is equally fine and hands you a durable conversation URL for free. Caveat: do not choose a framework on this use case alone.
• RAG assistant: Mastra. Built-in chunking, embeddings, vector stores, retrieval, and GraphRAG. Flue has no RAG story in its 2.0 docs - you would wire a vector store through tools or MCP yourself. Caveat: RAG quality is mostly your embeddings and retrieval tuning, not the framework.
• Predictable IT automation workflow: Mastra - with a "neither" caveat. Explicit typed graphs, retries, suspend/resume, and scheduled workflows fit ops automation well. Caveat: if the flow genuinely never needs model judgment, plain code plus cron or Temporal is simpler than either framework.
• Incident-response assistant: Mastra. Channels (Slack, Teams, Discord, Telegram, WhatsApp, iMessage) plus human approvals plus evals. Caveat: running it reliably 24/7 is on you; the paid Platform exists for a reason.
• Autonomous coding agent: Flue 2.0. Sandbox-first design, built-in bash/read/write/edit/grep/glob tools, skills, and durability - this is the whole point of the project. Caveat: local() executes on your host; use a container sandbox for anything real, and the project is young.
• Agent that dynamically gains tools: Flue 2.0. Conditional hooks are the flagship 2.0 feature and it shows - persistent state plus conditional useTool/useModel is the documented pattern. Caveat: it is the newest code in a new framework; expect rough edges.
• Multi-agent system: Mastra. Supervisor agents, subagents with automatic memory isolation, A2A support. Caveat: the patterns are still evolving - the older .network() API was deprecated in favor of supervisors.
• Long-running resumable task: Flue 2.0. Every accepted message settles exactly once through crashes and redeploys; durable tools with step.do(); Durable Objects on Cloudflare. Caveat: on Node you must provision Postgres (or similar) yourself, and 2.0 removed workflow-run inspection (getRun) - you reconcile state from your own orchestrator.
• Production system needing strong tracing: Mastra. Local Studio trace viewer, OpenTelemetry and a dozen exporters, and Platform observability with Trace Intelligence. Caveat: the polished hosted dashboards are the paid Platform; local Studio covers development only.
• Existing TypeScript backend that should not be restructured: Mastra. Server adapters, middleware, request context, and first-class integration with Next.js, Express, Hono, NestJS, and AI SDK UI - you drop it in. Flue 2.0 demands a Vite build, a Hono app.ts, and the 'use agent' project shape. Caveat: Mastra still has its own conventions and a very large API surface to learn.

And the honest neither: a fully deterministic flow (plain code + cron/Temporal/Inngest), a Python-first ML organization, or a pure streaming chat where you do not need a framework at all (the Vercel AI SDK alone). Adopting a framework has a cost; only pay it where the framework earns it.

Documentation Gaps, Breaking Changes, and Ecosystem Risk

Mastra: the docs are extensive - the llms.txt index maps dozens of guides and references - but the surface is enormous, weekly releases outpace docs in places, and several migrations are recent: the 1.0 upgrade, .network() to supervisor agents, AI SDK v4 to v5, and the rename of "Mastra Cloud" to "Mastra Platform" (migration guides exist for all of these). The Playground became Studio in October 2025. File-based agents shipped July 3, 2026 and are still marked beta per a third-party write-up I checked. Most 2025 tutorials are stale; the official docs and templates are the reliable path.

Flue: the docs are good for a young project but visibly thin where the design is "bring your own" - there is no memory or RAG guide, and the persistence pages carefully explain what Flue stores (conversations, accepted submissions, persistent state, attachments) and what it does not (your business data, sandbox files). The 2.0 rewrite invalidated every 1.0-beta tutorial, including the popular "agent as a directory" posts: src/agents/, src/workflows/, and src/channels/ discovery are gone, replaced by the 'use agent' scan and explicit app.ts routing. The changelog shows real churn (three patches in five days, including a fix for a scaffolded-dependency peer conflict), and the project depends on Pi (@earendil-works/pi-ai) and, on Cloudflare, on the Agents SDK and wrangler versions. Version-pin aggressively and read the changelog before every upgrade.

Ecosystem risk: Mastra is venture-backed with a commercial platform - low abandonment risk, but the ee/ boundary will keep growing and the incentives point toward the paid platform. Flue is an Astro-org open-source project with a smaller community, no standalone company product I could verify, and meaningful API-stability risk this early. The counterweight is that Flue's pure Apache-2.0 licensing makes it the safer thing to build *on top of*.

The Decision Framework

Choose Mastra when: you are adding AI to an existing TypeScript application; you need memory, RAG, and evals out of the box; you want deterministic workflows with human approvals; your team wants a local Studio and dashboards; you prefer a vendor with funding, enterprise licensing, and a hosted option.

Choose Flue 2.0 when: you are building autonomous, sandboxed agents - coding agents, tool-running assistants; you need capabilities that change at runtime; you deploy on Cloudflare Workers and want Durable Object durability; you want pure Apache-2.0 with no ee/ boundary; you are comfortable with Vite/Hono conventions and assembling your own observability stack.

Consider another approach when: the flow is fully deterministic (plain code, cron, Temporal, Inngest); your organization is Python-first; you only need streaming chat (Vercel AI SDK); or you cannot absorb either project's upgrade churn - in which case pin versions and treat the framework as a library, not a platform.

I did not pick a winner, and neither should you until you have built your real workflow - with a tool call, a failure path, a human approval point, and something observable - in both. The good news: both are TypeScript, both are Apache-2.0 at the core, and neither locks you into a proprietary runtime at the start. The bad news: both will break your code if you ignore upgrades for a quarter, so your choice is really about which breakage pattern you can live with - weekly platform motion or a young project's big-bang rewrites.

What are you building, and which one are you leaning toward? Drop it in the comments.

Until next time, keep your systems thoughtful.