The agent booked the meeting, drafted the email and updated the CRM, and everyone in the room applauded. Two weeks later it was in front of real users, where it tried to update a record that had been deleted, received an error it did not understand, decided the correct response was to try again, and did so nineteen more times before someone noticed the API bill. It was not confused about the task. It had simply never been given a way to fail.
AI agent interview questions are almost entirely about that gap. Wiring a model to a few tools is a weekend project; making an agent that terminates, recovers, stays inside its permissions and can be measured is the actual engineering. This guide covers the six areas interviewers probe, and what a strong answer sounds like in each.
What an agent is, precisely
The definition that scores: an agent is a system where a model decides which actions to take, in what order, using tools, iterating on the results until a goal is met or a limit is reached. The distinguishing property is the model controls the control flow — unlike a fixed pipeline where you decided the steps in advance.
Then add the judgment that senior interviewers are listening for: most problems that get called agentic are better solved as a fixed workflow. If you know the steps, encode the steps — it is cheaper, faster, more testable and more reliable. Agents earn their complexity when the path genuinely varies by input. Saying this unprompted is one of the strongest signals available in this round.
Tool design
Tools are where agents actually succeed or fail, and this is the most under-prepared topic.
- Narrow, well-named tools beat one general tool. A
search_orders(customer_id, status)tool is far more reliable than arun_query(sql)tool, and it is also safer. - Schemas do the prompting. Parameter names, types, enums and descriptions are how the model learns to call it correctly. A vague description is a bug.
- Return errors the model can act on. "Error 400" teaches it nothing; "no order found with that ID — check the ID format, which is ORD-######" lets it recover. This distinction comes up constantly.
- Make destructive tools explicit and gated. Deletion, payment and email-sending should require confirmation or a human approval step.
- Idempotency. Agents retry. A tool that creates a record must be safe to call twice with the same arguments.
- Too many tools degrades selection. Past roughly a dozen, accuracy falls; the answer is grouping, or a retrieval step that selects the relevant tool subset for the task.
The agent loop
- Plan, act, observe, repeat. Be able to describe ReAct-style interleaved reasoning and action, and contrast it with plan-then-execute, where the model produces a full plan up front. Interleaved adapts better to surprises; upfront planning is more predictable and easier to review.
- Termination is a design decision, not an emergent property. A maximum step count, a token budget, a wall-clock timeout, and a check for repeated identical actions. The opening story is a missing loop guard.
- Reflection. Letting the agent critique its own output can help, and it also costs tokens and can talk itself out of a correct answer. Have an honest position.
- State between steps. What the agent carries forward, and why appending every raw tool result into context is the most common cause of both cost blowup and degraded reasoning.
- Failure handling. What happens when a tool errors, when the model produces malformed arguments, or when the task turns out to be impossible. "Ask the user" and "give up and report why" are both legitimate outcomes that most demo agents lack.
Memory and context
- Short-term. The working context for the current task, which needs summarisation or truncation as it grows. Note that models attend unevenly across long contexts, so more context is not monotonically better.
- Long-term. Facts persisted across sessions, usually in a vector store or a structured store, retrieved when relevant. Our vector database interview questions guide covers the retrieval layer.
- Structured over free-text where possible. Storing a user's preferences as fields is more reliable than storing a paragraph and hoping retrieval surfaces it.
- Forgetting. What expires, what is corrected when facts change, and how you avoid an agent confidently repeating something that was true in March.
- Context budgeting. How you decide what goes in — system prompt, tools, retrieved memory, conversation history — when they compete for the same window.
Multi-agent architectures
Expect "when would you use multiple agents?" and answer with restraint.
Genuine reasons: genuinely separable sub-tasks that can run in parallel, different tool permissions per role, or specialised prompts that conflict if merged. A supervisor or orchestrator pattern, where one agent routes to specialists, is the common shape.
The honest cost, which strong candidates state: every agent boundary is a place where context is lost, latency multiplies, cost multiplies, and failures become harder to attribute. Many multi-agent systems perform worse than a single well-designed agent with good tools. Being able to say that is worth more than being able to name five frameworks.
Evaluation, where most candidates stall
"How would you know your agent is working?" This is the question that decides the round, and vague answers are common.
- A task set. Fifty to a couple of hundred real tasks with known correct outcomes, drawn from actual usage rather than invented.
- Outcome evaluation. Did the agent achieve the goal? Exact match where possible, an LLM judge where not, spot-checked against humans.
- Trajectory evaluation. Did it take a sensible path — right tools, no redundant calls, no loops? An agent that reaches the right answer after fourteen wasteful steps is not fine.
- Component evaluation. Tool-selection accuracy and argument-formation accuracy measured separately, so you know which part to fix.
- Regression testing. Run the task set on every prompt, model or tool change. Model upgrades change agent behaviour in ways you cannot predict, which is why this matters more here than in ordinary software.
- Production signals. Task completion rate, average steps per task, tool error rate, human escalation rate, and cost per task.
Our MLOps interview questions guide covers the monitoring discipline this borrows from.
Guardrails, safety and cost
- Least privilege. The agent's credentials, not the user's admin token. Scope every tool to what the task needs.
- Human in the loop for irreversible actions — payments, deletions, external communication.
- Prompt injection. The critical one: content the agent retrieves — a web page, a document, an email — may contain instructions. Never let retrieved content escalate permissions, treat it as data rather than instruction, and validate tool arguments independently of what the model asked for.
- Output validation. Schema-check every tool argument before execution rather than trusting the model.
- Cost control. Token budget per task, step limits, caching, and using a smaller model for routing or classification while reserving the large one for reasoning. Be ready to estimate cost per task out loud.
- Latency. Agents are slow because they are sequential; parallelising independent tool calls and streaming intermediate progress to the user are the standard mitigations.
Questions you should expect verbatim
- "What is the difference between an agent and a workflow, and when would you use each?"
- "How do you stop an agent from looping forever?"
- "How would you evaluate an agent?"
- "How do you design a good tool for an LLM?"
- "What is prompt injection and how do you defend against it?"
- "How would you reduce the cost and latency of an agent?"
Where each prep option actually helps
- Anthropic's writing on building effective agents — the clearest published argument for workflows over agents where possible, which is the framing interviewers reward.
- Build one and let it fail — give an agent a broken tool and watch what it does. That experience answers half this round.
- The ReAct paper, or a good summary — enough to describe interleaved reasoning and action accurately.
- OpenTelemetry-style tracing for agent runs — being able to say how you would debug a bad trajectory is a strong practical signal.
- ChatGPT — good for drafting tool schemas and generating test tasks. It will not tell you your agent has no termination condition.
- Greenroom — the spoken layer. Ari, the AI interviewer runs AI-engineering rounds out loud and asks the evaluation follow-up, which is where most candidates stop. Honest tradeoff: Ari will not run your agent, so build one.
Our LLM production engineer interview questions guide covers the wider role and RAG interview questions covers the retrieval layer agents usually sit on top of.
Frequently asked questions
What is the difference between an AI agent and a workflow?
In a workflow you decide the steps in advance and the model fills in specific tasks; in an agent the model controls the control flow, choosing which tools to call and in what order until a goal is met or a limit is reached. The judgment interviewers listen for is that most problems described as agentic are better solved as fixed workflows, because encoding known steps is cheaper, faster, more testable and more reliable. Agents earn their complexity only when the path genuinely varies by input.
How do you design good tools for an AI agent?
Prefer narrow, well-named tools over one general tool, because a search_orders tool with typed parameters is both more reliable and safer than a run_query tool that accepts arbitrary SQL. Treat the schema as the prompt — parameter names, enums and descriptions are how the model learns correct usage. Return errors the model can act on rather than bare status codes, make destructive tools explicit and gated, ensure every tool is idempotent since agents retry, and group tools once you exceed roughly a dozen because selection accuracy degrades.
How do you stop an AI agent from looping forever?
Treat termination as an explicit design decision rather than something that emerges. Set a maximum step count, a token budget and a wall-clock timeout, and detect repeated identical actions so the agent cannot retry the same failing call indefinitely. Also give it legitimate exits — asking the user for clarification, or reporting that the task appears impossible and why — because most demo agents have no defined way to fail.
How do you evaluate an AI agent?
Build a task set of fifty to a couple of hundred real tasks with known correct outcomes drawn from actual usage. Evaluate outcomes with exact match where possible and a spot-checked LLM judge where not, evaluate trajectories to check the path was sensible rather than fourteen wasteful steps, and evaluate components separately so you know whether tool selection or argument formation is failing. Run the whole set as a regression suite on every prompt, model or tool change, and track production signals such as completion rate, steps per task, tool error rate and cost per task.
What is prompt injection and how do you defend against it in agents?
Prompt injection is when content the agent retrieves — a web page, a document, an email — contains instructions that the model follows as though they came from the user. Defences are architectural rather than prompt-based: treat retrieved content as data rather than instruction, never let it escalate permissions, scope every tool with least privilege so the agent's credentials cannot exceed the task, validate tool arguments against a schema independently of what the model asked for, and require human approval for irreversible actions.
When should you use multiple agents instead of one?
When sub-tasks are genuinely separable and can run in parallel, when different roles need different tool permissions, or when specialised prompts would conflict if merged — typically with a supervisor agent routing to specialists. The honest cost, which strong candidates state, is that every agent boundary loses context and multiplies latency, cost and the difficulty of attributing failures, so many multi-agent systems perform worse than one well-designed agent with good tools.