Hello to all the new subscribers who have joined us from the Customer Education series! It’s great to have you hear. Not all of my thoughts are specifically focused on Learning specifically - todays article covers my thoughts on Workflows vs Agents.
I try to include actionable tasks in every article or post I write and this is no exception - let me know in the comments if you manage to work through the exercise, and what your outcomes are. As ever, if you want to get these articles straight to your inbox, feel free to click the subscribe button, and share with others if you think they might benefit.
Think of a factory assembly line. Each station performs one specific task, in a fixed order, to build a final product. It’s a marvel of efficiency and predictability. A bolt is tightened, a panel is attached, a circuit is connected. If This, Then That. The process is rigid, documented, and it works flawlessly as long as nothing unexpected happens.
This is the world of automation. It’s powerful, essential, and the bedrock of operational efficiency. Yet, in our rush to embrace the future of work, we’ve started using a new, more seductive term: "agent." Everyone wants to build an "AI agent." We imagine autonomous systems solving complex problems while we focus on strategy.
I have had this “Agent” conversation so many times in the last couple of weeks with colleagues, leaders, peers from other companies that I felt compelled to write about it.
The problem is, most people talking about agents are actually describing a very sophisticated assembly line. They are skipping a crucial step, and in doing so, they are setting themselves up for failure. Before you can dream of autonomous agents, you must first master the humble workflow.
Workflow vs. Agent: Know The Difference
The confusion is understandable, but the distinction is critical. Getting it wrong wastes time, money, and credibility.
An Automated Workflow is a sequence of pre-defined actions triggered by a specific event. It follows a script. It has no decision-making power of its own; the intelligence was in the person who designed the script. Think of it as a set of digital dominoes. You push the first one, and the rest fall in a predetermined sequence.
Example: A customer submits a support ticket with the subject "Password Reset." The workflow automatically identifies the keywords and sends an email with a password reset link. It’s efficient, scalable, and solves one specific problem perfectly. It cannot, however, handle a ticket that says, "I can't get into my account and I think I've been hacked."
An Agentic Workflow, or an "Agent," is fundamentally different. You don’t give it a script; you give it a goal and the tools to achieve it. An agent can perceive its environment, make decisions, take actions, and even learn from the outcomes. It operates not on a fixed path, but within a framework of possibilities to reach an objective.
Example: You give an agent the goal: "Ensure this new customer successfully onboards." The agent monitors the customer's behaviour. It sees they haven’t configured a key feature after 48 hours, so it queries the knowledge base and proactively sends them the relevant guide. It notices they’ve invited three teammates and suggests a resource on collaborative features. If the customer’s activity suddenly stops, the agent can summarise the situation and escalate it to a human Customer Success Manager with a recommendation.
A workflow follows a map. An agent is given a destination and told to find the best route.
The Unavoidable Foundation: Your House Must Be In Order
Here is the hard truth. You cannot build an effective agent on a foundation of chaos. The allure of agentic AI makes it tempting to believe the technology can just figure it all out. It can’t.
Before you can successfully implement either a complex workflow or a true agent, you need two things in place.
Document the process
First, you must have a documented process. You cannot automate what you do not understand. If your current method for solving a problem is "Steve in accounts just handles it," you don't have a process. You have a dependency. An agent can’t learn from Steve’s intuition. You must first map the territory: every step, every decision point, every possible exception. This act of documentation alone often reveals enormous inefficiencies you can fix long before any AI gets involved.
The output of the documentation stage should be whatever gives you the most clarity for the least effort. It's a tool, not a deliverable. Avoid the trap of creating heavy, formal specifications for a process you haven't even validated yet.
Think of it as Minimum Viable Documentation. The goal is to create just enough clarity to build a pilot, communicate with a stakeholder, or hand off to a developer for a quick test. Anything more is waste.
For most initial workflows, this should consist of two simple parts:
A Basic Flowchart: A diagram is the fastest way to communicate a process. It doesn't need to be in a fancy tool; a whiteboard photo is fine. It must clearly show the sequence, including:
The Trigger: What specific event starts the workflow?
The Actions: What are the distinct steps the system or person takes?
The Decision Points: Where does the path diverge? Use simple IF/THEN logic.
The Endpoints: What are the possible successful or unsuccessful outcomes?
A Lean Functional Description: This is a one-page document, not a 20-page spec. It should concisely answer these questions:
Objective: What business problem are you trying to solve? (e.g., "Reduce support tickets for password resets.").
Actors: Who or what is involved? (e.g., "The customer, Zendesk, our email platform.")
The 'Happy Path': In a simple numbered or bulleted list, describe the steps when everything goes right.
Key Exceptions: What are the one or two most common failure points or alternative paths? Don't try to map every edge case; focus on the 80/20 rule.
Success Metric: How will you measure if it's working? (e.g., "A 15% reduction in manually handled password tickets within 30 days.").
The less impactful approach is to spend a month writing a comprehensive technical specification that tries to account for every possibility. That's launching a boulder.
The better approach is to create a one-page diagram and description you can validate with a colleague in 15 minutes. This allows you to move quickly, test the core logic, and "fail smarter" if your initial assumption is wrong.
Clean Data
Second, you need clean, accessible data. An agent is only as smart as the information it can access. If your product documentation is outdated, your CRM is full of duplicate contacts, and your knowledge base is a graveyard of un-tagged articles, your agent will be useless. It will confidently make bad decisions based on bad information. "Garbage in, garbage agent" is the new reality. Your data infrastructure is the sensory system for any agent you hope to build.
When Do You Actually Need an Agent?
The goal isn't to use the most advanced technology. The goal is to solve a business problem effectively.
Stick with an automated workflow when the task is high-volume, predictable, and has low variability. Think password resets, sending welcome emails, or generating standard reports. Automation here delivers speed and efficiency. It’s about doing the same thing, faster.
Reach for an agentic workflow when the problem is complex, requires multiple steps, and involves significant variability. Think resolving complex customer issues, personalising a partner enablement path, or managing project resources. Agency here delivers effectiveness and resilience. It's about achieving a better outcome, whatever the path looks like.
Don't over-engineer your solution. A simple, robust workflow that works is infinitely more valuable than a complex, expensive agent that doesn’t. Master the assembly line before you try to build a self-driving car.
The path to the future of work isn't a leap into the unknown. It's a structured ascent. It starts with understanding and documenting your processes. It relies on clean and organised data. It is built by mastering automation first.
The real question isn't whether you're ready to build an agent. It's whether you've done the hard work on your own processes first.
Your First Step: The 30-Minute Workflow Audit
Theory is useful, but action is better. Before you think about agents again, put this article into practice with a simple diagnostic exercise.
Find the Friction. Identify one repetitive, low-value task that consumes your team's time. What is the most common, basic question your support team has to answer? What onboarding resource do you send manually, over and over again? Pick one.
Map the Manual Path. On a whiteboard or in a document, map out every single step a human currently takes to resolve that one issue. Be brutally honest. Note every click, every system they have to open, and every piece of information they have to find. This is your current, manual workflow.
Design the Simple Fix. Now, sketch out the "dumbest" possible automated workflow to solve it. Use simple IF [Trigger], THEN [Action] logic. For example: IF a customer completes their profile setup, THEN send the 'Next Steps' checklist email. The goal is not a perfect, all-knowing agent; it is a predictable, scalable script that handles 80% of the work.
This short exercise does more than just design a single workflow. It builds the process-first discipline required for any serious automation strategy. It is the essential, unavoidable first step.
P.S. - I tried out Googles Veo3 video creator to see what it would create based on this prompt:
“I want to create a video that represents the concepts of Automated workflows vs AI Agents. Workflow mapping is the first step before even considering whether it needs agency”
The result, not bad….. :