These are the questions agent-engineering interviews keep returning to, grouped by topic. Each answer shows what a strong response covers. Interviewers are less interested in which framework you used and more interested in whether you can keep an agent bounded, recoverable, and measurable. Back every answer with something from your capstone or labs.
The AI Engineer fundamentals — tokens, retrieval, evaluation, security — come up too. Practise the AI Engineer interview questions as well if those feel shaky.
Foundations
1. What is an agent, and how is it different from a workflow? In a workflow, your code chooses the sequence. In an agent, a model chooses some next steps — usually which tool to call — based on what it has observed, within limits your runtime enforces. Many good systems are workflows with one adaptive step. → What is agentic AI
2. When should you not use an agent? When the sequence is known and reliable. A fixed workflow is cheaper, faster, and easier to test. Strong answers describe measuring a fixed baseline first and adding autonomy only where it measurably helps within the same budget. → Workflows before agents
3. What are the parts of an agent system? Model, instructions, tools, state, observations, and a runtime. The model proposes; the runtime validates, checks permissions and budgets, executes allowed tools, and records results. The runtime — not the model — enforces the rules. → Components of an agent system
Tools and execution
4. How do you make tool calling safe?
An explicit allowlist, argument validation, authorization from trusted identity, per-tool deadlines, bounded output size, and a step and cost budget for the whole task. A generated tool call is a request, never permission. Prefer narrow tools like get_ticket(id) over a general SQL or shell tool. → Tools and bounded execution
5. A write times out. Do you retry? Not blindly — the write may have succeeded. Use an operation ID as an idempotency key, or query the remote state and reconcile before retrying. Tell the model "operation pending", not "failed", so it does not invent a second action. → Tool runtime
6. How do you stop an agent looping forever? Hard limits enforced in trusted state: steps, elapsed time, tool calls, context growth, and spend. Every stop produces an explicit terminal state and reason. The model can never raise its own budget.
Memory and state
7. What is the difference between context and memory? Context is what the model sees for this decision. Memory is what persists for later decisions, so it needs ownership, provenance, expiry, correction, and deletion. Do not turn every inference about a user into a permanent fact. → Memory with provenance
8. Your agent crashes halfway through a task. What happens on restart? Recovery uses durable facts — checkpointed state and recorded operation IDs — not a regenerated guess from the transcript. Version-checked state transitions stop two workers claiming the same step, and idempotent effects stop duplicates. → Checkpoint workflows
Planning and oversight
9. Does reflection ("check your answer") improve quality? Only with new evidence or a concrete rubric. Without them, a model can replace a correct answer with a more confident wrong one. Bound the number of revisions and measure whether they actually improve evidence support. → Plans and feedback
10. How do you design human approval properly? Bind approval to an exact, immutable proposal: target, content, resource version, approver, and expiry. Any change invalidates it. Recheck permissions and version at execution time. A model saying "the user approved" is not an approval. → Bind approval to the exact action
11. When are multiple agents worth it? When separate responsibilities improve a measured result against a single-agent baseline with the same budget. Each handoff is a new failure point, so use typed handoff records, shared durable state for facts that must agree, and explicit conflict handling. → Coordinate specialists
Integration
12. What is MCP, and does connecting a server make its tools safe? The Model Context Protocol standardises how a host application connects to servers that expose tools, resources, and prompts. It does not decide what your user is allowed to do. Treat discovered tools and descriptions as untrusted, pin versions, and never auto-grant new capabilities. → Connect tool servers
13. How do you choose an agent framework? Start from your requirements — durability, interruption, typing, language, tracing — and compare against a plain-code baseline on the same tests. LangGraph, OpenAI Agents SDK, Google ADK, CrewAI, PydanticAI, and Koog each start from a different abstraction. No framework replaces your authorization contract. → Choose and compare frameworks
14. What extra risks come with computer-use or browser agents? Stale observations, layout changes, unexpected navigation, downloads, and page text that tries to redirect the agent. Validate every action against the latest observation, restrict origins, sandbox the environment, and confirm state after each meaningful action. → Sandboxed computer use
Evaluation and operations
15. How do you evaluate an agent? Grade the trajectory, not only the final answer: tool choice, argument validity, access decisions, stop behaviour, and side effects. An agent that gets the right answer through an unauthorised action fails. Replay deterministic fixtures and run live-model cases separately. → Evaluate agent behaviour
16. A document tells your agent to export all tickets. What happens? Nothing, if the runtime is right: retrieved content is data, the agent has no export tool, and the step is outside its permissions. Add it as a blocking regression case. If the only defence is the prompt, that is the bug.
17. How do you handle a user interrupting a voice or streaming agent? Tag every event with a turn ID and drop events from cancelled turns. Cancel work where you can, but remember committed side effects cannot be undone by closing a stream. Never treat a partial transcript as approval. → Handle interruptions
18. How do you run agents in production? As bounded jobs: a durable queue, leases so one worker owns a task, per-user quotas in shared state, versioned prompts and tool schemas, and a runbook for stuck tasks and uncertain side effects. → Operate agents as bounded jobs
System design
19. Design a support agent that can update tickets. Start with a fixed search-and-draft baseline. Add a bounded loop with narrow read tools; make writes proposals that need exact-action human approval; persist task, proposal, approval, and operation records; make application idempotent; isolate context per user and tenant; and gate releases on trajectory evaluation. Explain where you would stop adding autonomy. → Capstone brief
20. Design a research agent that writes a cited report. Break the question into claims, keep an evidence ledger with source, version, and origin, bound search depth and calls, treat copied sources as one origin, surface unresolved contradictions, and have the writer use only the ledger. → Evidence-seeking research
How to practise
Answer each question out loud in under two minutes and point to a trace or test from your project. Ask a peer to push with "and if the tool times out?" or "who authorised that?" — strong agent engineers answer those calmly with evidence.
Practise with the interview practice mode, and use the Android AI Interview Handbook for 150 more AI questions. To make sure your resume shows your agent projects well, book a Resume Review.