AI Engineering Interview Questions: Agents & Agent Loops
Reviewed by Mark Dickie · Last updated
An agent loop is the repeating perceive-reason-act cycle at the core of every autonomous AI agent, where the agent reads context, calls a model or tool, updates its state, and decides whether to stop or iterate again. Interviews on this topic test whether you can build agents that terminate reliably, handle tool failures gracefully, and stay within token and cost budgets — not just whether you know the vocabulary. You should understand how the loop connects to memory, tool-calling conventions, and the signals an agent uses to decide it is done. Knowing where loops go wrong (infinite iteration, runaway token spend, silent tool errors) matters at least as much as knowing how they work when everything goes right.
What does an AI engineering interview on agent loops actually test?
Interviewers are looking for three things: whether you can reason about loop control flow, whether you understand the data that flows between iterations, and whether you have opinions about failure modes from real experience or careful study. Abstract knowledge of the ReAct pattern is table stakes; the harder questions push on edge cases like partial tool responses, context-window overflow mid-loop, and how you'd write an exit condition that is not just max_steps.
Core concepts you need to know cold
| Concept | What to know |
|---|---|
| Perceive-Reason-Act cycle | The three phases of each loop iteration and what data moves between them |
| Scratchpad / working memory | How intermediate reasoning is stored and passed across turns |
| Tool call & result handling | JSON schema for function calls, how to surface errors back into context |
| Stopping criteria | Hard limits (max steps, token budget) vs. soft signals (model says DONE) |
| Context-window management | Truncation strategies, summarisation, retrieval to keep the loop from stalling |
| Multi-agent delegation | When a parent agent spawns a sub-agent and how results are returned |
| Observability | Traces, span IDs, logging tool inputs and outputs for debugging loops |
How to structure your preparation across difficulty levels
Work through concepts in this order — each level builds on the one before:
- Level 1–2 (foundations): Be able to draw the basic loop on a whiteboard, name each phase, and explain what a tool call returns. Know the difference between a single-turn LLM call and a multi-turn agent loop.
- Level 3 (design): Explain how you'd implement a stopping condition without relying solely on a step counter. Describe at least one strategy for keeping context fresh across many iterations.
- Level 4 (failure modes): Walk through what happens when a tool returns a 500 error mid-loop. Show how you'd detect and break an infinite loop where the model keeps calling the same tool with the same arguments.
- Level 5 (systems thinking): Discuss tradeoffs between a single long-running agent loop and breaking the task into a chain of shorter loops with checkpoints. Cover cost attribution, latency budgets, and how you'd test an agent loop in CI without hitting live APIs.
Most interview panels mix levels within a single session, so knowing the vocabulary at level 1 but having a concrete opinion at level 4 is what separates candidates who pass from those who get the "not enough depth" feedback.
Key facts
- Tarmac has 123 AI Engineering interview questions on this topic, 10 of them on this page, at difficulty 1–5 of 5.
- Tarmac last reviewed these AI Engineering interview questions on 20 July 2026.
At a glance
| Questions | 10 shown · 123 in the bank |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | Ordering, Multiple choice, Multiple answer, Fill in the blank, Short answer, True / false, Code output, Flashcard, Find the bug, Design exercise |
What you'll review
- agent loops
- tool calling
- agents
- agentic rag
Practice questions
AI Engineering/agents/agent-loops
Arrange the steps of a standard LLM agent loop in the correct execution order, starting from the beginning of one iteration.#
Put these in order
Show answer
In a standard LLM agent loop, the correct execution order is: (1) the LLM reasons over the current context and selects an action, (2) that action or tool call is executed, (3) the agent receives the observation or tool result, (4) a stopping condition is checked to see if the task is complete, and (5) if not done, the observation is appended to context and the next iteration begins. This repeating think-act-observe cycle is the core pattern behind frameworks like ReAct.
An agent loop (also called a ReAct loop or think-act loop) follows a repeated cycle: the agent observes the current state/context, reasons or thinks about what to do, takes an action (e.g., calls a tool), receives an observation back, and repeats until a stopping condition is met. This is the fundamental pattern behind virtually all LLM-based agent frameworks.
AI Engineering/agents/agent-loops
In a typical LLM-based agent loop, which component is responsible for actually executing a tool call (e.g., running a web search or calling an API)?#
Options
Show answer
The agent runtime (or orchestrator) that wraps the LLM is responsible for actually executing tool calls like web searches or API requests. The LLM itself only reasons about which action to take and what arguments to pass — it cannot run code or call external services directly. The runtime performs the action, then feeds the result back to the LLM as an observation to continue the loop.
In an agent loop the LLM does NOT execute code or call APIs directly — that is the job of the surrounding runtime/executor. The LLM's role is limited to reasoning and deciding which action to take and what arguments to pass. The runtime then actually performs the action and returns the result (observation) to the LLM.
AI Engineering/agents/agent-loops
Which of the following are valid stopping conditions that can terminate an LLM agent loop? Select all that apply.#
Options
Pick every one that applies.
Show answer
Valid stopping conditions for an LLM agent loop include the LLM emitting a designated "Final Answer" signal, a cap on the maximum number of steps or iterations being reached, and a programmatic check detecting that the task objective is satisfied. Any of these terminates the loop, which would otherwise run indefinitely. Reaching a minimum token count, by contrast, is not a practical or meaningful stopping criterion.
Without a stopping condition an agent loop would run forever. Common termination criteria are: the LLM emits a special 'Final Answer' token/signal, a maximum number of steps/iterations is reached, or the task objective is detected as satisfied. Reaching a minimum token count is not a meaningful stopping condition and is not used in practice.
AI Engineering/agents/agent-loops
To prevent an agent loop from running indefinitely, developers should set a _____ limit on the number of iterations, and the loop should also exit when the agent emits a _____ action (e.g., finish or final_answer).#
Show answer
To prevent an agent loop from running indefinitely, developers should set a maximum-step limit on the number of iterations, and the loop should also exit when the agent emits a terminal action (e.g., finish or final_answer).
A maximum-step (or max-iterations) guard is essential to prevent an agent loop from running forever when the LLM never produces a terminal action or gets stuck in a tool-call cycle. Without it, the loop can consume unbounded tokens and API calls. The other options — temperature, embedding size, and chunk size — do not control loop termination.
AI Engineering/agents/tool-calling
Explain how LLM tool calling (function calling) works end to end. Who actually executes the tool?#
Show answer
You give the model a set of tool definitions with names, descriptions, and JSON-schema parameters. When the model decides a tool is needed it doesn't run anything — it returns a structured tool-call request with arguments matching the schema. Your application code executes the function, then sends the result back to the model as a tool-result message, and the model continues, optionally calling more tools, until it produces a final answer. The model only chooses and fills in arguments; your code is the one that actually executes the side effect.
Tool calling is a structured-output contract: the model emits a request (tool name plus schema-validated arguments) rather than running code itself. The host application executes the function, returns the result as a tool message, and the loop repeats. This separation is the whole security model — the model never has direct execution authority, so you can validate arguments, enforce permissions, and sandbox effects before acting. It is also the foundation of agent loops and MCP.
AI Engineering/agents
Giving an agent a hard iteration/token budget guarantees it will produce a correct final answer within that budget, as long as the budget is large enough.#
Options
Show answer
False. A hard iteration or token budget bounds cost and runtime — it forces the agent to stop — but it does not make the agent's reasoning or tool use correct. An agent can exhaust its entire budget on a flawed plan or a misread tool result and still be wrong when the cap hits, and enlarging the budget only lets more unproductive work happen before the forced stop rather than fixing why the agent went wrong. Budgets protect cost and latency; correctness needs its own guardrails, like sufficiency checks and evaluation.
A budget bounds cost and runtime — it forces the agent to stop — it does not make the agent's reasoning or tool use correct. An agent can exhaust its entire budget on a flawed plan, misinterpret a tool's result, or oscillate between two unproductive strategies and still be wrong (or return a low-confidence partial answer) when the cap hits. Enlarging the budget only lets more of that unproductive work happen before the forced stop; it doesn't address why the agent went wrong in the first place. Budgets and correctness are separate concerns — the budget protects cost and latency, while quality needs its own guardrails, such as sufficiency checks, verification steps, and evaluation.
AI Engineering/agents/agent-loops
This models an agent loop that re-sends its whole transcript each iteration. sent accumulates the input tokens billed across the run. What does it print?#
context = 1000 # system prompt + goal
sent = 0
for step in range(4):
sent += context # the whole transcript is re-sent
context += 500 # this step's tool call + result
print(sent, context)Options
Show answer
The loop prints 7000 3000, billing 1000, 1500, 2000 and 2500 input tokens across its four iterations, summing to 7000, while the transcript itself only reaches 3000 tokens. The gap is the whole point: every earlier token is paid for again on every later step, so the run costs more than twice the final context size. Counting only the tokens each step adds gives 4000 — the single-call intuition that makes agent bills surprising. At 10 steps the sum reaches 32,500 against a 6000-token transcript.
Trace the four iterations: the loop bills 1000, then 1500, then 2000, then 2500, summing to 7000, while context ends at 1000 + 4·500 = 3000. The point is the gap between those two numbers. The transcript grew to 3000 tokens, but the run was billed for 7000 — more than twice the final size — because every earlier token is paid for again on every later step. Option (b) is what you get by counting only the tokens each step adds, which is the intuition most people carry over from single-call pricing and the reason agent bills surprise teams. Option (c) mistakes the final context size for the amount billed. Extend the loop to 10 steps and the sum reaches 32,500 against a 6000-token transcript: the growth is quadratic, which is why trimming what you carry forward is the strongest cost lever in an agent loop.
AI Engineering/rag/agentic-rag
What is agentic RAG, and when would you choose it over a classic retrieve-then-generate pipeline?#
Show answer
Agentic RAG turns retrieval into a tool an LLM agent controls rather than a fixed pipeline step. The agent decides whether to retrieve, what query to issue (reformulating or decomposing it), can retrieve iteratively for multi-hop questions, route across multiple sources, and judge sufficiency before answering — re-querying when the context falls short. Choose it for multi-hop, ambiguous, or multi-source questions where one static top-k retrieval is inadequate. Avoid it for simple single-fact lookups: the extra LLM calls add latency, cost, and non-determinism with no accuracy gain. Rule of thumb: match the retrieval architecture to query complexity.
Classic RAG always retrieves once; agentic RAG makes retrieval a decision the model takes inside an agent loop. The upside is adaptivity on hard queries; the downside is more round-trips, so it's a deliberate trade, not a free upgrade.
AI Engineering/agents/agent-loops
The following Python snippet implements one iteration of an OpenAI function-calling agent loop. There is exactly one bug that will cause the agent loop to silently malfunction (wrong role/message structure fed back to the model). Identify the buggy line number.#
import json, openai
def run_agent_step(messages, tools, tool_registry):
response = openai.chat.completions.create(
model="gpt-4o",
messages=messages,
tools=tools,
tool_choice="auto",
)
msg = response.choices[0].message
messages.append(msg)
if msg.tool_calls:
for tc in msg.tool_calls:
fn_name = tc.function.name
fn_args = json.loads(tc.function.arguments)
result = tool_registry[fn_name](**fn_args)
messages.append({"role": "assistant", "content": str(result)})
return messagesShow answer
The bug is on line 17.
The bug is on line 17. The code appends the tool result to messages as a dict with role assistant, but tool/function call results must be appended with role tool and must reference the tool_call_id from the assistant's message (e.g., {"role": "tool", "tool_call_id": tc.id, "content": str(result)}). Appending the result as an assistant message (a) loses the tool_call_id linkage and (b) causes the model to treat the observation as its own prior utterance rather than an external tool response, breaking the agent loop. All other lines are structurally correct for a minimal function-calling agent loop.
AI Engineering/agents/agent-loops
Design the agent loop behind a support assistant that answers billing questions. It can read invoices, read the customer's plan, and issue refunds up to a limit. Runs take anywhere from 2 to 40 iterations. Cover how the loop terminates, what happens when a tool fails, how context is kept under the window, how refunds are controlled, and how you would debug a bad run a week later. State your assumptions.#
Show answer
Assume a few thousand runs a day, a refund ceiling of $200, and 30-day trace retention. Most tickets follow a handful of shapes, so I would route: a classifier sends the common ones down fixed workflows and only the tail reaches the agent, which cuts cost and shrinks the surface where things can go wrong.
The loop terminates on four conditions, not one: the model returns a final answer that passes a goal check; a cumulative token budget for the run is exhausted; a step cap fires as a backstop; or a repeated-call detector sees the same (tool, arguments) hash twice with nothing new in context. Budget is the primary control because steps are a poor proxy for cost — each iteration re-sends the transcript, so late steps cost far more than early ones. On any stop without an answer the agent hands the ticket to a human with its partial findings attached, rather than replying with something it is not sure of.
Tool failures go back into the context as tool results flagged as errors, so the model can adapt — try a different lookup, or tell the user. Retry policy is per-tool, not global: reads retry with exponential backoff, and the refund call never retries blindly, because a 5xx there is ambiguous rather than failed. Refunds carry an idempotency key so a duplicate collapses server-side.
For a 40-iteration run I pin the system prompt, tool schemas and goal, summarise older turns into a running recap once the transcript passes a threshold, clear stale tool results while keeping the calls that produced them, and keep large invoice payloads in storage behind a reference the agent re-reads on demand.
Refunds are gated in code. The loop intercepts the call before execution, verifies the amount against the invoice server-side, and requires human approval above a threshold — the model's authority is whatever the loop grants it, and the system prompt is a hint, not a control. Invoice text is untrusted: it reaches the context as data, and instructions inside it have no privilege, which is exactly why enforcement cannot live in the prompt.
Every run writes a trace keyed by run id and ticket id, one span per iteration, capturing the rendered prompt, the tool calls and arguments, results, token counts, and the stop reason. A week later I can open the ticket, find the run, and see which iteration went wrong and what the model was looking at when it did.
The main tradeoff is autonomy against friction: a lower approval threshold means fewer bad refunds and more human load. I would start conservative, measure the approval queue, and raise the threshold only against evidence.
This exercise separates people who have run an agent in production from people who have read about them. The tells are consistent. A weak answer treats max_steps as termination, wraps every tool in one retry, plans to 'use a bigger context window', and puts the refund limit in the system prompt. A strong answer knows that a step cap does not bound cost, that retry policy is a property of the tool rather than of the loop, that trimming has to pin the instructions it must never drop, and above all that a prompt instruction is not an authorization boundary — the loop executes tools, so the loop is the only place a refund limit can be enforced. The prompt-injection probe is the sharpest discriminator: any design where the model's instructions are the sole control fails it, because the invoice is attacker-influenced text arriving in the same context. The debuggability criterion is what makes the whole thing operable — without per-iteration traces tied to a run id, nobody can answer 'why did it do that' a week later, and every incident becomes a guess.
Related interview questions
The other 113 questions
This page shows 10. A free account opens the rest and marks your answers, which a page of answers can't do. Miss one and it returns a few days later, then a week after that, until you stop missing it.
Free · the whole bank · 100 graded answers per 30 days · written feedback and job-ad quizzes on the paid plan