AI Agent Interview Essentials: Core Concepts, Four Components, and Planning Patterns Explained

What Is an AI Agent: The Fundamental Question Every Interviewer Asks

In interviews for AI-related roles, "How do you understand Agents?" is almost always on the list. Many candidates make the mistake of equating Agents with large language models (LLMs) — that's a classic misconception. An Agent is not the model itself. It's an AI execution system that uses an LLM as its control core and autonomously drives toward a goal.

Two key points here: first, it relies on an LLM for decision-making; second, it operates autonomously — capable of breaking down complex tasks, planning execution paths, and ultimately delivering results the user is satisfied with.

The fundamental difference between an Agent and traditional Q&A AI isn't that it "answers better" — it's that the entire working model has changed. Traditional Q&A systems are passively reactive: you ask a question, it gives an answer, each exchange relatively independent. An Agent, by contrast, is continuously decomposing tasks, calling tools, and maintaining state under goal-driven conditions, converging on a result through multiple iterations.

An Agent's essence, therefore, is not a single inference pass — it's a running loop of decide → act → observe → decide again. Internalize this loop, and you've grasped the core concept for any interview.

Component 1: The LLM Is the Agent's Brain

An Agent's core components can be grouped into four parts: the large language model, tools, memory systems, and planning capabilities. All four are essential.

The LLM is the decision-making hub of the entire system. User instructions, tool return values, memory retrieval results, and current task state all flow into the LLM, which then determines the next action — whether to continue reasoning, call a tool, request more information from the user (i.e., human-in-the-loop), or output a final answer. Without an LLM making unified decisions, the other components are just isolated capability modules.

In practice, model selection comes down to several key dimensions:

• System Prompt: Defines the Agent's role, behavioral boundaries, output format, and constraints — essentially the instruction manual for the entire Agent.
• Model reasoning capability: Significant differences exist across models. Under identical prompts, a stronger reasoning model performs better at task decomposition, tool selection, and error recovery. That said, for most day-to-day development work, general-purpose models like GPT, DeepSeek^Ad, or Zhipu GLM are capable enough — there's no need to chase the highest-performance option, especially since higher performance means higher token costs.
• Tool-calling reliability: The key here is structured output capability. Format errors or malformed parameters lead to failed calls, retries, and wasted tokens.
• Context window: Every tool result and intermediate state gets added to the context. On complex, multi-step tasks, the window fills up quickly.

Model selection isn't about spending more — it's about striking the right balance between reasoning capability, latency, cost, and context capacity.

Component 2: Tools Are the Agent's Interface to the External World

Tools are the easiest of the four components to understand. An LLM is, at its core, a language processor — it can't browse the web, read files, execute code, or operate business systems on its own. It can draft the content of an email, but it can't actually send it.

Tools are the Agent's only channel for taking real-world actions and sensing external feedback. Anything that can be wrapped in a function can become a tool — if you've used a framework like LangChain, you'll know that defining a tool looks almost identical to defining a regular function, with just an annotation added.

Search engines, database queries, code executors, email senders — all of these can be packaged as tools. Going further, today's popular concepts like Skills, external MCP services, and Hooks in Claude Code are all just different forms of tools. What they share: they give the Agent an interface to interact with the outside world. Tools are precisely what allow an Agent to break through the model's inherent limitations, and through tool return values, understand the real-world effect of its actions.

MCP (Model Context Protocol) is an open protocol released by Anthropic in late 2024, designed to standardize how AI models connect to external tools and data sources. Before MCP, every Agent framework had its own conventions for defining tools, making cross-framework reuse difficult. MCP provides a unified server-client architecture: tool providers publish their capabilities as "MCP Servers," and any MCP-compatible Agent application can call them directly — essentially creating a "USB standard interface" for the AI tool ecosystem. Claude, Cursor, and other mainstream products now support MCP natively, and a large number of open-source MCP Servers have emerged covering file systems, browser control, database operations, and more, dramatically reducing the development cost of integrating external capabilities into Agents.

Component 3: Memory Systems Maintain State and Cross-Task Continuity

Memory addresses the "amnesia" problem in Agent execution, and is typically divided into short-term memory and long-term memory.

Short-Term Memory

Short-term memory refers to the context of the current task or conversation — it stores intermediate state, tool results, and the basis for decisions. For example, if you ask an Agent to help build a system across multiple conversation turns, that dialogue must be preserved; otherwise, the Agent can't continue building on previous steps.

