A prompt is a task.
A workflow is a process.
An agent is a system that acts.

Welcome to Barely Shipping. My name is Nathan Thompson, and today we are going to talk about something I've talked about before, but I built this, uh, page to help walk you through it. And at the end, there is a downloadable PDF if you'd like to take that with you and use into any AI tool you'd want to help you with your, uh, go-to-market projects.

So this, uh, page is at systemsledgrowth.ai/chat-vs-workflows-vs-agents. And the goal is to talk through the role of each one because I've been seeing a lot of different teams still, even with all the advancements in AI models that we've seen, use the wrong type of AI, chat versus workflow versus agent, for the wrong types of projects and then understand why things are going on.

So I just wanted to clear up how I see it, having built workflows for the past three and a half years and how, uh, a-agents and chats fit around those and when to use which system for which project. So right now, even still, a lot of teams are stuck on the very first level, that chat level. Now credit to where credit is due, chat is incredibly valuable for scaling an individual.

Uh, where it lacks is it starts to break down when you're trying to scale a team for a few reasons that we'll talk about in just a moment. That said, chat's capabilities are incredible, whether you're using OpenAI or Claude or Gemini. Um, any of those are, uh, phenomenal tools to help an individual get their work done faster and can be prompted, you know, prompt by prompt by prompt to help them with an overall process.

So it is very useful. I am a big fan of using chat tools, um, but they're not always the right solution, and they do have a few drawbacks. One of the first drawbacks that you've probably seen with people using chat tools is outsourced thinking. And this is when someone, instead of giving the right context or ideas to AI, they let AI come up with the ideas for them and then run with it.

You've probably seen this leading to something called AI slop, where the idea is somebody pops in and says, "Write me a LinkedIn post about thought leadership." And then it will give a pretty confident, albeit vague, post rather than someone creating a voice menu with their own thoughts on thought leadership and then having that draft a LinkedIn post based on their voice, based on their context and their role within a company.

And the outsourced thinking is a real problem. It's scaled laziness. The other problem when teams come to try to use this is, uh, team silos. And the idea is that if everyone has access to a chat tool, even in a team space or license, they might be approaching the same process with either different prompts or a different series of prompts.

So everyone is building their own way of working in a silo, and you can't necessarily go through to get the same consistent outputs by two different team members because they are using the tool differently to meet the same end goal. Another problem I've seen, which is really interesting, especially with the rise of MCPs, is this false context confidence.

So let's say that you have Gong or another call recorder, the MCP in your chat tool, and you have five hundred calls a month, uh, as a team, and you want to know the common themes or objections that come up in those calls. Often people will type, "Hey, what are the common themes or objections?" But because the corpus or the, the knowledge body is so large, it's not actually taking all of the, uh, context into the prompt.

In other words, you'll get a very confident response, but it might only be on a percentage of the act-actual transcripts that you have available. The other problem is that it is doing a semantic search, which means keyword for keyword. And as you're looking in those calls, unless somebody said something very specifically that you added to the prompt, it will sometimes give you misleading results.

Whereas if you have a fuzzy search where it is going more thematically rather than strictly keyword, um, it's a limitation right now of using an MCP with your chat database. Also, the, uh, scales as a person, not the team. Chat multiplies whoever is already good at using chat, but the real gain is capped at one headcount.

And again, it's an individual scaler. It is great for helping the individual get through their day, but workflows will scale a process and agents will help scale decisions. And if you're not sure if you're ready to move away from chat, and you're not very sure if you should use, um, an agent, uh, or a workflow, which we'll define in just a moment, you can use this quick test.

It's a yes or no question. Is this a process that's repeated? Yes. Can you write an SOP from start to finish? In other words, can you go through the entire process by hand because it's something that you've run for years? Let's say you can. That would be a workflow. Now, let's say it's a repeated process, but no, you can't write an SOP start to finish because there are outliers.

