Agentic AI Interview Questions

"In a plain call or a fixed chain, I decide the steps in code and the model only produces content. In an agent, the model decides the steps: it looks at the goal and the observations so far, picks a tool or an answer, sees the result, and repeats. That flexibility is the point and also the risk, so agentic systems need budgets, stop conditions and evaluation that workflows do not."

"ReAct interleaves reasoning and acting. The model writes a short thought about what it needs, issues an action such as a search or a database call, reads the observation, and then reasons again with that new information until it can answer. Today the same loop is implemented with native tool calling, so the action is a typed function call instead of text the developer has to parse."

"I give the model a list of tools, each with a name, a plain-language description and a schema for its arguments. When the model thinks a tool would help, it replies with a structured call, my code executes it and sends the result back as a tool message, and the model carries on from there. The model never runs anything itself; it only asks."

"I write the description as if for a new teammate: what it does, when to reach for it, when not to, and what comes back. I keep arguments minimal and typed, use enums instead of free strings, and avoid two tools that overlap because the model will pick the wrong one. Results are trimmed and structured, and errors say what to do next, like 'no results, try a broader query'."

"Simple agents plan step by step from what they just observed; more robust ones write an explicit plan first and then execute it, updating it as they learn. The failures I see most are the agent losing the original goal in a long context, retrying the same failing tool call, and claiming it is done without checking. So I keep the goal and a progress list pinned in the prompt and add a verification step before the final answer."

"I always start with one agent because it is the easiest to reason about and debug. I split into an orchestrator with specialist workers when I see accuracy drop as the tool list grows or as the context fills with irrelevant results, because each worker then gets a small tool set and a fresh context. The hand-off has to be explicit, with the orchestrator passing a clear task and receiving a structured result, or the system becomes harder to debug than the problem it solved."

"There is the context window, which is working memory and needs summarising as it fills. There is long-term memory, which is a store of facts and preferences outside the model that I retrieve into the prompt when relevant. And there is a record of past runs, which I keep as structured outcomes so the agent can learn what worked without re-reading whole transcripts. The important design rule is that memory writes need rules too, or the agent stores junk it later trusts."

"Every run gets a step limit, a token and cost budget and a timeout, enforced in my code, not in the prompt. I also detect repetition: if the agent issues the same tool call with the same arguments twice, I inject a note asking for a different approach, and stop after another repeat. When a limit is hit the agent returns what it has plus a clear reason, so the user or a human reviewer can continue."

"I classify actions by how reversible they are. Reading, searching and drafting need no approval. Anything that leaves the system, like sending an email, making a payment or changing production, pauses and shows a human exactly what will run with which arguments. The approval screen has to be fast, otherwise people click through without reading, which is worse than no gate."

"MCP is an open standard for connecting models to tools and data. A server publishes what it offers, tools with schemas, resources and prompt templates, and a client can discover and call them without custom glue. For agent teams it means an integration is built once and shared. I treat any external server as untrusted: its results can carry injected instructions and its tools get the minimum permissions."

"I build a set of tasks in a sandboxed environment with the real tools mocked or copied, and each task has a checker for the end state, not just the final message. Then I score the trajectory: right tools, no dangerous or wasted calls, steps and cost within budget. Because agent runs are non-deterministic I run each task several times and report a pass rate, and every prompt, tool or model change reruns the suite."

"Reflection means the agent reviews its own output against the goal before returning it, and revises. It pays off when there is something concrete to check, like running tests on generated code or verifying each claim against a source, because the critique is grounded. On open-ended writing it mostly adds latency and can make the answer worse, so I use it where a checker exists and measure whether it improves the pass rate."

"The page's text goes into the context, and the model cannot reliably tell instructions in data from instructions from me, so it may obey them, for example by calling a tool that sends data somewhere. I design assuming that will happen: the agent has only the tools it needs, credentials never sit in context, write actions need approval, and network egress is allow-listed. Then I log the origin of every tool call and keep known injection pages in the test suite."

"Agents retry a lot, on timeouts and on their own judgement, so every write tool takes an idempotency key derived from the run and the step, and the backend ignores duplicates. Where I can, I make actions two-phase, like creating a draft that a later step publishes, so a failed run leaves nothing harmful. For the few truly irreversible actions I log them as first-class events so they can be compensated."

"I model the agent as a state machine where the state is the message history, the plan and the results so far, and I persist it after every step. That means a crash or a deploy only loses the current step, and a human-approval pause is just a run waiting on an event. Graph-style agent frameworks and durable workflow engines give you this out of the box; if I roll my own, the rule is the same: the process must be able to die at any moment and pick up where it left off."

"If I can write the steps down, I should, because code is cheaper, faster and auditable. I reach for an agent only when the right sequence depends on intermediate results and the number of cases is too large to enumerate, like open-ended research or debugging. In practice most production systems are a fixed pipeline with one or two bounded agentic steps inside it, which gives flexibility where it is needed and predictability everywhere else."

"A tool never throws into the void; it returns a structured error with a short hint, like 'rate limited, wait' or 'not found, try a broader query', so the model can adapt. Transient failures are retried in my code with backoff and a cap, because the model is a bad retry scheduler. If a tool can return partial data, it says so explicitly, and the agent decides whether to continue or report what it has."

"I built an agent that triaged incoming support tickets by looking up the customer, reading recent orders and drafting a reply. The hardest bug was that it sometimes drafted refunds for the wrong order. The traces showed the order tool returned a list sorted by creation date and the model assumed the first item was the latest. I changed the tool to return the most recent order explicitly with a clear field name and added that case to the eval set, and the error disappeared."

"Guardrails are checks outside the model at three points. On the way in I screen user input and retrieved content. Around every tool call I validate the arguments and apply policy, like which domains can be fetched or how much can be spent. On the way out I check the answer for secrets, unsupported claims and unsafe content. The action layer is the one that matters most for agents, because that is where real-world harm happens."