The 7 Ways AI Agents Fail in Production — And How to Catch Them
Every agent failure follows a pattern. Once you know the patterns, you can catch them before they do damage.
I introduced harness engineering yesterday — the discipline of building a safety and reliability layer around AI agents. Today I want to get concrete. These are the seven failure modes every team hits when they run agents in production, how to detect each one, and what to do when you catch it.
What it looks like: The agent calls grep with the same pattern six times, gets identical results each time, and never acts on any of them. It’s “gathering context.” Each call burns tokens. The context window fills. Eventually the session times out or produces garbage.
Why tools miss it: Observability dashboards show six grep calls. They look productive. Orchestration frameworks execute each call faithfully. No error fires. The session is “still running” until it isn’t.
Detection: Don’t count identical calls. Track information gain — did this call produce new data that led to forward progress? A file write, a test pass, a decision, a state change? If the same tool with the same inputs produces the same outputs four times in a row with no downstream action, it’s a loop.
Fix: Mild loops get a nudge — a message injected into the agent’s context suggesting it move on or produce output. Severe loops (accelerating token burn, no progress for 8+ turns) get a circuit-break: session paused, checkpoint saved, human notified with full trace.
What it looks like: The agent reads files throughout the session. By turn 8, the context is at 85%. By turn 10, the agent has forgotten what it read at turn 3. It re-reads those files, filling context further. Output quality degrades without any error being raised.
Why tools miss it: There’s no failure event. The agent is producing output — it’s just getting worse. No monitoring tool tracks output quality relative to context pressure. This is a silent decline, not a crash.
Detection: Track context pressure as a percentage of the window. Track information density — what fraction of context is recent, actionable, and relevant versus stale, redundant, or dead. Track file re-reads without intervening modifications. When stale fraction crosses a threshold while pressure is high, the session is degrading.
Fix: Trigger context compression. Four layers: preserve recent tool outputs, summarize older context, drop redundant file reads, keep the current task and reasoning chain intact. The agent never notices the compression. Quality stays consistent.
What it looks like: Two flavors. Runaway cost: a simple refactoring burns $12 in tokens because the agent went down an investigation rabbit hole. Model mismatch: a complex architectural change gets routed to a cheap model that produces garbage — and the rework costs more than using the right model upfront.
Why tools miss it: Observability shows cost after the fact. Gateways route to the cheapest available model by default. Neither checks whether the task complexity matches the model capability.
Detection: Track cost as a moving average per task type, per model, per agent. Fire when cost exceeds 3× the moving average. Separately, classify task complexity and check model suitability before routing. Track the second derivative — accelerating cost is more dangerous than steady high cost.
Fix: For runaway cost: nudge the agent to produce output or compact context. For model mismatch: escalate to a more capable model mid-session. If cost is accelerating with no sign of completion, pause and notify a human.
What it looks like: The agent reads .env or a config file. Echoes contents into a response. An API key, database password, or JWT secret now sits in a log file, chat history, or Slack thread.
Why tools miss it: Guardrails check for PII and toxicity. An API key is neither — it’s just a string. SAST scans code before commit. This is runtime behavior: the agent moving information from a protected source to an unprotected sink.
Detection: Run detection in the output path — between the agent producing content and that content reaching any external system. Combine regex patterns (AWS key formats, JWT structures, generic high-entropy strings) with entropy analysis. Check against known safe patterns to reduce false positives.
Fix: Block the output before it escapes. Write an immutable audit record. Notify security with the full trace: what secret was about to leak, which agent produced it, what file it read the secret from, the chain of actions leading to the leak. This is a circuit-break scenario — no nudge, no warning, immediate intervention.
What it looks like: Agent A waits for Agent B. Agent B waits for Agent A. Neither can proceed. The orchestrator faithfully waits for each to produce output. Ten minutes pass. Sessions time out. Work is lost.
Why tools miss it: The orchestrator sees two active sessions awaiting output. The observability tool sees no errors. Everything looks normal — just slow. Multi-agent systems multiply failure modes: deadlocks, redundant outputs, conversation stalls.
Detection: Track inter-agent dependency chains. When two or more agents have been waiting on each other for more than 60 seconds, it’s a deadlock. Separately, detect when multiple agents produce identical outputs (variety collapse) or when no agent has produced a message in 45 seconds (conversation stall).
Fix: Inject a strong message into all waiting agents’ contexts to break the cycle. If that fails within 30 seconds, circuit-break: save checkpoints, stop agents, notify human. For variety collapse, inject diversity signals that force different approaches.
What it looks like: The agent starts with “refactor the auth module to use JWT tokens.” By turn 8, it’s editing the payment module. By turn 12, it’s rewriting the database schema. Each step was logical in isolation. The aggregate has diverged completely. No error was raised. The code it wrote is valid. It’s just not the code anyone asked for.
Why tools miss it: This isn’t hallucination — the agent isn’t inventing things. It’s following a chain of reasoning that led somewhere unintended. Output is valid code. Guardrails see nothing wrong. The orchestrator executed each step correctly.
Detection: Compare the agent’s current actions against the original task using semantic similarity. When the distance crosses a calibrated threshold, it’s drift. This is the hardest detection problem because drift is subjective — what looks like drift might be a necessary detour. The threshold must learn from overrides.
Fix: Nudge the agent back toward the original goal with a context injection. If drift persists, pause for human review. Every override feeds back into the detection threshold.
What it looks like: Every failure teaches a lesson — and that lesson stays in a human’s head, a Slack thread, or a post-mortem doc. It doesn’t make it back into the system. The loop detector that was too slow last week is still too slow this week. The staleness threshold that was too generous last month is still too generous. After 100 sessions, you’ve learned a lot. Your harness hasn’t learned anything.
Why tools miss it: Detection thresholds are static configuration. Nobody updates them between incidents. The feedback loop from failure to rule improvement is entirely human, and humans are busy.
Detection: This is the meta-problem — the failure of the failure-detection system itself. Mine session audit trails. Cluster failures by type. Identify which detectors fired too late or not at all.
Fix: Automate the improvement cycle. Mine weaknesses → propose targeted rule edits → validate against regression tests → apply only if outcomes improve without regressions. The meta-harness runs across sessions, continuously. Research from Shanghai AI Lab (arXiv:2606.09498) validated 33-60% pass rate improvement across six model families with zero human intervention. This isn’t theoretical.
Look at these seven failures again. In every case:
The agent didn’t crash
No error was raised
The orchestrator executed faithfully
The observability dashboard showed nothing unusual until after the damage was done
That’s why harness engineering exists. It’s the layer that sits between orchestration and observability, watches behavior in real time, and asks the question neither asks: is this agent behaving correctly, right now?
The tools to catch these seven failures exist. The principles to build them are known. The only question is whether your agents have a harness yet.
I have taken the reference from :
https://checkgenai.com/
https://github.com/jalajagrawalgenai/HarnessForge
I introduced harness engineering yesterday — the discipline of building a safety and reliability layer around AI agents. Today I want to get concrete. These are the seven failure modes every team hits when they run agents in production, how to detect each one, and what to do when you catch it.
What it looks like: The agent calls grep with the same pattern six times, gets identical results each time, and never acts on any of them. It’s “gathering context.” Each call burns tokens. The context window fills. Eventually the session times out or produces garbage.
Why tools miss it: Observability dashboards show six grep calls. They look productive. Orchestration frameworks execute each call faithfully. No error fires. The session is “still running” until it isn’t.
Detection: Don’t count identical calls. Track information gain — did this call produce new data that led to forward progress? A file write, a test pass, a decision, a state change? If the same tool with the same inputs produces the same outputs four times in a row with no downstream action, it’s a loop.
Fix: Mild loops get a nudge — a message injected into the agent’s context suggesting it move on or produce output. Severe loops (accelerating token burn, no progress for 8+ turns) get a circuit-break: session paused, checkpoint saved, human notified with full trace.
What it looks like: The agent reads files throughout the session. By turn 8, the context is at 85%. By turn 10, the agent has forgotten what it read at turn 3. It re-reads those files, filling context further. Output quality degrades without any error being raised.
Why tools miss it: There’s no failure event. The agent is producing output — it’s just getting worse. No monitoring tool tracks output quality relative to context pressure. This is a silent decline, not a crash.
Detection: Track context pressure as a percentage of the window. Track information density — what fraction of context is recent, actionable, and relevant versus stale, redundant, or dead. Track file re-reads without intervening modifications. When stale fraction crosses a threshold while pressure is high, the session is degrading.
Fix: Trigger context compression. Four layers: preserve recent tool outputs, summarize older context, drop redundant file reads, keep the current task and reasoning chain intact. The agent never notices the compression. Quality stays consistent.
What it looks like: Two flavors. Runaway cost: a simple refactoring burns $12 in tokens because the agent went down an investigation rabbit hole. Model mismatch: a complex architectural change gets routed to a cheap model that produces garbage — and the rework costs more than using the right model upfront.
Why tools miss it: Observability shows cost after the fact. Gateways route to the cheapest available model by default. Neither checks whether the task complexity matches the model capability.
Detection: Track cost as a moving average per task type, per model, per agent. Fire when cost exceeds 3× the moving average. Separately, classify task complexity and check model suitability before routing. Track the second derivative — accelerating cost is more dangerous than steady high cost.
Fix: For runaway cost: nudge the agent to produce output or compact context. For model mismatch: escalate to a more capable model mid-session. If cost is accelerating with no sign of completion, pause and notify a human.
What it looks like: The agent reads .env or a config file. Echoes contents into a response. An API key, database password, or JWT secret now sits in a log file, chat history, or Slack thread.
Why tools miss it: Guardrails check for PII and toxicity. An API key is neither — it’s just a string. SAST scans code before commit. This is runtime behavior: the agent moving information from a protected source to an unprotected sink.
Detection: Run detection in the output path — between the agent producing content and that content reaching any external system. Combine regex patterns (AWS key formats, JWT structures, generic high-entropy strings) with entropy analysis. Check against known safe patterns to reduce false positives.
Fix: Block the output before it escapes. Write an immutable audit record. Notify security with the full trace: what secret was about to leak, which agent produced it, what file it read the secret from, the chain of actions leading to the leak. This is a circuit-break scenario — no nudge, no warning, immediate intervention.
What it looks like: Agent A waits for Agent B. Agent B waits for Agent A. Neither can proceed. The orchestrator faithfully waits for each to produce output. Ten minutes pass. Sessions time out. Work is lost.
Why tools miss it: The orchestrator sees two active sessions awaiting output. The observability tool sees no errors. Everything looks normal — just slow. Multi-agent systems multiply failure modes: deadlocks, redundant outputs, conversation stalls.
Detection: Track inter-agent dependency chains. When two or more agents have been waiting on each other for more than 60 seconds, it’s a deadlock. Separately, detect when multiple agents produce identical outputs (variety collapse) or when no agent has produced a message in 45 seconds (conversation stall).
Fix: Inject a strong message into all waiting agents’ contexts to break the cycle. If that fails within 30 seconds, circuit-break: save checkpoints, stop agents, notify human. For variety collapse, inject diversity signals that force different approaches.
What it looks like: The agent starts with “refactor the auth module to use JWT tokens.” By turn 8, it’s editing the payment module. By turn 12, it’s rewriting the database schema. Each step was logical in isolation. The aggregate has diverged completely. No error was raised. The code it wrote is valid. It’s just not the code anyone asked for.
Why tools miss it: This isn’t hallucination — the agent isn’t inventing things. It’s following a chain of reasoning that led somewhere unintended. Output is valid code. Guardrails see nothing wrong. The orchestrator executed each step correctly.
Detection: Compare the agent’s current actions against the original task using semantic similarity. When the distance crosses a calibrated threshold, it’s drift. This is the hardest detection problem because drift is subjective — what looks like drift might be a necessary detour. The threshold must learn from overrides.
Fix: Nudge the agent back toward the original goal with a context injection. If drift persists, pause for human review. Every override feeds back into the detection threshold.
What it looks like: Every failure teaches a lesson — and that lesson stays in a human’s head, a Slack thread, or a post-mortem doc. It doesn’t make it back into the system. The loop detector that was too slow last week is still too slow this week. The staleness threshold that was too generous last month is still too generous. After 100 sessions, you’ve learned a lot. Your harness hasn’t learned anything.
Why tools miss it: Detection thresholds are static configuration. Nobody updates them between incidents. The feedback loop from failure to rule improvement is entirely human, and humans are busy.
Detection: This is the meta-problem — the failure of the failure-detection system itself. Mine session audit trails. Cluster failures by type. Identify which detectors fired too late or not at all.
Fix: Automate the improvement cycle. Mine weaknesses → propose targeted rule edits → validate against regression tests → apply only if outcomes improve without regressions. The meta-harness runs across sessions, continuously. Research from Shanghai AI Lab (arXiv:2606.09498) validated 33-60% pass rate improvement across six model families with zero human intervention. This isn’t theoretical.
Look at these seven failures again. In every case:
The agent didn’t crash
No error was raised
The orchestrator executed faithfully
The observability dashboard showed nothing unusual until after the damage was done
That’s why harness engineering exists. It’s the layer that sits between orchestration and observability, watches behavior in real time, and asks the question neither asks: is this agent behaving correctly, right now?
The tools to catch these seven failures exist. The principles to build them are known. The only question is whether your agents have a harness yet.
I have taken the reference from :
https://checkgenai.com/
https://github.com/jalajagrawalgenai/HarnessForge
Fuente: Artículo original