Course Content
Agents & Tools Interview Prep
6 sections · 40 lessons
When should you use tool use versus simpler patterns like prompting or chaining?
What you need to know
Three levels
Prompt
- One call, no tools
- All input is already in hand
- Cheapest, most predictable
- Example: tag a review as positive or negative
Chain
- Fixed steps in code
- May call tools, but code decides when
- Each step testable alone
- Example: fetch order, then draft reply
Agent
- Model chooses steps and tools
- Step count varies per request
- Most flexible, hardest to test
- Example: investigate a failed refund
Questions to decide
- Is all the information already in the prompt? Then you do not need tools; one call is enough.
- Do you always need the same lookups in the same order? Then call them in code before the model (a chain). This is "pre-fetching" and it saves a round trip.
- Does the next step depend on the last result? Then the model needs to choose — use tools in a loop.
- What does a mistake cost? Agents multiply both cost and blast radius. Side-effect tools need approval and rollback plans.
A middle ground: single-shot tool use
You can give a model tools but only one turn: it chooses which lookup to make, your code runs it, and the next model call writes the answer. This is a chain with one model-chosen branch — often enough for support bots.
Cost comparison (illustrative)
| Approach | Model calls | Typical latency | Relative cost |
|---|---|---|---|
| Prompt | 1 | 1–2 s | 1× |
| Chain with 2 pre-fetched lookups | 1 | 1.5–3 s | about 1.2× |
| Agent, 5 steps | 5–6 | 10–30 s | 5–15× (history resent each turn) |
A real-life example
A bank's customer app has three AI features.
- "Explain this transaction" — the app already has the transaction JSON. One prompt: "Explain this charge in plain words." No tools.
- "Why was my UPI payment declined?" — the steps are always the same: fetch the transaction, fetch the decline code table, explain. The team wrote a chain: code does both lookups, then one model call. Response in 2 seconds, and they test it with 300 recorded declines.
- "Help me dispute these charges" — the path varies. Some disputes need card transactions, some need merchant details, some need the customer's earlier tickets, and some need a human. That feature is an agent with read tools and a
create_disputetool that requires confirmation.
The team first built the decline feature as an agent. It worked, but took 9 seconds and cost 6 times more, because the model re-discovered the same two lookups on every request.
Follow-up questions to expect
- "How do you migrate an agent to a chain?" — Read its traces. If 90% of runs make the same calls in the same order, hard-code that path and keep the agent only for the rest.
- "Can a chain include tool calls?" — Yes. Your code calls APIs directly; the model just does not decide when.
- "When is an agent cheaper?" — When a fixed chain would have to fetch everything "just in case", and the agent fetches only what each request needs.