Agentic AI Engineering: Architecture and Patterns Interview Prep

Single-agent vs Multi-agent vs Planner-executor — When Each Pattern Earns Its Complexity

Sample interview questions

1. What are the three irreducible properties that make a system an AI agent rather than a sophisticated LLM application?
   • A. A loop (repeated LLM calls), decision-making (the LLM chooses what to do next), and a stop condition (a goal or budget that terminates the loop). ✓
   • B. A system prompt, a memory module, and a multi-step planner.
   • C. An orchestration framework (e.g., LangGraph), a vector database, and an eval harness.
   • D. A fine-tuned model, a streaming interface, and a human-in-the-loop queue.

   Option A is correct. The canonical definition from the agent-architecture literature reduces to three properties: (1) a loop — the LLM is called repeatedly, each call informed by previous results; (2) decision-making — the LLM is steering, not just narrating; it decides which tool to call or what to do next based on prior observations; (3) a stop condition — the loop terminates when a goal is reached or a budget limit fires. Without any one of these three a system is a sophisticated LLM application but not an agent. Option B is wrong because a system prompt and memory module are common additions but not definitional. A minimal agent can start with no persistent memory and still be genuinely agentic. A multi-step planner is one loop pattern (Plan-and-Execute) but not required; basic tool use with a stop condition is enough. Option C is wrong because an orchestration framework, vector database, and eval harness are production-readiness additions layered on top of the core. An agent running in a few dozen lines of Python calling an LLM API directly is still a valid agent. Option D is wrong because fine-tuning is not required — base tool-calling capability is sufficient. A HITL queue is a production safety feature, not a minimum requirement. Production reality: the stop condition is the most-skipped property. Teams that ship without one produce the most expensive bugs: unbounded loops that exhaust token budgets without returning useful answers.

2. Which of the following most accurately distinguishes an AI agent from a chatbot that has access to tools?
   • A. An agent uses a larger language model than a chatbot.
   • B. An agent runs a persistent control loop — plan, act, observe, replan — across multiple tool calls without requiring human prompting between steps. ✓
   • C. An agent always requires a vector database for memory, whereas a chatbot does not.
   • D. An agent generates longer responses and more detailed explanations than a chatbot.

   Option B is correct. The defining characteristic of an agent is the autonomous control loop. A chatbot with a tool attached still processes one user turn and returns one response — it does not continue independently to the next step. An agent, by contrast, can initiate a sequence of tool calls, observe the results, update its plan, call more tools, and iterate — all without requiring the user to prompt again between steps. This is what "agentic" means: the system has autonomy over the step sequence. Option A is wrong. Model size is not the distinguishing factor. A small model can power an agent if it supports tool use; a large model used in a one-turn chatbot is not an agent. Option C is wrong. Memory (via vector database or otherwise) is a common agent addition but is not definitional. An agent can operate with only in-context state from the current session and still be genuinely agentic. Option D is wrong. Response length is irrelevant. An agent might return a very short final answer after dozens of internal steps, while a chatbot might return a lengthy essay in a single turn. Production reality: the "chatbot + one tool call" pattern is a trap. Adding a single tool call to a chatbot does not make it an agent because there is no loop. The agent pattern requires designing the loop first — what is the stopping condition? what happens on tool error? how many steps are budgeted? — before adding tools.

