Lesson 1 of 6 in Agentic Architecture & Orchestration

1.1 · Agent, workflow, or conversation?

Every LLM system you build falls into one of three archetypes. The single most common architecture mistake — the one that inflates cost, degrades reliability, and shows up as wrong answers on the exam — is choosing the wrong one. This lesson gives you a decision framework for picking correctly, and shows you the specific over-agentification patterns the exam rewards you for rejecting.

1.1.1 Three archetypes, one decision

A conversational system answers in one turn without acting on the outside world. Ask it a question, get an answer. No tools, no loop, no state that survives the turn. This is the shape of a plain chatbot answering from its training data.

A workflow is a pre-defined sequence of LLM calls that YOU wrote. You know the steps in advance and encode them: step 1 extracts, step 2 validates, step 3 formats, step 4 writes. The LLM does the individual steps; the developer chose the sequence.

An agent is an LLM in a loop where the model decides the next step at runtime. The developer sets up the tools and the loop mechanics, but the model — not the developer — picks which tool to call, when, and in what order.

Key point — Archetype is chosen at design time, not runtime. Once you build a workflow, you cannot make it agentic without restructuring; once you build an agent, you cannot make it a deterministic workflow without stripping out its autonomy.

1.1.2 The three properties that make something an agent

An agent has three properties: autonomy (the model picks next steps), tool use (it acts on the world), and an action loop (it iterates on tool results). Remove any of the three and you have something simpler. A single LLM call with tool use but no loop is a function call, not an agent. A loop with predetermined steps is a workflow, not an agent. Autonomy without tools is just multi-turn reasoning.

Analogy — Think of it like driving. A conversational system is asking a passenger for directions. A workflow is following turn-by-turn GPS instructions someone gave you. An agent is being handed the keys, an address, and a fuel budget — you decide when to turn, when to stop for gas, when to reroute around traffic.

Exam trap — The exam frequently presents a scenario where the correct answer is 'this shouldn't be an agent at all — use a workflow.' Adding subagents, orchestrators, or extra loops to a fundamentally deterministic task is a wrong answer, even if the extra structure sounds sophisticated.

1.1.3 When agents earn their cost

Agents cost more, run longer, and fail in less predictable ways than workflows. Every extra iteration is another API call, another chance for the model to pick the wrong tool, another opportunity for context to grow beyond useful bounds. That cost is only worth it when the path depends on what the model discovers along the way — open-ended research, dynamic troubleshooting, exploratory analysis, tasks where you literally cannot enumerate the steps in advance.

Deciding by task shape
# WORKFLOW territory (steps knowable):
# 'Extract totals from 100 invoice PDFs to a spreadsheet.'
# → read → extract → validate → write. Deterministic.

# AGENT territory (path emerges from findings):
# 'Investigate why our checkout conversion dropped 8% this week.'
# → look at metrics, form hypothesis, check logs, refine,
#    pivot to funnel data if needed. Steps unknown up front.

1.1.4 The over-agentification trap

Reaching for agents by default is the most common junior-architect mistake, and the exam tests it directly. If a workflow can do the job, a workflow will be cheaper, faster, more testable, and easier to debug. Every additional degree of autonomy you grant is a degree of predictability you give up — sometimes that trade is worth it, but you should be making the trade deliberately, not by reflex.

Key point — When the exam gives you an answer that adds an agent, a subagent, or an orchestrator to a task with knowable steps, that answer is almost always wrong. The correct answer is usually the simplest solution that meets the requirements — often 'improve the prompt' or 'write a straight workflow.'

Takeaways

  • Three archetypes: conversational (one turn), workflow (you wrote the steps), agent (model picks steps at runtime)
  • Agent = autonomy + tool use + action loop. Missing any one and it's something simpler
  • Agents earn their cost only when the path depends on what the model discovers
  • Default to the simplest archetype that meets requirements — the exam rewards this
  • Adding agents to deterministic tasks is a common wrong-answer shape

Exam traps

Adding a coordinator agent to a task with fixed, knowable steps
The exam presents scenarios where the workflow-shaped answer looks 'simpler' and the agentic answer looks 'sophisticated.' Reject the agentic answer when the steps can be written down in advance. Coordinators exist for dynamic decomposition, not for wrapping deterministic pipelines.
Choosing an agent because 'the input is complex' or 'the volume is high'
Complexity of input is not what determines archetype — knowability of path is. High volume favours workflows and batch processing, not agents. Agents cost more per task; scaling them up scales the cost linearly.
Treating multi-turn conversation as agentic behaviour
Back-and-forth chat that doesn't call tools or take actions in the world is conversational, not agentic. Multi-turn does not imply agentic; agentic requires action loops with tool use.

Practice scenario

A team wants to process 100,000 support tickets nightly: read the ticket, extract sentiment and category into a fixed schema, and write results to a warehouse. Latency doesn't matter (overnight batch). They propose building a coordinator agent that spawns subagents per ticket. What should you recommend?

Next →