The agent loop interview questions
12 questions across 4 sections, in the order you would learn them. Every answer here is one that works — but an answer you have read is not an answer you can give, so use Test yourself and say it out loud first.
What an agent actually is
Read the section that teaches thisIf this comes up in an interview
What is an agent, in one sentence?
A loop that calls a model, executes any tools the model requests, feeds the results back, and repeats until the model stops asking or a budget runs out.
When would you not use an agent?
When the steps are known in advance. A fixed pipeline is cheaper, faster and far easier to debug. Agents earn their cost only when the path depends on what is discovered along the way.
Then they push further
Give an example of a task that looks like it needs an agent but does not.
Summarising a support ticket and routing it to a team. It feels open-ended, but the steps are fixed: classify, summarise, route. Two calls with structured output do it cheaper, and every step can be tested on its own. An agent would add variance and cost for no gain.
And one that genuinely does?
Working out why a customer's invoice is wrong across billing, usage and plan history, where what to look up next depends on what the last lookup showed. The number and order of steps cannot be written down in advance.
What gets marked up. Strong answers name what agency costs: variance, latency, money and harder debugging, and treat an agent as something a task has to earn. Weak answers treat agents as the default modern architecture.
Where does the loop run?
In your code. The model cannot execute anything or call itself. It only emits a structured request, and your program decides whether to act on it and what to send back.
Budgets, loops and giving up well
Read the section that teaches thisIf this comes up in an interview
How do you stop an agent running forever?
Three independent budgets: turns, wall-clock time and cost. Any one being exceeded stops the run. Turns alone are not enough because a single turn can be slow or expensive.
Then they push further
Why is a turn limit alone not enough?
One turn can call a slow tool or produce a huge output, so a run can blow its time or cost budget in very few turns. Each budget protects against a different failure.
What does the user see when a budget trips?
A structured partial result: what was done, what was not, and why it stopped, with a way to continue if that makes sense. A silent failure or a generic error throws away the work already done.
How would you choose the limits?
From data. Run the eval tasks, look at turns, time and cost for the runs that succeeded, and set limits a little above the high end of that range. Revisit them when tools or models change.
What gets marked up. Marked up for independent budgets, for returning partial results instead of throwing, and for deriving limits from measured runs rather than picking round numbers.
An agent keeps calling the same tool with the same arguments. What do you do?
Detect the repeat by hashing the tool name and arguments, and when it repeats, return a result telling the model it is stuck and should try something else. Killing the run is the fallback if that does not work.
What should an agent return when it runs out of budget?
A structured partial result: what it achieved, what it could not, why it stopped, and what it cost. Raising an exception throws away work the caller could still use.
Managing the context as it grows
Read the section that teaches thisIf this comes up in an interview
An agent overflows its context after ten turns. What do you do?
In order: make tools return less, drop stale tool results, summarise older turns while keeping recent ones verbatim, and offload large payloads to storage with an id the model can use to retrieve them. Moving to a bigger context window is the last resort.
Then they push further
Which of those usually gives the biggest win?
Making tools return less. Tool results are usually most of the context, and a tool that returns a whole record when the model needs three fields fills the window fast. Trimming at the source also cuts cost on every later turn.
What is the risk of summarising older turns?
The summary drops something that matters later: an id, a constraint the user stated, or a failed attempt the agent will now repeat. Keep a structured record of decisions and key facts outside the summary, and keep recent turns word for word.
What gets marked up. Strong answers attack the source of the bloat before compressing, and name what compaction loses. A bigger context window as the first answer is marked down.
What must survive compaction?
The original task, anything the user said including corrections and constraints, decisions already taken, and failures already hit. Losing those causes the agent to wander or repeat work.
How does prompt caching interact with context management?
Caching matches a stable prefix, so anything volatile must go last. If a summary is inserted near the front, it invalidates the cache every time it updates. Order from most stable to most volatile and the cache keeps working.
Knowing whether it works
Read the section that teaches thisIf this comes up in an interview
How do you evaluate an agent rather than a single completion?
Check the end state of the world rather than the text, because the agent's job is to do something. Then track efficiency alongside correctness: turns and cost per task. A run that succeeds after fourteen turns is not equivalent to one that succeeds in three.
Your agent's success rate is unchanged after a prompt edit. Is it safe to ship?
Not necessarily. Check turns and cost as well. A change can hold the pass rate while doubling spend, and nothing in a pass-rate-only eval will tell you.
How many eval tasks do you need?
Twenty real ones beats two hundred synthetic ones. Draw them from actual usage, include every failure you have already seen in production, and version the set so a score from last month still means something.
These are the questions for one topic. The whole question bank covers every topic on the site.