Agentic AI Interview Questions (2026)

A plain call is one shot: prompt in, text out, done. It's agentic when the model gets to decide what to do next in a loop — it can call tools, look at the results, and choose the following step, until it decides it's finished. So the real ingredients are autonomy over control flow plus the ability to take actions in the world. A model that answers a question isn't an agent. A model that says "I need to search, then read this file, then compute, then answer" and drives that itself — that's an agent.

The model reasons about what to do, takes an action (usually a tool call), observes the result, and feeds that observation back in to reason again — reason, act, observe, repeat, until it has an answer. ReAct just means interleaving the thinking and the doing instead of planning everything upfront. The observation step is the whole point: the agent isn't guessing blind, it's reacting to real results. And you always need a stop condition — a final-answer signal or a step limit — or it never gets off the loop.

Most of the time, honestly. If the task is a fixed sequence you already know — fetch, transform, respond — that's a pipeline, and a pipeline is cheaper, faster, and easier to debug than letting a model improvise. You reach for an agent when the path genuinely can't be hardcoded: the number of steps depends on what you find along the way, or the tool choice depends on the input. My rule of thumb: if you can draw the flowchart, code the flowchart. Only when you can't draw it does the agent earn its cost.

You give the model a list of tools, each with a name, a description, and a schema for its arguments. The model doesn't run anything — it emits a structured request that says "call this tool with these arguments." Your code executes it, then hands the result back so the model can continue. So the model is a planner that picks tools and fills in arguments; your runtime is the thing that actually does the I/O. The description matters more than people expect — a vague tool description is the number one reason the model calls the wrong tool or skips it entirely.

Feed the error back as an observation and let the agent react — that's the strength of the loop. A good agent reads "404, not found" and tries a different query instead of blindly retrying the same failing call. In my code I make tool errors explicit and readable rather than swallowing them, cap the number of retries so a flaky tool can't burn the whole budget, and give the agent a graceful exit — "if you can't complete this, say so" — so a broken tool degrades to an honest "I couldn't" instead of a confident hallucination.

Short-term memory is the context window: the running transcript of this task — what the agent's done, what tools returned so far. It's automatic but bounded, and it fills up on long tasks. Long-term memory is anything that survives across sessions — usually facts written out to a store (often a vector store) and retrieved when relevant, so the agent "remembers" a user's preferences next week. The trap is dumping everything into the context; a long transcript both blows the window and dilutes the model's attention. So real memory work is mostly about summarising and pruning the short-term trail and being selective about what you promote to long-term.

Hard limits first: a max-steps cap and a token or dollar budget per run, so a stuck agent fails loudly instead of spending your money. Then loop detection — if the agent's repeating the same action with the same arguments, break out, because it's not making progress. I also prefer smaller, well-scoped tools over one giant do-everything tool, because ambiguity is what sends agents into circles. And I log every step, so when a run costs ten times what it should, I can actually see where it went wrong instead of guessing.

It's worth it when the work genuinely splits into specialised roles with different tools or context — a researcher, a coder, a reviewer — and a single agent's context would get muddy juggling all of it. It's over-engineering the moment you add agents for tidiness rather than need. Every handoff between agents is a place for the message to get garbled and for cost to multiply, and multi-agent systems are brutal to debug because the failure is spread across a conversation. My honest default: start with one agent and good tools, and only split when one agent visibly can't hold the job.

MCP, the Model Context Protocol, is a standard way to plug tools and data sources into an agent — think of it as a universal adapter, so you don't hand-write a custom integration for every tool. A2A, agent-to-agent, is about agents talking to each other: a standard for one agent to hand a task to another, even if a different team built it. Rough split: MCP connects an agent to its tools, A2A connects agents to other agents. I go deeper on where each fits in LangGraph vs MCP, since people constantly mix up the orchestration layer with the tool-connection layer.

LangGraph is orchestration — it models your agent as a graph of nodes and edges instead of a free-for-all while-loop. That buys you explicit control over the flow: you decide which step can go where, you can loop deliberately, add human-in-the-loop checkpoints, and persist state so a run can pause and resume. The reason people like it for anything real is exactly that control — a bare ReAct loop is fine for a demo, but when you need a specific step to always run before another, or an approval gate in the middle, a graph makes that legible instead of buried in prompt hope.

Three big ones. Loops — the agent gets stuck repeating a step and never converges. Tool errors — a tool returns something unexpected and the agent either crashes or confidently makes something up. And cost blowups — a task that should take three steps takes thirty, and the bill scales with it. Under all three is the same root cause: the agent has autonomy but no guardrails. So the fixes are guardrails — step caps, budgets, loop detection, explicit error handling, and logging every step so you can actually diagnose the run afterward.

Two levels. Final outcome: did the agent actually accomplish the task — build a set of tasks with checkable success criteria and measure the pass rate, not vibes. But the harder, more revealing part is the trajectory: did it take a sane path? An agent can stumble to the right answer after twelve wasteful steps and two wrong tool calls, and that's not a system you want in production. So I score the path too — did it pick the right tools, in a reasonable number of steps, without looping — often with an LLM-as-judge over the logged trace. Evals plus cost-per-task is how you turn "it works" into a number you can move.