EPISODE 1866

[INTRODUCTION]

[0:00:01] ANNOUNCER: Most AI agent frameworks are back and focused and written in Python, which introduces complexity when building full stack AI applications with JavaScript, or TypeScript frontends. This gap makes it harder for front-end developers to prototype, integrate, and iterate on AI-powered features. Mastra is an open-source TypeScript framework focused on building AI agents and has primitives such as agents, tools, workflows, and RAG. Sam Bhagwat and Abhi Aiyer are Co-Founders at Mastra. They join the podcast with Nick Nisi to talk about this state of front-end tooling for AI agents, AI agent primitives, MCP integration, and more.

Nick Nisi is a conference organizer, speaker, and developer focused on tools across the web ecosystem. He has organized and emcee'd several conferences and has led NebraskaJS for more than a decade. Nick currently works as a Developer Experience Engineer at WorkOS.

[INTERVIEW]

[0:01:14] NN: Welcome to Software Engineering Daily. Today's episode features the founders of Mastra, and I'd like to welcome to the show, Sam Bhagwat and Abhi Aiyer. How's it going, guys?

[0:01:23] SB: Hey.

[0:01:24] AA: Good to be here.

[0:01:25] NN: Great to have you. Sam, why don't you go first and introduce yourself?

[0:01:29] SB: Probably, I'm best known for being the Co-Founder of Gatsby. I worked at a few startups around the valley before that as an engineer. I'm also the author of a book called Principles of Building AI Agents, and now the Co-Founder and CEO of Mastra.

[0:01:48] NN: Nice. Welcome to the show. Happy to have you. I've definitely heard of Gatsby. Abhi, why don't you introduce yourself?

[0:01:54] AA: Yeah. I'm Abhi Aiyer. I'm the CTO and Co-Founder of Mastra. We also have a third co-founder. His name is Shane. Just wanted to pour one out for him. Yeah, and I used to work at Gatsby as well very early on, and that's how Sam and I met. Then, I also worked at Netlify, because we got acquired by them. I'm sure we'll get into that, but that's how I got here.

[0:02:15] NN: Nice. Yeah, just digging right in, how did you come together on Mastra? Was it something that was born out of something that you worked on Gatsby or, yeah, I'm just curious how it got started?

[0:02:26] SB: Probably the best way of saying it is that it was born out of frustration. After Gatsby and we left Netlify at various points, but we were working in building a CRM. We thought that we thought we did a lot of fun building dev tools and we were going to build something new. It actually turned out that as we were building the AI parts of the CRM, which we called Kepler, and we were building this CRM for, all three of us together for about nine months or so. We started using - building the AI parts of Kepler and using the TypeScript AI libraries that were available at the time. It just didn't feel like any of them were up to snuff.

[0:03:06] AA: Yeah. We were pretty exhausted from doing DevTools for so long. We thought a CRM game would be a great place for us, which we slowly realized that it probably wasn't.

[0:03:18] NN: What timeframe is this? Around what year?

[0:03:20] SB: This was in October of last year, so October of 2024, when we decided to pull the plug on the CRM and start building Mastra instead.

[0:03:29] NN: Nice. Okay. AI has been around for a while, in its current form, ChatGPT and all of that, and the rise of agents is coming. One thing that's very notable, and we should talk about what Mastra actually is. But before we get to that, it's written in TypeScript, which a lot of AI tooling right now is written in Python. What was your drive to buck that trend and go with TypeScript?

[0:03:53] AA: I think, originally, it was just super self-serving, because we were trying to build AI features into our product that we were building, and we were all TypeScript engineers and very much in this industry and community for so long. Also, maybe where DevTools snobs a little bit, but we did give things a fair shot. The fair shot, meaning we actually tried to implement other people's libraries. There was a point where you were like, any time you, as a DevTools person, you think like, "I'm just going to go fetch from OpenAI directly and just do this stuff myself." Then the amount of people like us, telling us the same thing, it was just a natural thing, like we had to do this. It has to be in TypeScript, because that's the whole point of what we were trying to do in the first place.

[0:04:39] NN: Nice. Yeah. It being in TypeScript was a major appeal to me just looking into it and getting started and playing around with it, because it was one less thing that I had to be a complete novice at, which all of the agent stuff when I was getting started was complete. Don't know what I'm doing. If I threw another language on top of that, then I really wouldn't know what I was doing, but it helped to ground me a little bit and get going. From there, let's talk about what Mastra actually is. How would you describe it?

[0:05:05] SB: Mastra is a TypeScript framework for building AI agents. That means we have all the primitives that you need, whether that's an agent running in a loop. Whether that's a workflow graph, whether that's EVALS and tracing, memory, tool calling, RAG, a local dev playground. You can build an agentic feature into your SaaS app. You could build a whole new agent from scratch that's aimed at a specific industry, or pain point. You could do internal automation of various types of workflows with LLMs and building, tooling to do that within your organization.

We've seen folks build all sorts of interesting, fun use cases, whether that's a personal email manager, or someone, or Japanese community built some anime generation and anime writing and analysis is a big need to see what they were doing there.

[0:05:57] AA: When we first started building the framework, we only had a couple of primitives. We realized that there's just so many things that you have to understand when you're doing "AI engineering." We may have started Mastra with two primitives, like tools and agents, and that was cool. Then we slowly realized like, oh, there's this RAG thing. Oh, people need workflows. Then the number of primitives grew, but they had to be in a very sensible way. Then we learned that a lot of people were learning AI engineering through Mastra's primitives, because we're essentially self-documenting and educating people what exists.

