AI Agent Failure Modes: Twelve Ways Our Agents Failed in Production

AI agent failure modes are rarely model failures. Across the first two months of running four AI agents on real company work, from late July 2026, twelve incidents cost us time, trust or both. In nine of them, the system raised no error at all. The agents reasoned fine. The boundaries, checks and instructions around them failed.

This page is the index. Each failure below gets one paragraph: what happened, the number that tells you how bad it was, and the rule we took from it. Every one links to a full post-mortem with the chronology and the fix. The system they all come from is the four-agent mesh that runs Neogen Media, documented in our Neogen AI OS case study. JARVIS works for the founder, Taurus runs operations, Kiara runs HR and Neo runs revenue.

What are the most common AI agent failure modes in production?

In our build, they fell into four groups: failures nobody could see, checks that could not fail, agents holding the wrong idea of who they are or what they may do, and boundaries that existed on paper only. Hallucination, the failure most people ask about first, did not cause a single one of the twelve.

That matches the research better than it matches the discourse. Mert Cemri and colleagues built the Multi-Agent System Failure Taxonomy (MAST) from more than 1,600 annotated traces across 7 multi-agent frameworks and sorted what went wrong into 14 failure modes in 3 categories: system design issues, inter-agent misalignment and task verification. Most of our list lands in the first and third. The design let something wrong persist, and the verification said it was fine.

The twelve, grouped by the shape of the failure:

• Silent failures: a mesh dead for six days, a memory call eating 300 seconds per reply, a backup of a directory nothing wrote to
• Checks that could not fail: a substring health gate, a test suite that only tested its own fakes, monitors nobody had seen fire, a 12-second stability check on a crash loop
• Wrong identity or authority: 33 copied skill files, an agent obeying a stale sentence over a live permission, three bots sharing one session
• Paper boundaries: agents that could read each other's secrets, and an approval gate where 86% of requests were noise

Which agent failures produce no error at all?

The expensive ones. A failure that throws gets fixed the same day. A failure that produces silence looks exactly like a system with nothing to do, and ours ran for days before anyone noticed. These three were found by a human asking a question, not by an alert.

1. The mesh was dead for six days and every check was green

On or before 2 August 2026, the model behind our inference gateway moved a version. Our scheduler correctly refused to run any job whose stored model config had drifted, and it refused roughly 2,975 times across three agents without telling anyone. The bus served 200s, the dispatcher woke workers, container isolation held. Every check we had was a presence check. We now run a watchdog every 15 minutes that alerts on three consecutive failures of any job, or any message queued for over three hours. Full write-up: our agent mesh was dead for six days. The rule: monitor for silence, not just for errors.

2. Context compression cost five minutes per reply

On 31 July our agents took five minutes to answer a voice note. The speech pipeline accounted for 1.8 seconds. The other 300 seconds were a context compression call timing out, because the cheapest job in the system had been routed to the most expensive model. The first fix failed on a config alias the code documented but did not support. After the fix, the same call took 1.2 seconds. Full write-up: how context compression cost us five minutes per reply. The rule: a documented alias is not a supported one, so test the config on one agent before it reaches all of them.

3. The nightly backup archived a dead directory

Our off-site backup exited 0 every night and uploaded an encrypted archive every night. By 31 July, the directory it archived was one nothing wrote to anymore. On 9 August a restore drill found a second fault: an archive that passed its own manifest check and could not be extracted. Neither fault produced an error. Full write-up: a backup you have never restored is not a backup. The rule: restore is the only test of a backup.

Why do health checks and tests pass on broken agents?

Because most checks are written to confirm success, and nobody feeds them a failure before trusting them. Four of our twelve incidents were instruments reporting good news about a broken system. Each check was logically sound for the input its author imagined and blind to the input that actually arrived.

4. A substring check verified a failed deploy

On 25 August our deploy script tested whether the health response contained the word connected. The response said disconnected, which contains connected, so the deploy exited zero on a component that was down. We caught it only because the script printed the raw payload one line above its own wrong verdict. Unhealthy contains healthy, unauthorized contains authorized: this check can only turn failures into passes. Full write-up: how a substring check verified a failed deploy as good.

5. 49 passing tests, and the feature could never fire

The same day, we shipped a WhatsApp reply-alert feature for JARVIS with 49 tests green. The first real reply vanished, then the second. The real CLI printed a session banner after its JSON, so the parser rejected every real output, and WhatsApp addressed replies by a linked identity instead of the phone number our fixtures assumed. The fail-closed path turned both defects into silence. Full write-up: when the test double is all you tested. The rule: a test double proves the double works. Capture real output before you mock it.

6. Monitors that had never been seen to fire

In August three separate checks covered nothing: a notifier nobody had watched deliver, an org-chart drift detector that reported stale on every run because of one extra blank line, and a planned CI-on-push check that would have slept through the five days nobody pushed the repository, which were the five days the week's mistakes were made. Breaking six checks on purpose took less time than writing any one of them, and found two bugs in the checks themselves. Full write-up: AI agent monitoring: the checks that never fired.

7. A 12-second stability check passed a crash-looping container

Docker counts a container as successfully started after ten seconds up, and resets its restart back-off when that happens. Our container lived eight to twenty seconds per cycle, so the loop never slowed and our check, which waited twelve seconds, landed in an up-window. RestartCount reached 342 and we burned about eight OAuth device codes before anyone read it. Full write-up: self-hosting an AI agent before it holds any credentials. The rule: hold the restart count at zero for a full minute, read it twice.

