logo

Command Palette

Search for a command to run...

Workflows Vs Agents

Friday, Aug 1
Tech

In the last post, We laid out basic building blocks for understanding agentic systems: It all starts with a Goal, you need a Procedure to get there, and you can use an LLM as a powerful engine to execute the steps.

This led us to a fundamental question: When We building a system, who is actually in charge of creating the procedure? Are we the one designing the step-by-step plan, or is the LLM?

I think, the answer to this question is the single biggest difference between what I call a AI Workflow and what I call an AI Agent.

The Workflow: Where We are the Architect

The first path is the one We feel most in control of. In a Workflow, We are the architect. We explicitly write down the entire procedure, breaking the goal down into a series of fixed tasks .

The LLM's role here is to be a fantastic employee. It doesn’t improvise; it just executes the one or more tasks we assigned it, exactly as we told it to.

For example, imagine We want to automate managing customer emails. We can build a workflow like this:

  • Step 1: Our system scans my inbox for new customer emails.
  • Step 2: It sends the email content to an LLM with a precise prompt: "Read this email and categorize it as either a 'Billing Inquiry' or a 'Technical Support' question."
  • Step 3: Based on the LLM's structured output, an automation rule forwards the email to the correct department's queue.

We call this approach rigid, and that’s its strength . The process is predictable and reliable. This is perfect for systems designed for goals that always follow the same procedure .

The Agent: Where the LLM Is the Architect

The second path is where We hand over control. With an Agent, We don't give the LLM a detailed procedure. We give it the high-level goal and ask it to figure out the procedure on its own . The LLM acts as the manager, operating in a loop: it decides on a step, acts, observes the result, and then decides the next step, repeating until the goal is met .

Imagine a much more complex goal, like "Improve customer satisfaction." This is too broad for a simple workflow. We give this goal to an agent. It might decide to:

  • Analyze recent customer support tickets to find common complaints.
  • Based on that, draft a new FAQ page to address these issues.
  • Then, monitor if the number of tickets about those issues decreases.
  • If not, it might try a new strategy, like drafting better template replies for the support team.

This approach is incredibly dynamic . It can change its plan on the fly, which is what makes agents so powerful for systems that have to handle a wide variety of goals, where each goal might need a completely different procedure.

The Ideal vs. The Reality: Why Not Use Agents for Everything?

This leads to a logical question: If an agent is so powerful and flexible, why not use it for everything? Ideally, a sufficiently intelligent agent could achieve whatever a workflow can, and much more .

But the reality, right now, is that the LLMs are not yet perfectly intelligent . They have real-world limitations. They can be less reliable, they hallucinate, have strict context limits that cause them to forget information, suffer from higher latency (slowness), and are often more expensive to run for simple tasks .

This is the big trade-off. Because of these current downsides, for goals with a fixed procedure where we need high reliability and efficiency, a workflow is often the smarter, more practical choice today .

So why bother with agents at all? Because building a custom workflow for every single potential goal is often impossible or would require a massive amount of upfront work. We can't program a workflow for every unique customer problem or research question. Agents make sense when we need a system to handle a vast, unpredictable range of goals, and we are willing to accept their current downsides to gain that flexibility.

Cheat Sheet

FeatureWorkflowAgent
Who's the Architect?Us, the system designerThe LLM
Control FlowStatic, predefinedDynamic, context-aware
ReliabilityHighLow
AdaptabilityLowHigh
TransparencyHighLow
Cost / LatencyLowHigh
Best ForSystems where goals share the same procedure.Systems that handle goals requiring different procedures.

Next Up: The Hybrid approach

So We have two main approaches: the controlled Workflow and the creative Agent. But the more I think about it, the more I realize "versus" is the wrong word. The most powerful solutions I've seen aren't purely one or the other.

In the next post, We will dive deep into this middle ground. I’ll share my personal framework for deciding when to lean one way or the other and explore the powerful hybrid patterns that combine the reliability of workflows with the flexibility of agents. Let's try to figure out how these two concepts can work together, not just against each other.