← Agents Behaving Badly

Engineering the Inner Loop: Preparation, Failure Modes and Responses

A practical guide to preparing agent workflows, recognizing recurring mistakes, and choosing checks and responses. The patterns and checks are working guidance, not an exhaustive taxonomy or a validated detection suite.

Return to Article 2, Section 2.

Start with the cause of the difficulty

An agent can fail because the specification is incomplete, necessary knowledge is absent, context is unusable, tools fail, work is misrouted, or the task exceeds the configured agent's capability. Improving these conditions is part of engineering the inner loop. Environmental causes, where the agent lacks something it needs, call for preparation; agent failure modes, where it has what it needs and still errs, call for the checks and responses below. Calling all of them agent failure modes obscures the different remedies they need.

For this article, an agent failure mode is a recurring pattern of incorrect decisions or actions on tasks within the configured agent's demonstrated capabilities, despite having sufficient, accurate and usable knowledge and context at the relevant step. A failure-mode-induced error is an observed instance supported as matching that pattern.

Apply that definition to the particular decision under investigation. Establish the obligation, what information the agent actually received or could reasonably retrieve, and evidence of capability on comparable work. A document existing somewhere in a repository is not proof that its contents reached the agent. A successful comparable attempt supports capability; it does not by itself explain this failure. Record not established when the evidence cannot distinguish an agent error from missing prerequisites.

A check can establish a defect without establishing its cause. Repairing an omitted requirement may be justified before we know whether the omission originated in an agent's decision, a truncated handoff or an incomplete specification. Preserve those distinctions in the learning record.

Prepare the work: guidance from the General Principles

The General Principles supply preventive practices; the catalogue below describes behavioral patterns to investigate. Use them together when designing an agent's task, a pipeline stage or a graph edge. Each node needs a responsibility, sufficient inputs, bounded authority, expected outputs and a route for failure. Each handoff must preserve the requirements, state and unresolved questions its receiver needs. A responsibility does not necessarily require a separate agent.

These practices draw on the General Principles for supportive environments, context strategy, verification and implementation. Anthropic's context-engineering guidance provides further discussion of selecting context and preserving information across long tasks. Context budgets and other operating limits need to be tested for the configuration and tasks being used.

Capability limits, provider outages, quotas, denied operations and adversarial inputs also need explicit handling. They are not automatically mistakes by the agent. An agent's response to a clear tool error or untrusted instruction can be a behavioral incident; the outage or exposure itself is a different observation.

Investigate agent behavior: the catalogue

The prerequisite test above applies to every entry. These descriptions specify behavior that could meet our definition. A signal alone does not establish the pattern, its cause, or a need to interrupt work. Checks and corrections below are proposals to qualify and measure in the learning loop. The patterns can overlap; assigning several labels to one mistake does not make it several independent incidents.

Unfaithful handoff of available requirements or evidence

The agent receives clear requirements or evidence but produces a handoff that omits, changes or invents a consequential claim. A downstream worker that only receives this defective handoff has an information gap; do not count that automatically as a second behavioral error.

Check: compare consequential handoff claims with their source obligations before dependent work begins. A schema can detect missing identifiers; checking preservation of meaning needs further evidence or judgment.

Respond and verify: restore the source meaning, identify dependent work and repair affected artifacts. Exercise the omitted behavior in the candidate. For the storage-read example, verify that a failed read returns a read-failure result and leaves the stored bytes unchanged, while absent data still yields an empty list. A complete reference list alone does not prove a faithful handoff.

Skipped work or premature completion

The agent skips a clear, feasible obligation and presents the task as complete despite available evidence of unfinished work.

Check: compare the completion claim with required artifacts, actual execution records and unresolved findings. Distinguish incomplete collection from evidence that a step was skipped.

Respond and verify: return the specific unmet obligation, complete or correct the work and evaluate its substance. If it cannot be completed within the limits, record an unsuccessful stop. File existence and a polished summary are insufficient.

Unsupported execution or verification claims

The agent asserts an execution or verification result that the available records contradict, or presents it as established despite knowing it remains unverified.

Check: match claims to commands, outputs, exit status and the exact candidate. Missing logs alone establish an evidence gap, not fabricated execution.