For example, um, there are-- is inbound lead scoring, and you're always having, uh, these leads come with little nuances involved as to the person's role, the person's company, all of these little things that you can't really account for the same every single time. Can you write an SOP start to finish? No.

Then you probably need an agent. Now, when you are trying to figure out which one that you should use, we can see here for content, for example, if you have chat, write me a LinkedIn post about this blog, you upload the blog, you upload the tone of voice, you input your thoughts on the blog to give it a unique perspective.

It's one task, it's one output, and it's done when you close the tab. But let's say that you wanted to batch that and you have a process for writing LinkedIn posts, which is you read the blog post, you have your voice notes stored, and then you add a small transcript or a few additional comments about your unique perspective, and you have the ability to now do that.

You need to come up with twelve of those in a week, and they all follow the exact same process. Read the blog post, take into account your thoughts and perspectives, take into account your voice, and then have a post come out for a human to edit on the back end before publish. When that's the case, you would wanna use a workflow.

You have the keyword, you have maybe some research. Let's say that you were even doing this for a blog post. You wanna look at your internal links, gap analysis. Whenever you can define an exact process and the process doesn't change, or the inputs don't change, and the goal is always the same, you're typically looking at a workflow.

Whereas with an agent, let's say that a draft arise, the agent needs to score one against the brand brief and send it to pass to scheduling and returns failures to the writer with a reason attached. There are small decisions along the way where the inputs change, the returns of failures, the reasoning behind it, where you'd want an agent to route the right doc to the right person with the right notes attached.

If you're in sales, and you can go through this on this page if you'd like, it's interactive, um, write a cold email, so it sounds less like a template. Or you have something where every single time somebody writes a cold email, they are going to go, uh, research the account. They are going to go research the names, the firmographics, the hiring signals.

They're gonna research all of the same set of things every single time. You're looking at a workflow. It is a predefined process where an expert has built out how they do something so that anyone use it can get the same result back. Whereas with an agent, again, inbound lead routing and deal hygiene, it would need to decide the owner, who is the best person for this.

It is going to need to decide the priority and the next action, and it will only be as good as your instructions to steer that agent. However, um, it is able to then make those decisions a little more efficiently than a workflow would. But there are a few drawbacks to each of these. Uh, so chat, nothing compounds.

Everything starts from zero. There's no audit trail in each individual user's, uh, experience and their interface, so you can't see what's leading to either good or bad outputs. The quality tracks by whoever is typing it, and so again, you can't codify a quality of result across different users because people are using their own prompts or they're using their own series of prompts through their own internalized process.

They are researching something with a different prompt. They are, uh, drafting with a different prompt. They've added different context for voice notes. And then that's where the context you paste in dies with the tab. So when you start a new chat, you're starting from scratch. You can build stuff into projects certainly, but you're still limited in terms of the context that you're adding during that chat session. Workflow is where consistency is the feature and the trap.

It works both ways every time. If you take a fuzzy or unoutlined process, then you're going to get fuzzy, uh, and subpar results. It also means that if you change one input format and it fails, it will usually do so quietly, and you might get results back that you weren't expecting because, again, you've changed a piece of the process, meaning the input.

So you're trying to add a new input to an already codified process, then you're, you're likely going to get something that doesn't look right on the back end and might just assume that it was the workflow's fault when really you've made a change that you need to change downstream. The other problem is that somebody who-- has to own the spec forever.

So when you do make those changes, somebody has to know the process well enough that they are able to go in and make the changes downstream for whatever new inputs you're having. And if you build something wrong and then you scale it, it will happily produce a scaled version of that wrong thing on schedule.

So if you're not quali-- if you're not testing this enough with enough quality, then it will unfortunately scale that broken process and produce broken results, uh, by the hundreds or even thousands. Now, agents, uh, have a different and unique problem. Their errors tend to compound across steps, and we'll get into that just a second.

They can be hard to debug because the path is different on every run, so they're dynamic enough, uh, running through a process that it is hard to figure out where in the chain it is-- needs more instructions. They need real guardrails and a real human check on anything irreversible, and this is messages going out to clients.

