On this page
Key takeaways
- Start with the simplest design that works. Many problems need one model call with retrieval, not an agent.
- A workflow follows code paths you defined. An agent decides its own steps, so it costs more and is less predictable.
- Interviewers ask which of the five common workflow patterns fits, and why, then how you would test it.
- Add human checkpoints and tests before you add autonomy.
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?
Try it first: turn on practice mode to hide the answers, think through each question, then reveal.
A team wants "an agent" to answer HR policy questions. Do they need one?
What a good answer 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.
What is the difference between a workflow and an agent?
What a good answer 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.
When is an agent the right choice?
What a good answer 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.
What does adding an agent cost you?
What a good answer 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?
Explain prompt chaining and give a case for it.
What a good answer 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.
When would you use routing?
What a good answer 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.
Parallelization: sectioning or voting?
What a good answer 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.
What is orchestrator-workers, and how is it different from parallelization?
What a good answer covers
a central model decides the subtasks at run time and hands them to workers. In parallelization the subtasks are fixed in advance.
When does an evaluator-optimizer loop help?
What a good answer 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?
How do you write a tool definition?
What a good answer covers
a clear name, a description a junior engineer would understand, parameters with examples, edge cases, and how this tool differs from similar ones.
The model keeps calling the wrong tool. What do you change first?
What a good answer covers
the tool names and descriptions, not the model. Overlapping tools are a common cause.
What does "make the tool hard to misuse" mean in practice?
What a good answer covers
change the arguments so mistakes are harder to make. Anthropic's example: requiring absolute file paths fixed errors that relative paths caused.
A tool returns an error. What should the model see?
What a good answer 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?
Which actions should never run without a human?
What a good answer 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.
How do you show a reviewer what the agent did?
What a good answer covers
the plan, each tool call with its inputs and result, and the final answer, in an order a non-engineer can read.
The business wants full autonomy from day one. What do you say?
What a good answer 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?
How do you test an agent before production?
What a good answer 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.
An agent passes your tests and fails in the pilot. What happened?
What a good answer 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.
Would you use a framework?
What a good answer 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.
Walk me through an agent you built. What would you remove now?
What a good answer 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
Written by
AIXL Academy
AIXL Academy trains engineers to build and ship AI systems for real customers. Subscribe by RSS or follow the AIXL Academy page on LinkedIn for new question banks.
Keep reading
Interview questions
LLM evals cheat sheet: what to check, how, and when
A one page guide to evaluating LLM and agent systems: code checks, rubrics, model judges, eval sets and when to run them.
Interview questions
AI engineering system design interview questions, with what good answers cover
Common system design questions for AI engineer and forward deployed engineer interviews, and what a strong answer covers for each.