Key Concepts
- 1Tool calling is how the agent acts — querying inventory, pricing, tax, placing orders — turning a language model into a system that does things, not just talks
- 2Good tool design gives the model clear, narrow, well-described tools; vague or overlapping tools cause the model to call the wrong one or misuse arguments
- 3Deterministic work belongs in tools, not the model: pricing, tax, and inventory should be authoritative tool calls, never the LLM's approximation
- 4Error handling per tool is essential: tools fail, time out, and return unexpected data, and the agent must handle that gracefully rather than hallucinate around it
- 5Parallelizing independent tool calls cuts latency; sequencing dependent ones correctly preserves correctness — a key performance/correctness balance
- 6Confirmation gating on side-effecting tools (charge, place order, issue refund) is a safety pattern: read tools can be free, write tools need guardrails
- 7Tool schemas and descriptions are prompt engineering: how you name and document a tool directly shapes whether the model uses it correctly
Why It Matters for PMs
Reliability of action: Tool design determines whether the agent acts correctly. Clear, narrow tools and per-tool error handling are what make the agent dependable.
Correctness via delegation: Routing deterministic work (pricing, tax) to authoritative tools instead of the LLM is the core pattern for trustworthy commerce agents.
Safety on side effects: Distinguishing read from write tools and gating writes with confirmation is a foundational safety pattern that prevents costly mistakes.
Test Your Understanding
Question 1 (Multiple Choice)
What work should be delegated to tools rather than the LLM?
Question 2 (Multiple Choice)
Why gate side-effecting tools (charge, place order) with confirmation?
Question 3 (Multiple Choice)
Why do tool schemas and descriptions matter so much?
Question 4 (Short Answer)
How would you decide what belongs in a tool vs the model's own reasoning?
Think about your answer before revealing the explanation.
Question 5 (Short Answer)
How would you design tool error handling so a failed call doesn't lead to a hallucinated answer?
Think about your answer before revealing the explanation.