one more thing
some people think this is how you keep score (?)
it's not why we're building this, but definitely a morale boost
and a reminder for all of us that great things take time
made a gametime decision that since we had the spotlight
we may as well cut the beta
x.com/calcsam/sta...
ofc folks also found the parts that didn't work quite right
unclear docs, meh apis, weird ui artifacts
our linear project is full of papercuts
so this sprint we're sanding all the rough edges
the first thing we saw was lots of excited devs
people loved mastra's agent playground, the workflow api, the dev environment
still catching our breath from last week
here's what we learned when our typescript agent builder went viral
As an example, our workflow graph API has three main methods, .step() for branching, .then() for chaining, and .after() for merging.
Every time we show it to someone building with AI, they immediately nod along. The control flow is apparent and intuitive.
Even better, I can do this collaboratively on a screenshare with an engineer, so they can themselves learn the process and begin to develop better taste for APIs
And that was incredibly difficult....until LLMs
Now, I can describe the parameters of an API problem to Claude -- on web or in Cursor -- and ask it for help.
It can access all the underlying code. It will propose five or six plausible approaches.
One of the main reasons Next.js beat Gatsby was that @kylemathews and I struggled to articulate our taste around APIs in a way that was legible to others, as well as meaningfully review APIs others proposed.
Left to their own devices even great engineers tend to ship overly verbose API names, create overly large options dictionaries, and overload methods in unintuitive ways.
Class and function names and parameters need to be immediately intuitive
Should a variable be a function parameter or part of an options object?
Can you set configdefaults on a class but override them on a particular invocation?
Do you want descriptive or evocative apis?
so @mastra_ai is an open source typescript agent framework
when you’re building a framework, you need to do a lot of API design, specifically the nouns and verbs your users use.
excited to announce that we used llms to solve the hardest problem in computer science
naming things
please share what you build!
thanks @libsqlhq @tursodatabase
huge step forward today for @mastra_ai with a new storage layer
you can persist agent messages. conversation history. tool calls.
when you suspend a workflow, it persists that state too
all using libsql so no local docker setup
If you're interested in multi-agent orchestration, take a look at the code: github.com/mastra-ai/m...
And the deployed app: mastra-eight.vercel.app/
It passes the data into another agent that validates it and formats it for the user, again using a Zod schema:
In order to get the agent to perform well, we needed to write rather exhaustive instructions:
Tools take in defined input schemas using Zod and can call external APIs while maintaining strict typing.
The first agent has detailed instructions and access to a set of tools. It generates a set of possibilities using tools provided and ranks them according to the user's preferences.
It can call the tools in whatever order it needs.
so everyone wants to plan their next trip with an (AI) agent
now with @mastra_ai you can
we just built a Travel AI that does everything a good travel agent should.
input: budget and preferences.
output: flights, accommodations, itinerary options
how we did it:
nice! if helpful
github.com/mastra-ai/ma...
we're building this into mastra, why?
it's a 🔥🔥🔥 getting started experience for the next million AI devs
also: first bits of a new `mastra init` are working.
you can decide which top level objects of mastra (agents, workflows, tools) you want to start with.
you can decide whether you want example code included. or more bare.
you can do it interactively or with cli flags.
