# Agentic AI interview questions: 20 questions and what a good answer covers

URL: https://aixl.academy/blog/agentic-ai-interview-questions/
Published: 2026-11-02
Updated: 2026-11-02
Author: AIXL Academy
Topics: agentic ai, interview questions, ai engineering, tool design, llm agents

Agentic AI interviews have moved past "what is an agent". Interviewers now want to see whether you can pick the simplest design that works, explain why, and show how you would test it.

The clearest public reference for the vocabulary is Anthropic's engineering post "Building effective agents" (December 2024). It separates workflows, where LLMs and tools follow predefined code paths, from agents, where the LLM directs its own process and tool use. It also describes five common workflow patterns. Many interview questions now assume you know these terms.

We have grouped the questions by what they test. For each one we list what a good answer covers. There are no model answers to memorise.

## 1. Design judgment: workflow or agent?

**1. A team wants "an agent" to answer HR policy questions. Do they need one?**
Covers: probably not. A single LLM call with retrieval over the policy documents may be enough. A strong answer starts with the simplest option and names what would justify more complexity.

**2. What is the difference between a workflow and an agent?**
Covers: a workflow follows code paths you defined; an agent decides its own steps and tool calls. A good answer adds the trade: agents cost more and are less predictable, so they need a reason.

**3. When is an agent the right choice?**
Covers: open-ended problems where you can not predict the number of steps or hardcode the path, and where you can trust the model's decisions inside a safe environment.

**4. What does adding an agent cost you?**
Covers: latency, token cost, and errors that compound across steps. A strong candidate says how they would measure each one before and after.

## 2. Patterns: which one, and why?

**5. Explain prompt chaining and give a case for it.**
Covers: a task split into fixed steps, each call working on the previous output, with checks between steps. Good fit when the task breaks cleanly into subtasks.

**6. When would you use routing?**
Covers: inputs fall into distinct categories that are better handled separately, for example support queries split into general, refund and technical, or easy questions sent to a smaller model.

**7. Parallelization: sectioning or voting?**
Covers: sectioning splits independent subtasks; voting runs the same task several times for confidence. A good answer gives one example of each, such as a separate guardrail check, or several reviewers on the same code.

**8. What is orchestrator-workers, and how is it different from parallelization?**
Covers: a central model decides the subtasks at run time and hands them to workers. In parallelization the subtasks are fixed in advance.

**9. When does an evaluator-optimizer loop help?**
Covers: when there are clear evaluation criteria and feedback measurably improves the output. A good answer names the criteria before naming the loop.

## 3. Tools: can the model use what you built?

**10. How do you write a tool definition?**
Covers: a clear name, a description a junior engineer would understand, parameters with examples, edge cases, and how this tool differs from similar ones.

**11. The model keeps calling the wrong tool. What do you change first?**
Covers: the tool names and descriptions, not the model. Overlapping tools are a common cause.

**12. What does "make the tool hard to misuse" mean in practice?**
Covers: change the arguments so mistakes are harder to make. Anthropic's example: requiring absolute file paths fixed errors that relative paths caused.

**13. A tool returns an error. What should the model see?**
Covers: a message that says what went wrong and what to try next, not a raw stack trace.

## 4. People: where does a human check?

**14. Which actions should never run without a human?**
Covers: anything that moves money, changes records other people rely on, or contacts a customer. A strong answer ties this to the business owner, not to the model's confidence.

**15. How do you show a reviewer what the agent did?**
Covers: the plan, each tool call with its inputs and result, and the final answer, in an order a non-engineer can read.

**16. The business wants full autonomy from day one. What do you say?**
Covers: start with a human checkpoint on risky actions, measure how often the human changes the result, and widen autonomy as that number falls.

## 5. Testing: how do you know it works?

**17. How do you test an agent before production?**
Covers: a set of real tasks with known good outcomes, run in a sandbox, scored on task success and not just on how the answer reads.

**18. An agent passes your tests and fails in the pilot. What happened?**
Covers: the test set did not look like real inputs. A good answer says how to collect failing cases from the pilot and add them.

**19. Would you use a framework?**
Covers: frameworks help you start, but can hide the prompts and responses. A strong answer says they would understand the code underneath, or call the model API directly for simple patterns.

**20. Walk me through an agent you built. What would you remove now?**
Covers: a specific system, the part that added complexity without improving results, and how they found out. This is where real experience shows.

## How to practise

Take one real process you know, such as invoice queries or ticket triage. Answer questions 1, 5, 10, 14 and 17 for that process, out loud. Then ask someone to push back on every "it depends".

If you want to practise this on a real build, with your work assessed rather than your attendance, the AIXL Academy Forward-Deployed AI Engineering cohort covers agent design, tools and testing.

## Sources

- Anthropic, "Building effective agents" (19 December 2024): https://www.anthropic.com/engineering/building-effective-agents