[0:06:36] NN: Yeah, definitely. I definitely fall into that camp of learning what all of these tools are in primitives through what Mastra provides and why I would use that. I will say, for the longest time, when I was getting started with it, I just couldn't, for some reason, wrap my head around what the heck an agent actually is. Could you give a description of in your words, what an agent is?

[0:07:00] AA: I was at a panel where they asked the same question. I want to give the same answer, which was mine was very stupid and poetic. Everyone on the panel had a different answer. I think the thing that we're trying to do at Mastra is to make this new wave of agents, which is a loaded term, which is just a box of compute and intelligence, if you put it down. An agent has a lot of things that defines intelligence. An agent can speak, it can execute workflows, which are for a human, maybe a playbook, or it might be muscle memory. You have memories as humans, so do agents. We're trying to reflect the human intelligence through our primitives. I think that's what really an agent is, allows you to do all that stuff. But the other people in the panel, they were like, "Oh, it's just a loop." It is a very loaded term.

[0:07:50] NN: Great. The confusion that I had was like, how is an agent different from just like, ChatGPT, like a prompt? Is it just a chat tool with some fancy prompt on the beginning of it? Is that how it gets started? When you're talking about the loop, is it that where I ask a question, or give it some text, it responds, and then we go back and forth and that's the loop?

[0:08:14] AA: Yeah. See, this is where it gets super loaded. Because some people could define an agent as a one LLM call that maybe has tools on it. In that case, if you're using ChatGPT, ChatGPT has internal tools that it calls, because you don't really expose your own tools there. Then you could say, that interaction is an agentic interaction. I think it gets more agentic when there are multiple terms that are happening in one request. For example, I ask it to do something with unstructured data, right? I'm using just a prompt. Then now, there's a reasoning section to happen of like, what do I need to do, execute, and then also, what do I need to return? Which then, may cause other type of interactions, or other requests that need to happen.

Yeah, I think it's very much in a spectrum. That's how we think of it here. It's like, agentic is a spectrum. It could start as just LLM calls. It could progress into structured workflows, where you are the puppet master and you're calling all the LLMs, but the steps themselves are who knows what's going to happen, because it's agentic. Then you get into this middle ground where you have maybe a single agent that does a bunch of things and orchestrate stuff by using its LLM and its tools. Then finally, you get the AGI thing that they sold us a year ago, which is you can just do unstructured thing to a network of agentic components and magically all this stuff will just happen and the world will become a better place. It's probably a spectrum.

[0:09:48] AA: Yeah, I love that. I think if you're doing code execution, let's say, and then you're sending the feedback and the error states back into the agent, that's higher on the agency spectrum. There are things that you can score it something higher, the more of these advanced elements it has.

[0:10:06] NN: All of those other pieces, like the workflows, the tooling and all of that, how does that play into - does everything start with an agent and then it goes into those from there, in Mastra specifically?

[0:10:18] SB: I would see them as put it out like you have these different primitives that you would compose in interesting ways. For example, agents by themselves have to decide which tool to choose. For example, agents aren't very good if you give them more than, let's say, eight to 10 different tools, even if you write really good tool descriptions. For example, maybe you could group the tools that you're giving an agent into two different categories and wrap them into maybe two workflows, so you could have an agent that's calling workflows.

You could also have a workflow that's doing an agent handoff, where one agent handles perhaps, asking the user for some requirements and then we hand it off to another agent that's doing code generation. It's sort of see them both as like, within Mastra how it works is that they are these separate primitives, and then you can compose them in any way you want. I think that's really the power. Rule of two things, it's the power of AI engineering in general is having these different primitives you can compose in interesting ways, but it's also the power of Mastra as a framework.

[0:11:22] NN: When you say composing them, is that what workflows are composing all of these tools calls together, or how does that work?

[0:11:28] AA: Yeah. For composing them, all the primitives in Mastra, so we'll start with agent, for example. Agents can have tools. It could also have workflows that get executed as well. Essentially, those get executed as another tool that it has in its arsenal. From the reverse perspective, a workflow, you can start with a workflow, and for a step of a workflow, you can pass it in an agent, or you could pass it a tool. Because now these steps are you're in control. Now from that perspective, you're in control, you're doing a very deterministic thing. I mean, our workflows do have control flow and branching, etc., that you need, but the steps themselves are leveraging the agent primitive. If you really want to just yellow it, we have a primitive called agent network where you pass all the primitives in there and then you just pray. Then, that's what happens.

[0:12:23] NN: All of that is to try and bring some determinism to the task that an agent is trying to do?

[0:12:28] AA: Yeah. The reason why we came up with workflows in the first place as the important primitive is that at the time, especially and even now, the models aren't good enough to just execute complex workflows. A lot of the times, the engineers that we're talking to to pretty much extract all these features out from when we're talking to them, they actually know what they want to do. Why do you need to prompt anything? You just write some code. Just because you could use an LLM doesn't mean you have to. Then we learn that it's what they're executing at the points of the graph that they know that they're going to. It's that during the execution is where they want to do LLM calls, or anything like that. Beginning, our workflow system was super trash, too, because we didn't really think it was that important. Almost with, Sam remember, we almost didn't want to do it at all.

[0:13:16] SB: Yeah. We debated that. We're like, well, maybe you should just use Ingest, or Temporal, or another workflow engine. One of the reasons we decided to build our own was that we saw that in AI engineering, having this workflow primitive has tracing built in. It has a development environment where you can test it and replay it. It's relatively more important, because you're wrapping these non-deterministic agents, these non-deterministic LLMs. Being able to just observe what's going on at every step is really important, because usually in software engineering, if something is returning different output, depending on, "Hey, if I ran my CI at 11 p.m. versus 3 p.m., I had some time zone issue that only came up, if UTC is different than PST, or whatever." We call it non-deterministic and we say, that's a bug.

