Mastra vs LangGraph vs CrewAI

Method.This is drawn from each project’s current documentation and source, not from a benchmark — we have not built the same agent three times and timed it. Version-specific behaviour changes fast; the primary sources are listed at the end. What is durable is the axis these frameworks actually differ on, which is not the one the comparison posts use.

The one axis that matters

Framework comparisons usually tabulate memory, RAG, tool calling and observability, conclude that all three have all of them, and leave you no better informed. The useful question is what the abstraction obliges you to name — because that determines what is easy, what is awkward, and what you cannot express at all.

CrewAI: the abstraction is social

from crewai import Crew, Process

crew = Crew(
    agents=my_agents,
    tasks=my_tasks,
    process=Process.hierarchical,
    manager_llm="gpt-4o",   # or manager_agent=my_manager_agent
)
result = crew.kickoff()

The role-and-backstory design is often dismissed as theatre. It is not: it is a prompt-engineering convention with a schema, and for genuinely divisible work — research, then draft, then edit — it produces good results with very little code. The cost is that a meaningful amount of behaviour lives in prose fields interpreted by the framework, which makes that behaviour hard to test and hard to port.

Flows are the part worth knowing about

CrewAI also ships Flow, a decorator-driven orchestration layer that is considerably more precise than a Crew — and it changes the assessment. A Flow[State] has a typed Pydantic state, a @start() entry point, and @listen(...) steps that fire on completion of a prior step. Crucially, a step can be a direct LLM call, a single agent, or a whole Crew.

from crewai.flow.flow import Flow, listen, start
from pydantic import BaseModel

class ResearchState(BaseModel):
    topic: str = ""
    raw_research: str = ""
    summary: str = ""

class ResearchFlow(Flow[ResearchState]):
    @start()
    def research_topic(self):
        result = llm.call(f"Research the topic: {self.state.topic}")
        self.state.raw_research = result
        return result

    @listen(research_topic)
    def write_summary(self, research_output):
        # A step can be an LLM call, one agent, or an entire Crew.
        self.state.summary = str(summarizer.kickoff(self.state.raw_research))
        return self.state.summary

That composition — deterministic Flow on the outside, agentic Crew on the inside — is the shape most production CrewAI should probably take, and it is a much better answer than an all-agentic crew for anything with compliance or cost constraints. It is also less discussed than the role-playing crews the framework is known for.

LangGraph: the abstraction is a state machine

The trade is verbosity for control. You declare the state, the nodes and the wiring, and in exchange you get properties the others do not offer.

Durability is tunable rather than binary. Recent versions expose three modes — 'sync' persists before the next step starts, 'async' persists while the next step executes, and 'exit' persists only when the graph exits. That is a real latency-versus-recoverability dial, and picking exit for a long agentic run because it looked faster is a decision to lose the run on a crash.

The human-in-the-loop primitive is the strongest reason to choose LangGraph, and it is genuinely well built: a node calls interrupt(), the invocation returns with an __interrupt__ marker, and the caller resumes by invoking with Command(resume=...). The prebuilt HumanInterrupt type even carries an action request with per-request flags for whether the human may accept, edit, respond or ignore — which is the shape an approval UI actually needs.

Mastra: the abstraction is your application

Its distinguishing property is not an agent concept at all — it is that it treats the surrounding application as the primary context. Documented integrations cover Next.js, React, Astro, Express, SvelteKit and Hono, plus a Mastra Studio UI for interactive development.

For a team whose product is already a TypeScript web application, that removes an entire category of friction: no second language runtime, no Python service to deploy alongside your Node app, shared types between your agent tools and your API layer, one deployment story. For a Python team it is simply irrelevant, and no feature comparison changes that.

One caveat on this section: Mastra’s documentation is thinner on workflow internals than the other two, so if durable multi-step orchestration is a hard requirement, verify the current workflow semantics directly rather than assuming parity with LangGraph’s checkpointing.

The resume trap

This is the most consequential thing in this article, because it is a correctness trap that reads as a feature. The mental model people bring — the run pauses at the interrupt and continues from that line — is wrong, and the failure is silent.

# ✗ WRONG: the write happens twice.
def ask_human(state):
    db.audit.insert(...)             # runs on the first pass...
    answer = interrupt("Approve?")   # ...run suspends here...
    return {"value": [answer]}       # ...and on resume the WHOLE node re-runs,
                                     #    so the insert fires a second time.

# ✓ RIGHT: nothing before the interrupt but the interrupt.
def ask_human(state):
    answer = interrupt("Approve?")
    return {"answer": answer}

def record_decision(state):          # a separate node, after the resume
    db.audit.insert(...)
    return {}

The replay semantics compound it. Replaying from a checkpoint taken before the interrupt re-fires the interrupt and re-executes that node again, while nodes before the checkpoint and after the interrupt do not re-run. So the same node can execute three times across one logical approval, and the count is visible in the library’s tests rather than in a warning.

The rule that follows: an interrupting node should contain nothing but the interrupt. Side effects go in a node that runs after the resume, or they are made idempotent — which is the same discipline as everywhere else an agent can retry itself. See idempotency for agent actions for keying that survives a re-execution.

This is not a criticism of LangGraph. Re-execution is the correct implementation of resumable execution over checkpoints — the alternative would require suspending a Python stack frame. It is a criticism of how rarely it is stated, given that the natural way to write the node is the broken way.

When to use none of them

The loop is not the hard part and it is not where any differentiation lives. If that is all you need, take one and move on — the Agent SDK is one such harness, and the API tool runners are another.

The cost of leaving

Worth weighing at selection time, because this category is young and you will likely make this decision again. The question to ask of any framework: if this project were abandoned tomorrow, what would I have to rewrite?

In every case the tool implementations are yours, which is the practical argument for keeping tools in plain functions behind a thin adapter rather than defining them with framework decorators. That is a small discipline at the start and the difference between a port and a rewrite later.

Choosing

Durability comes first because it is the requirement you cannot retrofit cheaply. Adding roles to a graph is an afternoon; adding checkpointed resumable execution to something that never had it is a rewrite.

And whichever you pick, the layers the framework does not cover are still yours: what the agent is permitted to do without a human, and the record of what it did. No framework on this list supplies either — see the seven-layer stack for where they sit and why they are the ones that decide whether a pilot reaches production.