Ask a chatbot "book me the cheapest flight to Bangalore tomorrow" and it explains, very politely, how to book flights. Ask an agent the same thing and it searches the flights, compares prices, books the ticket and messages you the PNR. Same model underneath — completely different system around it. "Agentic AI" is the loudest phrase in the industry right now, it's all over job descriptions, and interviewers are actively checking who actually understands it versus who just says the word. Let's put you in the first group.
Chatbot vs workflow vs agent — the ladder
Three rungs, and interviews check whether you can tell them apart. Chatbot: text in, text out, done. One LLM call, maybe with RAG. Workflow: a fixed sequence you programmed — extract the invoice, validate the fields, store the record — with LLM calls inside steps. The path is decided by your code. Agent: the path itself is decided by the model at runtime. You give it a goal and tools; it plans, acts, reads results and decides the next step — a route nobody pre-programmed. The defining question: who decides the next step? Your code → workflow. The model → agent.
The agent loop — ReAct
The classic pattern is ReAct — Reasoning + Acting, interleaved. The trace literally reads: Thought ("I need flight prices first") → Action (call search_flights(...)) → Observation (the results) → Thought ("cheapest found, now the weather") → … until a final answer. Two reasons the explicit "thought" step earns its tokens: it measurably improves tool choices (the model commits to a reason before acting — lesson 6's chain-of-thought, recycled), and it gives you a readable log of why the agent did what it did — priceless when debugging a weird run. Under the hood, the machinery is exactly lesson 8's function calling wrapped in a loop with a step limit. You'll write that loop in the Practice Zone — it's ~20 lines.
Tools — the hands
An LLM alone can only produce text. Tools are the functions/APIs you hand it — search, database lookups, calculators, email, code execution — its hands for touching the world. Two engineering truths: tool descriptions are prompts(the model picks tools by reading them — vague description, wrong pick), and capability = model × tools: a modest model with sharp tools often beats a genius model with none. And one safety truth, delivered properly in lesson 12 but worth planting now: give agents the minimum tools the job needs — an agent can't leak a database it can't query.
Agent memory — engineered, never innate
Nothing survives between LLM calls (lesson 8's statelessness), so every kind of agent "memory" is built. Short-term memory = the running context window: the goal, the conversation, this task's thoughts and tool results. Long-term memory = external storage — often a vector database holding past interactions, user preferences and learned facts, retrieved back in when relevant. Read that again: long-term agent memory is literally RAG applied to the agent's own history — one of those connections that makes an interviewer sit up. Deciding what deserves the limited context tokens each step — goal, recent observations, retrieved memories — is the craft the industry now calls context engineering.
Multi-agent systems — a team, not a hero
One agent juggling research, writing, coding and review gets a bloated prompt, a hoard of tools, and mediocre focus. The fix mirrors human teams: specialists. In the common supervisor/orchestrator pattern, a coordinating agent splits the goal into subtasks, routes each to a focused worker (researcher with search tools, coder with a code runner, reviewer with a rubric), and assembles the results. The honest trade-off to volunteer: every extra agent adds latency, tokens and new failure modes — multi-agent is a scaling tool, not a default.
LangChain, LangGraph & friends — the names in every JD
You don't hand-write the loop in production; frameworks carry the plumbing. LangChain: the veteran toolkit — chains, prompts, RAG components, tool integrations. LangGraph: agents as explicit graphs (nodes = steps, edges = decisions) with state, checkpoints and human-approval pauses — the current production favourite. CrewAI: quick role-based multi-agent teams. AutoGen, OpenAI's Agents SDK and others round out the field. Placement level: know what each is and be able to say why graphs help (explicit control flow, resumability, approval gates). Deep dives get their own course on this site next — the agentic-ai subject in the AI section.
Wait — my task runs the same 4 steps every time. Do I need an agent?
No — and saying so is the strongest answer in this whole topic. If the steps are known in advance (extract → validate → enrich → store), hard-code the workflow and use LLM calls inside the steps that need language. It'll be faster, cheaper, testable and predictable. Agents earn their overhead only when the path cannot be known upfront — open-ended support issues, research tasks, "figure out why this failed." Workflow when you can, agent when you must. Interviewers in 2026 actively reward this restraint — the hype phase is over; judgement is the differentiator.
Keeping agents safe — the two-line preview
An agent that acts can act wrongly: loops that never terminate (hence step limits and budgets), tools misused on the wrong target, and injected instructions hiding in the content it reads — a poisoned webpage telling the agent to exfiltrate data. The defences — least-privilege tools, human-in-the-loop approval for irreversible actions, input/output guardrails — are the subject of lesson 12, the final lesson.
Selection-round radar: the three agent questions that keep appearing: "chatbot vs agent?" (who decides the next step), "explain ReAct" (thought → action → observation, looped), and "when would you NOT use an agent?" (fixed path → workflow). Prepare all three as 30-second answers; they're asked at Accenture, Amazon, Microsoft and Google in almost this exact wording.
Common mistakes
- Calling every LLM app an "agent" — no goal-driven loop with tools, no agent.
- Building an agent for a fixed pipeline — workflows are cheaper, faster and testable.
- No step limit / budget cap — a stuck agent is an infinite bill.
- Handing over powerful tools "because it might need them" — minimum toolset, always.
- Expecting innate memory — all agent memory is engineered (context + external storage).
- Skipping the trace — without logged thoughts/actions, agent bugs are undebuggable.
Quick recap
| Concept | One-liner |
|---|---|
| Agent | LLM in a loop with a goal and tools — it decides the next step |
| ReAct | Thought → Action (tool call) → Observation → repeat → answer |
| Tools | described functions the model can request — descriptions are prompts |
| Memory | short-term = context window; long-term = RAG over its own history |
| Multi-agent | supervisor routes subtasks to specialists — scaling tool, not default |
| Frameworks | LangChain (toolkit), LangGraph (graphs+state), CrewAI (role teams) |
| The judgement call | workflow when you can, agent when you must |
Practice Zone — PYQs from real selection rounds
Six MCQs and three build-it tasks: trace a ReAct run, equip a support agent (including the tool you must NOT give it), and write the 20-line agent loop.
The core difference between a chatbot and an AI agent is:
Asked in
The ReAct pattern for agents interleaves:
Asked in
For an agent, tools are:
Asked in
An agent's short-term vs long-term memory typically maps to:
Asked in
In a multi-agent system, the supervisor/orchestrator pattern means:
Asked in
When is an agent the WRONG design choice?
Asked in
Build-it tasks:
An agent has tools search_flights(from, to, date) and get_weather(city, date). User goal: "Find me the cheapest flight from Delhi to Bangalore tomorrow, and tell me if I should carry an umbrella." Write the ReAct trace (thoughts, actions, observations) you'd expect.
Asked in
You're designing a customer-support agent for an online electronics store. Choose 4–5 tools you'd give it (name + one-line description each), and name one tool you would deliberately NOT give it, with the reason.
Asked in
Sketch the skeleton of a minimal tool-calling agent loop in Python (pseudo-SDK is fine): call the model, execute any tool it requests, feed the result back, stop when it produces a final answer or hits a step limit.
Asked in
FAQ
Is 'agentic AI' just marketing for function calling?
Function calling is the mechanism; agency is the architecture — a goal, a loop, and the model choosing each next step. One tool call decided by your code isn't agentic; a self-directed sequence of them is. The distinction is real, even if the marketing is loud.
Do I need LangChain/LangGraph to build agents?
No — the Practice Zone's raw loop is a real agent, and building it once teaches you what frameworks abstract. Frameworks earn their keep in production: state, retries, checkpoints, human-approval gates, observability. Learn the loop first, the framework second.
What is MCP that keeps appearing next to agents?
Model Context Protocol — an open standard that lets any AI app connect to any tool/data server through one common interface, instead of custom integrations per pair (think "USB-C for AI tools"). It's becoming the plumbing of the agent ecosystem — and it gets its own course on this site soon.
Are agents reliable enough for production?
Increasingly — with discipline: bounded loops, minimal tools, human approval on irreversible actions, evaluation and tracing. Teams ship agents for support, research and coding today; the failures come from skipping exactly those disciplines, which is why lesson 12 exists.
Final lesson: shipping all of this without ending up in the news — Lesson 12: Guardrails, Injection & Evaluation →