Original practice question. The scoring rubric is our teaching guide. How we research and score answers
TL;DR: Find out why it loops before capping it: read the expensive traces and classify the causes (unhelpful tool errors, ambiguous goals, missing stop conditions, a tool that never returns what the agent expects). Fix the causes, then add hard budgets on steps, tokens, cost and time, detect repeated actions, and design a clean outcome when a budget is hit.
How to approach it
Ask how often it happens and what share of total cost these runs account for. Long-tailed cost is typical: a few percent of runs can be a large share of spend. Then say you will read traces before changing anything, because a cap without a diagnosis hides the problem and leaves users with failed tasks.
A strong answer
Step 1: read the expensive runs. Pull the 50 most expensive tasks from last week and read the traces. Loops in agents usually come from a short list of causes:
| Cause | What the trace shows | Fix |
|---|---|---|
| Unhelpful tool errors | Tool returns "Error 400" with no detail; the agent retries the same call | Return actionable error messages ("date must be YYYY-MM-DD") |
| Missing stop condition | Agent keeps searching for a "better" answer | Define what done looks like in the instructions; add a completion check |
| Ambiguous goal | Agent explores many interpretations | Ask the user a clarifying question early |
| Tool mismatch | Agent needs data no tool provides and keeps trying | Add the tool, or detect the gap and hand off |
| Growing context | Each step resends the whole history; cost per step climbs | Summarise history, cap context |
Often one or two causes explain most of the cost. Fixing an unhelpful error message can remove a whole class of loops in an afternoon. Anthropic's guidance on writing tools for agents (September 2025) makes the same recommendation: write error responses that communicate "specific and actionable improvements, rather than opaque error codes", and cap how much a single tool can return (its own default is 25,000 tokens per response) so one call cannot flood the context.
Step 2: add budgets, enforced outside the model. The model should not be the thing deciding whether it has spent too much. The orchestration code enforces:
- A maximum number of steps per task (say 15 for a task that normally takes 5).
- A token and cost ceiling per task (say 10 times the median cost).
- A wall-clock timeout.
- Repeated-action detection: the same tool with the same arguments three times in a row stops the run.
- Retry limits per tool and per failure type: retrying a timeout makes sense, retrying a permission error does not.
Check what your framework actually enforces, because the built-in controls differ. OpenAI's Agents SDK raises an exception when a run exceeds max_turns (running agents), a hard stop on steps. Anthropic's task budgets are, in its own words, "a soft hint, not a hard cap" that the model is told about, and its Agent SDK's max_budget_usd is an estimate that "can pass this value, so leave headroom" (task budgets and SDK reference, checked November 2026). A soft budget shapes behaviour; a hard ceiling still belongs in your own orchestration code. Anthropic's docs suggest setting budgets from the p99 of per-task token spend, which is the same tail this answer starts from.
Step 3: design what happens at the limit. A budget hit should never look like a crash. The agent stops, summarises what it did and what it could not finish, and either asks the user for what it needs or hands off to a person with the trace. A user who gets "I found three of the four documents; I couldn't access the 2023 contract, here is what I have" has a partial result and a clear next step.
Step 4: make it measurable. Add cost per task and steps per task to the dashboard, with the 95th and 99th percentiles, not only the median. Set an objective: for example, p99 cost per task under $1. Run every fix through the eval set to confirm the task success rate held.
The economics are worth showing. If 3% of runs cost $4 and the rest cost $0.20, the average is about $0.31, and the runaway 3% account for nearly 40% of spend. Fixing the causes and capping the tail brings the average close to $0.20 and makes the cost predictable enough to price.
What interviewers probe next
"Won't hard caps make the agent fail tasks it could have finished?" Some, which is why caps sit well above normal usage and why hitting one triggers a useful handoff. Track tasks stopped by the cap; if many were close to done, raise it for that task type.
"Who sets the budgets?" Product, from the economics: what the task is worth and what the price allows. Engineering implements them.
"Can't we just tell the model its budget in the prompt?" Telling it helps it plan, and some providers now support exactly that. It is not enforcement: a budget the model can read is a budget the model can overrun.
How it's scored
| Signal | Weak | Hire | Strong Hire |
|---|---|---|---|
| Diagnosis | Caps steps immediately | Reads traces | Classifies loop causes from expensive traces and fixes the dominant ones |
| Controls | One limit | Step and cost limits | Step, token, cost and time budgets enforced outside the model, plus repeat detection and per-failure retry rules |
| Product | Task just fails | Error message | Graceful stop with summary and handoff, tail percentiles on the dashboard, cost objective tied to pricing |
Common mistakes
Asking the model to monitor its own spending.
Capping without fixing causes, so users hit the cap constantly.
Watching average cost per task while the tail drives the bill.