Agents vs Workflows: Why Not Both? — Sam Bhagwat, Mastra.ai

Okay, agents or workflows, why not both? Thank you, Alex, for the nice intro.

Like you said, I used to be the founder of—co-founder of—Gatsby. I wrote a book called "Principles of AI Agents," which is floating around. Hopefully many of you have gotten a copy; we have more around the conference. There was a big debate a couple of months ago, which the terminally on Twitter people may have noticed, which I just referenced.

And I think, like, this is a big reason why I'm—why we're having this talk, why we're having this track. This is going to be kind of like a reverse mullet talk or something like that. It's like party in the front, business in the back, or something.

So we're going to start with the party, or the debate, or whatever this is. This was referenced in the last talk as well. Anthropic wrote a great blog post in December. It was called "Building Effective Agents." It had great diagrams.

It showed what an agent was. Can we close the door, please? It showed, like, some workflow examples. Like, different sort of types of routing and orchestration. It was a great blog post. In April, OpenAI also released a paper.

I think there was some controversy about that on Twitter because some of the points people made were like, look, this isn't a lot of new material. Other people pointed out this kind of callout at the end, which is basically like an anti-workflow blast.

It's like, hey, like—and I think people were like, hey, yo, what's going on here? This is just, like, not accurate, and it's coming from a big model provider, so it's kind of muddying the water. So there was a lot of controversy around that.

That was the Swix blog post I was referencing. It's an emergency blog post. It went out on Latent Space. I have a couple hot takes on that, and then I have a takeaway. I promise both the hot takes and the takeaway are relevant to the systems you're building.

We care a lot about this. It's the reason we wrote a book. First hot take is, like, look, just—I'm going to@OpenAI here. But it's like, just don't be that guy. And I'll explain, like, the context of the—like, I mean, I think we know this meme, but, like, what I mean by that guy in this context.

So that guy just thinks that, like, they and they alone, like, know the onlyright way to do development. Sometimes, and, like, we—I actually ran into Lori Voss in the hallway yesterday, and we started talking about that guy that we sort of had known from the last decade.

But sometimes that guy works for, like, a FAANG-style company, and they're in, like, a public-facing role, and then the rest of us are just really in for it. Because, like, if you sort of look at the last decade, a lot of web devs got these, like, lectures by not all Googlers, but, like, certain Googlers about, like, theright way to use the platform.

And it was just, you know, again, I'm going to go really deep. I don't know how deep into web dev, like, folks are, but, like, it was just sort of this anti-React codeword, and it was kind of, like, they were sort of pushing these technologies that were not very easy to use instead.

I'm just kind of hoping, like, the model providers kind of have this, like, elevated position in the ecosystem. So whatever they say carries a lot of weight, similar to, like, the FAANG companies in, like, you know, web dev and in general.

So, like, let's just—here's to hoping for a good quality of discourse this time around. Here's a hot take number two, and I'm going to@LangChain here. We should consider, like, graph, node, and edge APIs within frameworks harmful. And, like, I say this as someone who used to be a co-founder of a ReAct meta-framework that famously used GraphQL as a default way of fetching data.

We wrote our data fetching queries like this. It was really cool in 2017.

We—GraphQL is still cool,right? GraphQL is a great technology. But we indexed on this pattern, and it became kind of the default way of fetching data in Gatsby.

Some of our users loved this, but many of them didn't. Many of them just wanted a ReAct meta-framework. Okay, why is he talking about, like, the last decade of web development? You'll see why. They ended up using other frameworks instead.

And when I see APIs that look something like this, it gives me flashbacks. I do not think you should need to learn graph theory to write workflows, to build production applications. More problematically, you should also probably not need your, like, all of your team to grok graph theory.

A more grokable pattern, like, looks something like this. And I've used, like, I've used Mastra workflows here. But it's sort of like a fluent syntax. You can, like, clearly see the control flow. But, I mean, like, this is, like, the ingest workflow syntax.

