# Agents interview questions > 15 agents interview questions for AI and ML engineer roles, each with a model answer. Canonical: https://llmdojo.dev/interview/topic/agents Last updated: 2026-10-23 15 questions: 1 junior, 8 mid-level and 6 senior. ## [What actually is an AI agent?](https://llmdojo.dev/interview/q/what-actually-is-an-ai-agent) Level: Junior An LLM in a **loop with tools**: it picks the next step, calls a tool such as search or code execution, reads the result, and repeats until it judges the task done. **Diagram: The tool-call loop** 1. The context holds the tool definitions and the user's question. 2. The model emits a structured call: a tool name and JSON arguments. With Anthropic's API the reply stops with stop_reason "tool_use". 3. The call is text the model generated. Your code checks it before anything runs. 4. Your code executes the function. The model has no hands: it only asked. 5. The output goes back into the context (a tool_result block) and the model runs again, until it answers instead of calling. After AI Engineering, Ch. 6 "Function calling", and Anthropic, "Tool use with Claude" (fetched 2026-10-21). Illustrative call. Unlike a fixed pipeline, **the model controls the flow**, so it handles open-ended tasks, and can fail in open-ended ways. ## [LLM workflow or agent: which is better?](https://llmdojo.dev/interview/q/llm-workflow-or-agent-which-is-better) Level: Mid-level Neither by default. A **fixed workflow**, code that calls the model in set steps, is cheaper, faster and easier to test; use it when you know the steps. An **agent** earns its cost when the steps can't be known in advance. Start with the simplest thing that works, and add autonomy only where **evals show it helps**. ## [Your agent is very slow. What can you do?](https://llmdojo.dev/interview/q/your-agent-is-very-slow-what-can-you-do) Level: Mid-level Profile one run: count the **model calls**, tokens per call and tool latency. Then run independent tool calls **in parallel**, use a small fast model for routing and simple steps, cache tool results and the static prompt prefix, trim the growing history, cap the steps, and turn predictable chains into **plain code**. Stream progress, so users see it working. ## [What are guardrails, and where do they sit in an agent?](https://llmdojo.dev/interview/q/what-are-guardrails-and-where-do-they-sit-in-an-agent) Level: Mid-level Checks **outside the model** on what goes in and comes out: input filters for injection or off-topic requests, **validation of tool calls** before they run (allowed tools, arguments, permissions), and output checks for policy, private data and format. The tool boundary matters most, because that's where an agent's mistakes become **real actions**. ## [What are the bottlenecks of AI agents, and how do you keep them in check?](https://llmdojo.dev/interview/q/what-are-the-bottlenecks-of-ai-agents-and-how-do-you-keep) Level: Senior **Compounding errors**: every step can fail, so long chains fail often; keep them short and check intermediate results. **Loops and cost**: cap steps, tokens and spend per task, and catch repeated identical calls. **Latency** grows with each call. **Context** fills with tool output, so summarise it. **Unsafe actions**: least-privilege tools, and a confirmation for anything irreversible. Trace every run, so failures can be replayed and turned into tests. ## [Design a harness for running a tool-using agent safely, and an evaluation platform on top of it.](https://llmdojo.dev/interview/q/design-a-harness-for-running-a-tool-using-agent-safely-and-an) Level: Senior The harness owns everything the model doesn't. It runs the **tool-call loop**, executes tools in a sandbox with no network by default, scoped credentials and time limits, enforces step and token budgets, and gets human approval for irreversible actions. Every step is logged as a replayable trace. **Diagram: The tool-call loop** 1. The context holds the tool definitions and the user's question. 2. The model emits a structured call: a tool name and JSON arguments. With Anthropic's API the reply stops with stop_reason "tool_use". 3. The call is text the model generated. Your code checks it before anything runs. 4. Your code executes the function. The model has no hands: it only asked. 5. The output goes back into the context (a tool_result block) and the model runs again, until it answers instead of calling. After AI Engineering, Ch. 6 "Function calling", and Anthropic, "Tool use with Claude" (fetched 2026-10-21). Illustrative call. Evaluation reuses that harness: a versioned task suite with **deterministic graders** where possible, such as tests passing or final state matching, rubric graders otherwise, and several runs per task because agents are stochastic. Report success, cost, steps and safety violations, and turn production failures into new tasks. ## [Design a code-review agent that combines LLM orchestration with deterministic tools.](https://llmdojo.dev/interview/q/design-a-code-review-agent-that-combines-llm-orchestration-with-deterministic-tools) Level: Senior Let **deterministic tools do what they do reliably**: linters, type checkers, tests and static analysis run first, and their results go in as facts. The LLM reads the diff with retrieved context, such as callers, related files and the ticket, and comments on intent, logic and design that tools can't see. Review per file or hunk, then one pass dedupes and ranks findings. **Precision beats recall**, since noisy bots get ignored: each comment must name a line and a concrete failure. Evaluate on past PRs against comments humans accepted, then track acceptance in production. ## [Design a computer-use agent end to end: how it perceives the screen from pixels and accessibility trees, and how it takes sequential actions.](https://llmdojo.dev/interview/q/design-a-computer-use-agent-end-to-end-how-it-perceives-the) Level: Senior It's a loop: observe, decide, act, check. **Perception** pairs a screenshot with the accessibility tree when one exists; the tree gives element names and ids, which are far more reliable to target than raw coordinates. Without one, mark candidate elements on the image and let the model pick a mark. **Diagram: The tool-call loop** 1. The context holds the tool definitions and the user's question. 2. The model emits a structured call: a tool name and JSON arguments. With Anthropic's API the reply stops with stop_reason "tool_use". 3. The call is text the model generated. Your code checks it before anything runs. 4. Your code executes the function. The model has no hands: it only asked. 5. The output goes back into the context (a tool_result block) and the model runs again, until it answers instead of calling. After AI Engineering, Ch. 6 "Function calling", and Anthropic, "Tool use with Claude" (fetched 2026-10-21). Illustrative call. Actions are typed tools: click, type, scroll, key press. After each, a fresh screenshot **verifies the effect**. Run in a sandboxed VM, treat on-screen text as data, not instructions, and **ask the user before irreversible steps**. Measure task success on benchmarks like OSWorld. ## [Design an LLM agent system that picks up Jira tickets, grounds itself in the codebase, writes a fix in a sandbox and opens a pull request.](https://llmdojo.dev/interview/q/design-an-llm-agent-system-that-picks-up-jira-tickets-grounds-itself) Level: Mid-level A pipeline with an agent in the middle. **Triage** first: take only tickets with a clear reproduction and a scoped component. The agent gathers context with tools: code search, file reads, git history, and tests run in a **sandbox** without production credentials. It writes a failing test, edits code and loops until tests pass, under step and cost limits. **Diagram: The tool-call loop** 1. The context holds the tool definitions and the user's question. 2. The model emits a structured call: a tool name and JSON arguments. With Anthropic's API the reply stops with stop_reason "tool_use". 3. The call is text the model generated. Your code checks it before anything runs. 4. Your code executes the function. The model has no hands: it only asked. 5. The output goes back into the context (a tool_result block) and the model runs again, until it answers instead of calling. After AI Engineering, Ch. 6 "Function calling", and Anthropic, "Tool use with Claude" (fetched 2026-10-21). Illustrative call. The output is a pull request with a summary and links, always **reviewed by a human**. ## [Design an agentic system that reads support tickets, classifies them, gathers evidence from logs, metrics and docs, and proposes a diagnosis.](https://llmdojo.dev/interview/q/design-an-agentic-system-that-reads-support-tickets-classifies-them-gathers-evidence) Level: Senior Use an agent only where judgement is needed. **Classify** the ticket into service and issue type, which picks the playbook and tools. Then an **investigation loop** queries logs, metrics, traces, recent deploys and runbooks through read-only tools, with time windows anchored to the ticket and budgets on steps and tokens. It returns a diagnosis with **cited evidence**, a confidence and next steps, which an engineer accepts or corrects. Evaluate on resolved past tickets: root-cause accuracy, whether cited evidence supports the claim, time to diagnosis, and how often engineers accept it. ## [Design an agentic shopping search that interprets a goal, asks clarifying questions, and searches and refines over several steps. Where should deterministic logic win?](https://llmdojo.dev/interview/q/design-an-agentic-shopping-search-that-interprets-a-goal-asks-clarifying-questions) Level: Senior An LLM planner turns the goal into structured intent: category, constraints, budget, occasion. It asks a **clarifying question** only when the answer would change the results, otherwise it searches with sensible defaults. Each step calls the existing search and filter APIs, inspects results and refines. **Deterministic logic wins** wherever correctness is checkable: price, stock, delivery dates, compatibility, policy and safety rules. The LLM picks queries and explains choices; it **never invents product facts**. Cap the steps for latency, stream partial results, and measure task success and conversion against classic search. ## [Design an agent that classifies uploaded documents and suggests traceable revisions, keeping deterministic rules separate from model judgment and letting a human override.](https://llmdojo.dev/interview/q/design-an-agent-that-classifies-uploaded-documents-and-suggests-traceable-revisions-keeping) Level: Mid-level Split the work by what can be checked. A classifier labels the document type, and the type selects a **rule set**. Checkable rules run as code: required clauses present, dates valid, amounts consistent. The model handles judgment rules, and every finding cites the rule id, the exact span and a proposed edit. Suggestions arrive as a reviewable diff; **humans accept, reject or override**, and their decisions are logged as eval data. ## [You have a contract and several dozen legal rules. Design an LLM agent system that revises the contract until it complies with every rule.](https://llmdojo.dev/interview/q/you-have-a-contract-and-several-dozen-legal-rules-design-an-llm) Level: Mid-level Don't put every rule into one prompt. First **map each rule to the clauses it touches**. Then, per rule, a checker decides compliant or not and cites the span, and a reviser edits only failing clauses. Fixes can conflict, so **re-check every rule against the revised contract** and loop until all pass or a budget runs out, escalating conflicts to a lawyer. Output a tracked-changes diff and per-rule report. ## [How would you train an LLM agent for long-context, long-horizon tasks? What environments and rewards would you build?](https://llmdojo.dev/interview/q/how-would-you-train-an-llm-agent-for-long-context-long-horizon) Level: Mid-level Build **environments that mirror the work**: a sandbox with a document store, search and editing tools, and tasks spanning dozens of steps over long files. Warm-start with supervised fine-tuning on expert trajectories, then RL. Prefer **verifiable rewards**, like the right clauses found or the final document passing checks; use a calibrated judge for the rest, a small step penalty, and a curriculum from short to long tasks. Read transcripts for reward hacking. ## [What are the components of an LLM agent's memory, what does each one store, and how is information written to and read from it?](https://llmdojo.dev/interview/q/what-are-the-components-of-an-llm-agent-s-memory-what-does) Level: Mid-level **Working memory** is the context window: task, recent turns, tool results. Session memory keeps the conversation plus a rolling summary. Long-term memory is **episodic** (past events), semantic (facts and preferences) and procedural (instructions and skills). Writes: after a turn, an extraction step decides what's worth keeping, timestamps it and updates conflicting facts. Reads: retrieve by **relevance, recency and importance**, then fit the results into the prompt's budget. ## Related - [All interview questions](https://llmdojo.dev/interview)