TL;DR: An agent is a loop where a model decides which tool to call next, the tool runs, and the result goes back into the context. Unbounded iteration, unbounded cost and a model that can be talked into calling a tool by its own input are what make it operationally different from a service.
How to approach it
Describe the loop concretely, then derive the operational problems from it rather than listing them. Every difference (cost, latency, security, testing) comes from the same two properties: the number of steps is decided at run time, and part of the input comes from whatever the tools returned.
A strong answer
The loop is simple. You give the model a goal and a list of tools it may call, each with a described input schema. The model responds either with an answer or with a tool call. Your code executes that call, puts the result back into the conversation, and asks again. Repeat until the model returns an answer or you stop it.
Everything that makes this hard to operate follows from that.
The number of iterations is not known in advance. A normal request does a fixed amount of work. An agent might take two steps or forty, and forty steps against a frontier model is a large bill and a long wall-clock time for one user request. You need a hard iteration cap, a token budget per run, and a timeout, all enforced by your code rather than requested in the prompt. An agent that loops calling the same failing tool will keep doing it until something stops it, and the thing that stops it has to be you.
Cost is per request and highly variable. The whole conversation, including every tool result, is resent on each iteration, so context grows and cost grows superlinearly with steps. Budget alerts belong per run and per tenant, not just monthly, because a single runaway agent can spend a month's allowance overnight.
The tools are the blast radius. Whatever the agent can call, it can call wrongly. Read-only tools are cheap mistakes. A tool that opens pull requests, deletes records or moves money is a different risk class and needs its own treatment: scoped credentials per tool, a confirmation step for anything destructive, and an audit log of every call with its arguments.
Its input is not trustworthy, which is the security point that matters. The model reads tool results, and those results contain text from somewhere else: a web page, a ticket, an email, a document. Text in there can instruct the model. That is prompt injection, and the useful way to think about it is as a confused deputy: the agent holds your credentials and is being told what to do by whoever wrote the content it just read. The mitigation is not a better prompt. It is limiting what the tools can do, so a successful injection cannot cause an action that matters.
Testing is different. The same input does not produce the same sequence of steps, so assertion-based tests do not apply to the trajectory. You test the tools normally, and you evaluate the agent against a fixed set of scenarios scored on whether it reached an acceptable outcome, accepting a pass rate rather than a pass.
Observability has to cover the trajectory. A request log saying 200 in nine seconds tells you nothing. You need the full trace: every model call, every tool call with arguments and results, tokens and cost per step. Debugging an agent without that is guesswork, and it is the first thing to build rather than the last.
What interviewers probe next
"How do you stop a runaway loop?" A maximum iteration count, a token budget, a wall-clock timeout, and detection of repeated identical tool calls. All in your code, all non-negotiable.
"Where should the tool credentials come from?" Scoped per tool and ideally per user, so the agent acts with the permissions of whoever asked rather than with a service account that can do everything. That single choice bounds most of the damage.
"When is an agent the wrong answer?" When the sequence of steps is known. A fixed workflow calling a model at two points is cheaper, faster, testable and predictable. Reach for an agent when the path genuinely varies with the input.
Common mistakes
Running with no iteration cap or token budget, which is how a single request spends a large amount of money.
Treating prompt injection as a prompt engineering problem instead of bounding what the tools can do.
Giving the agent one broad credential, so every tool can do everything any tool can do.
Logging requests and responses without the intermediate steps, leaving no way to explain what it did.