Agent failures are not random. They come in a small number of recognisable shapes, and each shape has a control that catches it. The reason teams get surprised is that they instrument for the wrong one: general accuracy metrics catch confidently wrong answers and catch almost nothing else on this list.
Here is the catalogue, each failure paired with what actually detects it.
The six failure modes at a glance
| Failure mode | What it looks like | The control that catches it |
|---|---|---|
| Looping | Same tool, same parameters, same result, repeatedly | Compare consecutive observations; end the run on a repeat |
| Tool misuse | A granted tool called with wrong or invented parameters | Parameter validation at the tool boundary, plus a granted-tool catalogue |
| Stale context | Acting in step five on what was read in step one | Re-read immediately before any write |
| Silent partial completion | Two of three sub-tasks done, run reports success | Distinct exit reasons and per-step observation storage |
| Confident wrong answer | Fluent, plausible, incorrect | Grounding in live records; a null confidence rather than a default |
| Runaway cost | Steps per run drifting upward across a fleet | Cost per completed goal, plus per-run token and step ceilings |
Looping
An agent loops when its reasoning returns to a state it has already been in. It calls the same tool with the same parameters, gets the same answer, and concludes that it should try again, often with a slightly different rationalisation each time, which is why reading the trace makes it look like progress.
The control is cheaper than most people expect: compare each observation with the previous one. Two identical results in a row means the agent is not learning anything from its tools, and the run should end. Oneop’s AI agents do exactly this, ending a run as no progress on two identical consecutive observations, underneath a step ceiling of six by default with a hard cap of twelve.
The distinction between those two mechanisms is worth understanding. The step ceiling is a budget backstop: it stops the loop eventually, after you have paid for it. Observation comparison is a detector: it stops the loop at the moment the loop becomes evident. You want both, and you want the detector to fire first.
Tool misuse
Tool misuse is an agent calling a tool it holds, with parameters that are wrong, malformed or invented. The agent believed the parameter existed, or hallucinated an identifier, or passed a value of the right type and the wrong meaning.
Two controls, layered. First, a fixed tool catalogue with a granted subset per agent: a tool the model names that was not granted is refused rather than improvised. That converts an entire class of failure into an immediate, visible refusal. Second, validation at the tool boundary: the tool itself rejects parameters that do not resolve, rather than the model being trusted to produce good ones.
The design principle: an agent asking for a capability it does not have should produce a boring refusal, not an error, and definitely not an approximation.
Stale context
A run takes time. An agent reads an invoice in step one, reasons through steps two to four, and writes in step five. Everything it believes is a snapshot taken at step one, and the world moved.
This is the failure mode that punishes architectures where the AI reads a synced copy of your data rather than the records themselves. A nightly sync makes every agent decision up to twenty-four hours stale by construction. Reading live records narrows the window from hours to seconds, which is most of the benefit. Oneop agents query the same invoices, deals, tickets and stock rows staff have open, in the same workspace, rather than an API copy. The argument for that architecture is set out in the AI agent system of record.
Narrowing is not closing. The remaining control is re-reading immediately before a write: check the state you are about to change at the moment you change it, not at the moment you decided to.
Silent partial completion
The worst one, because it generates no signal. The agent is asked to do three things, does two, and ends the run reporting success. Nothing errored. The trace looks fine to a skim. The third thing surfaces a week later when something downstream needs it.
Two controls. First, distinct exit reasons rather than a success boolean. Oneop stores nine, including out of steps, out of tokens, out of time, no progress and tool error, so a run that stopped because it ran out of room is not filed alongside one that finished. Second, storing the observation from every step, so completion can be verified against what tools actually returned rather than against the agent’s own closing summary.
That second point is the general rule for this entire list: never let the agent’s account of itself be the record. An agent’s summary is generated by the same process that made the mistake.
Confident wrong answers
The failure everybody knows about, and the one where controls are weakest, because fluency and correctness are produced by the same machinery.
Grounding is the main lever: an agent answering from live records is wrong less often than one answering from training data, and it is wrong in ways that are traceable to a record you can inspect. The complementary control is a hard rule about empty results. When a read finds nothing, the agent must be told there is nothing on file, not left with an absence to fill. That single behaviour is the difference between an agent reporting an empty pipeline and one describing an imaginary deal.
Be sceptical of confidence scores as a control. A score attached to a run is the model’s own assessment of its answer; it is useful for sorting a review queue and it is not a calibrated probability. The honest implementation stores null when no scoring pass produced a value rather than defaulting to something plausible, which is what Oneop does. A simulated run stores no confidence at all rather than a flattering number.
Runaway cost
Runaway cost is rarely one dramatic incident. It is drift: steps per run creeping up across a fleet, each run individually unremarkable, the monthly total quietly doubling.
Per-run ceilings bound the worst case: a token budget, a wall clock, a step cap. What catches the drift is the ratio: cost per completed goal, not cost per run. A fleet whose cost per run is flat while its completion rate falls is getting more expensive at the thing you wanted, and only the ratio shows it.
Two implementation details make cost controls trustworthy rather than decorative. A reservation should be taken before the call and must fit what is left, so four credits remaining and a five-credit action means the action does not start rather than starting and stopping mid-run. And a call the provider never completed should be refunded, with the reservation released, so you pay for answers rather than attempts. Both behaviours are described on AI governance, along with the credit weights per kind of work and an honest note that an action the platform has not classified is charged at the heavier rate rather than the lighter one.
The failure case: three controls, one incident, none of them fired
A reorder-planning agent reads stock levels, works out what needs reordering, and drafts purchase orders. It has a step ceiling, an action ceiling and a cost alert. All three are correctly configured.
A supplier’s product codes change. The stock read still succeeds (the rows are there), but the agent’s matching logic now finds no supplier for half the items. It reasons that those items have no supplier on file, skips them, drafts purchase orders for the rest, and ends the run at goal reached in three steps. Under the step ceiling. Under the action ceiling. Cheaper than usual, so the cost alert reads as an improvement.
Three weeks later, half the catalogue is out of stock.
Every control worked as designed and none of them was a detector for this failure, because this is silent partial completion and the three controls installed were all bounds. Bounds stop runaway behaviour. They say nothing about work that quietly did not happen. What would have caught it is a check on the observation content — items examined versus purchase orders drafted, as a ratio, alerting when the gap moves — which is a detector rather than a bound, and belongs in the operator view described in AI agent observability.
The argument
Most agent reliability work goes into making failures less frequent. That is the lower-value half. Frequency is a property of the model and it improves on someone else’s schedule; what happens when a failure occurs is a property of your system, and it is the half you control.
So the question to ask of any agent deployment is not “how often is it wrong?” It is: for each of the six modes above, name the mechanism that detects it and what that mechanism does next. If the answer for any row is a prompt instruction, that row is uncontrolled. The input-side half of this, covering what reaches the model in the first place, is in AI agent guardrails.