Course Content
Agentic AI Patterns
9 sections · 50 lessons
What do you understand about Agentic AI? How is it different from Traditional AI?
What you need to know
Three levels of "AI system"
| Level | Who decides the steps? | Example |
|---|---|---|
| Single model call | Nobody; there is one step | Classify an email as spam or not |
| Workflow | Code fixes the steps; the model fills them in | Extract invoice fields, then validate, then summarise |
| Agent | The model picks each step at runtime | "Resolve this support ticket" with 8 tools available |
The word workflow matters in interviews. Many systems called "agents" are really workflows: the model is called at fixed points in a path the engineer wrote. That is not a weakness. Workflows are cheaper, faster, and easier to test.
What changes when the model owns the loop
- Control flow is decided at runtime, so you cannot list every path in advance.
- State builds up: tool results, a plan, notes, and memory carry across steps.
- Actions change the world. Tools can write to databases, send emails, or book tickets.
- Termination is a model decision, which is why every agent needs step, time and cost limits in code.
Why not always use an agent?
Agency buys flexibility for tasks with an unknown number of steps. It costs latency, tokens and predictability. Each step can fail, and failures multiply: a 10-step run where each step is 95% reliable succeeds only about 0.95^10 ≈ 60% of the time. A fixed path with 3 steps at 95% succeeds about 86% of the time. So I choose the least dynamic pattern that works.
Traditional AI or a workflow
- Steps written by engineers
- Same input gives a predictable path
- Easy to test each step alone
- Fails loudly on inputs nobody planned for
Agentic AI
- Steps chosen by the model at runtime
- Path varies from run to run
- Needs trajectory-level evaluation
- Handles new cases, but can also do unwanted things
A real-life example
An insurance company processes motor-accident claims.
Traditional pipeline: an OCR model reads the claim form, a classifier tags the damage type, and a rules engine checks the policy. This works for 70% of claims. The other 30% fall to a human queue because something is missing: a garage estimate is a photo instead of a PDF, or the policy number has a typo.
Workflow version: the same fixed steps, but an LLM does the extraction, so messy documents are read better. The path is still fixed.
Agent version: the claims agent gets tools such as get_policy, search_prior_claims, request_document and estimate_repair_cost. For a claim with a wrong policy number, it searches by the customer's phone number, finds the right policy, notices the estimate is missing, and asks the customer for it. No engineer wrote that path.
The team keeps the workflow for the 70% of clean claims and routes only the messy 30% to the agent. That keeps cost down and puts the agent's flexibility where it earns its keep.
Follow-up questions to expect
- "Is a chatbot with RAG an agent?" — Not by itself. If it always retrieves once and answers, it is a workflow. It becomes agentic when the model decides whether, what and how many times to retrieve.
- "What makes an agent stop?" — The model declares it is done, or a limit in code fires: maximum steps, wall-clock time, or spend. You always need the code limits, because the model's own judgment can fail.
- "When would you pick a workflow over an agent?" — When the steps are known in advance. It is cheaper, faster and testable, and most production "AI features" are workflows.