AI agents: what you should actually be able to do before discussing them in interviews

What we mean by "agent" here

Industry vocabulary is not settled, and it would be dishonest to impose a definition. We use agentic system to mean a system that uses a model to decide or orchestrate some of its steps from an objective, relying on tools and within a set of constraints. How much decision is left to the model varies enormously between systems: that share is exactly what sets the difficulty.

What follows neither defends nor disputes the value of agents. The angle is professional: which skills separate someone able to design an agentic system users can rely on from someone able to demo one? The gap is clear, and it shows in interviews as soon as the conversation turns to failures.

Deterministic workflow versus agentic behaviour

Many systems presented as agentic are fixed sequences where a model steps in at a few precise points: extracting information, drafting, classifying. The flow is decided by code. That is often the right call, and saying so is not a lack of ambition: a fixed sequence is far easier to test, replay, fix and supervise.

Agentic behaviour starts where the model chooses what comes next: which tool to call, with which arguments, how many times, when to stop. You gain coverage of unforeseen cases and lose predictability. A core skill is placing that boundary deliberately, step by step, instead of letting it settle by default.

Tool calling: the real contract between model and system

Getting a model to call a function is simple. Designing a tool that stays safe when called at the wrong moment, with approximate arguments, twice in a row or in parallel, is much less so. The quality of an agentic system rests largely on the quality of its tools.

• Scope: one tool doing one thing, with a description that also says when not to use it.
• Validation: arguments produced by a model are untrusted input; validate them like any external input.
• Effects: explicitly separate read tools from tools that change something. Those are two different risk regimes.
• Returns: give back errors the model can act on, rather than a raw exception or an empty message that leaves it looping.
• Budgets: bound the number of calls, the depth and the total duration, independently of what the model decides.

State, context and orchestration

An agent chaining steps accumulates information, and the accumulation itself becomes a problem: growing context, stale information that lingers, early decisions no longer visible at the end. You have to decide what is kept, in what summarised form, what is reinjected at each step, and what belongs in external storage rather than in the context.

On orchestration, the concrete questions are: is the flow sequential or parallel, who decides to stop, what happens when a step returns a partial result, and how do you resume an interrupted run without starting over. A system that cannot resume is a system you rerun in full after every incident, with the cost that implies.

Consequential actions, permissions and human validation

A wrong answer can be corrected. An email sent, a refund triggered, a ticket closed, a record updated in a business system cannot be corrected the same way. As soon as the system acts, design changes nature: it is no longer only a quality question, it is an accountability question.

• Permissions: whose rights does the agent act with? They should be the rights of the user concerned, not a technical account with broad powers.
• Human validation: placed where the cost of an error exceeds the cost of waiting. Validation on everything ends up being approved without being read.
• Reversibility: prefer actions that can be undone, or plan explicitly how to compensate one that cannot.
• Idempotence: when an action is replayed after a network incident or a retry, the system must recognise it was already performed. A classic engineering point, often missing from prototypes.
• Audit log: keep who asked for what, which actions ran, with which arguments and which outcome.

Human validation only helps if the person has what they need to decide: what the agent is about to do, what it is basing that on, and what happens if they refuse. A context-free "Confirm?" dialog protects nothing.

Retries, timeouts, partial failures

An agentic system calls several services, at least one of them a model with variable response time. Failures are not exceptional, they are ordinary. Three behaviours immediately separate a prototype from something operable.

1. 1

   Bound time and attempts

   1

   A timeout per tool call and a global run budget. An unbounded agent eventually loops, costs money and blocks a waiting user. The number of attempts depends on the error type: retrying a temporary outage makes sense, retrying a validation error does not.

2. 2

   Handle partial failure

   2

   Three steps out of five succeeded and the fourth fails: the system must know whether it continues, stops, rolls back what was done, or returns a clearly flagged incomplete result. That is as much a product decision as a technical one, and it is what is most often missing.

3. 3

   Make failure legible

   3

   To the user: what was done, what was not, what they can do next. To the team: a full trace allowing the case to be replayed. A system that fails cleanly is more usable than one that succeeds slightly more often and fails silently.

Evaluation and observability

Evaluating an agent is harder than evaluating a single answer, because the outcome depends on a path. Two apparently identical runs can take different paths. So you evaluate both the final result and the trajectory: were the right tools called, in an acceptable order, without costly unnecessary calls?

• Replayable case sets, including known failure cases and ambiguous inputs, not only the happy path.
• Per-run traces: steps, tools called, arguments, durations, costs, stopping decision.
• Operational indicators: completion rate, human intervention rate, average and worst-case cost per run, duration distribution.
• Drift detection after a model change, a tool version bump or an instruction edit: without replay, those regressions are discovered in production.

Impressive demo versus recoverable system

The comparison below is not about technical difficulty but operability. The second system is less spectacular; it is the one a team can put in users' hands.

The limits of autonomy, and naming them

The more latitude the model has, the higher the variance, the harder cost per run is to predict and the harder diagnosis becomes. That is not a reason to avoid it, it is a reason to dose it. Being able to say "I would not have given the model that freedom here, because the case is stable and verifying costs more than coding it" signals professional maturity.

On security, the agent-specific point is that uncontrolled text — a retrieved document, a web page, a user message — can end up being read as an instruction. A system that acts must therefore treat all external content as data, constrain what tools permit, and never make an authorisation depend on the model's judgement alone.

MCP can be used to expose tools to an agentic system in a uniform way. It is one possible building block among others, worth knowing, but it replaces none of the questions above: tool scope, permissions, validation, resumption and observability remain yours to handle.

How this plays out in interviews

The questions that separate candidates are rarely "can you do tool calling". They look more like: what happens if the tool errors on the third call? how do you prevent an action from running twice? how do you learn your agent was wrong without a user telling you? what does a run cost, at worst?

If your experience stops at a prototype, present it as one and move on to what you would add before handing it to users. That is a strong answer. Claiming production experience you do not have gets caught on the second question.

• Agents
• Evaluation
• Production