What failure modes should a founder expect before an AI agent goes into production?
Before putting an AI agent into production, expect failures in four classes: specification gaps, coordination failures, false verification, and unsafe tool use. Most do not look like crashes. They appear as incomplete work, plausible but wrong confirmations, rising cost, repeated actions, or an approval step that quietly stops protecting you.
That distinction matters because uptime is a weak success metric for an agent. A process can stay online all day while it researches the wrong company, drafts from stale context, marks partial work complete, or repeats an external action. The system is available. The outcome is still wrong.
My rule is simple: do not ask only whether the agent runs. Ask how it can be wrong, how that wrongness becomes visible, and what stops it before the business absorbs the consequence. Crash recovery belongs in that plan, but it is only one failure mode. The wider problem is work that completes incorrectly and looks normal.
Why are silent agent failures more dangerous than clean crashes?
A clean crash gives you a useful signal. The process stops, an error appears, and someone knows the task did not finish. Silent failure is harder: the agent returns a polished answer or a success message, but the underlying job is incomplete, based on the wrong source, or never verified against the real destination.
This is why ordinary service monitoring is not enough. CPU, memory, response time, and HTTP status can tell you whether software is alive. They cannot tell you whether a booking was created for the correct person, whether a CRM update landed on the correct record, or whether a report cited the source it claims to cite.
An AI agent failure mode is a repeatable way the system produces wrong, unsafe, or incomplete work. It can begin in the instructions, the model, the tools, the handoff between components, or the final verification step. The important part is repeatability: if you can name the failure, you can design a test, boundary, or recovery path for it.
The existing guide on [durable agent execution](https://gallmur.com/en/notes/agent-crash-recovery-durable-execution/) explains how to resume work after interruption. That protects execution continuity. Production readiness also needs protection against work that never interrupts and still produces the wrong result.
Which specification failures make an agent do the wrong work correctly?
The first class starts before the model acts. The workflow has a vague goal, missing acceptance criteria, conflicting instructions, or no definition of what must remain under human control. The agent then optimizes the nearest interpretation. It may execute every step competently and still solve the wrong problem.
A request such as “qualify this lead” is not an operating specification. Which evidence counts? What happens when company and contact data disagree? Can the agent change the record, or only recommend a change? What makes the result complete? Without those boundaries, the agent fills gaps with probability. That is useful for drafting and dangerous for business state.
The fix is not a longer prompt by default. It is a narrower contract: required inputs, allowed actions, forbidden actions, completion evidence, and an explicit path for uncertainty. If a decision changes money, access, customer communication, or a system of record, the agent needs a defined approval boundary rather than a vague instruction to “be careful.”
Before launch, run representative cases and ugly cases. Include missing fields, contradictory records, unavailable tools, stale context, and a request that should be refused or escalated. A workflow that passes only the happy path is a demo.
How do coordination and handoff failures appear in multi-step work?
The second class appears when one step depends on another. A research worker can return incomplete evidence. A writing step can treat that brief as authoritative. A publishing step can accept malformed content. Each component may look reasonable alone while the chain amplifies one early mistake.
Research presented at NeurIPS 2025 in the MAST framework analyzed more than 1,600 annotated traces across seven multi-agent systems. It grouped 14 failure modes into system design, inter-agent misalignment, and task verification. In that analysis, system-design failures represented 41.8% of identified failures, inter-agent misalignment 36.9%, and task-verification failures 21.3%. The practical point is not the leaderboard. It is that coordination itself creates a large failure surface.
Treat every handoff as an interface, not a conversation. Define the fields that must arrive, the evidence attached to each claim, and the conditions that make the next step stop. A downstream agent should not convert “source unavailable” into a confident paragraph. A publisher should not convert “draft created” into “page verified live.”
Also preserve state outside the running model. The guide to [AI agent state management](https://gallmur.com/en/notes/ai-agent-state-management-persistence/) covers the separation between conversation memory, execution state, and business records. That separation matters because a handoff should consume durable facts, not depend on what happens to remain in one model's context window.
Why does self-verification produce false confidence?
The third class is verification failure. The same agent that performed the work looks at its own output and declares success. It checks whether the response sounds complete instead of checking the target system. This is how “email prepared” becomes “email sent,” “file generated” becomes “artifact works,” or “API returned 200” becomes “the correct record changed.”
Completion evidence must come from the destination. Read back the exact CRM record. Fetch the public URL. Confirm the message receipt. Compare the generated file against its required structure. For a reversible internal task, a deterministic test may be enough. For an external side effect, the system needs a receipt tied to the exact target.
The verifier should also be independent where the consequence justifies it. That does not always mean another model. A schema validator, database read, checksum, browser fetch, or API lookup is often cheaper and more reliable. Use model judgment for ambiguity. Use deterministic checks for facts the machine can prove.
A useful pre-production question is: what evidence would convince a skeptical operator that this specific task finished correctly? Put that evidence into the workflow before launch, not after the first incident.
What security failures are specific to tool-using agents?
The fourth class appears when an agent can read untrusted content and use tools. A webpage, document, email, or retrieved record can contain instructions that compete with the owner's intent. If the agent treats external content as authority, prompt injection becomes an operating risk rather than a chat oddity.
Microsoft's AI Red Team taxonomy separates agentic safety and security failures, including goal hijacking, context contamination, tool and plugin abuse, and disclosure of capabilities or architecture. Its 2026 update reports that human-in-the-loop bypass was the most consistently exploited failure mode during a year of red-team engagements. Attackers did not always remove approval. They manipulated when it appeared, exhausted the reviewer, or escalated actions gradually until the control stopped working.
An approval button is not a complete control. The person approving needs the real action, target, and consequence in plain language. Sensitive tools should have the minimum permission required. Untrusted content should remain data, not become instructions. Logs should preserve what the agent saw, what it decided, which tool it called, and what the destination returned, without exposing secrets in the log itself.
This is also why broad tool access on day one is a bad trade. Start with read-only or reversible actions, prove the workflow, then expand permissions only where the measured value justifies the added failure surface.
What should you verify before production launch?
Start with one bounded workflow and write its completion proof before writing its happy-path instructions. Name the system of record, the actions the agent may take, the actions that require approval, and the conditions that force a stop. Then test wrong inputs, missing tools, timeouts, duplicate requests, stale state, hostile content, and partial completion.
Make retries idempotent. A second attempt should resume or reconcile, not duplicate a payment, message, booking, or record. Keep durable state outside the model process. Separate the worker that acts from the check that proves the action. Monitor cost and outcome quality alongside uptime because a system can remain available while retries and context growth make each completed task uneconomic.
Use the [durable execution checklist](https://gallmur.com/en/checklists/durable-agent-execution/) as a practical starting point. It will not eliminate every model error. It will force the business to decide where evidence, recovery, ownership, and human judgment belong before the agent touches real operations.
What are the limits of a failure-mode checklist?
A checklist cannot prove that an open-ended agent is safe in every future situation. Models change, tools change, external data changes, and attackers adapt. Tests show behavior on selected cases, not a permanent guarantee. High-impact workflows still need constrained permissions, monitoring, incident review, and a manual path when the agent cannot establish certainty.
The research also does not give you one universal failure rate for your business. MAST reported failure rates from 41% to 86.7% across the multi-agent frameworks and tasks it evaluated, but those figures describe that experimental setup. They are evidence that coordination failures are common, not a forecast that your workflow will fail at the same rate.
The right target is not “zero failures.” It is bounded damage, visible uncertainty, verifiable completion, and recovery that does not repeat the side effect. If the workflow cannot provide those four properties, it is not ready for unsupervised production work.