In engineering, it's actually just part of the game, because you're working with these LLMs that are inherently non-deterministic. You have to add all these guard rails around them to get them to - They're very powerful, obviously. We all know they're very powerful. But you have to add these guard rails around them to get them to behave properly. The idea that we have in Mastra of the structured workflow graph in this primitive that we have is one way that we do that.

[0:14:29] NN: Let's take a step back and help to paint a picture of when someone might reach for Mastra, or reach for creating their own agent workflow. Maybe, you start with an example of a great idea that you've seen, or a great intro into this that you've seen as people adopt Mastra?

[0:14:45] SB: Sure. Yeah. I'll give an example of a company that we know very well. They're building something to generate CAD diagrams for, like they're working in the aerospace industry and they're ingesting these hundred-page long PDFs of part manuals and stuff. Then you need to link these things up in some electrical circuit, depending on the capacity and the wattage and the voltage and all this stuff. You can ingest some of the stuff from the manual. It is a task that you need to extract a bunch of information and feed it into an LLM in a creative way and feed the right amount of context. They're using Mastra to wrap a bunch of these pieces and components in order to do that. That's a fun example, where hates LLM's in a novel industry.

Another one that comes to mind, there's another company that's using it, Mastra. They're making software for veterinarians. If the veterinarian is going and looking at your dog, when you bring your dog into the vet, they're talking to you and they're making notes verbally and it translates the transcript of the conversation and the things they're saying. It takes that and it generates action items in their task management system that they built into their software. You can imagine how you wrap an LLM where you can take this raw text and end up with some structured data at the end of the day that delineating a list of tasks, or representing a particular CAD diagram.

[0:16:13] AA: Yeah, when we first started in Y Combinator, we were in the batch that everyone was focused on verticalized agents. Those are our first users of trying to build verticalized agents. That's where we learned what primitives need to be created to serve them. A lot of our initial real-world use cases came from people doing either bridging the real world to the AI, through back of house, or some type of office type of thing. Or they're trying to do assistant co-pilots in other industry, aerospace and stuff.

Since then, it's been all over the place, like internal tooling and things that Sam mentioned. It's just exploded from there. Glad that we did the vertical agent stuff first, because then we came to the market with a lot of primitives that people learn over time.

[0:17:03] NN: Can you define what vertical agents are?

[0:17:06] SB: You can think about any of these kinds of real-world industries. Maybe you're in finance, maybe you're in defense or manufacturing, and you have a lot of things that are specific to your particular industry. There's a lot of SaaS that maybe it's a SaaS for manufacturing, or maybe it's a SaaS for aerospace, or maybe it's a SaaS for finance. There's a specific workflow in finance. The difference obviously is like, now we're making agents that can work on and autonomously create, complete tasks within that, or they can be co-pilots who assist humans in solving tasks, rather than just being a software that can record, "Hey, I did X thing. I did Y thing." And a human is checking off all the items in the checklist.

Maybe the agent can generate the checklist. Maybe the agent can complete some of the items in the checklist. It's a software, but it's doing work for people, or helping them so they work within their industry.

[0:17:59] AA: Yeah. They were telling us the target salary rate, there's two levels to it. You're trying to replace the 50K USD salary, or you're trying to replace the highly skilled labor salary, like 200K or whatever. You got these two groups of people working on both ends of that skilled labor section.

[0:18:18] SB: I think more broadly speaking, like I was saying, some of the first folks we had using Mastra were doing these kinds of things. Since then, more broadly, a lot of people are like, "Hey, I'm trying to help the sales people inside my company process a lot of the information they're trying to process faster than they'll build an assistant to help them do that." That's the internal tooling stuff.

Or they'll have an existing SaaS app at scale and they say, "Well, I need to build in an agentic screen to help people find information within the SaaS app." It's not just some chatbot on the side. It's really a full screen takeover, where it's like, okay, I'm going to go through and I'm going to go do some research that's very specific to this field. Then I'm going to summarize that and check the results of that. Anyways, so they're building these screens within their software applications that they're working on, that have these agenda capabilities and co-pilot capabilities, but it's an existing SaaS app that's running at scale.

Then, I think, also, there's just a lot of people that if we rewind back to 2016 or 2017, a lot of people were using Gatsby to build personal blogs and portfolio sites, right? Then you fast forward in that world, the jam stack world, or whatever, people start using Gatsby and they start using Next and they start building maybe an e-commerce site, or they started building their company's website with Gatsby and with Next, right? I think, there's a lot of people that are just, hey, I'm playing around with these technologies.

Our co-founder, Shane, created a storybook app, where it would generate stories for his daughter, his three-year-old daughter. It wraps the image generation, capabilities from OpenAI. It's like, it's just such a cute thing. This is probably a story you could go read Piper. This is amazing. There's a lot of these kinds of use cases too, where people are just playing around with it for our own fun and benefit and games.

[0:20:07] NN: That's awesome. I definitely need to steal that storybook idea. That would be great. Yeah, just thinking about it in terms of that, because I feel like that's a good, everyone understands stories, right? There's lots of ways that you could approach that. I've, of course, done that with my kids where I give ChatGPT like, here's a list of things that my kids want in the story. Plus, here's maybe a lesson that I want to teach them. Like, oh, be nice to your little brother, or things like that. Then, it can generate a story from that. This is going deeper where it can actually create a book with images and the images could make sense between pages and -

