Applied GenAI Curriculum for AI PMs · Core Sequence

Unit 04 — Workflows vs. Agents: The Foundational Distinction

The core architectural split — predefined code paths vs. the model directing itself — the five composable workflow patterns, and a checklist for when an agent is justified at all.

Why this unit is the architecture anchor

You've decided a feature is worth building (Unit 03). The very next fork is how it's structured — and it's the fork teams most often get wrong, usually by reaching for an "agent" because it sounds powerful. The guiding principle here is blunt: find the simplest solution possible, and only add complexity when it demonstrably improves outcomes. For many applications, a single well-optimized model call with retrieval and good examples is enough. This unit gives you the vocabulary to hold a team to that discipline.

1. The distinction that organizes everything

"Agentic systems" is the umbrella. Underneath it sits one architectural line that matters more than any other:

Workflows

LLMs and tools orchestrated through predefined code paths. A human wrote the steps; the model fills in the hard parts.

→ Predictable, consistent, easier to debug

Agents

Systems where the LLM dynamically directs its own process and tool use, keeping control of how it accomplishes the task.

→ Flexible, model-driven, higher cost & risk

The trade is explicit: agentic systems buy better task performance with latency and cost. Workflows give predictability and consistency for well-defined tasks; agents earn their keep when you need flexibility and model-driven decisions at scale. That's the whole decision in one sentence — everything below is detail.

The question to ask in the room When a team says "let's build an agent," ask: "Can we predict the steps in advance?" If yes, a workflow is simpler, cheaper, and more debuggable. "Agent" should be a conclusion you're forced into, not a starting point.

2. The building block: the augmented LLM

Before any pattern, there's one primitive. Every box in every diagram below is this same thing — an LLM enhanced with augmentations it can actively drive: generating its own search queries, picking tools, deciding what to remember.

LLM + Retrieval Tools Memory

Two things make this primitive good: augmentations tailored to your use case, and a clean, well-documented interface for the model to use them (one standard way to wire this up is the Model Context Protocol). For the rest of the unit, assume every model call already has these capabilities.

3. The five workflow patterns

These are composable building blocks, not a prescriptive menu — you shape and combine them. Knowing their shapes lets you read an architecture diagram and name what you're looking at.

01Prompt chaining

step 1 → [gate] → step 2 → step 3

Decompose a task into a fixed sequence, each call processing the last one's output, with optional programmatic gates checking progress between steps.

Use when: the task cleanly splits into fixed subtasks and you'll trade latency for accuracy. E.g. write an outline → check it → write the doc.

02Routing

classify input → route to specialized path

Classify the input, then send it to a specialized follow-up. Separation of concerns lets each path use a focused prompt without one input type degrading another.

Use when: distinct categories are better handled separately and classification is reliable. E.g. route support queries by type; route easy questions to a cheap model, hard ones to a capable one.

03Parallelization

split → run simultaneously → aggregate

Run work in parallel, then combine. Two variants: sectioning (independent subtasks at once) and voting (same task several times for diverse outputs / higher confidence).

Use when: subtasks parallelize for speed, or multiple perspectives raise confidence. E.g. one model answers while another screens for policy violations (a guardrail); several prompts vote on whether code is vulnerable.

04Orchestrator–workers

orchestrator breaks down → delegates → synthesizes

A central LLM dynamically breaks a task into subtasks, delegates them to worker LLMs, and synthesizes the results. Looks like parallelization but the subtasks are not pre-defined — the orchestrator decides them from the input.

Use when: you can't predict the subtasks in advance. E.g. a coding change touching an unknown number of files; multi-source research.

05Evaluator–optimizer

generate → evaluate → refine → (loop)

One call generates, another evaluates and gives feedback, in a loop — mirroring how a writer iterates toward a polished draft.

Use when: you have clear eval criteria and iteration measurably helps — specifically when articulated feedback improves the output and the model can produce that feedback. E.g. literary translation with an evaluator critiquing nuance.

Note the ladder of autonomy Patterns 01–03 run on fixed, human-defined paths. Pattern 04 hands the decomposition to the model. Pattern 05 hands it a loop with a stopping judgment. Each step gives the model more control — and costs more predictability. Full agents are the end of this ladder, not a different thing.

4. Agents — and when they're justified

An agent is, mechanically, "just an LLM using tools based on environmental feedback in a loop." It starts from a human command or discussion, then plans and operates independently — gaining ground truth from the environment at each step (tool results, code execution) to gauge progress, pausing for human checkpoints or on blockers, and stopping on completion or a cap (e.g. max iterations) to stay in control.

Agents fit when…	The cost you accept
The problem is open-ended and you can't predict the number of steps or hardcode the path.	Higher cost from many turns.
You can trust the model's decision-making in this environment.	Potential for compounding errors across steps.
The environment is trusted, and the task scales with autonomy.	Need for sandboxed testing and guardrails before production.

Two domains where agents genuinely earn it — and notice the shared traits: both require conversation and action, have clear success criteria, enable feedback loops, and integrate human oversight:

Customer support	Conversational flow + tools to pull data and take actions (refunds, tickets); success is a measurable resolution — enough that some vendors charge only for successful resolutions.
Coding agents	Solutions are verifiable by automated tests, so the agent iterates on test feedback; the problem space is structured and output quality is objectively measurable. Human review still matters.

The checklist that prevents an expensive mistake Before greenlighting an agent, require yes to: (1) steps genuinely unpredictable, (2) clear success criteria, (3) a real feedback signal from the environment, (4) a trusted/sandboxed environment with guardrails, and (5) a stopping condition. Miss any, and a workflow is almost certainly the safer, cheaper build.

The three agent principles (for when you do build one)

If a team clears the bar and builds an agent, hold them to three principles — each is a place a PM can ask a pointed question:

Maintain simplicity	Resist added complexity that doesn't demonstrably improve outcomes.
Prioritize transparency	Explicitly show the agent's planning steps, so its reasoning is inspectable.
Craft the agent-computer interface (ACI)	Invest in tool documentation and testing as much as you would a human interface — poorly designed tools are a leading source of agent errors.

What "good" looks like after this unit

You can now:

State the workflow-vs-agent distinction in one line — predefined paths vs. the model directing itself — and the cost/latency-for-performance trade behind it.
Recognize and name the five workflow patterns from an architecture diagram, and say which fits a given task.
Run the five-point checklist that decides whether an agent is justified — and default to "workflow" when any point fails.
Ask the three sharp questions (simplicity, transparency, ACI) of any agent proposal that does clear the bar.

Deeper agent mechanics — tool design, planning, failure-mode budgeting, memory — are deferred to Unit 18, pulled in only when an agent project is actually greenlit.