3. A system reads a user's query, retrieves three passages from a knowledge base, and sends all three plus the query to an LLM which returns one answer. Is this system an agent?
   • A. Yes, because it uses retrieval-augmented generation, which is an agentic pattern.
   • B. No — it is a RAG pipeline. The LLM is called once with no decision loop; the retrieval order is hardcoded by the developer, not chosen by the LLM. ✓
   • C. Yes, because it makes at least one tool call (the retrieval step).
   • D. It depends on the size of the knowledge base — larger bases make retrieval agentic.

   Option B is correct. RAG (Retrieval-Augmented Generation) is a pipeline pattern: retrieve content from a knowledge base, add it to the LLM prompt, generate an answer — one pass. The order of operations is hardcoded by the developer; the LLM is not deciding whether to retrieve, what to retrieve, or whether to retrieve again. There is no loop, and the LLM is not making steering decisions. This is a sophisticated LLM application, not an agent. The system would become agentic if the LLM could decide whether to retrieve, what to search for, how many times to retrieve, and whether the retrieved content was sufficient — and loop until satisfied. That pattern (Agentic RAG or Self-RAG) has a decision loop; the basic RAG pipeline does not. Option A is wrong. RAG and agents are distinct ideas. RAG is a knowledge-injection technique the agent might use as one of its tools. RAG by itself, without a decision loop, is not agentic. Option C is wrong. A single tool call — even a retrieval call — does not make a system an agent. The defining property is the loop: the LLM decides what to do next based on previous results, in repeated steps. Option D is wrong. Knowledge base size does not determine whether a system is agentic. The decision loop is the only thing that matters. Production reality: this distinction matters because the failure modes differ. A RAG pipeline fails by retrieving the wrong chunks. An agent fails by drifting over twenty steps, looping on tool calls, or refusing to stop. Different failure modes need different engineering responses.

4. Which layer of the four-layer agent architecture is responsible for rubric scoring, adversarial critique, and regression testing of agent outputs?
   • A. Knowledge layer — because knowledge quality determines output quality.
   • B. Runtime layer — because the loop executes evaluation steps.
   • C. Quality layer — it judges the runtime's outputs via rubric scoring, critic agents, and eval harnesses. ✓
   • D. Meta layer (AgentOps) — because all monitoring lives in the meta layer.

   Option C is correct. The four-layer architecture assigns distinct responsibilities: Knowledge (what the agent knows — context, memory, retrieval), Runtime (how the agent executes — the loop, tool dispatch, orchestration), Quality (judging what came out — rubric scoring, adversarial critics, guardrails, regression tests), and Meta / AgentOps (improving over time — observability, drift detection, evaluation-driven improvement, cost accounting). Rubric scoring, adversarial critique, and regression testing are all mechanisms for verifying that agent outputs meet defined standards — that is the Quality layer's job. Option A is wrong. The Knowledge layer shapes the agent's input context. It affects output quality indirectly, but rubric scoring and adversarial critique are Quality layer components, not Knowledge layer components. Option B is wrong. The Runtime layer executes the agent's loop — it routes tool calls and manages the message thread. Eval harnesses and scoring rubrics are built on top of the Runtime to judge its outputs, not part of the Runtime itself. Option D is wrong. The Meta layer (AgentOps) uses evaluation results to improve the system over time — it closes the feedback loop by feeding quality signals back down to the Knowledge and Runtime layers. But the mechanisms that produce those quality signals (rubric scoring, critics, regression tests) live in the Quality layer. Production reality: teams that build only the Runtime layer and skip the Quality layer ship brittle systems — they cannot tell whether yesterday's update made things better or worse. The Quality layer is the layer most commonly underbuilt in early-stage agent projects.

5. When does the ReAct (Reason + Act) pattern earn its added token cost compared to a direct tool-calling loop?
   • A. ReAct is always preferred because reasoning before acting improves reliability in all scenarios.
   • B. ReAct earns its cost when the task requires multi-step debugging, ambiguous tool selection, or when human reviewers need to audit the decision trail. ✓
   • C. ReAct is only appropriate for multi-agent architectures where the orchestrator needs to broadcast reasoning to sub-agents.
   • D. ReAct should be used when the model context window is small, because reasoning reduces the number of tool calls needed.

   Option B is correct. ReAct — where the model emits a reasoning trace before each tool call — adds overhead in tokens and latency. That overhead pays off in specific scenarios: (1) multi-step debugging tasks where the intermediate reasoning explains why each tool was selected, making failures diagnosable; (2) ambiguous tool selection situations where the model needs to reason about which of several similar tools is appropriate; (3) auditability requirements where human reviewers need to follow the decision trail. In straightforward single-tool pipelines or well-scoped tasks, the reasoning trace adds cost without improving reliability. Option A is wrong. Claiming ReAct is always preferred ignores the token and latency overhead. For simple, well-defined tasks where tool selection is unambiguous, the reasoning prefix adds cost with minimal reliability gain. Option C is wrong. ReAct is a single-agent prompting pattern, not a multi-agent communication protocol. The reasoning trace is internal to the agent's context, not broadcast to sub-agents. Option D is wrong. ReAct reasoning does not reduce tool calls — it precedes them. If anything, it increases total token usage. Context window size does not motivate the ReAct choice. Production reality: LangGraph, CrewAI, and the Anthropic SDK all support streaming the reasoning trace separately from tool calls. Enable ReAct when you need the audit trail; use a streamlined prompt when you need lower latency.

