interviewDeck

Your one-stop platform to prepare, practice and ace your interviews.

Loading your questions…

interviewDeck

All Questions

Filters & tools

AI Agents Interview Questions and Answers

22 hand-picked AI Agents interview questions with detailed answers. Open the interactive version above to search, filter by difficulty, run code, bookmark questions and track your progress.

Agent vs workflow vs chatbot — what's the actual difference?

  • Chatbot — prompt in, text out. No tools, no state beyond the conversation.
  • Workflow — LLM calls wired together on a path you defined: classify → retrieve → summarise → format. The model fills in steps; your code decides the order.
  • Agent — the model decides the control flow: which tool to call next, how many times, and when it's finished. Your code defines the tools and the boundaries, not the sequence.

The distinction that matters in practice: with a workflow you can reason about every path and test it; with an agent you can't enumerate the paths, so you need guardrails, budgets and observability instead.

Most production "agents" are workflows with one or two agentic steps — and that's usually the right design.

What does the agent loop actually look like in code?

Stripped of frameworks, it is a while-loop around a chat completion with tools:

  1. Send messages + tool definitions to the model.
  2. If the response contains tool calls → execute them, append the results as tool messages, loop.
  3. If it contains only text → that's the final answer, stop.

Everything else — planning, memory, sub-agents — is a variation on what you put in the message list before step 1.