[0:20:41] AA: Yeah. You have to keep the characters maybe consistent, right? You're not just generating five different images that are disconnected from each other. You're going to have consistent character representation across the story. You have to consistent narrative formatting. There's a lot of thought that goes into creating it in that level of quality that you can build into your agent.

[0:21:00] NN: That's fascinating. Yeah. There's a lot to that. I'm just trying to think of how I would get started with Mastra, and you have a lot of these primitives. I guess, how do people who are getting started with it learn how to orchestrate all of them together? Is that something that the docs cover really well? Is it just intuitive as you get in there? Is it trial and error?

[0:21:20] SB: It's both and all the above.

[0:21:22] AA: Yeah. It's definitely all the above kind of thing. Okay, at Mastra we think docs is our second product. It's as important as anything we build. In doing so that - I mean, community as well is another product. In doing so, the docs have to be super good. We try to make our docs amazing. We think they're decent. We still have a long way to go. Then, we started seeing a trend of people are just hanging out in their IDEs, so we should meet them where they are. We made an MCP docs server, so you can get the docs into your IDE and ask questions and stuff. You can also ask it to write code for you. That was a good way to introduce people to Mastra.

Then eventually, even with the docs and stuff, they don't teach you architecture. They don't teach you, essentially, what to do, so we created another extension of the MCP docs, which is the Mastra course called Mastra 101. You can actually take a Mastra class from us within your IDE through the Mastra docs server. You just say, if you have it installed, you just say, start course, and then it'll go through a bunch of chapters that our co-founder, Shane, meticulously developed to teach Mastra. Then, that's another place that once again, second product, right? We're consistently iterating on how do we educate people where they are.

[0:22:49] NN: Actually, features that you wouldn't even think about, is that that course can speak to in whatever language you speak, right? It can speak to you in French, it can speak to you in Japanese. Because it's the LLM teaching you. As far as we can tell, it's the first course released as an MCP server in the world. Maybe someone else did it, but we aren't aware of it, and no one else has been able to tell us like, "Hey, someone else did it first." We think we're the first.

[0:23:15] NN: What a brilliant idea. I hadn't considered using MCP like that. I guess, to ask a more technical question on that, the MCP piece of that, is that keeping track of your state through the tutorial, or through the course? It's like, I'm not going to give you step two until you've shown me that you've completed step one. All along the way, it can help you debug that, because it's just using the LLM to do that. Is that what the MCP is providing to it?

[0:23:40] SB: Yeah. You give us your email, of course, so we can show you the results and stuff. Then from there, we're just tracking your course state. You can always reference it. You can always say like, "Oh, I'm done with all the courses and stuff and go through it and stuff." Yeah, that's all there. People can track their progress. It looks really nice, too.

[0:23:59] NN: Nice. Is that built with Mastra?

[0:24:02] SB: It is.

[0:24:03] AA: Yeah.

[0:24:03] NN: Nice. That answers another question.

[0:24:05] SB: Yeah. When MCP started taking off, we created an MCP, or MCP primitives, so you can build an MCP server, you can build an MCP client. You can build those using Mastra. We see a number of folks doing that.

[0:24:18] AA: We got so lucky on the MCP hype, because it was January or November, actually. Because for Mastra, we were thinking like, "Oh, man. We're going to need to get all these tools. Then we're going to build a bunch of tool integrations." Then we discovered MCP the next day, and we were like, "Should we just do this instead?" Then we just took a bet, and then it was good. We had MCP support from the beginning.

[0:24:41] SB: Everybody was releasing MCP registries. We were like, "Our friends are releasing MCP registries. What if we released an MCP registry-registry?" Then that went viral on Twitter. I think, maybe it was the metaness of the joke, but lots of people were like, "Well done. Yeah." Here's the thing, is that's actually it was a joke that became a feature in a way, because tool discovery for MCP is a real thing.

[0:25:08] AA: Yeah. Anthropic is making the registry API. I don't know. A lot of things we do are meta on purpose, because that's the way we think. We're a framework, so it has to be meta, but it's also really funny. It's also funny, because you don't know if we're serious or not, because we are kind of serious, but we're also kind of not. The registry-registry was epic, because people were like, "Wow, what a great idea." We originally released that as a joke.

[0:25:37] SB: We got lots of inception memes. I want to go deeper.

[0:25:42] NN: All the best tools are like that.

[0:25:43] SB: If you die in this, you die in real life.

[0:25:48] NN: There's a couple of questions that came out of this that I wanted to ask. On the MCP side, MCP stands for Model Context Protocol. It's a way to give an LLM, or an MCP client, cloud desktop, cloud code, cursor, any of those. The ability to act on your behalf, or to get information from sources that it may not have information from, but also actually, go and execute tools. At the end of the day, it's just a rest endpoint that the LLM knows how to hit and get data, send data to and get data back from. My question is around that, you said that you're on there from day one. How does that relate to, I guess, the tools in Mastra? Is that the same thing? Are they different? Because I think of MCP a lot as tooling, but should I think of master tools in the same vein, or are they different?

[0:26:37] SB: One way of thinking about that is that an MCP server, like an agent is a container for tools. You could imagine, if you have a bunch of tools, you could put them into an MCP server and you could just give it to your local windsurf agent, or whatever and see like, hey, how does the windsurf agent interact with these tools when I put them in an MCP server as a container and give it to them. Great, that's what the MCP primitive is. Because it's this decentralized way of interacting with tools that you don't control, people have created these MCP servers that wrap tools to access, GitHub or Notion, or all these interesting third-party services.

