Agent failure modes

What actually goes wrong in production. Interviewers use this to separate people who have run an agent from people who have read about them.

The loop failures

Infinite looping. The agent repeats a call because the result isn’t what it wanted. Fix with a step limit and loop detection on repeated identical calls — and feed the detection back as an observation rather than aborting, because the model often recovers when told it’s stuck. See 02_the_agent_loop.md.

Premature termination. The agent answers before finishing the job, often when a tool returns something ambiguous. Mitigate with an explicit finish tool carrying a schema, so completion is a deliberate act with required fields rather than the absence of a tool call.

Thrashing. Alternating between two approaches without committing. Usually a sign the task is under-specified or the tools don’t actually cover it.

The tool failures

Wrong tool selected. Almost always a description problem, not a model problem. Tool descriptions are prompts — vague ones produce wrong choices. Overlapping tools are worse than too few.

Too many tools. Selection accuracy degrades noticeably past roughly 20-40 tools. Consolidate behind fewer tools with a mode parameter, or split across servers loaded per task.

Malformed arguments. The model produces plausible arguments that don’t satisfy your schema. Validate before executing and return the validation error as an observation — the model usually corrects on the next turn.

try:
    args = ToolArgs.model_validate(call.args)
except ValidationError as e:
    observation = f"Invalid arguments: {e}. Check the schema and retry."
else:
    observation = execute(args)

Unbounded tool output. One SELECT * fills the context window. Cap and paginate at the tool boundary, not afterwards.

Silent tool failure. A tool returns "" or null on error and the agent treats it as a valid empty result, then confidently reports nothing was found. Return explicit errors: "Search failed: connection timeout. Retry or try a narrower query."

That last one is subtle and very common — an interviewer who has shipped an agent will recognise it immediately.

The reasoning failures

Compounding errors. A wrong intermediate conclusion propagates. By step 8 the agent is reasoning confidently from a false premise it established at step 3. Mitigations: ground each step in tool output rather than prior reasoning, add verification steps, keep chains short.

Confabulated tool results. The model sometimes generates what a tool would have returned instead of calling it — more common with weaker models and long contexts. Detect by asserting that every claimed result corresponds to a logged tool invocation.

Ignoring context. The relevant fact is in the context but sits in the middle of a long prompt. This is lost-in-the-middle, and it’s why fewer, better-ranked observations beat more. See ../06_transformers_llm/08_context_windows.md.

Overconfidence on failure. The agent couldn’t complete the task and produces a confident-sounding answer anyway. Make “I could not determine X” a first-class, rewarded output — a schema field for gaps and unknowns.

The systems failures

Cost explosion. Context grows every step, so cost is superlinear. One runaway agent can produce a memorable bill. Hard-cap tokens and cost per run, not just steps.

Latency. Ten sequential steps at 2s each is 20 seconds. Users abandon. Stream intermediate progress, parallelise independent tool calls, and consider whether a workflow would do.

Duplicate side effects. Agents retry; retried actions repeat. Idempotency keys on anything with effects. See 05_durable_execution_hitl.md.

Partial completion. Failure at step 7 with steps 1-6 already applied. Needs compensation, or a design where effects commit only at the end.

The security failures

Prompt injection reaching tools. The headline risk: untrusted content instructs the agent to misuse its tools. Architectural mitigations only — least privilege per agent, separate read-only from write-capable, human approval on consequential actions, and server-side authorization independent of what the model asked. See ../11_mcp/03_building_and_securing.md.

Data exfiltration. A tool that takes a URL becomes an exfiltration channel. Restrict egress and audit any tool accepting an arbitrary destination.

Excessive agency. The agent has tools it doesn’t need for the task. Scope the tool set per task, not per application.

Building for it

A checklist worth reciting:

Testing an agent

Non-determinism makes conventional testing awkward. What works:

• Fixed-seed regression suites over a curated set of tasks, scored on final outcome rather than exact trajectory.
• Trajectory assertions for what must happen — “must call verify_identity before refund_order” is testable and important.
• Mock tools so tests are deterministic and fast; run a smaller live suite separately.
• Adversarial cases — injection attempts, missing data, failing tools, ambiguous requests.
• Cost and step-count budgets as test assertions, so a regression that doubles cost fails CI.

That last one is unusual and valuable: treating cost as a tested property catches regressions no accuracy metric would.

Interview angle

• “What goes wrong with agents in production?” — loops, wrong tool selection from vague descriptions, context overflow from unbounded tool output, compounding errors from bad intermediate conclusions, cost explosion, duplicate side effects on retry, and prompt injection reaching privileged tools.
• “Your agent loops forever. Debug it.” — check tool descriptions first (usually the model can’t find a tool that does what it needs), add loop detection on repeated identical calls, feed that back as an observation, and enforce step and cost limits as hard stops.
• “A tool fails and the agent reports ‘nothing found’. Why?” — the tool returned empty on error instead of an explicit failure. Return actionable error strings; an agent can’t distinguish “no results” from “the search broke” unless you tell it.
• “How do you test a non-deterministic agent?” — regression suites over curated tasks scored on outcome, trajectory assertions for required orderings, mocked tools for determinism, adversarial cases, and cost/step budgets as CI assertions.
• “How do you stop cost running away?” — hard token and cost caps per run, not just step limits, since context growth makes cost superlinear in steps. Plus bounded tool output, which is the usual cause.
• “How do you stop an agent making things up when it can’t complete the task?” — make “I couldn’t determine X” a structured, expected output with a dedicated field. Otherwise the model produces a confident answer, because that’s what the training distribution rewards.