The parts frameworks hide but you still own: the iteration cap, per-run token/cost budget, error handling for failed tools (return the error to the model, don't crash — it can often recover), and parallel execution of independent tool calls.

let messages = [{ role: "user", content: task }];

for (let i = 0; i < MAX_STEPS; i++) {
  const res = await client.messages.create({ model, tools, messages });
  messages.push({ role: "assistant", content: res.content });

  const calls = res.content.filter(c => c.type === "tool_use");
  if (!calls.length) return res;                    // final answer

  // independent calls run in parallel
  const results = await Promise.all(calls.map(async c => {
    try   { return { tool_use_id: c.id, content: await run(c.name, c.input) }; }
    catch (e) { return { tool_use_id: c.id, content: `Error: ${e.message}`, is_error: true }; }
  }));
  messages.push({ role: "user", content: results });
}
throw new Error("agent exceeded step budget");

What makes a good tool definition for an agent?

Tool definitions are prompts — the model chooses purely from the name, description and schema.

  • Name and describe by intent, not implementation: search_orders_by_customer beats queryDB. Say when to use it and when not to.
  • Few, well-chosen tools. Selection accuracy degrades as the toolset grows; 5 clear tools beat 30 overlapping ones. Above ~20, route by loading a subset per context.
  • Flat, typed, constrained parameters — enums over free strings, required fields marked, no deeply nested objects.
  • Return what the model needs, not what the API returns. Dumping a 40-field JSON blob per result burns context and buries the signal. Summarise, paginate, and truncate with a note.
  • Make errors instructive — "No customer with that id; try search_customer_by_email" is far more useful than a 404.

How does MCP work, and what does it standardise?

MCP (Model Context Protocol) is a client–server protocol over JSON-RPC that lets any compliant host connect to any compliant integration — the "USB-C for AI tools" pitch. Without it, every tool integration is rewritten per assistant.

Roles: the host (the AI app) runs clients that connect to servers (your integration), over stdio for local processes or HTTP/SSE for remote ones.

Servers expose three primitives:

  • Tools — model-invoked functions with side effects (query a DB, create a ticket).
  • Resources — readable context the app can attach (a file, a record).
  • Prompts — user-invoked templates (a slash command).

The value is combinatorial: N tools × M assistants becomes N + M integrations. The cost is that every connected server spends context on its tool definitions and expands what a compromised or malicious server could reach.

How do you give an agent memory?

"Memory" is three different mechanisms people conflate:

  • Working memory — the current context window. Bounded, expensive, lost when the run ends.
  • Short-term / session memory — the conversation so far, kept under budget by a sliding window plus a rolling summary of what fell off.
  • Long-term memory — facts persisted outside the model and retrieved when relevant: user preferences, prior decisions, project facts. Usually a store plus retrieval, not "more context".

Long-term memory needs decisions that are product questions, not model questions: what is worth remembering (explicit user statements and outcomes, not every message), when to write (end of session, or on an explicit "remember this"), how to resolve contradictions (newer wins, with the old value kept for audit), and how the user deletes it.

Also useful: a scratchpad the agent writes to a file rather than holding in context — durable across compaction and inspectable by you.

How do agents plan, and why does planning often fail?

Two broad shapes:

  • Plan-then-execute — generate the full plan up front, then run each step. Reviewable and cheap, but brittle: a plan written before any tool output is based on assumptions that the first result may invalidate.
  • Interleaved (ReAct) — decide the next step after seeing each observation. Adaptive, but can wander without a goal to anchor it.

The pragmatic middle: plan up front, execute, and re-plan when an observation contradicts the plan.

Why planning fails: the model doesn't know what the tools will actually return; it under-estimates step count and over-estimates its own success; failure mid-plan often leads to plowing ahead rather than revising; and long plans drift as the original goal falls out of attention.

Practical fixes: keep the goal restated in context, write the plan to a durable to-do list the agent updates as it goes, and require an explicit verification step before declaring done.

When does a multi-agent system beat a single agent?

Multi-agent helps for a specific reason: context isolation. A sub-agent can burn 50k tokens exploring and return a 500-token summary, so the main agent's window stays clean. It also lets you parallelise genuinely independent work and give each role a narrow toolset and prompt.

Patterns: orchestrator–worker (a lead delegates subtasks — the most useful in practice), pipeline (fixed handoffs), evaluator–optimiser (one generates, one critiques, loop).

Where it hurts: token cost multiplies; sub-agents can't see each other's context so they duplicate work or make contradictory assumptions; the handoff is lossy — everything a sub-agent learned is compressed into whatever it chose to write; and debugging goes from one trace to N interleaved traces.

Reserve it for parallelisable read-heavy work — research, multi-file analysis, broad search. For sequential write-heavy tasks, one agent with good context management usually wins.

How do you keep a long-running agent from filling its context window?

Every tool result accumulates, so a long run hits the window and quality degrades before it does. Four techniques, usually combined:

  • Compaction — when usage crosses a threshold, summarise the run so far (decisions made, current state, remaining work) and continue from the summary plus the most recent messages.
  • Externalise state — write findings, plans and intermediate results to files or a store. The agent re-reads what it needs instead of carrying everything.
  • Trim tool output at the source — return 20 results not 500, truncate long file reads with a note, strip HTML boilerplate. This is the highest-leverage fix and it belongs in the tool, not the prompt.
  • Sub-agents for exploration, so the wide search happens in a context you throw away.

What must survive every compaction: the original goal, constraints given by the user, decisions already made, and what's left to do.

What guardrails does an agent with real tools need?

Enforce them in code, never in the prompt — a prompt is a request, not a control.

  • Least-privilege tools — expose only what this task needs; read-only by default, writes as a separate, explicitly granted tool.
  • Human-in-the-loop for irreversible actions — sending, paying, deleting, deploying. Show exactly what will happen and require approval.
  • Budgets — max steps, max tokens, wall-clock timeout, max tool calls per type. Every one of these has saved someone a large bill.
  • Sandboxing — run code in a container with no credentials and restricted egress; scope filesystem access to a working directory.
  • Authorisation on the user's identity — the backend checks what the user may do, not what the agent asked for.
  • Audit log — every tool call, arguments and result, tied to a run id.

How should an agent handle tool failures?

Distinguish who can fix the error:

  • Transient (429, 503, timeout) → retry in your code with backoff. The model shouldn't waste a turn on it.
  • Model-fixable (bad parameters, wrong id, validation failure) → return the error text to the model with guidance. This is where self-correction shines: "date must be YYYY-MM-DD" gets fixed on the next call.
  • Terminal (permission denied, resource doesn't exist, feature unavailable) → tell the model plainly so it stops retrying and either finds another route or reports back to the user.

Guard against loops: track repeated identical calls and break the pattern — after two identical failures, inject a message telling it that approach isn't working and to try something else or stop. A cap on total steps is the backstop.

How do you evaluate an agent?

Harder than evaluating a single prompt, because the same task has many valid paths.

  • Outcome evaluation — did the end state become correct? For agents with side effects this is checkable programmatically: the ticket exists with the right fields, the tests pass, the file matches. Always prefer this.
  • Trajectory evaluation — was the path sensible? Did it call the right tools, avoid redundant calls, stay within budget? Useful for diagnosis, but don't over-constrain — a different valid path isn't a failure.
  • Efficiency — steps, tokens, wall-clock, cost per completed task. These are real product metrics for agents.
  • Safety — did it attempt an action outside policy? Should be a hard fail regardless of outcome.

Build a set of tasks with verifiable end states and run them on every prompt, model or tool change. And measure a completion rate over multiple runs — agents are stochastic, so a single pass tells you almost nothing.

What do you need to log to debug an agent in production?

A trace per run, with a span per step, is the minimum viable debugging story. Per span record: the prompt actually sent (after templating), the model and version, the response including tool calls, tool arguments and results, token counts, latency and cost.

Rolled up per run: total steps, total tokens and cost, terminal state (completed / hit step cap / errored / user-aborted), and the user-visible outcome.

Why it matters more than for normal services: you cannot reproduce a failure from an error message. The behaviour depends on the exact assembled prompt — which included retrieved chunks, prior turns and tool outputs that no longer exist unless you stored them.

Tooling: OpenTelemetry-based tracing (LangSmith, Langfuse, Braintrust, Phoenix) gives you this shape out of the box. Redact PII on the way in — traces store full prompts and become your biggest privacy exposure.

Why are agents so expensive, and how do you control it?

The cost driver is structural: the entire conversation is resent on every step. A 15-step run doesn't cost 15 × one call — it costs the sum of a context that grows with every tool result, so cost grows roughly quadratically with steps.

Controls, in order of impact:

  • Prompt caching — the system prompt and tool definitions are identical every step, so caching them is the single biggest saving in an agent loop.
  • Trim tool outputs — every token a tool returns is paid for again on every subsequent step.
  • Model routing — a cheap model for routine steps, the expensive one for planning and hard reasoning.
  • Fewer steps — better tools (one call instead of three), parallel tool execution, and a clear stopping condition.
  • Hard budgets per run and per user, with the run terminated and reported rather than silently continuing.

Should you use an agent framework or build the loop yourself?

The core loop is ~50 lines, so frameworks earn their place through the surrounding machinery, not the loop.

What they give you: graph/state modelling and branching (LangGraph), durable execution and resumability, streaming plumbing, tracing integration, human-in-the-loop checkpoints, and provider abstraction.

What they cost: a large abstraction between you and the prompt — which matters because the prompt is the program. When behaviour is wrong, you need to see exactly what was sent, and heavy frameworks make that harder. They also churn fast and add dependency weight.

A reasonable rule: build the loop yourself while learning and for simple agents — you'll understand what's happening. Adopt a framework when you need durable multi-step state, complex branching, or a team standard.

How do you run long agent tasks reliably in production?

A run lasting minutes to hours can't live in an HTTP request. Treat it as a durable job:

  • Queue the work — return a run id immediately, execute on a worker, stream progress over SSE/WebSocket and let the client reconnect.
  • Checkpoint state after every step — messages, plan, step count — so a worker crash resumes rather than restarting. This is what durable-execution engines (Temporal, LangGraph's persistence) provide.
  • Idempotent tools — after a crash you may replay a step. A tool that charges a card must be keyed so replay is a no-op.
  • Interruptibility — the user must be able to cancel, and a paused human-approval step must survive a deploy.
  • Timeouts and dead-lettering — a stuck run should end, be recorded, and be inspectable, not linger holding a worker.

What are computer-use / browser agents, and what are their limits?

Agents that operate a GUI or browser the way a person does: take a screenshot or read the accessibility tree, decide an action (click at coordinates, type, scroll), execute it, observe the result, repeat.

Why it's valuable: it reaches systems with no API — legacy internal tools, vendor portals, anything behind a login with no integration.

Why it's hard: each step is a full model call over an image, so it's slow and expensive; a small UI change breaks a learned flow; error rates compound across many steps so long tasks fail often; and CAPTCHAs, bot detection and MFA block it by design.

Security is the sharp edge: a browser agent reads untrusted web pages while holding the user's session — the textbook indirect prompt-injection setup. Scope credentials tightly, keep it in a sandboxed profile, require confirmation for purchases, submissions and destructive clicks, and restrict which domains it may visit.

What is the biggest security risk in agent design?

Indirect prompt injection, and it becomes critical when a single agent has all three of what's often called the lethal trifecta:

  1. Access to private data,
  2. Exposure to untrusted content (web pages, emails, tickets, documents, tool output),
  3. An outbound channel (send email, HTTP request, post a comment, render a remote image).

With all three present, text inside a document can cause your agent to read secrets and ship them out — and the model has no reliable way to distinguish instructions from data, so no prompt fixes this.

Break a leg of the trifecta: don't give the same run both private data and untrusted input; remove or allowlist the egress path (no arbitrary URLs or recipients — note markdown image rendering is an exfiltration channel); require human approval for any outbound action; and enforce authorisation in the backend against the user, never against the model's request.

How do you design human-in-the-loop checkpoints?

Approval is only useful if the human can actually evaluate what they're approving — otherwise you've built a click-through ritual that adds latency and no safety.

  • Gate on impact, not on step count. Reads and drafts run free; anything irreversible, external-facing or expensive stops.
  • Show the concrete effect — the exact email, the exact SQL, the exact diff — not "the agent wants to use the send_email tool".
  • Offer edit, not just approve/reject. Letting the user fix a detail and continue is far more useful than forcing a restart.
  • Batch approvals where possible — twelve separate confirmations guarantee rubber-stamping.
  • Escalate on uncertainty — the agent should be able to ask when it's unsure, rather than guessing confidently.
  • Persist the paused state so an approval can arrive minutes later, after a deploy, or from a different device.

When should you NOT build an agent?

  • The steps are known in advance. Then it's a workflow — deterministic, testable, cheaper and faster. Most "agent" projects are this.
  • The task is a single call. Classification, extraction, summarisation don't need a loop.
  • Latency is user-facing and tight. Multi-step loops take seconds to minutes.
  • Errors are unacceptable and unverifiable. If you can't check the result and mistakes are costly, autonomy is the wrong shape — use assisted drafting with human sign-off.
  • Regulatory explainability is required. "The model decided to" is not an audit trail.
  • The environment is hostile — untrusted input plus privileged tools with no way to break the trifecta.

The honest framing for an interview: an agent buys flexibility and pays with predictability, cost and latency. Only take that trade when the flexibility is genuinely required.

How do you write tests for an agent in CI?

Split what's deterministic from what isn't.

Deterministic, run on every commit:

  • Tool unit tests — each tool with mocked backends, including the error paths.
  • Schema tests — tool definitions validate; parameters serialise as expected.
  • Loop tests with a stubbed model — script the model's responses to assert your orchestration: does it stop at max steps, retry correctly, surface tool errors, respect the budget? No API calls, milliseconds to run.

Stochastic, run on a schedule or before release:

  • Task suite against real models — a set of tasks with programmatically verifiable end states, run N times, tracking completion rate, steps and cost.
  • Tool-selection tests — fixed requests, assert on which tool was chosen. Far more stable than asserting on prose.

Gate CI on the deterministic layer; treat the stochastic layer as a tracked metric with thresholds rather than a pass/fail unit test.

How do you design the UX for an agent that takes 30+ seconds?

The core problem is that a long silence reads as a hang, and users cancel or double-submit.

  • Stream the reasoning and the steps, not just the final answer — "searching orders…", "found 3 matches, checking status". Visible progress is what makes a 40-second wait acceptable.
  • Show a plan up front so the user can see the shape of the work and correct it before it runs.
  • Make it interruptible. A cancel button that actually stops the run is a trust feature.
  • Render tool calls as structured UI — a card for a search result, a diff for a file change — rather than raw JSON.
  • Handle the tail well — a clear terminal state (done, stopped at limit, needs your approval, failed), never an ambiguous stall.
  • Persist across reconnect — a closed laptop shouldn't lose a five-minute run.

What goes in an agent's system prompt?

A structure that holds up in practice:

  1. Role and objective — what this agent is for, in one or two lines.
  2. Available capabilities — a short summary of what it can do; detail lives in the tool definitions, not here.
  3. Process guidance — how to approach the work: gather information before acting, verify before declaring done, ask when a required detail is missing.
  4. Hard constraints — what it must never do, and what requires approval. Keep this short; a long list of rules dilutes all of them.
  5. Stopping condition — what "done" means and what the final message should contain. Agents frequently over-run because nobody told them what finished looks like.
  6. Output format — how to report results back.

Keep it stable and put it first so prompt caching applies. Write rules as positive instructions ("ask the user for the order id") rather than prohibitions — models follow those more reliably.