You tell a new intern: "this customer says their order arrived broken — sort it out." You don't list the steps. They look up the order, check the returns policy, ask for a photo, issue the refund, and message the customer. You gave a goal; they figured out the path. Now replace the intern with an LLM that has access to your systems, and you've built an AI agent. This lesson makes that idea precise — and, just as importantly, teaches you when not to build one.
Three architectures, one picture
Chatbot: question in, answer out. One model call. Even with RAG bolted on, it's still a fixed two-step pipeline. Workflow: a sequence you programmed — extract, validate, enrich, store — with LLM calls inside some steps. The path is identical every time. Agent: a goal and a toolbox, where the model decides each next action from what it just observed. The path is different for every request, and nobody wrote it down in advance.
The defining question
Interviewers ask "what makes something an agent?" and get vague answers about autonomy and intelligence. Here is the crisp test: who decides the next step — your code, or the model?
Your code deciding = workflow, however many LLM calls it makes. The model deciding = agent, even if it only has two tools. It's a control-flow distinction, not a capability one. That single sentence answers the most common opening question of this topic and prevents the most common mistake in the industry: calling a pipeline an agent because it uses AI.
What every agent needs — goal, tools, loop
A goal. Not a question — an outcome. "Resolve this ticket", not "what is the refund policy?". The goal is also the termination condition: the loop ends when it's met.
Tools. An LLM alone can only produce text. Tools — functions and APIs it can request — are its hands: look up an order, query a database, send an email, run code. Capability is roughly model quality × tool quality (lesson 2).
A loop. Think, act, observe, repeat. Remove the loop and you have a single tool call; remove the tools and it can only talk; remove the goal and nothing tells it to stop.
💡 Tip: a fourth thing every production agent needs, which tutorials skip: a step limit. An agent that can't achieve its goal will try variations forever, and each try costs money. Bound the loop before you ship it.
Autonomy is a dial, not a switch
"Autonomous agent" sounds binary. In practice you set autonomy per action, based on how bad it would be if the model got it wrong. Reading an order status: fully autonomous, no harm possible. Issuing a ₹500 refund: autonomous within limits enforced in code. Issuing a ₹50,000 refund: propose it, let a human approve. Deleting a customer account: don't give the agent that tool at all — let it file a ticket.
Gate by reversibility and blast radius, never by the model's confidence — confidence is exactly the signal LLMs are worst at. Designing this ladder deliberately is one of the strongest things you can say in an agent design round (lesson 10).
Wait — my task has four steps. Should it be an agent?
Almost certainly not, and this is the most valuable judgment in the whole course. If the four steps are the same four steps every time, hard-code them. A workflow is cheaper (no reasoning tokens per step), faster (no deciding), testable (deterministic), and debuggable (each failure has one obvious place to look).
Agents earn their overhead only when the path cannot be known in advance: investigating why a job failed, resolving an open-ended support case, researching a topic where each finding changes the next question. Workflow when you can, agent when you must.
Selection-round radar: "When would you NOT use an agent?" is now asked at Google, Amazon and Accenture — the hype phase is over and restraint is the differentiator. Answer: fixed known path → workflow; the agent's value is runtime decision-making, and you pay for it in latency, cost and predictability.
Why now? The idea is decades old
Software agents have been discussed since the 1990s. What changed isn't the loop — it's that models became reliable enough at two specific things: following instructions well enough to choose sensible actions, and emitting valid structured tool calls instead of prose about what they'd like to do. Before that, the loop ran fine and produced unusable actions.
That's also why agent reliability still tracks model quality closely, and why an agent that works on a flagship model may fall apart on a smaller one — a practical detail worth knowing before you promise a cheap deployment.
Common mistakes
- Calling every LLM app an agent — no goal-driven loop with tools, no agent.
- Building an agent for a fixed pipeline, then debugging non-determinism you created for no reason.
- Treating autonomy as all-or-nothing instead of per-action.
- Shipping without a step limit or cost budget.
- Giving the agent every tool "just in case" — more confusion, more blast radius.
- Assuming an agent that works in a demo will work on a cheaper model.
Quick recap
| Concept | One-liner |
|---|---|
| Agent | LLM + goal + tools + loop, where the model picks each next step |
| The test | who decides the next step — code (workflow) or model (agent)? |
| Needs | goal, tools, loop — plus a step limit in production |
| Autonomy | set per action by reversibility and blast radius |
| When not to | known fixed path → workflow, every time |
| Why now | reliable instruction-following + valid structured tool calls |
Practice Zone — PYQs from real selection rounds
Six MCQs and two tasks — classify five real systems, then talk a manager out of an agent they don't need.
The cleanest test for whether a system is an agent rather than a workflow is:
Asked in
Which of these is genuinely an agent?
Asked in
What are the three things every agent needs?
Asked in
When is an agent the WRONG choice?
Asked in
"Autonomy level" of an agent usually refers to:
Asked in
Why did agents become practical only recently, when the idea is decades old?
Asked in
Hands-on tasks:
Label each as chatbot, workflow, or agent: 1) Gmail's "smart reply" suggestions. 2) A nightly job that summarizes yesterday's tickets and emails the summary. 3) A coding assistant that reads a failing test, edits files, re-runs the test, and repeats until it passes. 4) A RAG bot answering HR questions. 5) A system that takes "plan my Bangalore trip" and books flights, hotel and cab.
Asked in
Your manager wants an agent to process incoming invoices: read the PDF, extract fields, validate against the PO, and file it. Write the honest 4-sentence pushback and what you'd build instead.
Asked in
FAQ
Is a RAG chatbot an agent?
Not by default — retrieve-then-answer is a fixed pipeline. It becomes agentic when the model decides whether, where and how often to retrieve (agentic RAG).
Do agents need a special model?
They need a model with good instruction-following and reliable tool calling — most current flagship and mid-tier models qualify. Smaller models often struggle with multi-step tool sequences, so test before assuming a cheap model will do.
Can an agent learn from experience?
Not by itself — weights are frozen. "Learning" is engineered: store outcomes and preferences externally and retrieve them into future runs (lesson 6), or fine-tune deliberately on collected trajectories.
Next lesson: giving the model hands — Lesson 2: Tool Calling Explained →