Rob Ewaschuk sets the bar in the monitoring chapter of Google's Site Reliability Engineering book: "Your monitoring system should address two questions: what's broken, and why?" Items 4 to 7 answered neither, and did it with confidence. If you are putting agents into live operations and want the gates built so they are seen to fail before they are trusted, that is where our AI agent development engagements start.

How does an AI agent end up with the wrong idea of its own authority?

It reads it. An agent's identity and authority are whatever its instruction text says, and that text is copied, forked and edited by agents themselves. Permission tables, credentials and gates were correct in all three incidents below. The prose was wrong, and the prose is what the model reads while it reasons.

8. 33 skill files told the revenue agent he was the COO

We built Neo's skills by copying Taurus's, and every copied banner opened with "You are the COO agent." On 9 August we found 33 of them. The same day, one wrong belief about an API identifier spread into ten skill files, an architecture document and two agents before anyone checked the schema, and the first cleanup missed three copies because each agent had paraphrased it. Full write-up: multi agent system failures and the 33 misaddressed skills. The rule: after reversing a belief, search every phrasing of it in every agent.

9. The COO agent asked permission for decisions he already owned

Also on 9 August, Taurus sent seventeen messages over three hours seeking approval for operations changes the gate had already granted him. A stale sentence in his identity file said founder approval was required, and the sentence won. The inverse happens too: we found restrictions written in config and prompts that the runtime never enforced, written up in stated controls are not controls. Full write-up: agent authority lives in its prose, not its permissions. The rule: when an agent behaves more timidly than its permissions allow, read what it was told, not what it was granted.

10. Three Telegram bots answered as the same agent

All three of our agents introduced themselves as the HR agent. A session-lookup fallback in Hermes v0.19.0 dropped the profile name, and for a Telegram direct message the chat ID equals the user ID, so one person allowlisted on three bots collapsed onto one session. The blast radius was nil because that person was authorised for everything. The latent risk was any subordinate added to a second bot inheriting that profile's credentials. We filed it upstream as #74285. Full write-up: Hermes Agent in production.

Which AI agent failures come from boundaries that exist only on paper?

The ones where a document describes an isolation the runtime does not enforce. Both incidents below had correct access-control lists and correct policies. Neither mattered, because the agent could reach around them. Every control that held in our build sits somewhere the agent has no path to.

11. Any agent could read another agent's 47 secrets

On 30 July we found all of our agents running in one container as one Unix user. Holding the founder agent's key, the operations agent's shell got the founder agent's identity and read access to everything. Nothing was misconfigured. The credential had walked across a boundary that did not exist. Splitting to one container and one UID per agent broke roughly 235 skill files. Full write-ups: one container per agent and the credential theft it closed and the agent mesh architecture that runs a real company. The rule: a limit the agent can edit is not a limit.

12. 86% of approval requests were noise

In the fortnight to 8 August, 119 of 138 gated approvals were requests to run an arbitrary host command. The founder approved 106 and rejected 4, and 42 of the approved ones failed anyway. The agents were not being reckless. Root on the host was the only write lane they had, so every routine task became a root request. We built a lower lane that runs scripts inside the agent's own container, then added a second approver who can never approve its own request. Full write-ups: approval as a database rule, not a prompt instruction and a second approver so one human stops being a queue.

What do these twelve AI agent failures have in common?

None of them was the model being wrong. Every one was a description of the system disagreeing with the system: a check that described coverage, a file that described an identity, a document that described a boundary. We would argue this is the main risk in agent deployments right now, and that teams spending their time on prompt quality and hallucination rates are testing the part that failed least often for us.

It also changes what you should look at first in your own stack. Before building an evaluation suite, list every check that stands between an agent and a silent failure, and ask when each one last returned a failure. For most of ours the honest answer was never. Our reference for how the org chart becomes the routing layer that decides who may do what is what an agent mesh is and why the org chart is the routing map.

The primitive: a check you have never seen fail is decoration

If you keep one line from this index, keep that one. A gate that has never returned non-zero has not been tested; it has been observed agreeing with you. Before anything ships, feed it one input you know is bad and watch it refuse. It is cheap, it is boring, and in our build it would have caught most of the twelve.

Frequently asked questions

Is hallucination the biggest AI agent failure mode?

Not in our production experience. None of our twelve incidents was caused by a model inventing facts. The closest case was two agents inferring that two API fields were different identifiers from their names alone, an inference our own engineering session repeated. Even there, the damage came from the belief being copied into ten files, not from how it was first formed.

How do you detect an AI agent that has silently stopped working?

Write down what should happen and how often, somewhere the agents cannot edit, then check reality against it on a clock. Our watchdog reads the scheduler's list of 36 jobs as a contract and alerts on three consecutive failures of any job or any message stuck for three hours. Errors are not enough, because a stopped agent produces none.

How many agents should a small business start with?

One, with no credentials, until it has stayed up for a full minute with zero restarts and its checks have been seen to fail. We went from one to four between late July and early August 2026, and most of these incidents came from that growth. Each new agent needs its own container, user ID and key before it needs a single skill.

Should AI agents be allowed to approve each other's actions?

Only for actions that are reversible and stay inside the company, and never their own requests. That is the rule we delegate by. It moved routine approvals off the founder's phone without letting any agent approve its own request, which we check in two separate places so one refactor cannot remove it.

Where can I read the full chronology of the system?

The Neogen AI OS case study covers the architecture end to end, and the complete build log of four autonomous AI agents tells it in order from the first container. Each failure on this page links to its own post-mortem with dates, error strings and the fix.

If you want an agent build where these failure modes are designed out before the first credential is issued, talk to us about your agent project.