There’s a particular kind of interview question that looks like a definitions quiz and isn’t. “Explain how tool use works.” “What’s an agent loop.” “What could go wrong with one.” On the surface these ask you to define terms. In practice, an interviewer asking them is trying to find out something narrower: have you actually run one of these systems, or have you only read about them?
The tell is in the follow-up. A candidate who defines tool use correctly — “the model requests, the code executes” — but stops there gets a second question almost immediately: what happens when the model requests something that doesn’t exist? That follow-up is where the interview actually happens. The definition is table stakes.
Why “who executes the function” is the opening question
It’s common to open with some version of “who actually runs the function — the model or your code?” This isn’t a trick question, but it filters harder than it looks. A surprising number of candidates answer “the model” without pausing, because the vocabulary of “agents doing things” makes it feel like the model is the actor. Getting this backwards early in an answer tends to compound: every subsequent claim about safety, validation, or guardrails is built on a wrong foundation if the interviewer thinks you believe the model is executing code directly.
The correct framing — the model produces a structured request, your code is the only thing that ever executes anything — isn’t hard to state once you know it. What separates a strong answer from a memorized one is whether the candidate can immediately follow it with why that boundary matters, unprompted.
The failure modes are the real interview
Ask most candidates to describe the agent loop’s happy path and they’ll get through it fine: send a message, get a tool request back, run it, feed the result back, repeat until done. That’s the easy 70% of the answer.
The other 30% — the part that actually distinguishes candidates — is what happens when it’s not the happy path. Two scenarios come up constantly, in slightly different phrasing depending on the interviewer, but they’re really the same two questions every time. What happens when the model asks for a tool that doesn’t exist? And what stops the loop if the model never says it’s done?
The first tests whether you know that a hallucinated tool call is possible at all — not a bug in the model, just a natural consequence of a system that predicts plausible continuations rather than looking things up. The fix candidates are expected to name is specific: validate the requested name against a known list before running anything, and treat a failed lookup as a normal result the model gets to see and react to, not a crash.
The second tests whether you understand that an agent loop has no innate stopping instinct. Nothing about how the model was trained guarantees it eventually returns a final answer instead of one more tool request. The expected answer is a hard iteration cap enforced in code — not a request in the system prompt asking the model to wrap up.
Why “prompt-only safety” is the answer that costs you points
A subtler trap shows up when candidates propose fixing either failure mode purely through prompting — “I’d just tell it in the system prompt to only use the listed tools” or “I’d instruct it to stop after a few tries.” Both are reasonable-sounding and both miss the point an interviewer is checking for: a system prompt is a strong bias on the model’s behavior, not an enforcement boundary. It reduces the likelihood of an unwanted request; it doesn’t eliminate the possibility. Interviewers who ask “what’s the difference between doing this in the prompt versus in code” are checking whether you’ve internalized that distinction, because it’s the same distinction that separates a demo from a production system.
The pattern underneath all of it
If there’s one thing worth taking away from how these questions get asked in sequence, it’s this: the questions escalate from “can you describe the mechanism” to “can you describe what breaks” to “can you describe where the fix has to live.” Each step tests something the previous one didn’t. Preparing by memorizing a clean definition of tool use gets you through the first step and stalls immediately at the second — which is exactly why running a broken version of the loop yourself, on purpose, tends to stick better than reading about one.