Agentic AI interview questions
What interviews ask about AI agents: when to build an agent instead of a workflow, tool calling and MCP, memory and context, multi-agent systems, and how you keep an agent reliable in production.
32 questions across 10 topics. Answer each out loud, then open the points a strong answer covers.
Tool use and function calling
Asked in most interview loops
Walk me through what happens, step by step, when a model calls a tool?
- You send tool definitions with a name, description and JSON schema; the model replies with a structured call naming the tool and arguments, not prose.
- Your application, not the model, runs the function, then sends the output back as a tool result linked to that call’s ID.
- The loop repeats until the model answers in text; tool definitions are extra input tokens on every request, so they cost context and steer behaviour.
How do you design tools so the model uses them correctly and recovers when they fail?
- Keep tools few and clearly named, with descriptions saying when to use each, and shape inputs to resist misuse, such as enums or absolute paths.
- Use strict mode so arguments always match the schema, and tool_choice to let the model decide, require a call, force one tool, or disable tools.
- Return errors as a tool result with a clear message the model can act on, and cap retries so a broken tool can’t loop forever.
When does a model make parallel tool calls, and what can go wrong with them?
- When several independent lookups are needed, the model can return multiple tool calls in one turn, and your code runs them concurrently and returns each result with its call ID.
- It breaks when calls depend on each other or have side effects, such as creating a record and then updating it, because calls sent together are treated as independent and may run in any order.
- Turn parallel calls off for tools with ordering or side-effect constraints, and check traces for dropped results, since the API expects a result for every call ID.
Your agent has dozens of tools and keeps picking the wrong one; how would you fix it?
- Every definition sits in context on each request, so overlapping names and vague descriptions make tools hard to tell apart; merge or rename near-duplicates and say when to use each.
- Expose only the tools relevant to the current task, by routing to a smaller toolset or searching tool definitions on demand, which also cuts input tokens on every call.
- Build an eval of prompts labelled with the correct tool and track selection accuracy, so you can tell whether each change actually reduced the confusion.
How do models learn to call tools in the first place, rather than just being prompted to?
- Modern models are post-trained on examples containing tool definitions, structured calls and results, so they learn both the call format and when a tool is worth calling.
- Toolformer showed a self-supervised route: sample candidate API calls in text, execute them, and keep only those whose results make the following tokens easier to predict.
- Toolformer also found tool use only helped above a certain model size, a reminder to evaluate tool calling on the exact model you plan to deploy, not a larger one.
Agent loops: workflows vs agents
Asked in most interview loops
When would you build a fixed workflow instead of an autonomous agent?
- In a workflow your code picks the next step along a fixed path, such as chain, route, fan-out or evaluate-and-retry; in an agent, the model picks.
- Choose a workflow when the steps are known in advance: it’s cheaper, faster, more predictable, and far easier to test and debug.
- Reach for an agent only when the path can’t be predicted, like open-ended research or multi-file code changes, and accept higher cost and variance.
Draw an agent loop for me. How does it stop, and what goes wrong?
- The model reasons, calls a tool, reads the observation and repeats; ReAct-style thought, action and observation traces make every step inspectable.
- It stops when the model gives a final answer, backed by hard limits: a maximum step count, a token or time budget, and a repeated-action check.
- Common failures are runaway loops, trusting a bad tool result as fact, and unguarded side effects, so risky actions need validation or human approval.
What’s the difference between ReAct and plain chain-of-thought, and when would you use each?
- Chain-of-thought reasons entirely inside the model before answering, so it can’t fetch new facts and any wrong belief it starts with carries through to the answer.
- ReAct interleaves reasoning with tool calls, so each observation can ground or correct the next thought, at the cost of more calls, tokens and latency.
- Test both on your own tasks: ReAct helps when answers depend on lookups, but uninformative search results can pull its reasoning off track, which plain reasoning avoids.
Your agent keeps calling the same search tool with near-identical queries and never finishes; what do you check?
- Read the trace to see whether the tool results actually answer the query, since empty, truncated or error results often look to the model like a reason to retry.
- Check that the prompt says what “done” looks like, because a model with no clear success criterion tends to keep searching for something better instead of answering.
- Add a repeated-action check and a step budget that forces a final answer or an escalation, then add the looping task to your eval set to confirm the fix.
How would you add planning to an agent, and when is a plan up front worth it?
- In plan-then-execute, the model writes a step list first and then works through it, which makes progress visible and lets code or a human check the plan before any action.
- A fixed plan goes stale when an early step returns something unexpected, so let the agent revise the plan after each observation rather than following it blindly.
- Planning pays off on long tasks where wandering is the main failure; on short ones, measure whether the extra call raises success enough to justify its latency and cost.
Agent reliability: evals, failure modes and observability
Asked in most interview loops
How would you know your agent got worse after a prompt change?
- Run a fixed regression suite of real tasks before every change and compare pass rates, kept separate from harder capability evals that measure headroom.
- Grade outcomes rather than exact paths: code checks where possible, model judges for fuzzy criteria, and humans to calibrate the judges.
- Run each task several times because outputs vary, and report pass^k, the chance all k trials succeed, when consistency matters more than one success.
How do you debug an agent failure in production and stop it recurring?
- Trace every run as spans covering each model call, tool call, input, output, latency and token count, so you can find the exact failing step.
- Read the transcript to tell a real agent mistake from a broken grader or an ambiguous task before you change the prompt or tools.
- Turn each production failure into a new eval task, and require human confirmation for irreversible or high-stakes actions such as payments or deletions.
An agent fails halfway through a long multi-step task; how would you make it resume rather than start over?
- Checkpoint state after each completed step, such as the plan, tool results and files written, so a crash, timeout or deploy can restart from the last good point.
- Make tools idempotent or record which side effects already ran, because replaying a step that sent an email or charged a card turns a retry into a new bug.
- Test recovery on purpose by killing runs mid-task in staging, and track how often resumed runs finish correctly compared with uninterrupted ones.
What would you monitor for an agent running in production, and why each signal?
- Trace each run as spans for model and tool calls, and chart latency, cost and tokens per run, since agents can quietly take far more steps than you expected.
- Track tool error rates, steps per task and how often runs hit their limits, because a rise usually signals a broken tool or a confused prompt before users complain.
- Pair these with quality signals such as user feedback, abandonment and escalations, since cost and latency dashboards can look healthy while the answers are wrong.
How would you build the first eval set for a new agent with no production data yet?
- Start with a small set of realistic tasks drawn from what you already check by hand, from bug reports and from what users are expected to ask, each with a clear success check.
- Write each task so two experts would agree on pass or fail, and include a reference solution, since ambiguous tasks make grader or spec problems look like agent mistakes.
- Balance cases where the agent should act with cases where it shouldn’t, and add harder tasks once the set saturates, so it keeps telling you something new.
Prompt engineering as a discipline
Asked in most interview loops
Here’s a vague task. How would you write the prompt, and why each part?
- Put stable rules, role and constraints in the system prompt, and the specific task and its data in the user turn.
- State the goal, the audience and the exact output format, and wrap inputs in delimiters such as XML tags so instructions and data stay separate.
- Add a few varied examples when format matters, but watch for over-anchoring, and let the model reason before answering multi-step problems.
How do you manage and protect prompts once they’re running in production?
- Keep prompts in version control like code, and rerun a fixed eval set on every edit so one fix doesn’t silently break other cases.
- Split complex tasks into chained prompts with one job each, so every step is easier to test, debug and improve on its own.
- Treat user and retrieved text as data, not instructions; limit tool permissions and check outputs, since no prompt fully stops injection or leaking.
Structured outputs and validation
Asked in most interview loops
What’s the difference between JSON mode, structured outputs and function calling?
- JSON mode guarantees valid JSON in any shape; schema-constrained decoding guarantees the output matches your JSON Schema.
- Use function calling with strict schemas when the model must call your code, and a response format when it answers the user in a fixed shape.
- Validate anyway with something like Pydantic, because schemas can’t express business rules, and feed validation errors back in a bounded retry loop.
What can still go wrong with schema-constrained output, and how do you handle it?
- Strict modes accept only part of JSON Schema (OpenAI’s needs every field required and no open objects), so make optional fields nullable instead.
- A refusal or length cutoff won’t match your schema, so check the refusal field and the stop reason before you parse.
- Streamed objects arrive partly filled, so parse incrementally with a partial-JSON parser and act on a field only once it’s complete.
Model Context Protocol (MCP)
Asked often
How is MCP different from plain function calling, and when is it worth using?
- Function calling is how a model emits a structured call; MCP is a protocol for how an application discovers and invokes tools and context offered by external servers.
- A host runs one client per server, and because every server speaks the same JSON-RPC protocol, M apps and N integrations need M plus N implementations, not M times N.
- It adds a process boundary and another dependency, so for a few tools used inside one app, defining functions directly is often simpler and easier to debug.
Should this capability be an MCP tool, a resource or a prompt? How do you decide?
- Tools are model-controlled actions the model chooses to call, such as creating a ticket or running a query, so they suit anything that takes arguments or has side effects.
- Resources are application-controlled context identified by URIs, like files or database schemas, which the host decides to include; prompts are user-invoked templates, often surfaced as slash commands.
- Decide by who should trigger it, the model, the application or the user, and keep writes as tools so the host can ask the user for approval before running them.
When would you run an MCP server over stdio versus HTTP, and what security does each need?
- With stdio, the host launches the server as a local subprocess and exchanges JSON-RPC messages over standard input and output, which suits local tools like a filesystem or Git.
- Streamable HTTP runs the server as an independent service that many clients can reach remotely, so it needs authentication, typically OAuth, plus TLS and validation of the Origin header.
- Either way the server acts with real permissions, so scope its access, such as allowed directories or read-only credentials, and treat its output as untrusted input to the model.
Context engineering and agent memory
Asked often
Your agent works well early in a long session but degrades later; what’s happening and what would you do?
- As tool results and messages pile up, the instructions and facts that matter get buried among stale tokens, and quality drops well before the hard context limit.
- Clear old tool outputs that have already been used, and once the history passes a budget, compact it into a summary of decisions, open issues and next steps.
- Summaries lose detail that may matter later, so keep key facts in an external notes file and compare task success on long sessions before and after the change.
How would you design long-term memory for an assistant that remembers users across conversations?
- During or after each conversation, extract durable facts and preferences, such as names or settings, and store them outside the context, keyed by user and timestamped.
- On each new request, retrieve only the memories relevant to it, scored by relevance and recency, rather than loading everything the user has ever said into the window.
- Wrong or stale memories persist and compound, so update facts instead of duplicating them, let users view and delete memories, and evaluate on multi-session test conversations.
When would you load context up front, and when would you let the agent retrieve it just in time?
- Pre-loading runs embedding retrieval before the model is called, which is fast and predictable but can fill the window with stale or irrelevant chunks the model must ignore.
- Just-in-time retrieval gives the agent tools such as search, grep or file reads, so it pulls exactly what it needs and sees fresh data, at the cost of extra calls and latency.
- A hybrid often works best: pre-load small, always-needed context like project instructions, let the agent explore the rest, and compare task success and tokens per run.
Multi-agent systems and orchestration
Asked often
When would you choose a single agent over a multi-agent system?
- Each subagent sees only what it was given, so decisions made in parallel without shared context can conflict, such as two agents building parts that don’t fit together.
- Multiple agents pay off for read-heavy, parallelisable work like broad research, where subagents explore separately and return condensed findings, but they multiply token use.
- For write-heavy, tightly coupled work like editing one codebase, a single agent with good context management is usually more reliable, so compare both on success and cost.
What’s the difference between agents as tools and handoffs, and when would you use each?
- With agents as tools, an orchestrator calls a specialist like a function, gets its result back and keeps control of the conversation and the final answer.
- With a handoff, control passes to the specialist, which then talks to the user directly, suiting routing such as moving a customer from triage to billing.
- Agents as tools make it easier to combine results and enforce one policy; handoffs keep each prompt focused but must pass the right context, or the user repeats themselves.
Your multi-agent research system duplicates work and returns confident wrong answers; how do you debug it?
- Check the orchestrator’s task descriptions first, since vague delegation makes subagents overlap or misread the job; each needs an objective, an output format, tools and clear boundaries.
- Look for missing verification: if nothing checks subagent findings against their sources before synthesis, one agent’s mistake flows straight into the final answer.
- Trace every agent’s calls and messages, label failures by category, such as poor specification, inter-agent misalignment or weak verification, and fix the most frequent first.
Voice and realtime agents
Specialist topic or differentiator
Would you build a voice agent as a chained STT, LLM and TTS pipeline or with a speech-to-speech model?
- A chained pipeline gives you transcripts, inspectable stages and the freedom to swap any model, but each stage adds delay before the caller hears anything.
- A speech-to-speech model responds faster and can pick up tone from the caller’s audio, but it’s harder to inspect, constrain or hold to exact wording.
- Decide on time to first audio at p50 and p95, task success and how much control you need; flows that need exact scripts or audit trails often favour chaining.
Callers complain your voice agent keeps cutting them off mid-sentence; what would you change?
- A fixed silence timeout treats any thinking pause as the end of a turn, so people who stop briefly to recall a number or a name get interrupted.
- A voice activity detector only hears whether speech is present, so add a semantic end-of-turn model that reads the transcript to judge whether the thought sounds finished.
- Measure false-interruption rate on real or simulated calls alongside response latency, since waiting longer fixes interruptions but makes the agent feel slow.
Computer-use and browser agents
Specialist topic or differentiator
Your computer-use agent keeps clicking slightly off target; what do you check?
- Check that the screenshot the model sees uses the same coordinate space you click in, since resizing or high-DPI scaling shifts every click unless you map coordinates back.
- Locating small or crowded elements from pixels alone is a common failure, so try zooming in or targeting elements through the accessibility tree or DOM where available.
- Have the agent take a screenshot after each action to confirm the result, and measure click accuracy on a fixed set of tasks before and after the fix.
What guardrails would you put around a browser agent that acts on a user’s behalf?
- Run it in a sandboxed VM or container with minimal privileges, and give it only the logins and data the current task actually needs.
- Treat everything on screen as untrusted input, since a web page can carry instructions aimed at the agent, and restrict navigation to an allowlist of domains.
- Cap the number of steps, log every action with its screenshot, and require human confirmation before irreversible actions like purchases, sending messages or accepting terms.
Questions and answer points are written for SAADHO from each topic’s sources: question types interviewers ask, never leaked questions. How SAADHO is made