Agentic AI Interview Questions

I draw the line at two things: a persistent decision loop and self-directed tool use. A chatbot responds; it does not loop back to check whether its response worked. A workflow runs steps in a fixed sequence; it does not decide mid-run to call a different tool because the first one failed. An agent perceives, decides, acts, and re-evaluates: it chooses which tools to invoke and in what order based on what it just learned. The tools do not have to change the world: a deep-research agent that only reads is still an agent, because it directs its own search. Consequential side effects do not define agenthood, they raise its stakes: the moment actions become irreversible, guardrails and approval gates get serious. Autonomy defines, consequence escalates.

When I send a request that includes tool definitions, the model does not call anything directly. It returns a structured response containing a tool invocation: the tool name and the arguments it wants to pass. My code intercepts that, runs the actual function, and sends the result back as a new message in the conversation. The model then continues with that result in context. The loop can repeat: the model can call another tool, or it can produce a final text response. The key mental model is that the model is always just outputting text; the JSON-structured output that represents a tool call is a convention the API layer interprets, not real code execution by the model. My orchestrator is the one doing the work.

The honest answer is: most of the time, you do not. A single well-prompted agent with access to the right tools handles the majority of tasks that developers reflexively reach for a multi-agent architecture to solve. I add agents when three things are true: the work can be parallelized across independent subtasks, the context window would blow out if I kept everything in one agent, or I need genuine specialization where different parts of the task require meaningfully different system prompts and tool sets. The classic mistake is building a multi-agent pipeline because it looks impressive in a demo. If a single agent with a loop covers the use case, that is the right answer.

An agent's primary working memory is its context window, and that window is finite. In a long loop, every tool call result, every observation, every prior step gets appended to the context, and eventually the request hits the window limit, or the harness truncates or compacts older turns, and either way the model loses access to early material. The agent is not losing memory in a philosophical sense; it is running out of space for it. The fixes sit at a few levels. First, context compaction: periodically summarize older turns into a compact representation and replace the raw transcript with the summary. Second, pruning: not all content is equal, drop tool results that are no longer relevant, keep conclusions rather than raw data. Third, external memory: write important facts to a file or database and retrieve them on demand rather than keeping them live in context. The framing I use is that context is expensive, hot working memory, and external stores are cheap, cold storage. Design accordingly.

Before I ship any change, I run the new version against a frozen eval set of tasks where I already know the expected outcome, then compare the task completion rate and any step-level accuracy scores to the baseline. If both go up and no previously-passing case regresses, I have evidence of improvement. If only one goes up, I investigate whether the change traded off precision for recall on subtasks. The eval set is the key artifact: without a fixed reference point, every change feels like progress because you are always checking the cases you expect to work. I add new cases to the eval set whenever a failure surfaces in production, so the bar keeps rising with the system.

The most dangerous actions share two properties: they are irreversible and they have large blast radius. Think bulk emails sent to a million users, records deleted from a production database, financial transactions executed, or a cloud account drained on compute spend. The failure mode is almost always the same: someone assumed the prompt-level instruction was enough of a guardrail. The real answer has three layers. First, architectural constraints: give the agent tools that physically cannot perform dangerous operations unless that capability is explicitly unlocked. A read-only database connector cannot delete rows no matter what the model decides. Second, hard gates on irreversible, high-impact actions: any tool call above a defined risk threshold requires a human confirmation step before execution, with a timeout that defaults to abort, not proceed. Third, kill switches at the infrastructure layer: if the agent breaches a spend threshold, action rate limit, or time budget, the orchestration layer shuts it down before a human has to act. The pattern I return to is: design each guardrail to work even if every other guardrail has already failed.