We have to write lots of integrations to do our job, but we hate writing integrations and nobody wants to write integrations. In some ways, these MCP registries have ended up being this decentralized integration hub, that now your agents, your master agents can interact with, because your agent can take in MCP servers. If you feed in an MCP server as a tool, essentially, it will be able to access any of the tools contained in that remote MCP server that someone else maybe wrote, that you maybe had nothing to do with, but someone else created this functionality. Wow, now my agent is even more powerful, because it can use all this third-party functionality that someone else has built.

[0:28:00] AA: The low-key benefit of that is the MCP server doesn't have to be written in JavaScript. You could use tools from all over the communities that serve your purpose, but you're still connecting from your JavaScript written agent, or application. We do support you writing your own tools, of course. So, you can write your own functions for tools and they work. We think of MCP like a better NPM now for this, but there's no governance there just yet. Yeah. You can also just use import from NPM and then make your own tools as well, but might as well just go on the MCP train.

[0:28:36] NN: Yeah. Nice. I love that. It's so much extension for free, effectively, for all of this. That's awesome. The other question I had that came out of that, the discussion around your docs was treating docs as a second product. I have used the Mastra docs MCP immediately. It was like night and day difference, adding it and then it just knew everything. Made it really easy to get up and going and it knew what I wanted to do, and it knew what the capabilities of Mastra were right out of the box.

My question is, that's great when I know that I want to use Mastra. My question is around being a dev tools company and having this new-ish dev tool that may not be in the memory of LLMs. It might have come out after their training dates, right? How do you see that? How do you see marketing a dev tool in today's age, as you're consistently getting more and more people that are not going to go to Google to ask, what tool I should use to build agent? They're just going to ask ChatGPT, or Claude. Is that something that you think about?

[0:29:37] SB: We think about it a lot. I mean, honestly, this is our second time go around, and one of the great things about open source is the community and the fact that people can build things and share them with other things. Part of the community is also, you can show up at AI engineer in SF and it turns out, someone else is running a workshop on Mastra and showing people how to use Mastra, and you're like, "Holy crap." I'm showing up at a conference and someone else is running a workshop on this tool that we all built. This is crazy. This is amazing.

We also wrote a book. This was just this idea that came to us one day when we were just like - The book is called Principles of Building AI Agents. It's again, it's 140 pages and just walks through all the, what is rad? What is prompting? How do you write good prompts? What is an agent? What are the tool calling? It walks through all the core concepts. That also just came after we've done a lot of these kinds of white boarding sessions with other people that were trying to build agents and we just had these interesting conversations and had these - every time we had that, we'd shared some insight, people were like, "Oh, wow. This is really interesting. I didn't think that maybe I should be splitting up this one LLM call into 12 different LLM calls, instead of trying to have this one LLM call decide whether these 12 pieces of information, maybe I should just parallelize them and split."

We just had so many of these conversations and we're like, oh, it feels like everybody's figuring out how to do this, and maybe we should just write a book at it. I write pretty fast. And so, we already had docs that were an outline and a taxonomy, almost of those different concepts. Except, when you're looking at docs, it's 20% explanatory text and 80% code. We just took that, but then flipped it where we expanded the explanatory text, where it was like, 80% explanatory text and 20% code, and some historical background. There's a couple of weekends and we just kept writing and kept writing and kept writing. Then all of a sudden, it was 90 pages and we're like, "Okay. I guess, this is publishable." So, we published the book.

The reception has been really incredible. I think a lot of people have said like, "Hey, I keep hearing about agents. But when I read the book that you guys wrote, it all made sense to me and actually understood how I would do this." I think the reception has just been, we've been really humbled and we try to pass out a lot of copies of books at events and such now.

[0:31:56] NN: I can confirm, the book is great. I put a lot of pieces together in my mind. Yeah, plus one on that.

[0:32:03] AA: For the LLM, SEO technical bits, though, we do do LLM.text and full text and all that stuff. Then it's pretty much our game there. We're starting to get into ChatGPT responses now, but that's probably just because we're all over the Internet right now. There are actually companies in our YC batch that its job is to help you get on to LLM responses. That's their business. There's probably a whole little playbook that they have to do that.

[0:32:35] SB: Yeah. One of the things, too, is just about the model is basically, scan the Internet, especially when you put them in deep research mode, they scan the Internet and they pick up what's on the Internet. When your community members and this happens a lot, right? Tutorials about Mastra, that gets picked up. We didn't have anything to do with that. Someone just got really excited about Mastra and order a tutorial, and sometimes that tutorial is in Japanese, or whatever, because there's a huge Mastra community in Japan. That's been also one of the biggest things that has probably helped us on that front. It's just the community being excited, and writing things that gets picked up.

We've talked to other dev tools, folks, [inaudible 0:33:12]. What basically happens is when your tool has become the consensus choice among developers, the models can figure that out just by reading the Internet and seeing how people are describing it. When your tool has become the consensus choice, you almost get an amplification effect. I think that's great, because what that says is that you should build a great product that people love. If you build a great developer tool that people love using, everyone feels is the right thing. If you are successful on doing that, then the models will surface that to people who are coming in and asking them.

[0:33:49] NN: That makes perfect sense. It seems like, what we're doing to get your name out there for people to use, it's all amplified by these tools. They know how to surf the Internet, just like us. That's good. Then getting into actually using these tools, as new tools come out, your position in the perfect spot with your own docs MCP that immediately just gives all of the knowledge to the LLM to help you. That's great.

