AI Agents and Tool Use
An agent is a language model wrapped in a loop that lets it choose tools, act, observe the result, and decide what to do next. The skill interviewers test is judgment: knowing when that loop earns its unpredictability and when a fixed pipeline is cheaper, faster, and safer.
Transcript
Reach for a multi-agent swarm on a problem that wants a single retrieval call, and you've failed the judgment test. Interviewers are screening for restraint. The skill is knowing when the loop earns its unpredictability.
Strip away the hype. An agent is three parts. The model does the reasoning. The tools are functions it can call, like search, a database query, a calculator or an API. And the loop feeds tool results back to the model and asks, what now?
The common shape is ReAct, from Yao and colleagues in 2022. The model reasons about the goal, acts by emitting a tool call, observes the result, and reasons again. It keeps going until it produces a final answer instead of another tool call.
The next step isn't hard-coded. At runtime, the model decides whether to query the database, call an API, or stop, and that's what makes this an agent rather than a single call. It's the source of both the power and the danger.
So reach for an agent when the path is unknown until you see intermediate results. Think of a support task that might need a refund lookup, or an order status, or neither, depending on what the customer said. When the steps are knowable in advance, like retrieve, then summarize, then format, write those three steps as code. A pipeline is cheaper, faster, fully testable, and it can't wander.
Here's the framing to use. An agent is a controlled loss of control, and you pay for that flexibility in latency, tokens and unpredictability. Most production agents are really one or two tool calls behind a thin loop. That restraint is usually the right call.
Now the failure modes. Looping: the model calls the same tool, gets the same result, and tries again. Defend with a hard step cap and loop detection. Cost blows up too, because each turn is a full LLM call carrying the growing transcript. Turn eight rereads everything that turns one to seven produced, so ten turns cost at least ten times one.
Errors compound as well. A wrong tool call early poisons every later step, because the model reasons over its own bad output. At 90% success per step, ten steps come out right only about 35% of the time. And that assumes each step's success is independent of the last, which is optimistic.
And a tool that writes, pays or sends email needs a guardrail or a human confirmation, because the model chose to call it on its own. So before an agent runs against anything real, scope its tools to least privilege. Bound the loop with a hard step limit, and budget the tokens and the wall clock. Write the stop rule yourself. Gate the writes behind a confirmation, and log the whole trace.
The follow-up? Almost always evaluation, and you score three things: did it reach the right outcome, did it take a sane path, and what did it cost. A right answer reached through a 12-step detour is a latent failure. The full explainer is on fdeinterviews.com.
TL;DR: An agent is an LLM plus tools plus a loop: the model reads the goal, picks a tool, sees the result, and repeats until it decides it is done. That loop buys you the ability to handle open-ended tasks, but it also buys looping, cost blowups, and compounding errors, so you use it only when the task needs dynamic decisions a fixed pipeline cannot encode.
The loop is the whole idea
Strip away the hype and an agent is three parts. The model does the reasoning. The tools are functions it can call (search, a database query, a calculator, an API). The loop is the orchestration that feeds tool results back to the model and asks "what now?" The common shape is ReAct, from Yao et al. (2022, 'ReAct: Synergizing Reasoning and Acting in Language Models'), which interleaves reasoning traces with actions: the model reasons about the goal, acts by emitting a tool call, observes the returned result, and reasons again. It continues until it produces a final answer instead of another tool call.
What makes this an agent rather than a single call is that the next step is not hard-coded. The model decides at runtime whether to query the database, call an API, or stop. That is the source of both the power and the danger.
The flowchart is what an agent is. The spine above is what the loop needs before it runs against anything real: steps 3 and 5 are the two that stop a loop with no progress from spending until someone notices.
When an agent earns its keep
Reach for an agent when the path is unknown until you see intermediate results: a support task that might need a refund lookup or an order status or neither depending on what the customer said, a research task where each finding changes the next search. Use a fixed pipeline when the steps are knowable in advance. If the task is always "retrieve, then summarize, then format," write those three steps as code. A pipeline is cheaper, faster, fully testable, and cannot wander. The honest framing in an interview: an agent is a controlled loss of control, and you pay for that flexibility in latency, tokens, and unpredictability. Most production "agents" are really one or two tool calls behind a thin loop, and that restraint is usually the right call.
The trade-offs line up as:
| Factor | Favors fixed pipeline | Favors agent |
|---|---|---|
| Task path | Knowable in advance | Unknown until intermediate results |
| Dynamic decisions | None needed | Required at runtime |
| Cost per call | Lower | Higher (full LLM call per turn) |
| Error compounding | Bounded | Multiplies across turns |
| Testability | Fully testable | Unpredictable |
Failure modes you must name
- Looping. The model calls the same tool, gets the same result, and tries again. Defend with a hard step cap and loop detection on repeated calls.
- Cost and latency blowup. Each turn is a full LLM call carrying the growing transcript. Ten turns cost at least ten times one, and usually more, because turn eight re-reads everything turns one to seven produced. Budget steps and tokens explicitly.
- Compounding errors. A wrong tool call early poisons every later step, because the model reasons over its own bad output. Error rates multiply across turns: 0.9 multiplied by itself ten times is 0.35, so a 90% per-step success rate is only about 35% over ten steps, and that assumes each step's success is independent of the last, which is optimistic.
- Unsafe actions. A tool that writes, pays, or emails needs a guardrail or a human confirmation, because the model chose to call it on its own.
Why interviewers probe this
They are screening for restraint. The candidate who reaches for a multi-agent swarm on a problem that wants a single retrieval call fails the judgment test. The reserved follow-up is almost always evaluation. You evaluate an agent on three axes: did it reach the right outcome (task success on a golden set), did it take a sane path (number of steps, tool-call correctness, no loops), and what did it cost (tokens and latency per run). Trajectory, the sequence of steps it took, matters because an agent can stumble into the right answer through a wasteful path that breaks under load. Strong answers also mention scoping tools tightly and giving the model an explicit way to stop or escalate to a human.
Common misconceptions
- "More tools make a better agent." A large tool set raises the chance the model picks the wrong one each turn. Fewer, well-scoped tools beat a kitchen sink.
- "Agents replace pipelines." They handle the cases a pipeline cannot enumerate. For known steps, a pipeline wins on every axis that matters.
- "You only evaluate the final answer." A right answer reached through a 12-step detour is a latent failure. Score the trajectory too.
- "Reasoning loops are autonomous, so leave them alone." Step caps, action guardrails, and human checkpoints on irreversible actions are mandatory, not optional polish.
Key takeaways
- An agent = LLM + tools + a loop (reason, act, observe, repeat) that decides the next step at runtime.
- Use an agent only when the path is unknowable in advance; otherwise a fixed pipeline is cheaper, faster, and safer.
- The core failure modes are looping, cost blowup, and compounding errors; cap steps, scope tools tightly, and guard irreversible actions.
- Evaluate on outcome, trajectory, and cost, not just the final answer.