6. What are the primary risks of adopting a multi-agent architecture compared to a well-designed single-agent baseline?
   • A. Multi-agent is always riskier because language models cannot coordinate via message passing.
   • B. Multi-agent multiplies failure modes (cascading errors, message ordering bugs, silent stalls), increases cost, and makes root-cause debugging exponentially harder. ✓
   • C. Multi-agent is riskier only for creative tasks; for factual retrieval tasks it is strictly safer.
   • D. The primary risk of multi-agent is hitting context window limits in the orchestrator agent.

   Option B is correct. Moving from single-agent to multi-agent introduces several new failure categories: cascading errors (one agent corrupts another's context with a wrong intermediate result, and the downstream agent acts on it without detecting the error), message-ordering bugs (shared state or bus ordering issues cause agents to act on stale information), and silent stalls (an agent stops making progress but does not surface an error, leaving the pipeline blocked with no observable signal). In addition, every agent in the network adds model call cost, and debugging requires correlating traces across multiple agent spans — exponentially harder than a single trace. Option A is wrong. Language models can coordinate via message passing — that is the basis of all production multi-agent frameworks (CrewAI, AutoGen, LangGraph multi-agent). The claim is false. Option C is wrong. Multi-agent risk is not task-domain-specific. The failure modes (cascading errors, stalls, ordering bugs) apply to both creative and retrieval tasks. Option D is wrong. Context window limits in the orchestrator are a concern, but they are not the primary risk of multi-agent — they can be managed with context truncation or summarization. The primary risks are the structural failure modes that do not exist in single-agent designs. Production reality: the correct guidance is to start single-agent and add agents only when a specific, measurable requirement forces it — context overflow, genuine parallelism requirements, or isolation needs. Never add agents for architectural elegance.

7. A production customer-support agent is returning incorrect refund amounts. The team wants to bound the agent's autonomy before the next deployment. Which control mechanism directly addresses this?
   • A. Increasing the agent's step budget from 10 to 50 to give it more time to compute the correct answer.
   • B. Adding a confidence threshold: if the agent's refund calculation falls outside a validated range, it routes to a HITL queue for human review before executing the transaction. ✓
   • C. Switching from LangGraph to CrewAI because CrewAI handles financial calculations more reliably.
   • D. Fine-tuning the model on refund calculation examples to improve its arithmetic accuracy.

   Option B is correct. Bounding autonomy means defining the conditions under which the agent acts independently versus escalating to a human. For financial calculations with measurable correctness, the right pattern is a confidence or range gate: if the computed refund falls outside a validated range (e.g., outside min/max refund policy bounds) or if the agent's confidence in the calculation is below a threshold, route the decision to a HITL (human-in-the-loop) queue before executing any real-world action. This is the standard HITL escalation pattern for high-stakes agentic actions. Option A is wrong. Increasing the step budget gives the agent more tool calls, which is unrelated to bounding autonomy. It does not prevent incorrect outputs from executing — it just allows more steps before stopping. Option C is wrong. Switching orchestration frameworks does not change the underlying model's arithmetic reliability. LangGraph and CrewAI both call the same underlying language models; arithmetic errors are a model property, not a framework property. Option D is wrong. Fine-tuning might improve arithmetic accuracy at the margins, but it does not bound autonomy — a fine-tuned model can still produce incorrect outputs and act on them. The architectural control (HITL gate) is necessary regardless of model quality. Production reality: HITL queue integration is one of the most important production-readiness additions for any agent taking real-world actions. Define the escalation condition before deployment, not after the first incident.

8. Before shipping an agent that writes and executes code to production, which observability capability is the highest priority to implement first?
   • A. A dashboard showing aggregate success rates over the last 30 days.
   • B. Distributed tracing at the span level — capturing each tool call, its arguments, the result, and the model's reasoning — before the first user session. ✓
   • C. A weekly batch job that exports agent logs to a data warehouse for offline analysis.
   • D. A model evaluation pipeline that scores agent outputs on a static benchmark dataset.

   Option B is correct. Before the first production user session, the highest observability priority is real-time span-level tracing. Each tool call (and specifically each code execution) must emit a span capturing: what code was executed, what arguments were passed, what the result or error was, and what the model's reasoning was at that decision point. Without this, the first production failure is impossible to diagnose. OpenTelemetry GenAI semantic conventions define the standard span attributes. Tools like Langfuse, Phoenix (Arize), and W&B Weave consume these spans. Option A is wrong. An aggregate success rate dashboard is useful after you have baseline data, but it provides no diagnostic capability for investigating individual failures. A dashboard that says "85% success" tells you nothing about why the other 15% failed. Option C is wrong. A weekly offline export provides no real-time visibility. Production agents can fail in ways that require intervention within hours, not weeks. Batch analysis is complementary, not a substitute for real-time tracing. Option D is wrong. A static benchmark evaluation is valuable for pre-deployment testing, but it is not an observability tool. Once the agent is live, you need to observe actual production sessions, not benchmark runs. Production reality: observability instrumentation must be in place before the first user session, not added after complaints arrive. Retrofitting tracing into a running production system is significantly harder than building it in from the start.

9. When does a planner-executor split earn its extra coordination complexity over a single-agent loop?
   • A. Whenever the model being used is larger than 70B parameters.
   • B. When the task decomposes cleanly into subtasks, the planner improves scope control, or the subtasks can run in parallel to reduce latency. ✓
   • C. Whenever the team wants a more legible architecture diagram.
   • D. Whenever the agent needs a vector database for episodic memory.

   Option B is correct. A planner-executor split — where one model creates an explicit task decomposition and one or more executor agents carry out each step — is worth the extra coordination overhead under specific conditions: (1) the task decomposes cleanly into independent subtasks with clear handoff boundaries; (2) the planner can reduce scope creep and improve task framing before execution starts; (3) the subtasks are genuinely independent and can run in parallel, saving meaningful latency. If a single agent can hold the full task context and produce reliable output, the split adds orchestration overhead with no measurable benefit. Option A is wrong. Model size alone does not determine whether decomposition helps. A single large model can handle complex tasks, and a planner-executor split with smaller models may or may not outperform it depending on task structure. Option C is wrong. Architecture aesthetics are not a reason to add coordination overhead. Every added agent adds failure modes, cost, and debugging surface. Option D is wrong. Memory and planner-executor are independent architectural choices. You can add episodic memory to a single agent without introducing a planner-executor split, and you can run a planner-executor architecture with no vector database. Production reality: the most common mistake with planner-executor is using it as a default rather than a justified trade-off. If a single agent can do the work reliably, keep the single agent.

10. What does the Meta layer (AgentOps) add to an agent system that the Runtime and Quality layers alone cannot provide?
    • A. The Meta layer adds the ability to call tools and retrieve external data.
    • B. The Meta layer closes the feedback loop: it takes Quality layer verdicts and feeds them back to improve prompts, examples, and knowledge over time — making the agent a learning agent rather than merely a deployed one. ✓
    • C. The Meta layer enforces guardrails and blocks unsafe outputs before they reach users.
    • D. The Meta layer manages the message thread and enforces the step budget.

    Option B is correct. The Meta layer (the AgentOps / LLMOps layer in canonical field terminology) is the feedback loop that makes an agent get better over weeks, not just remain consistent. It takes quality signals — eval verdicts, human ratings, drift alerts — and feeds them back down to the Knowledge layer (refining prompts, adding better examples) and the Runtime layer (tuning loop parameters, improving tool schemas). Without this feedback path, you have an agent. With it, you have a learning agent. Key Meta layer components include observability and tracing (Langfuse, Phoenix), drift detection, cost accounting, and evaluation-driven improvement loops. Option A is wrong. Calling tools and retrieving external data is the Runtime layer's responsibility — tool dispatch and orchestration live there. Option C is wrong. Enforcing guardrails and blocking unsafe outputs is a Quality layer responsibility. Guardrails judge the runtime's outputs; the Meta layer operates above the Quality layer to improve the system over time. Option D is wrong. Managing the message thread and enforcing the step budget is the Runtime layer's job — that is the loop control logic (the agent's main() function). Production reality: most early-stage agent projects skip the Meta layer entirely. The result is an agent that cannot detect when a model upgrade silently changes its behavior, cannot identify which prompt edits made things better, and has no mechanism to learn from production failures. Building the Meta layer is the difference between a demo and a production system.