Respond and verify: correct the claim, run the relevant check when feasible and retain the result. Independently assess whether that check tests the obligation; a genuine passing command can still supply inadequate evidence.

Acting on the first plausible answer

The agent accepts a diagnosis or changes working behavior without examining available contrary evidence or a required prerequisite.

Check: compare the proposed action with the starting behavior, relevant requirements and already available counterevidence. A passing starting test suite does not establish that no change is needed.

Respond and verify: investigate the disputed premise before changing code, or explain why the existing behavior already satisfies the task. Verify the decision against the actual obligation, not merely the absence of test failures.

Using valid evidence for the wrong claim

The agent treats a passing result for one candidate, path or property as proof of another despite having the identities and scope needed to distinguish them. A controller that supplies the wrong revision belongs under system design.

Check: bind the claim, obligation, candidate, executed path and assertion. Compare the behavior exercised with the behavior asserted.

Respond and verify: withdraw the unsupported conclusion and execute a check on the intended subject. Identity matching can be deterministic; deciding whether the assertion supports the claim may require semantic review.

Taking a decision reserved for another actor

The agent makes a consequential disposition that a clear authority rule reserves for a human or another component. A controller promoting a legitimate recommendation is a separate design defect.

Check: compare actual transitions and actor identities with the authorized decision boundary. The word “complete” alone does not show an unauthorized transition.

Respond and verify: stop further dependent actions, restore the decision point where possible and present the evidence to the responsible actor. Confirm resulting state and side effects; revising the report alone may not undo the action.

Treating correlated agreement as independent corroboration

The agent calls agreement independent corroboration despite knowing the reviews rely on the same relevant assumptions or evidence.

Check: retain reviewer inputs, methods and findings, and compare them with the claim of independence. Model diversity or a reviewer count does not establish independence.

Respond and verify: narrow the conclusion to what was actually checked and obtain evidence that tests the shared assumption where needed. Multiple reviews remain useful for some purposes; agreement alone neither proves nor disproves correctness.

Unsupported causal diagnosis and repair

The agent attributes a symptom to a cause despite available evidence that contradicts the attribution or a feasible required check it neglects. Blaming the environment is one instance; an uncertain but explicitly tentative hypothesis is not itself an error.

Check: retain the diagnosis, competing explanations and a discriminating experiment. A failed repair alone does not prove a wrong diagnosis, and disappearance of the symptom does not prove the proposed cause.

Respond and verify: test the mechanism before broad repair where feasible, make the bounded correction and recheck both the obligation and relevant alternatives. Record unresolved causality rather than converting a convenient explanation into fact.

Misinterpreting a measurement

The agent reports a property of the system that the available population, query or denominator does not support. Missing or corrupt measurements require a different diagnosis.

Check: compare the claim with the retained population, filters, exclusions and units. For example, a percentage of decisive errors in failed runs is not a percentage of all errors or all runs.

Respond and verify: correct the calculation or narrow the claim and revisit decisions derived from it. A populated table is not evidence that the query answers the intended question.

Substituting visible checks for the stated obligation

The agent treats passing examples or isolated checks as sufficient completion despite a clear, feasible obligation requiring broader or composed behavior.

Check: exercise independently specified boundary and composition cases tied to that obligation. Preserve the candidate being tested. An unspecified preference revealed later is a specification issue, not evidence of this behavior.

Respond and verify: repair the general behavior and qualify the missing check against a relevant defective case. A counterexample establishes a coverage or behavior gap; it does not establish the agent's motive or complete the remaining test space.

Circumventing an explicit constraint

The agent ignores a clear restriction while pursuing completion. Unauthorized weakening or bypassing of protected evaluation is one instance. Authorized test repair and legitimate alternative operations remain different cases.

Check: compare observed effects and protected inputs with permissions and the governing obligation. Preserve temporary changes when observable; before/after hashes alone can miss change-then-restore behavior.

Respond and verify: stop the affected operation, restore the protected boundary and reassess the exact candidate using trustworthy checks. Verify actual effects; a command mentioning a protected file is not proof of successful tampering.

