- - Okay, Agents or Workflows, why not both? Thank you, Alex, for the nice intro. Like he said, I used to be the 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 this is a big reason why we're having this talk, why we're having this track. This is gonna 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 gonna start with the party or the debate or whatever this is. This is 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 some workflow examples, like different 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 was 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, the emergency blog post 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. This is the reason we wrote a book. First hot take is like, look, just this, I'm going to add 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 only right way to do development. Sometimes and like, 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 fang style company, and they're in like a public facing role, and then the rest of us are just really in for it.

It was 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. 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 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.

I'm just kind of hoping like, the model providers, right, kind of have this like elevated position in the ecosystem. So whatever they say carries a lot of weight, similar to like the fang companies in like, you know, web dev and in general. So like, let's just, here's to hoping for a good quality of a discourse this time around.

So here's a hot note, take number two, and I'm going to add link chain 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. We indexed on this pattern and it became kind of the default way of fetching data in Gatsby. 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? 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 all of your team to grok graph theory. A more grokkable pattern looks something like this. And I've used, like, I've used master workflows here. But it's sort of like a fluent syntax. You can clearly see the control flow. But I mean, 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're reading the code, your eyes can go from the top to the bottom. And then, 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? So, 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 tics 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 the right 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 and, like, 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?

Orgentic workflow patterns. And so, okay, let's just start with, like, what are agents and workflows. Maybe I'm not gonna spend a lot of time on the slide because I think the previous speaker talked about this. is 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 there. Put them in here. Props to Nick and Zach if they're in the room somewhere. But they did a workshop on Monster yesterday, which was amazing. Okay. So, but, like, okay, like, let's just, like, how would 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 gotta... I played Civ a lot when I was a kid. You gotta discover bronze working before you can research iron working, right? You gotta 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... 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're just more popular in AI engineering than sort of, like, normal engineering is because, like, non-determinism 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 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.

We've done a lot of whiteboarding sessions with, like, hey, I'm starting to build an agent, and I'm 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 it's not accurately pulling out the right information.

Okay, have you considered breaking that one LLM call into 12 LLM calls? 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 kind of encourage 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, 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? Coming to that, right? So, here's just some thoughts, right? Agents and workflow composition. So, agents have tools, and, 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.

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 the right 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 grokkable 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 the 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 at 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 the right 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, do you think, then, basically, would be even better if you combine the deep research agent plus the workflow, versus if you want to replace another ? 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 well right now with 20 tools. Yeah. But then I'll set your arguments that there is no need for me to orchestrate this workflow and just... So, the question is that 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... I'm @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... Yeah, anyway. Thanks, everyone, for coming.

Really appreciate it. Please grab a copy of the book around the conference. Thank you very much. Thank you very much. Thank you very much. Thank you very much. Thank you very much. Transcription by ESO. Translation by —