Free lesson · Claude Certified Architect - Foundations (CCA-F)
Agents, Workflows, and Conversational Systems - The Real Differences
Three Words People Use Loosely
In everyday conversation, people call almost anything built with a language model an "AI agent." That is fine in a meeting. It is not fine on this exam.
CCAR-F treats these as three different architectures with three different cost profiles and three different failure modes. Scenario questions describe a system in plain words and expect you to know which one it is, because the right answer usually depends on that.
The good news is that telling them apart comes down to one question.
The One Question That Separates Them
Who decides what happens next?
That is it. That single question sorts all three.
| Architecture | Who decides the next step | Has tools? |
|---|---|---|
| Conversational system | Nobody - it just replies and waits | Usually no |
| Workflow | Your code, written in advance | Often yes |
| Agent | The model, while it is running | Yes, always |
graph TD
A["Who decides the next step?"] --> B["Nobody<br/>It replies and stops"]
A --> C["My code<br/>decided in advance"]
A --> D["The model<br/>decides at runtime"]
B --> B1[Conversational system]
C --> C1[Workflow]
D --> D1[Agent]
This diagram sorts three architectures using one question: who decides the next step. If nobody decides and the system simply replies and stops, it is a conversational system. If your code decided in advance, it is a workflow. If the model decides at runtime, it is an agent.
Hold on to that question. It will get you through most of the questions in this domain.
Conversational Systems
This is the simplest of the three. Someone asks something, the model answers, and then it waits for the next message.
There is no plan. There is no next step. There is just a turn of conversation, and then the system stops until a human says something else.
A support chatbot that answers questions about your return policy is a conversational system. It knows things and it can explain them. It cannot look up your specific order, and it cannot process your return.
What it is good at: answering questions, explaining things, drafting text, being cheap and fast and easy to predict.
Where it stops: the moment the user needs something done rather than explained.
Tip: A quick way to spot one in a scenario: if the system can only tell the user things, and never changes anything anywhere, it is conversational. The word "tools" will be absent from the description.
Workflows
A workflow uses a model at one or more steps, but you wrote the order of those steps in your code.
Say you process invoices. Your code does this, every time, in this exact order:
- Read the PDF
- Ask the model to pull out the vendor, date, and amount
- Check the amount against the purchase order in your database
- If it matches, approve. If not, flag it for a human.
The model does real work in step 2. But it never decides that step 3 comes next. Your code decided that, months ago, when someone typed it.
This is a workflow, and for this task it is almost certainly the right design.
Why? Because invoice processing has a fixed shape. Every invoice needs the same steps in the same order. There is nothing to decide. Handing that decision to a model would add cost and unpredictability and buy you nothing.
graph LR
A[PDF arrives] --> B[Model extracts<br/>fields]
B --> C[Code checks<br/>against database]
C --> D{Match?}
D -->|Yes| E[Approve]
D -->|No| F[Flag for human]
This diagram shows a workflow for invoice processing running left to right. A PDF arrives, the model extracts fields, then code checks those fields against a database. A decision point asks whether the values match: a yes routes to approve, a no routes to flag for a human. Every step and the order between them was written in code in advance.
Notice the diamond in that diagram. There is a decision in this workflow - match or no match. But it is your code making it, based on a rule you wrote. The model is not choosing.
Important: A workflow can contain branches, loops, and decisions and still be a workflow. What makes it a workflow is that all of those were written by you in advance. Branching is not the same as autonomy.
Agents
An agent has tools and decides for itself which ones to use, in what order, and when to stop.
Take the same invoice, but change the situation. Now invoices arrive in twelve different formats, some are scanned photos, some reference purchase orders by a code that does not match your system, and roughly one in five has something unusual about it.
Writing a workflow for that means imagining every unusual case in advance and writing a branch for each. You will miss cases. You will keep discovering new ones for months.
An agent handles it differently. It reads the invoice. If the vendor name is unclear, it searches your vendor list. If the purchase order code does not match, it tries a fuzzy lookup. If it still cannot resolve it, it escalates. You did not write those branches. It worked them out.
What it is good at: messy inputs, situations you cannot fully predict, tasks where the right next step depends on what the last step found.
What it costs: more money per task, less predictability, harder debugging, and the need to add your own safety limits.
Seeing All Three on the Same Problem
The clearest way to feel the difference is to apply all three to one task. Say the task is: help a customer who says their order is late.
| Architecture | What it does | What it cannot do |
|---|---|---|
| Conversational | Explains your shipping timelines and return policy | Cannot see this customer's actual order |
| Workflow | Looks up the order, checks the ship date against a rule, sends a templated response | Breaks when the situation is not one of the cases you coded |
| Agent | Looks up the order, sees no delivery scan, checks the carrier, decides it is lost, offers a replacement | Might do something you did not expect |
All three are reasonable systems. Which one is correct depends entirely on your situation - how varied the cases are, how much a wrong action costs, and how much you are willing to spend per request.
Interview: Scenario questions rarely say "this is a workflow." They describe it. Phrases like "our pipeline calls the model at each stage," "the process runs the same steps every time," or "the code determines which branch to take" are describing a workflow. Phrases like "the model determines which tools to call" or "the system continues until it resolves the request" are describing an agent. Learning to hear these is worth several points.
Interactive animation: Workflow phrases against agent phrases - the scenario's wording tells you the architecture before you read the options.
The Middle Ground People Forget
Real systems are often mixed, and the exam does test this.
A common and very sensible shape is a workflow with an agentic step inside it. Your code runs a fixed pipeline, but one stage in the middle hands off to an agent because that particular stage is messy.
Going back to invoices: your code handles receiving, storing, and approving in a fixed order - because those steps genuinely are fixed. But the "figure out what this invoice actually says" stage is agentic, because that part is messy.
This gives you the predictability of a workflow everywhere it is possible, and pays the cost of agency only where the flexibility is genuinely needed.
graph TD
A[Fixed: receive invoice] --> B[Agentic step:<br/>understand this document]
B --> C[Fixed: check against<br/>purchase order]
C --> D[Fixed: approve or flag]
B -.->|Model chooses tools<br/>and order here| B
This diagram shows a hybrid design as a vertical sequence. Receiving the invoice is a fixed step. The next stage, understanding the document, is agentic, and an annotation notes that the model chooses tools and order within this stage only. Checking against the purchase order and approving or flagging are both fixed steps again. The result is a workflow with one agentic stage inside it.
Tip: When a scenario describes a process that is mostly predictable but has one messy part, the best answer is often this hybrid rather than making the whole thing agentic. Look for it - it is frequently the "most correct" option sitting among several defensible ones.
The Honest Default
Here is a rule that will serve you well on the exam and in real work:
Start with the least autonomous design that solves the problem. Add autonomy only where you can point at a specific reason you need it.
This is not conservatism for its own sake. It is because every unit of autonomy you add costs you predictability, and predictability is what makes systems debuggable, testable, and safe.
If someone asks why a workflow took a particular path, you can point at a line of code. If someone asks why an agent took a particular path, the honest answer is "it decided to." That is a much harder conversation, and in regulated or high-stakes settings it can be an unacceptable one.
Warning: Do not read this as "agents are bad." Where inputs are genuinely unpredictable, a workflow does not become more reliable - it just fails in a different way, by hitting cases nobody coded for. The point is to match the design to the problem, not to prefer one architecture on principle.
Exercise: Starter. Write one-line descriptions of a conversational system, a workflow, and an agent for the same task: handling a password reset request. Notice what each one can and cannot do.
Intermediate. Take a process at your work that currently runs as fixed code. Identify the single messiest step in it. Would making just that step agentic help? Write two sentences on what it would gain and what it would cost.
Advanced. Write a short scenario narrative - three or four sentences - that describes a system without naming its architecture, where the correct answer is "workflow." Then write another where the correct answer is "agent." Pay attention to which specific words in your narratives carry the signal. Those are the words to listen for on exam day.
Quiz: Quick check: A scenario describes a system that receives support emails, calls the model to classify each one into a category, then routes it to a team based on a lookup table in the code. The model has no tools. Which architecture is this?
A) An agent, because the model is making a classification decision B) A workflow, because the code decided the sequence and the routing rule C) A conversational system, because it processes text D) A hybrid, because the model is involved in one step
Answer: B - the model classifies, but it does not choose what happens next. The sequence and the routing rule were written in code in advance, and there are no tools. Classifying is not the same as deciding the path.