[0:34:13] SB: One of the other things that's really helped us a lot, we've gotten the band back together from the core team that was at Gatsby. I think we all working together and we've done this before. And so, we think we can work together pretty quickly to build great stuff. Honestly, that's probably the biggest thing working in our favor is just having a lot of great folks that like working together and have built an open-source JavaScript framework before.

[0:34:40] NN: Nice. Yeah. Yeah, for sure. One question I was going to ask is, Abhi, you mentioned almost stumbling into MCP, just being there, right there at the right time to jump on it. I'm curious if there have been any other decisions, or things that haven't panned out so well that you've had to pivot from.

[0:34:59] AA: First thing we did, we tried building a prompt builder, like a utility function that helps you build prompts. This is when prompt engineering was all the rage, and actually, models at the time were okay with XML tags and stuff, but now it really doesn't necessarily matter. we built something like that. Then, that's when we really learned that we should listen to our community more, because we posted an experimental exploration. We got a bunch of feedback from our - At that time we had nobody really in Discord. I'm sure nowadays, we get a lot of opinions. But at the time we had some early contributors are just like, "This is why I would never use this." It was a bunch of valid reasons. We were like, "Okay. Let's scrap this."

We tried building a MCP registry ourselves. Then we tried to get other registries involved early. But then with the lack of - Anthropic owns inspect and the governance is hard to try to get in there and shake some motion up. We just did the registry-registry thing, and then we'll maybe revisit stuff like that. The last big one that I remember is our initial version of workflows would never have worked for what we were trying to do. We built it half-assily in the beginning, and then we kept going on it, because we were too far in, much like many developer teams get into. You're too far in and you can't go back. Then you realize that you have to just go back. That was a big time sink for us. I'm glad we did, because now we have a lot of power that we can then use going forward.

[0:36:43] SB: There's been other times, it's just taken us the time to find the right thing. Initially, we knew we wanted to work with ASCK, which is the library from Versailles, as a model routing layer. the First way that we did it was we were republishing a bunch of their packages with a little bit of a wrapper. The import structure was too long. Then we were finally like, why don't we just expose their API? So, we ripped out our whole model routing layer that had been built on top of their model routing layer. Just said, use their model routing layer, while we were trying to figure out how to like, with it, but it wasn't the right API. That and this new workflow engine that we launched in March, those were the last two big re-architectures. That one was in January and then the workflows, we called it vNext at the time was in March. Those are the two big re-architectures that we've had to do over the nine months we've been working on this.

[0:37:37] NN: Nine months. That just got me thinking about how different the world was nine months ago.

[0:37:43] SB: Yeah. AI time is two to three, or four times as fast as normal time, I think.

[0:37:47] AA: It's just something different is happening in this part of the region. It's singularity, black hole, something. Had leash on. I don't know what it is.

[0:37:55] NN: You're focused on building these primitives, right? I'm sure that things have changed dramatically in the nine months that you've been doing this. Have you found that the choices that you've made have been pretty resilient amongst all of the changes in AI? Do you see that trend continuing?

[0:38:11] SB: Yeah. I would say, the first generation of AI frameworks, like LangChain, what they tried to do is they tried to do a lot of this prompt engineering stuff. Because at that time, the models weren't good enough. Then something flipped around June or July about a year ago, where the models were good enough, and then the right thing to do was build these workflow-based abstractions on top of that. When we started working on the problem, we landed on that, the correct abstraction, which is build the agent abstraction on top of the models, the workflow abstraction on top of the models.

The other big thing that has stayed the same over the last nine months or 12 months, but was different than before is that when you're building on top of APIs, you don't need to do any of this matrix multiplication machine learning stuff that a lot of the Python people are doing, which means that there's not a default language that you should be using. You can use any language, and why not use the language that you can build your whole app and why not use TypeScript? Even though things are moving quite quickly, there was distinct inflection point. Then we started building on the right side of that, where we ended up with the right architecture.

[0:39:17] AA: Yeah. It feels like we got a little head start with then the rest of the world by starting early. Every week, we have this channel in our Slack called Kindergarten, where we share all these blogs and white papers that we should read.

[0:39:33] SB: I'll be named that, because it was like, hey, we're all going back to kindergarten. We all got to learn this stuff. I think one of the things that, to stay up to date in the AI world, you have to stay humble. You have to not think that you've learned it all, because nobody's learned it all. There's new stuff coming out every week. I think it's hard to not be glued to Twitter-X in that world, because you're always just scanning for the new model releases. There's just a certain set of podcasts that you obsessively listen to and whatever. You stay humble and you stay in kindergarten to get taught.

[0:40:04] AA: Yeah. Then when you look at the articles and stuff that are coming, and these are research papers and stuff, a lot of them are coming out before Sam Altman tweets about them. That's the signal that everyone else is going to do, come into the thing. For example, agent memory, we've been focusing on that since we started the company, essentially, because we were reading a bunch of white papers on that. It wasn't mainstream yet. Then did what open AI do? ChatGPT has memory now, which now made people realize that this is a primitive that exists. I think we were very fortunate that we had a little head start and also, are in the mindset of always learning, because we haven't been off yet on our predictions on what's going to happen, or what thing is based on what we've read and stuff.

[0:40:49] NN: Nice. Yeah. That's very fortunate. I love the idea of just that kindergarten channel. I want to adopt that for sure. It's just constantly, take me back to school. We know nothing. That's one thing you mentioned the AI engineer at World's Fair like, talking to people there, it was so great, because I realized that everybody who's in the space right now, we're all just learning together. There's so much to glean and so many ideas. I just left there brimming with ideas. What an exciting time to have a great dev tool in that space.