You can kind of clearly see the flow of the code. You can see what happens, and then what happens after that, and what happens after that. You can just see it by, like, when you sort of, like, step—when you're reading the code, your eyes can go from the top to the bottom and, okay, I see what's going on here.

Great, I get it. Right? It's readable code. It's like a readable way of doing things. I think when if we have to use nodes and edges and connect things, we lose that readability of code, which is really important when we're building—we all build software in teams,right?

Generally.

So I mentioned this earlier,right? Like, you and your colleagues should be able to use a workflow framework or whatever without learning graph theory.

Again, like I said, it's a reverse mullet. Like, party in the front, hot takes in the front, like, business in the back. Okay, so, like, now that we've kind of, like, talked about, like, we've sort of, like, opined on the discourse of the day, let's get down to business, okay?

Design patterns for agents and workflows. And when I say design patterns, like, this phrase has kind of a storied history. So this is a book which came out, I think, like, late '70s by this guy named Christopher Alexander.

It was very famous. It spawned a bunch of, like, not—so, okay, Christopher Alexander was a professor at Berkeley. He was an architect. He sort of cataloged in both sort of, like, urban planning as well as, like, internal sort of, like, in-building architecture.

Like, these are a couple hundred of the patterns of what we see are theright ways of building. And just wrote them all up in a book. And so oddly, architects were not very fond of this, but, like, software engineers loved it.

And sort of it became all the rage in, like, the—and this predates me, but, like, the late '80s, early '90s, sometime around then. And so I think there's, like, I think what we do not yet have—we have sort of, like, steps towards this—but what we do not yet have is a commonly accepted verbiage and, like, language and glossary of what are agentic patterns,right?

What are agentic workflow patterns? And so, okay, let's just start with, like, what are agents and workflows? Maybe I'm not going to spend a lot of time on the slide because I think the previous speaker talked about this.

I was honestly, because people have covered this ground, these guys did a workshop yesterday, and they did a great job, so I just, like, took their slides and put them in here. Props to Nick and Zach if they're in the room somewhere.

But

they did a workshop on Mastra yesterday, which was amazing. Okay, so, but, like, okay, like, let's just, like, how do we explain it to a friend? Okay, I think about agents like a turn-based game,right? Like, I take a turn, then the agent takes a turn, then I take a turn, then the agent takes a turn, and then the agent takes another turn, maybe makes, like, a tool call or something,right?

It's like back and forth. And then I think about, like, workflows are like this rules engine for your tech tree,right? Okay, we got to—I played Civil War when I was a kid. You got to discover bronze working before you can research iron working,right?

You've got to get metallurgy before you can research gunpowder,right? Like, there's some sort of dependency chain here. And it's important to kind of track the dependencies because you can't do step B until you do step A. And a lot of workflows are these, like, data pipelines.

Step A, step B, step C, step D, step E, execute them all in order, go,right? You know, conversations have threads. You can have memory. Like, these are all the emergent properties that happen when you think about, like, lots and lots and lots of messages.

Similarly, if you think about these sort of, like, dependencies, you can think about branching and parallelism and conditions and loops and suspending and resuming and replaying and all this fun stuff. Like, those are sort of the emergent properties of workflows.

And, I mean, just kind of recapping, like, workflows have been around for a while, obviously. They're becoming more popular now for a variety of reasons, but one of them just—and I want to bring this back here because it's important,right?

Like, you can always just write, you know, code that says do A and then do B and do C and do D. But the reason why they, like, they're just more popular in AI engineering than sort of, like, normal engineering is because, like, nondeterminism is sort of core to what we're doing here.

And being able to kind of trace it and figure out what happened is, like, if it's important in software engineering, it's 10x as important in AI engineering. So, let's see. Look, at the end of the day, it's just a trade-off,right?

You can have power, or you can have control. You can decide which parts you want power on, which parts you want control on. You can start with power, and then anything that, like, goes off the rails, you can add control.

