01. Week 9 — Agents & Tool Calling¶
Key concepts to master¶
- LLM call: one-shot generation, no loop, often no tools
- Tool use: model can call a tool, but maybe only once
- Agent: model + tools + loop + state + stopping rule
- ReAct: think → act → observe → repeat
- Tool schema design:
- narrow scope
- clear descriptions
- typed arguments
- structured errors
- idempotency where possible
- Guardrails:
- max-step cap
- budget cap
- validation
- HITL for risky writes
- State across turns:
- chat history
- structured working state
- memory
🧠 Mental models¶
- Agent: "An LLM with hands, a notepad, and a stop rule."
- ReAct: "Drive, check the mirrors, correct the steering, repeat."
- Tool schema: "A power outlet shape; if the pins are vague, the plug misses."
- Planning loop: "A foreman breaks the job into steps, then re-plans after each observation."
- Guardrails: "Bowling bumpers that stop expensive gutter balls."
- State across turns: "Working memory plus a case file, not just the last sentence."
⚠️ Common traps¶
- Tool names or descriptions are ambiguous, so the model routes to the wrong function.
- Write tools are not idempotent, so retries after timeouts create duplicate side effects.
- Raw tool errors are dumped back into the loop with no structured recovery or fallback.
- No max-step, budget, or timeout caps, so the agent burns tokens in infinite loops.
- One agent handles planning, execution, validation, and risky writes with no separation of duties.
🔗 Prerequisites & connections¶
Builds on: Module 08 (RAG Advanced) — query loops, confidence gating, and retrieval retries become generalized agent control flow. Feeds into: Module 10 (MCP & Multi-Agent) — tool schemas, state, and stopping rules are the foundation for protocol-based multi-agent systems.
💬 Interview phrasing¶
- "What's the difference between a chatbot with tools and a true agent?"
- "How would you design a function or tool schema so the model calls it reliably?"
- "A tool call failed halfway through a write. How should the agent recover?"
- "When do parallel tool calls speed things up, and when do they create risk?"
- "Which guardrails are mandatory before an agent can touch production systems?"
⏱️ Difficulty markers¶
- 🟢 LLM call vs tool use vs agent
- 🟢 ReAct loop
- 🟡 tool schema design
- 🟡 state across turns
- 🔴 idempotent retries and error recovery
- 🔴 multi-step planning and agent architecture
Self-check questions¶
For deeper answers,
see 02_explainer.md chapter 6.
- Why is one correct tool call not enough? (explainer §1.1)
- ReAct's three steps — what does each do? (§2.1)
- Why do tool names and descriptions affect routing quality? (§3.1-§3.3)
- What is idempotency, and why does it matter for agents? (§3.5)
- Which guardrails stop infinite loops? (§4.1-§4.4)
- When should you add a human-in-the-loop gate? (§4.5)
- Parallel tool calls — when do they help, and when do they create risk? (§5.1)
- What five basics will module 10 assume from this week? (§5.7)
Health check¶
- [ ] Read all explainer chapters
- [ ] Can explain ReAct without notes
- [ ] Designed 3 clean tool schemas
- [ ] Shipped support agent with evals
- [ ] Can sketch the failure-fix table from explainer §6.1
- [ ] Passed the foundation-gap audit for module 10