Frequently asked questions

What is an AI agent?

An AI agent is a system where an LLM repeatedly decides what to do next — calling tools, reading and writing memory, generating output — until a goal is reached or a stop condition fires. Three properties make a system agentic: a loop (the LLM is called repeatedly, each call informed by prior results), decision-making (the LLM steers by choosing tools and next steps rather than just narrating), and a stop condition (the loop terminates when a goal is reached or a budget limit fires). A system missing any one of these is a sophisticated LLM application, not an agent.

How is an agent different from a chatbot or a RAG pipeline?

A chatbot answers one turn at a time with no loop — the LLM is called once per user message. A RAG pipeline retrieves content, stuffs it into a prompt, and generates one answer — the order is hardcoded by the developer, not chosen by the LLM. An agent runs a loop: it plans a sequence of steps, calls tools to execute them, reads results, updates its plan, and loops — often across many steps without human prompting between them. The key differences are the control loop and the ability to make steering decisions based on prior observations.

What are the four layers of a production agent system?

Every production agent system has work in four layers. Knowledge: what the agent knows — system prompt, retrieved context, episodic memory, knowledge graphs, and grounding data. Runtime: how the agent executes — the orchestration loop, tool registry, message thread management, and step budget enforcement. Quality: judging what came out — rubric scoring, adversarial critics, guardrails, and regression tests that verify outputs before they reach users. Meta (AgentOps): improving over time — observability and tracing (OpenTelemetry, Langfuse, Phoenix), drift detection, cost accounting, and the evaluation-driven improvement loop that feeds quality signals back to Knowledge and Runtime. A team that has only built the Runtime is shipping a brittle, drifting system.

