FDEInterviews logo
🤖 Retrieval & Agents
Foundational

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.

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: 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 an agent needs before it is safe to run 1 A goal open-ended, by definition 2 Scope the tools least privilege, named 3 Bound the loop a hard step limit 4 Budget the cost tokens and wall clock 5 Define the stop rule not "when it decides" 6 Gate the writes confirmation before effect 7 Log the whole trace every call and every result The next step is not hard-coded, which is the source of both the power and the danger. The tool list is the only hard boundary on what it can reach. Without a step limit, a loop that cannot make progress does not stop. It spends. Looping and cost blowups are the two failures that appear first. An agent that decides for itself when it is done will sometimes decide early and sometimes never. A stop rule you wrote is one you can test. Errors compound across a loop, so a trace that shows only the final answer cannot tell you which of nine steps went wrong.

The loop above is what an agent is; this is what it needs before it runs against anything real. Steps 3 and 5 are the two that stop a loop with no progress from simply spending until someone notices.

rendering diagram…

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.

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:

FactorFavors fixed pipelineFavors agent
Task pathKnowable in advanceUnknown until intermediate results
Dynamic decisionsNone neededRequired at runtime
Cost per callLowerHigher (full LLM call per turn)
Error compoundingBoundedMultiplies across turns
TestabilityFully testableUnpredictable

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 can be ten times the cost and the wall-clock time of one. 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, so a 90% per-step success rate is only about 35% over ten steps.
  • 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 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.
RELATED CONCEPTS
PRACTICE THIS IN REAL QUESTIONS