Ignoring regression evidence or repeating a disproven repair

The agent repeats a repair or accepts a regression despite receiving clear relevant failure history and having a feasible way to address it. Coupled requirements, flaky tests and inadequate feedback can produce similar symptoms.

Check: preserve candidate identities, changed obligations and repeated findings. Compare equivalent environments and requirements before calling a transition a regression or a cycle.

Respond and verify: expose the conflicting requirements and failed strategies, choose a different supported repair or stop honestly. Recheck both the repaired obligation and those previously satisfied. A novel patch alone is not evidence of progress.

Promoting untrusted data to instruction

The agent follows material supplied as data over the controlling task despite a clear and usable authority boundary.

Check: preserve the material's origin, exposure and subsequent actions. An injection-like string indicates exposure; it does not prove the agent followed it.

Respond and verify: contain affected actions, restore the controlling task and inspect resulting changes before resuming. Enforce sensitive permissions independently of the agent. Deliberate adversarial input and the agent's response are separate facts.

Omitting known uncertainty or adverse results

The agent presents a clean result while omitting material uncertainty or relevant unsuccessful attempts it knows about. Nondeterminism, quota stops and missing records are not themselves this behavior.

Check: reconcile the report with complete candidate and execution histories, unresolved obligations and comparable mixed outcomes. Changed output hashes can reflect timestamps rather than changed behavior.

Respond and verify: restore the omitted evidence, investigate consequential variation and revise the qualification claim. Count one reporting incident once even when uncertainty concealment and retry selection both describe it; do not infer deliberate deception.

Requiring unnecessary clarification or formalization

The agent repeatedly blocks work on already answered questions or imposes requirements that conflict with a clear authorized scope. A mandatory human decision or a workflow that requires excessive ceremony is a different case.

Check: compare each interruption with the supplied answer, governing requirements and authority rules. Counts and elapsed time measure burden, not whether the question was unnecessary.

Respond and verify: point to the existing decision and resume within scope, or revise the workflow if it created the burden. Preserve legitimate escalations. Measure whether the change actually reduces human work without increasing consequential mistakes.

Track consequences without calling them causes

Unused code, accumulated complexity and later regressions can reveal problems worth investigating. They do not establish whether an agent lacked information, misunderstood a requirement or neglected something it knew. Trace the contributing decisions; use static analysis, behavioral checks and comparable later maintenance work as evidence. Do not delete apparently unused code before checking legitimate indirect use.

Likewise, a false green describes an admission outcome. Investigate the production error and the separate reason the checks or enforcement failed to catch it. The same error can propagate through several artifacts without becoming several independent incidents.

Use the learning loop to choose mechanisms

For each incident, retain the violated obligation, actual inputs, configuration, earliest evidenced error, proposed pattern, alternative explanations, propagation, check result, correction and final outcome. Mark prerequisite support and causal uncertainty explicitly. Keep unsuccessful runs and human-review or post-release findings.

Compare ordinary agent recovery and evaluator-driven rework with the selected prevention or intervention, using comparable tasks, budgets and unchanged acceptance criteria. Measure check cost across all invocations, confirmed incidents, false alarms and misses, correction success and regressions, total time and tokens, completion within budget, escapes and human effort. Weight the consequences of an escape as well as its frequency. Repeated attempts matter because both the original mistake and the correction can vary.

Under the perfect-evaluator thought experiment, early correction cannot add correctness to an admitted candidate. It may improve cost and completion within budget. With real evaluators, complementary checks may also catch missed violations. Neither benefit follows merely from a detector firing. Humans review proposed changes to the loop before adoption.

Research and scope

EPAM's survey is useful for comparing recognizable behavior with context, handoff and orchestration problems, and for noticing that intervention itself can disrupt work. It uses a broader meaning of failure mode than this article. Its examples inform our design questions; they do not supply prevalence estimates or validate the patterns or checks in this guide.

Failure as a Process supplies empirical evidence about errors, propagation and recovery in coding-agent trajectories. Its categories and denominators remain the authors'; they cannot be substituted for our catalogue. Wink supplies evidence about targeted intervention in a particular deployed setting, not universal detection or correction rates.