At the end of the day, like, many things we do, it's just a trade-off.

This slide, I was not able to drop in, but the photo I wanted to drop in, but, you know, we've done a lot of whiteboarding sessions with, like, hey, I'm starting to build an agent, and I want to think, trying to figure out how to think about this.

Or my agent is, I'm feeding in this giant PDF of medical documentation, and I'm trying to diagnose 12 symptoms, and they're not—it's not accurately pulling out theright information. Okay, have you considered breaking that one LLM call into 12 LLM calls,right?

A lot of what you do in these kinds of sessions is you sort of think about, you kind of ask, hey, what part of your application is performing not very well in terms of reliability, and then, like, how could you add some structure to the process here so you can get additional reliability?

And I encourage that sort of, like, practice. We could have encouraged that practice. Like, obviously, we're happy to do that with whoever, but, like, also just, like, do it with each other, and, like, just try explaining your architecture to your friend or your colleague,right?

And then, like, diagram it out on a board because you can magic—when you're doing these things, like, magically, like, you realize that, actually, there's a better way of doing a certain thing, and maybe a more creative way of using the primitives together.

Coming to that,right? So here's just some thoughts,right? Agents and workflow composition. So agents have tools and, like, you know, they can call tools. You know, workflows have steps. An agent can be a step. A workflow can be a tool.

An agent can be a tool. A workflow can be a step. And, like, most primitives, the magic happens when you combine these things together. The agent supervisor model, you have an agent that is calling other agents as tools,right?

So, let's see, we have—this one was a research agent and a summary agent, and then, like, an orchestrator agent. These are, like, these are all, like, Mastra, sort of, like, Mastra code is just more of, like, an example of, like, you know, but I think, like, it's illustrative not the particular lines of code and what they are, but, like, these examples are sort of simple enough to fit in the, you know, slightly smaller version of theright panel of my slide,right?

And that's sort of the interesting thing. We can use these terms, and the implementation is not too long. It's grokable in a slide. And so, again, like, that's kind of what gives us power is that, like, the primitives are simple, but the combinations are also, like, once we get a hang around, once we get the hang of them, we can, you know, run pretty fast.

You know, you could have workflows as tools.

So I think, you know, it's like, hey, like, you want to plan location, you want to, like, check the weather, then you want to plan a trip. Maybe these are, like, more complex workflows. Pass that to an agent.

Let it sort of, like, iterate and decide. Workflows doing agent handoffs. I'm looking at time here. Dynamic tool injection. This is interesting, too. I think, like, you know, agents can start failing if you give them, let's say, double-digit numbers of tools, and you may want to be thoughtful about which tools you're handing to a particular agent at a particular time when it's performing a particular task.

You can also, you know, nested workflows. Again, workflow is a step. But again, like, the real, and just I'm going to reemphasize this, the real alpha comes from sort of, like, using these patterns together in theright sort of way.

Reality has a surprising amount of detail, and so do agentic workflows that sort of, like, by the time they enter production.

I think I also have a couple minutes for questions, so.

So do you think then basically it would be even better if you combined the deep research agent plus the workflow versus using one to replace another? Is that your argument?

So the question, yeah, the question is, would it be better to combine the deep research agent?

So I have a workflow that I know for a fact that it works very wellright now on deep tools with purpose, but then I also hear arguments that there's no need for me to orchestrate this workflow and just.

So the question is, your agent works great with 20 tools. I would say, like, we are a community of practice more than we are a community of theory. If your agent is working according to what you would need, like, do it.

If it's not theoretically correct, that probably means the theory is wrong, not the practice. This is a young field, and the practice is evolving faster than the theory,right? I think that's just my general comment. One more question.

Where can we find you after the talk?

You can find me around the conference. You can at, I'm at calcSAM, that's C-A-L-C, like calculator, and S-A-M, like my name, which is my handle when I was 12, because I was, yeah, anyway. Thanks, everyone, for coming. Really appreciate it.

Please grab a copy of the book around the conference.