What is the minimum viable agent?

A minimum viable agent needs exactly three things: a model that supports tool use (Claude, GPT-4o, Gemini, Llama with tool-calling all qualify), at least one typed tool registered so the model can call it by schema, and a loop with a hard stopping condition. The loop reads the model output, checks whether it is a tool call or a final answer, executes the tool if needed, feeds the result back as context, and exits when the model returns a final answer or a budget limit (max steps, token cap, wall-clock timeout) is hit. Everything else — memory, multi-agent coordination, reflection, observability — layers on top of this core.

What are the main agent design patterns and when does each earn its overhead?

ReAct (Reason + Act): the model narrates reasoning before each tool call, improving debuggability and tool-selection reliability. Use it when you need an audit trail or when tool selection is ambiguous. Planner-executor split: one model creates a task decomposition, another executes each step. Earns its overhead when the task decomposes cleanly, the planner reduces scope creep, or subtasks can run in parallel. Reflection loop: the agent critiques its own output before returning. Earns its overhead when a second-pass review meaningfully reduces errors. Multi-agent role assignment (orchestrator + specialist agents): use only when a single agent's context reliably overflows, when subtasks are genuinely independent, or when isolation is required. Each pattern adds overhead; use the simplest one that solves the problem.

When should you use multi-agent vs single-agent?

