Blog / AI & Automation

Why AI Agents Break in Production (and What to Build Instead)

By Keyona Meeks, Founder, ReRev Labs · Oct 30, 2026 · 10 min read

The short answer: AI agents fail in real businesses because they make a fresh decision on every run. Results vary, small mistakes stack up, tools get called wrong, every run costs money, models get retired, and anything they read can try to give them orders. The fix: have AI write plain code, and use a model only where a person or rule checks it.

By the end of this post, you'll be able to:

• Name the seven ways AI agents fail in live business processes, with the published research behind each.
• Pick the fix for each one before you build.
• Run an eight-point checklist on any AI system you're about to trust with real work.

The story usually goes like this. Someone sets up an AI agent to handle their inbox, their lead follow-up, or their invoicing. It is magic for a week. Then it sends something it should not have, skips something it should have caught, or starts doing the job slightly differently on Tuesdays, and nobody can explain why.

Nobody did anything dumb. An agent was asked to do a job a system should have been doing. These failures are predictable enough to design around before you build. Here is what goes wrong, and what we build at ReRev instead.

What counts as an "AI agent" in a business?

An AI agent is a language model given a goal and tools (your email, your CRM, a browser) that decides its next step while it runs. The full comparison with plain automation is in AI agents vs. automation. This post is about what happens when an agent meets daily work.

Why do AI agents fail in real businesses?

Seven failure modes show up over and over. Each comes with its fix.

1. The same input gets a different result

A language model does not run the same way twice. Useful for headline ideas. A problem when the question is "should this invoice go out?"

Researchers measured this. The τ-bench study (2024) gave agents customer-service tasks with policies to follow and ran each task repeatedly. Even state-of-the-art agents like GPT-4o succeeded on fewer than half the tasks, and in the retail scenario got a task right all 8 times in under 25% of cases. Newer models have shipped since, but the lesson holds: working on Monday is not proof it works on Friday.

The fix: anything that can be written as a rule should be code. Code gives the same answer every time, and you can read why.

2. Small mistakes compound across steps

Every step an agent takes is built on the step before. One wrong read early on (the wrong customer, the wrong date) gets carried forward and acted on. Anthropic, the company that makes Claude, says it directly in its guide to building effective agents: "The autonomous nature of agents means higher costs, and the potential for compounding errors."

