What Anthropic & OpenAI Actually Mean by Agents vs Agentic Workflows (It's Not What You Think)

What's the difference between Agentic Workflows and agents? Let's cover it. We're going to go through some anthropic documentation as well as OpenAI and a bunch of examples. This is something that I realize can get pretty confusing and when you're going to build something, you ask yourself, is this a gent or is this an agent? What's the difference? And I find that when you are going to build these, you typically just map out all of the steps that you're doing in real life before we had all this awesome AI magic going on. And you list those out and you typically start with a gentic workflows. So, in my case, when I've spoke about this on the channel before, it is where you have a set of predefined steps with a little bit of AI in the mix where you might have 10 steps in a work stream and on the 7th and the 9th, you're using AI to do something. But again, that list 1 through 10 is sequential. It will not change. can still have humans in the loop versus agents where once you've done it a bunch of times, you feel strongly that this thing's ready to be an agent. So, that's how I viewed it. But let's go a little bit deeper. So, I started by making this two-page PDF and it summarized the differences between the two based on documentation from both Enthropic and OpenAI. And so this document aims to clarify the concepts of the agentic workflows. Let me just grab a pen tool here. As defined by leading companies open AI and anthropic, understanding these terms is crucial for anyone working with AI systems as they represent different approaches to leveraging AI capabilities. Cool. So Gentic workflows these as defined by enthropic are systems where LLMs are orchestrated through predefined code paths to perform specific tasks. Workflows follow a structured sequence of steps and involve human oversight or input ideal for predictable well-defined tasks where consistency is key. Cool. And then AI agents are where the LMS are dynamically able to direct their own process and decide how to use the tools to accomplish the given task. So they operate more autonomously making decisions without a rigid predefined path. So you'll notice the big difference is path or no path and they're better suited for open-ended scenarios. One caveat is they can still have humans in the loop, right? Think of them as the milestones or the checkpoints when you're coding. from OpenAI. They are autonomous systems that can perform tasks independently. It doesn't even have an agentic workflow diagram actually. So that was what this came up with. And now if we look into a couple different diagrams that explain the two difference and then I'm going to go through the actual enthropic docs and then one of the frameworks that I actually find interesting. So here on the left, this is a gentic workflow. So predefined human in the loop. So you start, it has task one. You'll notice the big difference is these, right? They have numbers. These don't have numbers. So start and then you go 1 2 3 optional human review approved. If human review, then go back, do the thing, and it could redirect to number three or two, depends on the chain versus AI agent loop, which is autonomous. So start LLM decides the next step. It decides to pick one of these tools or call an API. It observes the result based on what happened. It uses its context to decide whether or not the goal was achieved. If not, decide the next step. So that's the big difference there. And if it's achieved, then done. Cool. So I pulled this out of the anthropic doc. So we'll just pull these open. This is from their building effective agents. If you guys want to get this, it's just on their blog and topic.com/engineering/building effective agents. So, consistently the most successful implementations use simple composable patterns rather than complex frameworks. Boom. Over the past year, we've worked with dozens of teams building large language models, agents across industries. Consistently the most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple composable patterns. Cool. So, agent can be defined in several ways. Some customers define agents as fully autonomous systems that operate independently over experienced extended periods using various tools. But let's just see what they think of. So at Enthropic we categorize all these variations as agentic systems but draw an important architectural distinction between workflows and agents. Workflows are systems where LMS and tools are orchestrated by those predefined paths that we spoke about. And agents on the other hand are systems where LLMs dynamically direct their own processes and tool usage. So path no path and then we're going to explore some of the examples. So when and when not to use agents. When building applications with LLMs, we recommend finding the simplest solution possible and only increasing complexity when needed. This might mean not building aentic systems at all. Agentic systems often trade latency and cost for better task performance. Consider this trade-off. Yep, that makes sense. When complexity is warranted, workflows offer predictability and consistency for well- definfined task. Whereas agents are the better option when flexibility and model driven decision-m are needed at scale. Yeah. So then we get into some of the frameworks and I am a Typescript person. I recognize my areas of competency and for me building production apps it doesn't make a lot of sense to use a ton of Python. So I veer away from langraph and lang chain just because it's Python. I will use it for the Google ADK but that's a different story. We have Amazon's Bedrock AI agent framework. Let's take a look at this one if you guys are familiar. I'm not. You can see I I don't have anything to do with AWS but it looks like you can do vector engines. Cool. I'm a GCP person. Let's get back to the article. Rivet is a drag and drop guey LLM workflow builder and Vellum. So, I actually was just looking at this one. You can see I was about partway through this video. What's interesting about this one to me is it's open source and it's in Typescript, so it works with what I work with. And I'm really happy that OpenAI recently announced that their agent SDK with responses API is now fully supported with TypeScript. So, that's fantastic news for the TypeScript people. But what this does is it's visual programming. So think of if NADN met writing the code. So it's NAN on steroids in some ways. It doesn't have obviously all the connections, but it's pretty cool. And he goes through an example where each one of these nodes represents a tool call. So you can see he has this graph open and on the left side he has it connected to a simple React app. But when he goes to ask a more complex question where he needs some math done then he references a function that is a tool call in here for calculate expression. Pretty cool. And again this one is open source. So definitely something I'm going to dig into a little bit more. But the frameworks make it easy to get started by simplifying standard low-level tasks like calling LLMs, defining and parsing tools, and chaining calls together. However, they often create layers of abstraction that it can obscure the underlying prompts and responses, making them harder to de to debug. If you've worked with lang chain before, it's the most popular one, then you know this problem. They were the first mover, which is awesome, but it's also caused it to be hard to debug. So, I've built stuff with it. I've built stuff without it. And being closer to the prompt, I think is better. Now, Rivet's interesting to me cuz it's open source. So is lang chain. But because it's open source, because it's TypeScript, I'd like to just dig around and see what the Reddit reviews are. like how close is it to just doing it yourself and connecting these things? But we suggest the developers start by using the LM APIs directly. Many of the patterns can be implemented in a few lines of code. And let's take a look at the cookbook. So these are little Python workbooks. So we have basic workflows. What's nice is they added this support for Jupyter notebooks inside of cursor. So this notebook demonstrates three simple multiLM workflows. We have prompt chaining decomposes a task into subsequential subtasks. That's the one that I'd be interested in. The project that I'm working on now, it's my weekend warrior project. Does all three of these actually prompt chaining, parallel parallelization, and routing. So just for an example of this of how it works is I'll open up a codebase real quick. This is Midday's codebase. I'm learning how they do their global search. But this is part of a project that I call AISDLC or the AI software development life cycle. And the idea is that you'd be mapping the best parts of Scrum remixed to the flavor of each step. And what do I mean by that is scrum and other methodologies like agile they have a set of steps where you can see on the left you have your idea to the product requirement document. Then once you had a product requirement document you would probably go and refine the backlog. You'd probably get stakeholder validation. you'd probably do some sort of capacity planning, some sort of sprint planning, and in my case, chunking is part of it. So, because I know that the smaller the context is, the more accurate the LLM and the higher the output will be. So, I've just chosen to smart chunk it. And smart means checking for any sort of crosscutting changes that'll be done in the codebase. Making sure that these worker agents, so the builder running in aer would be able to do its set of tasks in parallel with another one. That would be an example of the parallelization as well as the prompt chaining. And then when it comes to routing, that's actually just baked into whether or not I approve of the PRD. And I'm doing the routing in a simple way where it's actually just watching the folders. So if it goes to the next step, then it kicks off the next agent. But it's funny because it's an agentic workflow. Yeah, I guess it is just totally agentic because it's a defined set of steps. Yeah, maybe it'll be an agent soon or set of agents. Let's go back. So, you can check out the cookbook and then let's see the building blocks and workflows. So, the basic building block of agentic systems is an LM enhanced with augmentation such as retrieval. So retrieval would be vectors typically or you know when you think of it it's a PDF or something but what it does is it gives you a numerical representation of that piece of content so you can find out if it's semantically similar to something and it can use nearest neighbor. There's other ways of doing vector embeddings like the number of dimensions and a lot of stuff that's beyond my understanding. I have article headline level understanding of how it works because I just know it works when you set it up correctly. That's what that is. And I do have it in here actually. Let's see if I have any of the logs. No, I don't. But we're vectorizing all the chunks. So you can see if you had some piece of work that was done similarly for this new feature or piece of work. Can we learn something? Glean insights from previous stuff using similarity. So our models can actively use these capabilities like the retrieval, the tools which are function calls and memory. Memory I wonder how they define this. Our models can actively use these capabilities, generating their own search queries, selecting the appropriate tools, and determining what information to retain. So that's cool. I know memories is something across the board that's hit or miss, but so information comes in, the LLM can do one of these three things and then it goes out. They recommend focusing on two aspects of the implementation. Tailoring these capabilities to your specific use case and ensuring they provide an easy well doumented interface for your LM. While there are many ways to implement these augmentations, one approach is through our recently released MCP which allows developers to integrate with a growing ecosystem with a simple client implementation. I'm going to make a new video soon on this because I feel so out of water on MCPs. Need to get better with them. Although this tool, it does have three of them in it, the AISDLC, but I think I could be doing better. The way that I did it was I have a refs folder. And in the refs folder, I've pulled the markdown files from every L, sorry, MCP that I find to be helpful. So in this case it's context 7 for documentation the GitHub MCP for doing CRUD operations across GitHub. So historical for checks or ticket is issue creation milestones all those I think having more of that more data involved is better because I'm having a lot of issues with remote agents but I think it gets solved with this more structure and then sequential thinking which is recursive. It's basically loops on the thinking chain. And so then that goes up into this available tools XML file. So it shows you what the name of the tool is, what the summary of the tool is, what the description of the tool is, and then all the different capabilities and then those capabilities have their tools within them. Right? So you'll notice if you go to in this case context 7 you'll see on their documents these MCPs basically extend a different set of tools so you don't have to write the tool calls which is really nice. They've already done it for you but by passing in these they can't mess up. It really puts some strict guardrails around the actual MCPS when you're calling them. And then you'll notice I call this into the particular agents that need these tools. So let's go back. For the remainder of this post, we'll assume each LLM has access to these capabilities. So in the case of prompt chaining, you have the call, you have the gate. Does it pass? If it does, then keep going. If it doesn't, it fails. That's prompt chaining. You'd use that for fixed subtasks. Makes sense. Where prompt training is useful. Generating marketing copy and then translating it. That's smart. Writing an outline of a document. Checking that outline meets the certain criteria. So, this would actually be a really good example for something that I need to have, which is for this YouTube channel. So, I'm going to write that down. And then I'm going to put that on here. So that'll be in a future video. You guys should subscribe to the channel if you want to see this video in the future. So let me move that. And then exploring MCP docs. Cool. And then we'll do one more which will be building a multi- or an agentic workflow using prompt chaining for YouTube assistant. Great. Cool. Cool. Cool. And let's go back. So routing classifies an input and directs it to a specialized follow-up task. This workflow allows for separations of concerns and building more specialized prompts. Without this workflow, optimizing for one kind of input can hurt performance and other out inputs. So in you get to route it and then you make the call. An example of this routing workflow could be if I went to webdev Cody's YouTube and learning how he onramps and if I let's say that this is my YouTube channel I could have a call to the YouTube API on a schedule or when I get a new comment I could listen for it and then I could have it read the context or the content of the comment and then decide one of three options based on some parameters that I set to classify it. So I can say if this comment is something nice that I need to acknowledge and say something nice back or something simple then I can have it go to route one. If it's the second option is it's a question that I personally want to answer, then I can have it ping me in Discord or via text message over Twilio to say, "Hey, this person said this. It's a question. I'm not comfortable answering it. I want your reply." I could type it in and it comes back and posts. Then the third one could be, let's say, someone that is critiquing the concept or topic covered. then I could have a different answer or workflow for that chain. So those are some examples there. Let's see when they say when to use it. Okay. Distinct categories that are handled separately directing different types of customer service queries such as general questions, refund requests, technical support. Yeah, that makes sense. Cool. And then you can also select different models based on that which is really nice. And then parallelization. Sometimes they can work simultaneously on a task and have their outputs aggregated programmatically. Cool. Breaking a task into independent subtasks, running the same task multiple times to get diverse outputs. That's an interesting one. You could do that for UI. So in the case of AISDLC, you could have four different ADER agents, builder agents running on the same story and see how they all do with different models. And then the orchestrator workflows, a central LM dynamically breaks down the tasks, delegates them to worker LLMs, and synthesizes their results. So you'd have the orchestrator. In my case, this could be the person who's the product owner and then the product owner reaches out to the three different or I guess it could be engineering manager and then three engineers and then goes back into the code reviewer. That could be pretty cool. I'm going to explore this pattern. Let me put this into here because this will be relevant for the next video which is all about this. Let me just mark this up. Engineering manager. Let's change the color. Engineer code reviewer. Merge conflict officer. Coding products that make complex changes to multiple files each time. That would be a really good one. Search task that gather information from multiple sources. Yep. And the evaluator optimizer. Man, there's a lot of good ones in here. I think we thoroughly covered what the purpose of the video was. You guys should go and read this on your own time when you're curious. If you learned one thing in this video, make sure you like it. If you learn two things, make sure you subscribe and you will see more videos on the following topics. So, we just did a gentic workflows versus agents. The next video will either be on me doing this for my YouTube channel or for my coding agent software. And then we'll be exploring MCP a little bit later. I also have another channel. This is the daily upload. The other channel is where I actually do built with you sort of stuff. So the way that these channels are going to work is the following. So on the daily channel, I pick a topic I need to learn or want to go deeper on. I explore with examples. I make this is not a 5 to 10 minute summary. This is 20. And then I end up making resources out of this and I put it into our community, our network vi. And then the main channel is I pick a project I need to build. I build it. I jot down spots along the way that I should probably talk about. And then I record the recap. And then I put the codebase inside of VIA. VI. Wow. Cool. That's it for this video. I'll see you in the next one.