The final piece I wanted to touch on was your developer experience. I think that that's one of the major selling points of Mastra, just in my playing with it day-to-day. It's so easy to get going from the command line utility that walks you through getting set up, suggest the model to get going with. Then boom, pops you into a browser-based environment, where you can see the agent run the agent, see what tools it's calling, see all of the workflows and all of that. How did that come about? Was that through your experience building Gatsby and other dev tools, that you just knew how that was going to go? Or, a lot of trial and error again?

[0:41:57] AA: There's a funny story behind it, and Sam can add some color there. The first version of Mastra, let's say, Mastra -1. At the time this is October, right? At the time, AI products were very much gooey-driven. The nature of having a playground for us, like Mastra was not code first. It was actually JSON structure first, and you'd actually create all the agents and stuff through UI and all that. We showed it to a bunch of people we respected and they just said like, "Oh, that's cool."

If you're a dev tools builder, anyone says, "That's cool," actually mean, go F yourself, really. They're just too polite to tell you that you're doing something stupid. That's cool. I remember, Sam and I were together and Shane, I was literally distraught. All these people I respected just said, that's cool. Literally means, they should tell me to jump off a bridge, right? I'm just all distraught. We're at the bar. I'm like, "Guys, I think we have to rebuild everything." We did, which was the right thing. It was good.

The playground was like, when we changed everything to code first, we were just thinking like, "Hey, this playground was pretty cool though. We should probably keep that in some way." Sam, you and Shane had the brilliance behind that, so you should take over the story.

[0:43:10] SB: I think Shane was the one that really pushed for it the most. To get the playground to work, we had to do a bunch of really crazy bundling stuff. What you do in the playground, the playground is a visual chat tool. Mastra's a backend tool. You're building the backend of the agents. Then, you want to see how it works and you see how it responds to different commands. It gives you a chat. It lets you see the traces. It gives you a tool playground, where you can see inputs and outputs. It gives you a screen, where workflow visualization. If your steps, you have branching, or if you're chaining them together, it'll just show you them. Then you can put in a sample input and it'll run them.

It's like that interloop of development, right? You're like, "Oh, this thing is in the right direction, but I just need to tweak this bit, I need to tweak that bit. I need to add a step here. I need to tweak the prompt there. I need to think about this edge case." We just do so much of our development loop is that inter development cycle. We just were like, gosh, it was we're porting our old playground. Because initially, in Mastra -1 that we had in October, November of last year, the UI was driving it. In this case, it's a read-only UI. You're not changing the code. You go to VS code, or cursor, or whatever to change the code, but you can see how the code that you've written, what it does, and you give it this input and what the output is.

Then we switched it over that one, they're like, gosh, this feels like it's cool, and it really feels like, this is something unique and different. Once we committed to it, it's just 10,000 little things is the UI details where highlights the step in green when the step is running and then it moves on to the next step and add it to the next step in green. You can see the input and output at each step, and what do you do when you have a really big diagram and how do you represent nested workflows? How do you arrange the agent chat and how do you represent the tool call in the chat, so it displays visually differently?

We just went through the iteration. Then, like I said, a lot of bundling stuff we had to do, because you're exporting your workflows and your agents right in a way that you could use it in other bits of the code. Also, you have this dev server that's using them and pulling them into a different type of environments. There are some gnarly stuff there, that word from the team had to work on to get it right there.

[0:45:28] AA: Yeah. That's a good point to touch on. The skills that we learned at Gatsby to pull something like this off, one, we became bundle - we call them bundle ruskies. If you think about it, there are not many few people left in the earth that can bundle JavaScript proficiently, as we used to do back in the day. We used to do it back in the day. That was our job. We had to do it. How many people had to do it? There are very few people on the planet who can bundle JavaScript. That's us.

Second is we used to create Gatsby's GraphQL server from all the BS framework code. We're really good at making servers, too. That's how the playground comes about. We transform the framework into a master server, which becomes the rest end point for the playground, which has some gnarly bundling stuff with bundling server in JavaScript. But then, it allows us to do cool user experiences like that. It also allows you to run Mastra as a server. Or you can just run it as an import in your current application. Being good at bundling allowed us to have two different modes of usage.

[0:46:30] NN: Nice. I didn't realize that. I agree. I've dabbled in bundling and just get frustrated every moment of it. I think that these tools are very important, just from also a learning perspective. Being able to put things together and then see it visually, don't discount that. I think that you're definitely on the right track of just helping through those tools to easily help people, like myself who are new to all of this, understand what we're actually building and how it all works together. Kudos on that.

I wanted to ask about roadmap, or vision for the future. Things are changing constantly. Is it a lot of reactive-based on how things are changing in the world with AI? Or do you have plans for new features coming to Mastra? Do you want to speak to that?

[0:47:19] SB: It's a variety of a lot of different things. The core primitives are what a roadmap looks right now, we know what our core primitives are. Some proportion of our roadmap is interoperability for our core primitives. Some of it is like, we're working on some new eval stuff right now, where we have the concept of this score and a score, which we think is much better than these LLMs as judge and evaluator tools. We built that into the playground, right? Then we say after that, where we have a cloud product and we're building it into Mastra cloud as well. It's like, hey, you have these changes in the core that ripple out across things.

We're working, for example, right now on templates. Just walking through, hey, I want to build a docs chat bot. Here's a starter code, and a template code repo for you. To install a PDF upload is like, you really basic use cases. It's like, well, okay, cool. We built this library. Now we're going to get the CLI installed. Now we're going to run a hackathon to get into the community, to get the community to build some templates. We're going to get the templates working in playground. Then the templates have to go in in cloud. Some of it is like that, where you're like, "I got to trace this feature across a number of different platforms, almost." Think about roadmap.