A benchmark called TheAgentCompany (first published December 2024, revised 2025) built a simulated small software company and gave agents everyday work tasks. The most competitive agent in that study completed 30% of tasks on its own, and longer, harder tasks were still out of reach. (I walk through the simple math of stacked errors in the pillar post, so I won't repeat it here.)

The fix: short, fixed paths. The order of steps lives in code, and each step checks a real fact (did the row get written, did the email land in drafts) before the next one starts.

3. The agent uses its tools wrong

Agents work by calling tools, and a lot of failures are not "the AI was dumb" but "the AI used the tool slightly wrong." Anthropic shared a good example from its own work: while building a coding agent, the team spent more time improving its tools than its instructions, because the model kept making mistakes with file paths after moving out of the main folder. Changing the tool to require full paths fixed it (same guide).

That was an AI lab tuning its own model. Your agent meeting a CRM it has never seen will have rougher days.

The fix: let code call the tools. When the model's job is only to fill in a field, there is far less room for it to call the wrong thing.

4. The bill runs on every run

An agent pays for the model every time it thinks, and a multi-step job means many thoughts per run. A script inside tools you already pay for, like Google Workspace, does not. (Our breakdown of automation costs has the numbers.)

The fix: spend the AI once, at build time. The intelligence goes into writing the code, not into every execution.

5. The model underneath changes or disappears

This is the one almost nobody plans for. AI providers retire models on their own schedule. Anthropic's model deprecations page says it gives at least 60 days' notice before retiring a publicly released model, and that requests to a model past its retirement date will fail. OpenAI's deprecations page shows that on October 14, 2026, it told developers GPT-4o and GPT-4.1 will be removed from its API on January 14, 2027. It also notes that preview models can be retired with as little as two weeks' notice.

Even a swap to a "better" model shifts behavior. For an agent running your process, that is a silent change to how your business operates.

The fix: keep model calls few, small and isolated, so a model change touches one step you can retest, not the whole process. Plain code does not need any particular model to stay available.

6. When it breaks, nobody can say why

When a script fails, you get an error on a specific line. When an agent fails, you get a confident explanation of what it thinks happened, and a different path next time.

The fix: logs you can read, and decisions made by rules you can point at. If a person on your team cannot answer "why did it do that?" in five minutes, it is not ready to run unattended.

7. Anything the agent reads can try to give it orders

This is the security problem. OWASP, the nonprofit behind widely used security standards, ranks prompt injection as risk number one in its Top 10 for LLM applications. "Indirect" prompt injection is when instructions are hidden in content the AI reads, like a website or a file, and they change what it does. OWASP is blunt that "it is unclear if there are fool-proof methods of prevention for prompt injection."

So if an agent reads your inbox and can also send email, anyone who can email you can try to steer it. OWASP's companion entry on excessive agency traces the damage to agents with too much functionality, too many permissions, or too much autonomy, and recommends requiring a human to approve high-impact actions.

The fix: the model never holds the keys to anything you cannot undo. It can read and draft. Code with narrow permissions does the acting, and a person approves anything irreversible.

What do these failures look like side by side?

What should you build instead?

The pattern we build with: AI writes the code, plain automation runs it, and AI models only show up at specific points where a person or a rule checks the result.

A worked example: the Follow-Up Engine

One of my own systems, The Follow-Up Engine, shows the shape. Here is what it does, step by step:

1. A meeting transcript lands in a shared folder. That is the trigger, and it is the same every time.
2. Claude reads the transcript and pulls out what matters. The same run drafts the follow-up email, creates the tasks, and updates the contact record.
3. The email lands in my Gmail drafts, not in anyone's inbox.
4. I read it and hit send. The one step that cannot be taken back, emailing a real person, stays with me.

Now hold it up against the seven failures:

• Inconsistent results (1): the model writes a draft, and a draft that varies a little is fine because a person reads it.
• Compounding errors (2): the path is fixed in code. The model does one job in the middle, not every step.
• Tool mistakes (3): the steps run in the same order every time, and the step that matters most, the email, only ever becomes a draft.
• Cost per run (4): one model call per meeting, priced in cents (the math is here).
• Model changes (5): if the model is retired, one step needs retesting, not the whole system.
• Hard to debug (6): each step either happened or it didn't. The draft is in Gmail or it isn't.
• Prompt injection (7): even if a transcript contained hidden instructions, the worst outcome is a strange draft, a stray task or a wrong note on a contact. I see all of them, I can undo all of them, and no email leaves without me.

That last point is the design goal. You can't guarantee the model will never be wrong, so you arrange the system so that being wrong is cheap and visible.

Most of what I build runs on Google Apps Script, written by Claude, inside a Google account the business already has. The AI does its heaviest work once, when it writes the code.

A checklist before you put AI in a live process

1. Can the rules be written down? Then write them as code. Use AI to write that code.
2. Is the path fixed? The order of steps should live in code, not in the model's head.
3. Where exactly does the model appear? Name each point: reading messy input, drafting, summarizing.
4. Who or what checks each model output? A person, or a rule (a required field, an allowed list of values).
5. What can it touch? Give it the narrowest access possible. Read access is not send access.
6. What is irreversible? Money, emails to clients, deleting records. Those need a human approval step.
7. What happens when the model changes? You should be able to retest one step in an afternoon.
8. Can someone explain a failure in five minutes? If not, add logging before launch.

If you are not sure which job to start with, what to automate first walks through picking one. If your team wants to build these systems itself, our AI and automation training for teams teaches building, not just prompting.

Where this has limits

Agents are not useless, and I want to be fair.

• Some work really is open-ended. Research or a coding session you are watching fit an agent, because a person is right there steering.
• Plain code breaks when inputs change shape. The difference is that you will know exactly where.
• Models keep getting better. The research I cited is from 2024 and 2025, and newer models may well score higher on those tests. Better scores do not remove prompt injection or model retirements, and "usually right" is still not the bar for sending money or emailing clients.
• Someone has to own the system. True of any automation, and a real cost.

Frequently asked questions

Why do AI agents fail in production?

They make a new decision on every run, so results vary, early mistakes carry forward, and tools get called wrong. Every run also costs money, model updates change behavior, and content the agent reads can manipulate it.

Are AI agents safe to connect to my email?

Reading and drafting is lower risk. Letting it send email or change records on its own is risky, because hidden instructions in incoming messages can steer it, and OWASP says no fool-proof prevention is known.

What should I build instead of an AI agent?

Have AI write a plain automation, like a Google Apps Script, that follows fixed rules. Add a model only at specific steps such as reading messy input or drafting text, and have a person approve anything irreversible.

Do AI model updates break automations?

They can break anything that depends on a specific model. Requests to retired models fail. Plain code does not depend on a model, so it keeps running.

Will AI agents get reliable enough to run a business process alone?

They are improving quickly. For most small-business processes today, a fixed system with a human approving the risky steps is still more reliable, cheaper and easier to fix.