DEV Community

Jim L
Jim L

Posted on

I Switched from LangGraph to Mastra for My TypeScript Agents — 18 Hours vs 41

I spent three weekends in February trying to get a LangChain/LangGraph agent working in a Next.js app. By Sunday night of the third weekend, I had 41 hours logged, a mass of Python-to-TypeScript bridge code, and an agent that completed about 87% of what I threw at it.

Then a friend sent me a link to Mastra. Four days later, I had the same agent running natively in TypeScript. 18 hours total. No bridge code. No subprocess spawning. No serialization headaches between Python and my frontend.

I want to talk about what actually changed and where the rough edges still are.

The problem with Python agents in a TypeScript stack

My project is a multi-step research agent — it takes a topic, searches several sources, cross-references findings, and produces a structured summary. Standard stuff. The architecture is Next.js frontend, Vercel deployment, Postgres for state.

LangGraph is excellent software. The graph abstraction for agent workflows makes sense. But here's what nobody tells you upfront: if your entire stack is TypeScript, using a Python agent framework means you're now maintaining two runtimes, two dependency trees, two deployment pipelines, and a serialization layer between them.

I tried the LangChain.js port first. It's always a few versions behind the Python original. Some features exist in docs but not in the npm package. I filed two issues that turned out to be "not yet ported from Python." The community examples are 90% Python. Stack Overflow answers are Python. The mental overhead of translating between the two languages while debugging agent logic was genuinely draining.

So when I saw Mastra — TypeScript-native, built by the team that made Gatsby, YC-backed, sitting at around 22K GitHub stars — I figured it was worth a weekend experiment.

What switching actually looked like

Mastra's mental model is closer to how I already think about TypeScript applications. You define agents as objects with tools, instructions, and a model. Tools are just typed functions. Workflows (their equivalent of LangGraph's graphs) use a step-based API that chains with .then() and .branch().

Here's what surprised me: I didn't need to learn a new paradigm. The agent definition reads like a regular TypeScript module. The tools have Zod schemas for input/output validation — something I was already using everywhere else in the app. Type inference flows through the entire chain.

Rewriting my research agent took about 12 hours. The remaining 6 hours were spent on the retrieval pipeline (Mastra has a built-in RAG module with chunking and embedding support) and testing.

The part I dreaded most — the multi-step workflow where the agent decides which sources to query based on initial results — turned out to be simpler than the LangGraph version. In LangGraph, I had conditional edges between nodes, a state schema in TypedDict, and a routing function. In Mastra, it's a workflow with .branch() that returns the next step name. Both work. The Mastra version is about 60% less code and doesn't require me to think in graph theory.

The numbers that actually mattered

After running both implementations against my test suite of 200 research queries:

Task completion rate: Mastra agent hit 94.2% vs 87.4% with LangGraph. Some of this is probably down to me writing better tool definitions the second time around, so take the comparison with appropriate skepticism. But the type safety caught several edge cases during development that I'd missed in the Python version — malformed tool outputs that would silently pass in Python but threw compile-time errors in TypeScript.

P95 latency: 1,240ms (Mastra) vs 2,450ms (LangGraph). The LangGraph number includes the Python subprocess overhead and JSON serialization round-trips. Not a fair comparison of the frameworks themselves — more a reflection of what happens when you eliminate a language boundary. If you're running LangGraph in a pure Python backend, the gap would narrow considerably.

Deployment: This is where I felt the biggest quality-of-life jump. vercel deploy and you're done. 90 seconds. No Docker container for a Python runtime. No Lambda layer for dependencies. No cold start penalty from spinning up a Python process. It's just a Next.js app with some extra API routes.

Where Mastra is still rough

I'd be dishonest if I didn't mention the gaps.

The ecosystem is young. LangChain has integrations with seemingly everything — obscure vector databases, every LLM provider, dozens of document loaders. Mastra covers the major ones (OpenAI, Anthropic, Google, Pinecone, PGVector) but if you need something niche, you're writing a custom integration.

Documentation has improved a lot since I started, but there are still areas where I had to read the source code. The workflow error handling section, in particular, could use more examples.

The community is growing fast but it's a fraction of LangChain's. When I hit a problem at 11pm, there were maybe three relevant GitHub discussions. With LangChain, there would have been a dozen Stack Overflow threads.

And the agentic patterns — reflection, planning, multi-agent orchestration — are less battle-tested. LangGraph has been used in production by hundreds of companies. Mastra is getting there, but the edge cases in complex multi-agent setups are still being discovered.

Who should actually consider switching

If you're running a Python backend and LangGraph works for you, I see no reason to switch. The framework is mature and well-supported.

But if you're in the situation I was in — TypeScript stack, deploying to Vercel or Cloudflare, tired of maintaining a Python sidecar just for your agent logic — Mastra removes a real and ongoing source of friction. The 23 hours I saved on initial setup will compound every time I add a new tool or modify a workflow, because I'm working in one language instead of two.

I'm three months in now. The agent handles roughly 400 queries per day in production. I haven't regretted the switch.


Running TypeScript agents in production? I'm curious what framework you landed on and whether you hit similar Python-bridge problems. Drop a comment — genuinely want to compare notes.

Top comments (0)