Some of it is coming from externally to us. In the space and in general, it's two of the biggest problems in agent building. Or, one problem we call like, synthetic evals, which is, how do you take this raw traces that your agents and workflows are emitting and turn that into a set of tests, a set of statistical tests, these evals for your agent, what's the loop that helps you do that? Then another one is agent learning, which is how do you use those, again, that raw exhaust of traces and actually improve your agent performance and given what it did in the past, learn from that data? Those are two broad problems that were just widely recognized in the space to problems.

We're working on various approaches to there, but that's coming from the space as a whole. We're thinking about this, and there's other folks thinking about this as well. Somebody's going to figure it out over the next few months, and we hope, really, either be one of the first ones to do it, or once it's accepted, what the right way of doing it is, and it'll be really easy to build that into Mastra, one of the two things. Broadly speaking, the other things that we're thinking about are agent authentication, agent security guardrails for inputs and outputs.

Abhi was talking about our multi-agent primitive, or agent network. We're working on an event-based execution system, where you can custom define events and have them bubble up. Multimodal support, where there's images and voice. Again, we have some stuff there. But there's going deeper into voice, thinking about video, all these. The frontier of what the models are doing is shifting so quickly. A lot of other bits are the integrations with other their agentic front-ends, like co-pilot kit and assistant UI, for example. We have a lot of work that's work really well with them. Then a lot of the other providers in the space that have sandboxes for code execution and browser use tools, web scraping tools, good integrations there. I think a lot of it is driven by the ecosystem. A lot of it is driven by the natural development of our own primitives.

[0:50:46] AA: We got a lot of work to do.

[0:50:48] SB: That's for sure. I mean, time moves fast, but I think, yeah, the space is evolving so rapidly. It's like, yeah.

[0:50:55] NN: Yeah. It's constantly changing. But you seem to have a good instinct for it now. Keep that up. Keep it going. Is there anything that I didn't ask you about that you wanted to mention about Mastra?

[0:51:06] SB: I think one of the lessons that everybody should have is that something Abhi alluded to earlier. Whenever a new team member onboards, it takes a month or two for them to learn all the agentic concepts and how everything all works together. We've now watched, probably a dozen folks go through this transition. It's just a little bit of time and immersion. I think if you're new to the space, or if you feel like you don't know a lot, and a lot of what we said might be these terms, you're like, "What are they even talking about?" Don't be disheartened, or discouraged. Just, we watch so many people go through this. It's just, try to immerse yourself in it however you can. Build something yourself and that's the best way of doing it. Hopefully, just use Mastra. Find some toy storybook type project, where you can build it, that would be cool and fun and interesting, and use that as a vehicle to learn the concepts. Read the book, pre-copy at Mastra.ai/book.

Just immerse yourself in it for a month, or two months. You'll go from like, "I don't know what this stuff is, and what are these people even talking about," to like, "Wow, this is pretty cool. I'm getting the hang of this, right?" I think that's our biggest advice, or takeaway for folks.

[0:52:14] AA: Yeah. We're really dedicated to the education part of this. Every Thursday, there's a Mastra workshop. If you want to learn something new, even things that we learn tomorrow, we're doing a lesson on background agents with cursor and codecs and stuff. Sometimes it's not even about Mastra. We just like teaching things. on Mondays, I remember back in the day when I was learning JavaScript, JS Jabber was so cool. I used to listen to that stuff. We also do a live stream agents hour, where we talk crap with each other about just the things.

We've had so many new people to the community come through there, because you're now in the days where you're vibe coding and you're vibe listening to people vibe code themselves. It's this whole world that's coming. I would recommend, if anyone's trying to get into this, just come to those things and we're happy to have you.

[0:53:04] NN: Thanks. Yeah. I will try and be at the next one. That sounds great. How can folks reach out to you, or learn more about Mastra?

[0:53:12] SB: We're @Mastra_AI on Twitter/X. I'm @Calcsam. That's C-A-L-C-S-A-M on Twitter. I would say, you could also NPM create Mastra at latest and just walk through that and then NPM run dev and spin up the dev server and just play around with it for yourself as well.

[0:53:32] AA: Yeah. You can find me on X, @AbhiAiyer. Then yeah, just come join our Discord. We interact with the community. Come say, what up.

[0:53:40] SB: Yeah. Please, do. It's an exciting time to be a developer. I think it's an exciting time to be building. There's so many things that we can build now that we couldn't have built even a year ago, or two years ago, or three years ago. That's one of the things that just gets me excited is seeing all the cool things that everybody is building, all the cool agents people are building these days and all the cool AI engineering people are doing. It feels like a world where there's magic. It's that magical moment when I was learning how to program where I'm like, "Whoa. I'm doing this." But I didn't have that experience again, until AI. I think we can all have that experience again.

[0:54:16] NN: Yeah. I'll definitely second that. That feeling came back to me learning all of this. It was very exciting, and still is. Definitely, I'll second your suggestion on that. Thank you for sharing all of this knowledge. I love the DX of this tool. I love all of the ideas that you have with the doc server. I really want to check out this teacher MCP. Sounds really awesome. Most importantly, I'm just really excited about your excitement for teaching this and being open about that. I think that everyone can learn a lot from you guys and I look forward to learning more as we go. Thank you so much for joining Software Engineering Daily. Abhi, Sam, thank you so much. Have a great day.

[0:54:53] AA: Thank you.

[0:54:54] SB: Thank you, Nick.

[END]