AI Agents interview questions
AI Agents questions a AI engineer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What makes something an agent rather than a fixed LLM workflow?
The strongest answer: A workflow has its steps fixed in my code, with the model filling each one in; an agent lets the model decide the next step itself, looping with tools until the task is done
Why it works: Exactly — the difference is who owns the control flow. And when the steps are known in advance, the workflow is the cheaper, more predictable choice.
- Who decides the next step?
- Workflow: code owns the sequence.
- Agent: the model chooses, in a loop.
- Known steps? Prefer the workflow.
Walk me through the agent loop. What happens on each pass, and what ends it?
The strongest answer: The model reads the goal and the history and picks an action, usually a tool call; my code runs it and appends the result; this repeats until the model answers or a step limit stops it
Why it works: Right — decide, act, observe, repeat. The observation is what makes the next decision better than a guess, and the limit is what makes the loop safe.
- Decide, act, observe, repeat.
- The model picks; your code executes.
- Feed every result back in.
- End on an answer or a budget.
What is the ReAct pattern, and what does interleaving reasoning with actions actually buy you?
The strongest answer: The model alternates a short reasoning step, an action, and the observation that comes back — so each decision rests on what the tool really returned, not on a plan made before seeing any data
Why it works: Exactly — reason, act, observe. The reasoning trace also gives you something to read when you debug a bad run.
- Reason, act, observe — interleaved.
- Ground each step in real results.
- Never let the model invent observations.
- Keep the trace for debugging.
You are building a support agent that can look up orders, draft replies, issue refunds and close accounts.
Where do you put human approval in this agent — and where do you deliberately leave it out?
The strongest answer: On the actions that are costly or hard to undo — refunds, closing accounts — pausing with the exact proposed action shown; lookups and drafts run free, because approving everything trains people to click yes unread
Why it works: Exactly — gate by reversibility and cost, show the real arguments, and keep the prompts rare enough that people still read them.
- Gate by reversibility and cost.
- Show the exact action and arguments.
- Let reads and drafts run free.
- Too many prompts means none get read.
A trace shows your research agent calling the same search tool with near-identical arguments dozens of times before someone killed the run by hand.
What do you put in place so this cannot happen again?
The strongest answer: A step and cost budget that ends the run cleanly, detection of repeated near-identical calls, tool results that say what to change, and a defined exit — report what was tried and hand over
Why it works: Exactly — a budget stops the bleeding, loop detection catches it early, better tool feedback removes the cause, and the exit path means the user still gets something.
- Budgets in code, not in prompts.
- Cap steps and spend per run.
- Detect repeats; improve tool feedback.
- Exit cleanly: report and hand over.
On long tasks your agent starts well, but by step fifteen it has forgotten a constraint from the original request and is polishing a side issue.
What do you change in the agent’s design?
The strongest answer: Make the plan explicit state: a task list the agent re-reads and updates, the goal and constraints pinned in context while old tool output is summarised, and a check against the goal at milestones
Why it works: Exactly — the plan is state you manage, not something you hope survives in the middle of a long context.
- The plan is state — manage it.
- Write the plan down; re-read it.
- Pin the goal; trim old output.
- Check against the goal at milestones.
Your agent runs tasks that take most of an hour. A routine deploy restarts the worker in the middle of a run.
How do you design it so a restart means neither starting over nor doing things twice?
The strongest answer: Persist the run outside the process after every step — messages, tool results, what has been committed — so any worker can resume, and make side-effecting steps safe to repeat or recorded as done first
Why it works: Exactly — durable state gets you resumption, and idempotent or recorded side effects are what stop the resumed run from sending the email twice.
- State lives outside the process.
- Persist after every step.
- Any worker can resume a run.
- Make side effects safe to repeat.
A colleague proposes replacing your single agent with a planner, a researcher, a writer and a critic, each its own agent.
When is a multi-agent design worth it, and when is it not?
The strongest answer: Worth it when the work truly separates — parallel subtasks, different permissions, context too big for one window. Otherwise every handoff loses context and adds cost and debugging, so I fix the single agent first
Why it works: Exactly — agents are split for isolation and parallelism, not for the org chart. And you would prove the gain on the same test set before keeping it.
- Split for isolation, not for fashion.
- Name what the split isolates.
- Count what each handoff loses.
- Prove it against the single agent.
The business wants your operations agent to act on customer accounts without a person approving each step.
How do you decide how much autonomy it gets, and how does that grow over time?
The strongest answer: Per action, by blast radius and reversibility: start with reads and drafts, then make specific action types automatic once real traces show their error rate and undo path — keeping an audit log and a kill switch
Why it works: Exactly — autonomy is granted per action, on evidence, and it stays revocable. That is an answer you can defend to a risk committee.
- Autonomy per action, earned on evidence.
- Rank actions by blast radius.
- Promote on measured traces.
- Keep limits, logs and a kill switch.