Start single-agent. Add agents only when a single agent cannot hold the full task context (context overflow), when subtasks are genuinely independent and parallel execution meaningfully reduces latency, or when you need isolation — one agent's errors must not corrupt another's context. Multi-agent architectures multiply failure modes (cascading errors, message ordering bugs, silent stalls), increase cost per run, and make debugging exponentially harder. The correct guidance is to start with the minimum viable architecture and add agents only when a measurable requirement proves the simpler shape insufficient. Frameworks like CrewAI and AutoGen make multi-agent easy to set up, but the operational cost is real.

How do you budget agent iterations to prevent runaway loops?

Set three limits before the loop starts: (1) max steps — a hard cap on tool calls regardless of progress (typically 10-50 depending on task complexity); (2) token budget — a ceiling on total tokens used per run, both input and output; (3) wall-clock timeout — prevents runaway loops in async systems where the step counter alone is insufficient. When any limit is hit, return a partial result with a human-review flag rather than silently failing. Budget violations are the most common source of unexpected cost spikes in production. The stop condition is non-negotiable — an agent without one is a liability, not an asset.

Why do agents fail in production and what are the failure modes unique to agents?

Three production failure modes are not possible with a single-shot LLM call and arise only because of the agent loop: (1) runaway loop — only an agent can fail to stop; (2) hallucinated tool arguments — single-shot LLMs do not call tools mid-stream, but agents can repeatedly hallucinate tool names or argument values and compound errors; (3) trajectory drift — accumulating small errors across ten or twenty LLM calls produces a final output radically wrong even if each individual step looked plausible. Most production failures trace to missing guardrails: no step budget, no input validation on tool arguments, no output check after each step, and no observability to diagnose what went wrong. The model is rarely the root cause — the loop architecture is.

What observability tooling is standard for production agent systems?

Span-level tracing using OpenTelemetry GenAI semantic conventions is the standard. Each LLM call, tool invocation, and memory access emits a span capturing model name, input tokens, output tokens, tool arguments, tool results, and latency. A trace is the full record of one agent run. Langfuse, Phoenix (Arize), and W&B Weave all consume these traces and provide dashboards, replay, and annotation workflows. Cost accounting — tracking spend per run and per task type — should be built alongside tracing, not added later. All of this instrumentation must be in place before the first production user session.

What distinguishes a strong answer on agent architecture in an interview?

Strong candidates describe concrete patterns by name — ReAct, planner-executor split, reflection loop, multi-agent role assignment — and explain the cost, debuggability, and failure-mode trade-offs of each. They know the four layers (Knowledge / Runtime / Quality / Meta) and can map any component of a real system to the right layer. They can answer edge cases: what is the stop condition, what happens on tool error, what happens when the step budget is hit, how do you detect when the agent has drifted off-task. Weak candidates name-drop frameworks without understanding the loop semantics, describe agents as "smarter chatbots," and skip the engineering questions about bounding autonomy, handling partial failure, and proving the agent did the right thing at each step.

What are the most common agentic AI questions interviewers ask?

Questions cluster into six themes: (1) loop design — stopping condition, step and token budget, tool error handling; (2) single-agent vs multi-agent — when multi-agent earns its complexity and what failure modes it adds; (3) tool design — writing tool schemas the model calls reliably, validating arguments before execution; (4) planning patterns — when ReAct, planner-executor, or reflection earns its overhead; (5) observability — what spans to emit per tool call, how to debug a failed multi-step run; (6) safety and HITL — how to bound autonomy for high-stakes actions, when to route to a human reviewer. Expect at least one question from each cluster in a serious agent-engineering interview.

Related topics