Concept 6 of 7

AI Agent Failure Modes: Loops, Duplicate Actions and Plan Drift

2 questions test this

AI agents can fail through repeated work, invalid tool requests, duplicate effects, goal drift and misinterpreted tool results. These failures arise from the interaction between model decisions and ordinary distributed system behaviour.

The final answer may conceal the problem. An agent can report success after a failed lookup or send the same message twice before producing a reasonable summary.

Bound runaway loops and nested work

Repeated calls with unchanged inputs and no new information are a common sign of a loop. Set iteration, time and resource limits in application code, and record why a run stopped.

Nested agents must share the parent allowance or receive explicit allocations from it. A parent limited to 60,000 tokens has not enforced that limit if three children each receive a separate 60,000 token allowance.

Detect repeated failures while permitting legitimate polling or changed state checks. A repeat detector should consider the operation, arguments and relevant state.

Reject invalid calls before they reach a service

Validate tool names against a registry and arguments against a schema. Then check existence, ownership and permitted state transitions.

A regular expression can establish that an identifier has the right shape. It cannot establish that the record exists or belongs to the requester.

Return a specific error so the agent can clarify a missing value or stop when access is denied. Do not encourage repeated guesses at identifiers.

Prevent duplicate effects with durable operation identity

A timeout creates uncertainty because the action may have completed even though the caller received no result. Blind retry can therefore issue a second refund or send a second message.

Use an operation ID created for the intended business action and preserve it across retries, restarts and resumes. The downstream service or a transactional execution layer must atomically recognise that identity and return the prior result when appropriate.

A local “check then execute” cache can race under concurrency. A hash of tool name and arguments can also suppress a legitimate later action with identical values. The identity must reflect intent, with clear rules for mismatched parameters and expiry.

AWS discusses these design issues in Making retries safe with idempotent APIs. The relevant guarantee belongs at the side effect boundary, where the action is committed.

Keep the original goal and completion test available

Plan drift occurs when intermediate work becomes the objective. An agent investigating an invoice may spend the run exploring unrelated account history.

Store the goal, constraints and completion conditions in explicit run state. Recheck them at meaningful transitions and after substantial new information.

Restating the goal can help, but it does not guarantee compliance. Evaluate whether the actions remain necessary for the task and whether the final result meets the original request.

Distinguish missing data from failed observation

A search with no matches is different from a search that timed out. A stale record is different from a current observation. Tool results should make those differences explicit.

ok: the lookup completed and returned a current result
no_match: the lookup completed and found no matching record
unavailable: the lookup could not establish a result
unknown_outcome: a requested action may have completed

Choose recovery by status. A no_match response may require clarification, while unavailable may permit a bounded retry. Reconcile an unknown_outcome before attempting another side effect.

Tie approval and traces to the actual action

When approval is required, show the target, proposed change and consequences. Bind the decision to those arguments and recheck material changes before execution.

Trace proposed calls, validation decisions, approvals, execution results and stop reasons. Protect sensitive values and retain only what is needed.

Test failures deliberately. Lose a response after an action commits, restart the worker and issue a concurrent retry. A reliable system should explain the outcome and avoid duplicating the effect.

2 questions test this concept

A refund request times out after the provider may have committed it. What prevents a retry from creating a duplicate effect?

  • ACreate a fresh operation identity for every retry.
  • BTell the model never to mention the first attempt.
  • CHash only the amount so every matching refund is suppressed forever.
  • DReuse the durable operation identity under an idempotent service contract and reconcile the outcome.
Check whether it stuck.

One per page, with a worked explanation.

Start the set
Related material
Book
Site Reliability Engineering, On bounded retries and the budgets around a system that acts.
Book
Designing Data-Intensive Applications, On idempotency and what a timeout does and does not tell a caller.