Show HN: Mastra – Open-source JS agent framework, by the developers of Gatsby

I get the same feeing when I first looked at the LangChain documentation when I wanted to first start tinkering with LLM apps.

I built my own TypeScript AI platform https://typedai.dev with an extensive feature list where I've kept iterating on what I find the most ergonomic way to develop, using standard constructs as much as possible. I've coded enough Java streams, RxJS chains, and JavaScript callbacks and Promise chains to know what kind of code I like to read and debug.

I was having a peek at xstate but after I came across https://docs.dbos.dev/ here recently I'm pretty sure that's that path I'll go down for durable execution to keep building everything with a simple programming model.

Thanks! The conditional `when` clauses live on the steps, rather than being represented in the workflow, and in fact when we built this for an example, the last step being called depended on the results of the previous two steps.

How would you simplify this?

Same frustration with frameworks like Langchain and Llama_Index let me to build a simple UI base Agentic freamwork that runs locally. https://github.com/ranjanprj/agentollama

Yeah, I also found this a bit unintuitive at first. I’m building a workflow engine myself (https://pgflow.dev/pgflow, not released yet), and I’ve been thinking a lot about how to model the DSL for the graph and decided to make dependencies explicit and use method chaining for expansion with other step types.

Here’s how it would look like in my system:

  new Flow<string>()  
    .step("llm", llmStepHandler)  
    .step("decider", ["llm"], deciderStepHandler)  
    .step("agentOne", ["decider"], agentOneStepHandler)  
    .step("agentTwo", ["decider"], agentTwoStepHandler)  
    .step("workflow", ["agentOne", "agentTwo"], workflowStepHandler);  

I knew it will be bad when I seen "by the developers of Gatsby", but this is pure comedy.

JQuery plugin for LLM.

Why not use Elixir for agents as Electric is already heavily invested? It’s a much better fit than JS.

Abhi is one of the best engineers I know. I’m excited that he and his colleagues are tackling this problem.

we have a tutorial that covers this!

https://docs.mcp.run/tutorials/mcpx-mastra-ts

you don't even need to use SSE, as mcp.run brings the tools directly to your agent, in-process, as secure wasm modules.

mcp.run does have SSE support for all its servlet tools in the registry though too.

Added support in this PR https://github.com/mastra-ai/mastra/pull/1957! Isn't shipped just yet but will be soon

Hey! Glad to hear you're excited about it! Yes, we're currently working on improving our MCP support in general - we'll have more to share soon, but part of that is supporting SSE servers directly

thank you!

If you ignore the word "agent" and autocomplete it in your mind to "step", things will make more sense.

Here is an example-- I highlight physical books as I read them with a red pen. Sometimes my highlights are underlines, sometimes I bracket relevant text. I also write some comments in the margins.

I want to photograph relevant pages and get the highlights and my comments into plain text. If I send an image of a highlighted/commented page to ChatGPT and ask to get everything into plain text, it doesn't work. It's just not smart enough to do it in one prompt. So, you have to do it in steps. First you ask for the comments. Then for underlined highlights. Then for bracketed highlights. Then you merge the output. Empirically, this produces much better results. (This is a really simple example; but imagine you add summarization or something, then the steps feed into each other)

As these things get complicated, you start bumping into repeated problems (like understanding what's happening between each step, tweaking prompts, etc.) Having a library with some nice tooling can help with those. It's not especially magical and nothing you couldn't do yourself. But you also could write Datadog or Splunk yourself. It's just convenient not to.

The internet decided to call these types of programs agents, which confuses engineers like you (and me) who tend to think concretely. But if you get past that word, and maybe write an example app or something, I promise these things will make sense.

https://aider.chat/2024/09/26/architect.html

"Aider now has experimental support for using two models to complete each coding task:

An Architect model is asked to describe how to solve the coding problem.

An Editor model is given the Architect’s solution and asked to produce specific code editing instructions to apply those changes to existing source files.

Splitting up “code reasoning” and “code editing” in this manner has produced SOTA results on aider’s code editing benchmark. Using o1-preview as the Architect with either DeepSeek or o1-mini as the Editor produced the SOTA score of 85%. Using the Architect/Editor approach also significantly improved the benchmark scores of many models, compared to their previous “solo” baseline scores (striped bars)."

In particular, recent discord chat suggests that o3m is the most effective architect and Claude Sonnet is the most effective code editor.

I don't get it either. Watching implementations on YouTube etc it primarily it feels like a load of verbiage trying to carve out a sub-industry, but the meat on the bone just seems to be defining discreet units of AI actions that can be chained into workflows that interact with non-ai services.

I don't work in prompt engineering but my partner does and she tells me numerous need for agents in cases where you want some technology which goes and seeks things on the live web and then comes back and you want to make sense of that found data with the LLM and pre-written prompts where you use that data as variables, and then possibly go back into the web if the task remains unsolved.

AI seems to forget more things as the context window grows. Agents keep scope local and focused, so you can get better/faster results, or use models trained on specific tasks.

Just like in real life, there's generalists and experts. Depending on your task you might prefer an expert over a generalist, think f.e. brain surgery versus "summarize this text".

One of the key limitations of even state-of-the-art LLMs is that their coherence and usefulness tend to degrade as the context window grows. When tackling complex workflows, such as customer support automation or code review pipelines - breaking the process into smaller, well-defined tasks allows the model to operate with more relevant and focused context at each step, improving reliability.

Additionally, in self-hosted environments, using an agent-based approach can be more cost-effective. Simpler or less computationally intensive tasks can be offloaded to smaller models, which not only reduces costs but also improves response times.

That being said, this approach is most effective when dealing with structured workflows that can be logically decomposed. In more open-ended tasks, such as "build me an app," the results can be inconsistent unless the task is well-scoped or has extensive precedent (e.g., generating a simple Pong clone). In such cases, additional oversight and iterative refinement are often necessary.

One way to think about it is job orchestration. You end up with some kind of DAG of work to execute. If all the work you are doing is based on context from the initiation of the workflow, then theoretically you could do everything in a single prompt. But more interesting is when there is some kind of real-world interaction, potentially multiple. Such as a websearch, or executing code, calling an API. Then you take action based on the result of then. Which in turn might trigger another decision to take some other action, iteratively, and potentially branching.

Without checking out this particular framework, the word is sometimes overloaded with that meaning (LLM personality), but actually in software engineering in general, "agent" generally means something with its own inner loop and branching logic (agent as in autonomy). It's a neccessary abstraction when you compose multiple workflows together under the same LLM interface, things like which flow to run next, and edge case handling for each of them etc.

Yeah, this is something we've heard as well. No particular feature right now but we did ship an agent in local dev to help people improve their prompts.

Surprised this is comment is not higher. Gatsby was one of the worst technologies I have worked with in my long career of working with various JS libraries and frameworks. Im sure the team is smart and capable, but I would not be advertising their work with Gatsby.

Same experience, I had the exact same thought. Was new to react and had to make a website… big mistake, wasted so many hours untangling the regex and hacks keeping together Gatsby over the next few years until that website was retired.

Gatsby never made sense to me. Weird design decisions I couldn’t find any plausible reason for. As soon as Next.js became capable of doing SSG I convinced my team to abandon Gatsby. Definitely a minus, sorry.

gatsby was one of the first static react frameworks, now you have things like nextjs remix astro etc... i dont think abandonware is fair, thats just the way software goes

The character Gatsby didn't function very well either (as far as being a successful person goes, I quite liked the book and he functioned well as a character) :)

However, the Gatsby CMS had a couple of things that were really interesting about it - especially runtime type safety through GraphQL and doing headless WordPress.

Some people don't like frameworks. Some people do. We have a little bit of experience building frameworks, so we figured we'd build a good one.

Couldn't agree more. This also looks mostly like a Typescript "port" of Langgraph, and I say "port" because Langgraph has a TS framework already.

True. That's the reason I see a lot of people dropping similar frameworks like LangChain recently: https://medium.com/thoughts-on-machine-learning/drop-langcha...

I agree, and it feels like JS is just the wrong runtime for agents. Really languages that can model state in sane ways and have a good concurrency story like Elixir make much more sense.

And here’s a fun exercise: ask Claude via Cursor or Perplexity with R1 to create a basic agentic framework for you in your language of choice on top of Instructor.

You could describe all frontend JS frameworks the same way: you spend 95% of time on content and mechanics of your webapp, while the framework provides the easy 5%.

We're just starting to do that and have a few TTS providers: ElevenLabs, OpenAI, PlayAI.

We hear a lot from people who are outgrowing the voice agent platforms and moving to something like pipecat (in Python), and we'd love to be the JS option.

If you'd like, feel free to reach out to me via email with your requirements and we can get a conversation going. I've built a few voice agent systems in both python and JavaScript and would love to hear about what issues you're running into. Might be able to build what you need.