This is CRM updates if you let it run on autopilot, but it is starting to have those compounded errors that we just spoke about. It can then fill out bad sales data that is later used by other AI systems or humans to send out the wrong types of messages. And sometimes supervisions cost more than most teams budget for.

So keeping your eye on orchestrating all of these agents can be just as time-consuming or as costly as hiring people to do it by hand. Now, this isn't always true when they're set up correctly. Again, each of these buckets, chat, workflow, and agents, have a very strong place in any go-to-market function. Um, chat for tasks, workflow for codified processes end to end, and agent for processes where the inputs are different but the end goal is always the same.

Now, one of the reasons that agents fail, again, is this idea of compounding, uh, decision-making. And so let's say that on one decision in a chain that an agent is doing, the decision accuracy is about ninety-five percent. Pretty good. As that decision goes to the second, if it is also ninety-five percent accurate, then that drops the overall accuracy of the output, and that increases and compounds as more decisions are made.

Even if you get something to ninety-nine percent accuracy, if you start loading it with too many decisions, then you would get it correct every nine out of ten times. And as you build trust in this, it is easy to stop having oversight and letting that one error slip, which can be very, very costly. So this is where I believe that agents actually earn their keep.

Uh, inbound leads, specifically in go-to-market, every lead arrives as different, so it's a different input, but you always want the same thing, the right owner, very quickly, and it can be very good at making this type of decision. Support tickets. So you can't script every question that you're going to get, but the goal never changes, which is resolve that question or get someone who can really quickly.

Comment triage, where comments are unpredictable, so very different inputs each time. But you need an answer that is fast, and any answer is better than no answer. So getting the first draft very quickly to whoever's in charge of responding to that comment so that they can post the response, but again, being the human in the loop.

And then account signals. So account signals can fire from any order and in any combination. Um, the judgment you want applied to them is always fixed. And so you have these rules usually locked up in some doc or in an expert's head, um, where an agent can take that context and start to, um, help you with your account signals much faster than if you were doing it by hand.

So again, agents belong where the inputs are unpredictable, but the goal is always stable. Now, what I recommend is I made a PDF that helps walk through a process, going through and determining which project you're working on passes this test. So very quickly, the two-word test, is this repeated? No, then it's probably a chat tool.

If it's not a repeated process, then you probably wanna do it in chat. If it is repeated and you can write an SOP, meaning you know the process like the back of your hand, you're an expert in this field, and you're able to define the inputs needed to create an output, none of that in the system changes when you're running this process, then you're likely looking at a workflow.

And if you have a repeated process, but you cannot write the SOP start to finish, then you would need likely an agent with clear guardrails, clear instructions, and then you'd want a human to make sure that it is making the right decisions, certainly in the testing phase, without giving it too much content or, or too much confidence or too much access to your internal tooling or anything customer-facing before you release it.

And again, I have this downloadable PDF that walks you through everything that we just talked about, where agents, workflows, and chat tools. The same two-question survey here to get you to the right, uh, solution, and then a little worksheet with a scorecard that if you can write out the process, let's say writing a blog post, writing a, a content brief, uh, writing a follow-up email for sales, answering customer tickets.

If you can define that process, you would check box it depends. So the input is X question, well, it depends. And then you would score this so that you could see which one is most likely correct, along with some other helpful handouts. So if you have any questions, you can always reach out to me on LinkedIn.

Um, you can reach out to me at [email protected]. Um, or you can reach out to me on Substack via the comments or LinkedIn via the comments, uh, in the article. If, again, if you have any questions, just let me know. But, uh, I do think that this is a helpful way to break down, um, and then this PDF is a good thing that you can load into your, uh, AI tools to help make sure that, A, it's accurate.

So go ahead and pop this in and, and see if it's accurate and helpful to the goal. Uh, and B, help you decide which type of AI tool you need, a chat, workflow, or an agent in order to complete a given project.