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

Channel: aiDotEngineer

Published at: 2025-08-01

YouTube video id: 8SUJEqQNClw

Source: https://www.youtube.com/watch?v=8SUJEqQNClw

[Music]
Okay. Agents or workflows? Why not both?
Uh, thank you, Alex, for the nice intro.
Um, uh, like like he said, I used to be
the founder of co-founder of Gatsby. Um,
I wrote a book called Principles of AI
agents, which is floating around.
Hopefully many of you have gotten a
copy. We we have more around the
conference. Uh there was a big debate uh
a couple of months ago which the term on
Twitter people may have noticed um which
I just referenced. Um and I think like
this is a big reason why I'm h why we're
having this talk why we're having this
track. Um 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 or whatever this is. Um,
this is referenced in the last talk as
well. Anthropic wrote a great uh blog
post in December. Um, it was called
building effective agents. It had great
diagrams. It showed what an agent was.
Can we close the door, please? Um, it it
showed uh like some workflow examples um
like different sort of types of routing
and orchestration. It was a great blog
post. Um, in April, OpenAI also released
a paper. I think there was some
controversy about that on Twitter
because some of the points people made
was like, look, this isn't a lot of new
material. Um, other people pointed out
this kind of call out at the end, which
is basically like an anti-workflow
blast. It's like, hey, like and 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. It's just kind of
muddying the water. There was there was
a lot of uh controversy around that that
was the uh Swix blog post I was
referencing uh emergency blog post um
went out on latent space. Uh 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. Um we care a
lot about this. There's a reason we
wrote a we wrote a book. Um first hot
take is like look just this I'm going to
add open AI here but it's like just
don't be that guy. Um, and I'll I'll
explain like the context of the like I
mean I think we know this meme but like
the what I mean by that guy in this
context. So that guy just thinks that
like they and they alone like know the
only right way to do development. Um
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. Um, but sometimes that guy works
for this for like a fang style company
and they're in like a public facing role
and then the rest of us are just really
in for it. Um, 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 the right way to use the platform.
Um, and it was just, you know, again,
I'm going to go really deep. I don't
know how deep into webdev like folks
are, but like it was just sort of a this
code anti-react code word and it was
kind of like they were sort of pushing
these technologies that were not very
easy to use instead. Um I'm just kind of
hoping like the the the model providers
like kind of have this like elevated
position in the ecosystem. So whatever
they say carries a lot of weight um
similar to like the the fang companies
in in like you know webdev and and and
in general. So like let's just here's
here's the hoping for a good quality of
a discourse this time around. Um here's
a hot take number two and I'm gonna add
lang chain here. Um we should consider
like graph node and edge terminal APIs
within frameworks harmful. Um and 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 that we wrote our data fetching
queries like this. Um it was really cool
in 2017. Um we GraphQL is still cool,
right? GraphQL is a great technology but
we index on on this pattern and it
became kind of the default way of
fetching data in Gatsby. Um
some of our users love 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? Well, you'll see why
they ended up using other frameworks
instead. Um, 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 to to gro graph theory. a more
grockable pattern like looks something
like this. And I've used like I've used
master workflows um here. Um but it is
sort of like a fluent syntax. You can
like clearly see the control flow. Um
but I mean like this is like the ingest
workflow syntax. Um you can you can kind
of clearly see the the flow of of 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 your eyes can go
from the top to the bottom and okay I I
see what's going on here great I get it
right it's readable code it's it's it's
like a readable way of doing things um 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
um uh uh so to is I mentioned this
earlier right like you and your
colleagues should be able to use a
workflow framework or whatever without
learning graph theory um
again like I said it's a reverse reverse
mullet like party in the front hot tick
in the front like business in the back
um okay so so like now that we've kind
of like talked about like we we've sort
of like opined on the discourse of the
day um let's get down to business okay
um 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 '7s by this guy
named Christopher Alexander. Um it was
very famous. It spawned a bunch of like
not he so okay Christopher Alexander was
a professor at Berkeley. Um he was a
architect. He sort of um cataloged in
both uh sort of uh like urban planning
as well as like internal sort of like
inbuilding architecture. like these are
a couple hundred of the patterns of what
we see are the right ways of building.
Um and um just wrote them all up in a
book. Um and so um 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 this predates
me but like the late 80s early 90s
sometime around then. Um uh and so so I
think there's like I think what we do
not yet have um we have sort of like
steps towards this but what we do not
yet have is a commonly accepted verbiage
and and like language and glossery of of
what are agentic patterns right um what
are agentic workflow patterns um and so
um okay let's just start with like what
are agents and workflows um maybe I'm
not going to spend a lot of time on the
slide because I think previous speaker
talked about this. I was honestly
because people have covered this ground.
These guys did a a workshop yesterday
and they did a great job. So, I was just
like took their slides and put them in
put them in here. Props to Nick and Zach
if they're in the room somewhere. Uh but
uh they're um they're they did a
workshop on Monster X yesterday, which
is amazing. Um okay. Um so, but like
okay, like let's just like how would we
explain it to a friend? Okay. I 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. Um, and
then I think about like workflows are
like this rules engine for your uh for
your tech tree, right? Okay, we got to I
I played civil a lot when I was a kid.
Um, I I I I you got to discover bronze
working before you can research iron
working, right? You've got to get my
before you can uh research gunpowder,
right? like there's there's some sort of
dependency chain here. Um, 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. Um,
you know, um, conversations have
threads, you can have memory, like these
are all the emergent properties that
happen when you think about uh when you
think about like lots and lots and lots
of messages. Um similarly if you think
about these sort of like um 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 of
workflows. Uh, 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 um, you know, code
that says do A and then do B and do C
and do D. Um, but the reason why they
like they're just more popular in AI
engineering than sort of like normal
engineering is because like
non-determinism is is sort of core core
to what we're doing here and and we and
being able to kind of trace it and
figure out what happened is like if it's
important in in in software engineering,
it's 10x as important as in in AI
engineering. Um, so um let's see. Look,
at the end of the day, it's just a
trade-off, right? Um, 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.
Um, at the end of the day, like many
things we do, it's just a trade-off. Um
uh this slide was uh was not able to
drop in but uh the photo I wanted to
drop in but um uh we you know we we've
done a lot of whiteboarding sessions
with like hey I'm starting to build an
agent and uh I 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 not I'm
trying to diagnose 12 symptoms and I'm
they're not it's not accurately pulling
out the right information. Um, okay.
Have you considered breaking that one LM
call into 12 LM 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 in terms
of reliability and then like how could
you add some structure to the process
here so you could you you can get
additional reliability. Um, 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 match when you're doing these
things like magically like you realize
that uh actually there's a better way of
doing a certain thing and maybe a more
creative way of using the primitives
together. Um coming to that right so
here's just some thoughts right agents
and workflow composition so agents have
tools and you know they 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 um
the agent supervisor model you have an
agent that is calling other agents as
tools, right? So, um 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
these are all like MRA um sort of like
MRA code is just more of like an example
of like you know but 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 the right panel of my slide
right and that then that's sort of the
interesting thing we can use these terms
and the implementation is not too long
it's grockable in a slide um and 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 um
so um I think it 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
more complex workflows pass that to an
agent let it sort of like iterate and
decide um workflows is doing agent
handoffs. Uh I'm looking at time here.
Dynamic tool injection. This is
interesting too. I think like you know
agents um 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 in
handing to a particular agent at a
particular time when it's performing a
particular task. You can also um you
know nested workflows. Again, workflow
is a step, but again, like the real and
and just I'm going to re-emphasize this,
the real alpha comes from sort of like
using these patterns together in the
right sort of way. Um, reality has a
surprising amount of detail and so do
agentic workflows that um sort of like
by the time they enter production. Um,
I think I I also have a couple minutes
for questions. So, uh,
so do you think
Uh so the question yeah the question is
uh would it be better to combine the
deep research agent? I have a workflow
that I know for a fact.
So the the question is your agent works
great with 20 tools. I 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 like do it if it's not
theoretically correct that probably
means the theory is wrong not not the uh
not the practice. This is a young field
and the the the the practice is evolving
faster than the theory. Right? I think
that's just my general um comment. Uh
one more question.
Where can we find you after the talk?
Uh, you can find me around the
conference. You can at I'm calcam.
That's CALC like calculator and SAM like
my name, which is my handle when I was
12 because I was Yeah. Yeah. Anyway, uh,
thanks everyone for coming. Really
appreciate it. Please grab a copy of the
book around the comments.
[Music]