Agent reliability in the real world: 7 failure modes and how to design around them

Yesterday you probably watched another agent demo where a model clicks around a browser, files a ticket, updates a spreadsheet, and somehow everything works the first time. It’s the AI equivalent of a cooking video where someone throws a full meal onto a sheet pan and the smoke alarm never goes off.

In real operations, reliability is the whole game. Your tools time out. Your permissions are inconsistent. A UI changes and your carefully crafted selector turns into a pumpkin. Someone renames a folder. Your “one quick script” becomes a dependency you forget exists until it breaks on a Friday.

Agentic AI is exciting precisely because it turns language models from answer machines into action machines. That move also drags you out of the clean world of text and into the sticky world of systems. The failure modes stop being abstract. They become your calendar.

Here are seven ways agents fail in practice, and the design patterns that keep the damage small.

The first failure mode is permission drift. Your agent starts life with a neat set of credentials and a clean scope. Then someone adds a tool, upgrades a role, shares a drive, or changes an API key policy. Six weeks later the agent can do more than you intended, or less than it needs, and you only discover it after it has already taken a wrong action.

The fix is to treat permissions like production code. Separate “read” from “write.” Separate “can propose” from “can execute.” Make the default path for any irreversible action require a human tap. If you want a simple rule you can implement today, it’s this: agents can draft, humans can send. That one line prevents an embarrassing number of incidents.

The second failure mode is UI flakiness. A human can look at a webpage and instantly adapt when a button moves or a pop-up appears. Agents are getting better at this, but the long tail is still brutal. Cookie banners, two-factor prompts, modal dialogs, A/B tests, slow loads, and infinite scroll are not edge cases. They are the internet.

The fix is to prefer APIs over interfaces wherever you can. When you must use a UI, design for recovery: take screenshots, log the exact step, and include a “resume from here” checkpoint that a human can repair. If your agent can’t explain where it got stuck in plain language, it’s not an agent. It’s a roulette wheel.

The third failure mode is rate limits and hidden quotas. You don’t hit them in a demo. You hit them when the agent is running for real, at the same time as your team, on the same vendor account, in the same hour. Then you get partial completion. Half the emails drafted. Three of the five records updated. A queue that looks finished until you notice one missing row.

The fix is idempotency and retries with backoff. Every action should be safe to run twice without doubling the damage. Every batch job should be restartable without redoing already completed work. If you’ve ever paid for the same ad twice or sent the same invoice twice, you already understand why this matters.

The fourth failure mode is partial execution that looks like success. Agents are good at moving forward. They are less good at stopping to verify. They’ll happily paste something into the wrong field and then tell you the task is complete because the interface didn’t scream.

The fix is explicit verification steps that are separate from the action. After writing something, read it back. After updating a record, fetch it again. After creating a file, check it exists. If you can’t verify, report uncertainty. You want an agent that can say “I did not confirm this, here’s why,” because that sentence is the difference between a manageable miss and a silent disaster.

The fifth failure mode is memory drift. The agent “remembers” a process that used to be correct, or it carries forward a stale assumption about how your team works. This is not science fiction. It’s the same problem you have with new hires who learned the workflow from an outdated doc, except now it can happen at machine speed.

The fix is to make the process external and versioned. Don’t rely on an agent’s internal recollection of “how we do things.” Store the steps in a playbook file, a checklist, or a small set of rules. Update it when reality changes. Make the agent read it every run. The goal is to move truth out of the model and into something you can inspect.

The sixth failure mode is toolchain brittleness. Agents often depend on a chain of services: model provider, browser runtime, auth system, spreadsheet API, ticketing system, and your own scripts. When something fails in the middle, you get a mess that’s hard to unwind because the failure is not in one place. It’s between places.

The fix is simple observability. Log every tool call with inputs and outputs, redact sensitive data, and keep a trace you can replay. You don’t need enterprise monitoring to start. You need a timeline of what happened. If you can’t answer “what did it touch, and in what order,” you can’t trust it.

The seventh failure mode is missing rollback. Humans make mistakes, but humans also have intuition about reversibility. Agents will execute the plan you gave them. If the plan is wrong, they will execute it efficiently.

The fix is to build rollback into the workflow. Create drafts, not final changes. Use staged commits. Use “propose then apply” patterns. Keep backups. If your agent can’t undo its last action, it shouldn’t be allowed to do that action in the first place.

None of this is glamorous. This is not the part of AI that gets retweeted. But it’s the part that determines whether agents become a daily advantage for you or a recurring headache you learn to avoid.

If you want a minimal safe-agent checklist to start with, it’s boring on purpose. Separate read/write permissions. Log every step. Make actions idempotent. Verify outcomes. Keep the process in a versioned playbook. Design for resume. Design for rollback.

You don’t need perfect agents. You need agents that fail loudly, fail safely, and make it obvious what to do next. That’s what reliability actually means.