The core tension in short-term memory is this: complex tasks generate large amounts of intermediate information, but the context window is finite. You have to balance "remembering enough" with "not overflowing." Common strategies include compression, summarization, sliding windows, and external offloading.

To be concrete: compression reduces the overall size; summarization condenses 100 words down to 10, keeping only key points; a sliding window retains only the last N conversation turns; external offloading moves some information outside of memory entirely. But all of these strategies result in some degree of memory loss, which in turn affects subsequent execution. Anyone who's used Claude Code or Codex has likely hit the context limit and needed to apply summarization — the strategies and trade-offs behind that are genuinely important.

Long-Term Memory

Long-term memory preserves information across sessions and tasks. The most common implementation is vector database + Embedding vectorization + semantic retrieval. A complete long-term memory system often also requires structured storage, graph databases, metadata filtering, write strategies, and conflict resolution mechanisms.

The design challenge in long-term memory is: what information is worth persisting, and what should be discarded? Storing too much introduces noise and degrades retrieval precision; storing too little defeats the purpose. A more sensible approach is to evaluate importance before writing, retaining only information that genuinely affects future decisions.

Embeddings and vector databases form the technical foundation of long-term memory and deserve a brief explanation. Embedding is the process of converting text into high-dimensional numerical vectors, where semantically similar texts are closer together in vector space. Vector databases (such as Pinecone, Weaviate, and Chroma) are purpose-built to store and retrieve these vectors, enabling "semantic retrieval" — finding relevant memory fragments based on meaning rather than keyword matching. For instance, if an Agent previously handled a task where "the user prefers dark themes," the next time it works on a UI-related task, semantic retrieval will automatically surface that memory — even if the user never mentions it again. This is fundamentally different from traditional database queries by exact field match, and it's the core mechanism enabling Agents to maintain cross-session memory.

Component 4: Planning Capability Determines Whether an Agent Can Handle Complex Tasks

Planning is the ability to decompose complex goals into executable steps, and it fundamentally depends on the LLM's reasoning capability.

Common planning approaches include:

• CoT (Chain of Thought): Prompts the model to explicitly write out its reasoning steps. Since LLMs generate token by token, intermediate reasoning becomes context for subsequent generation, reducing logical leaps or breaks. Think of it as splitting a complex task into ten steps and executing each one in order, without skipping intermediate stages.
• ToT (Tree of Thought): Branches out multiple candidate paths at reasoning nodes, evaluates the quality of each, and continues along the best one. Well-suited for high-uncertainty tasks that require multi-path exploration.
• Thought graphs are less commonly used — awareness is sufficient.

In production environments, planning modules primarily follow two patterns:

ReAct pattern: Each step re-evaluates the next action based on current observations — no complete plan is made in advance; it's one step at a time. The advantage is flexibility; the downside is that it can get stuck in local optima and lose sight of the ultimate goal.

Plan and Execute pattern: The LLM first generates a complete list of steps, then executes them in order. The advantage is clear structure and ease of review; the downside is that when intermediate results deviate from expectations, the original plan may become invalid.

In real engineering practice, the two are often combined: generate a rough plan first to establish a direction, then dynamically adjust based on feedback during execution.

The ReAct pattern takes its name from the combination of "Reasoning + Acting," popularized by a paper of the same name from Princeton University in 2022. The core idea is to interleave Thought, Action, and Observation in the context, so the model can see its own reasoning process and the previous tool results at every step — enabling more grounded decisions for the next action. This "think while doing, do while thinking" approach mirrors how humans tackle unfamiliar tasks, and it's the most common default planning strategy in open-source Agent frameworks like LangChain and LlamaIndex. Its limitation is a lack of global perspective: when a task requires coordinating multiple interdependent sub-goals, it tends to exhibit short-sighted, "heads-down" behavior.

Interview Summary: How to Explain an Agent in One Sentence

An Agent is fundamentally an execution system that uses an LLM as its decision-making core, combines tools, memory, and planning capabilities, and can autonomously decompose and accomplish complex goals. Understanding it comes down to three key characteristics:

1. Autonomy: The LLM independently performs reasoning and task planning;
2. Action: It interacts with the external world through tools to complete concrete tasks;
3. Multi-step iteration: It doesn't return a result after a single inference pass — it converges on a goal through multiple iterative loops.

Also keep in mind a few real-world constraints: context window limits, tool reliability, token cost, and latency.

One closing thought: An Agent is not a smarter model — it's a decision-and-execution system that runs continuously toward a goal. Articulate these points clearly in an interview, and you'll walk away with a satisfied interviewer.