Why AI agents break in production: 5 patterns and their fixes

About three months after launch, a founder rang me about his support agent. He'd put roughly €18k into it. His team no longer trusted a word it sent.

The complaints were short and ugly. Customers got replies with another client's name on them. Refunds went through that never should have. And when he asked which tickets the agent had closed and which had quietly vanished, nobody on his team could tell him.

His instinct was to blame the model. The model wasn't the issue. The way the agent was put together was.

That distinction decides where your next euro goes. Call it a model issue and you'll pay to swap in a newer LLM, then watch the same failures return in nicer sentences. Call it an architecture issue and you spend the money on the part that's actually broken.

Is the model really the reason AI agents break?

Hardly ever. GPT and Claude aren't the weak link. What kills agents is that nobody planned for the days when things go sideways.

I've built and repaired a lot of agents over the past two years. When I compare the ones still working half a year after launch with the ones that got pulled, the model doesn't explain the gap. Neither does the framework. Neither does the use case. The survivors were designed to fail safely. The others weren't.

In a demo, everything cooperates. The input is tidy, the API answers, and everyone agrees on how the process works. Real operations look different. An API call times out. A customer sends half the details you need. The process has an exception that only lives in one colleague's memory. An agent built for the demo looks brilliant in the sales meeting, then starts burning trust somewhere around week two.

When an agent gets switched off, I nearly always find the same five gaps behind it. Running one today, or about to approve one? Check it against each.

1. What happens when a call fails and nobody notices?

The symptom. A request times out, or the model returns nonsense, and the agent simply halts. There's no second attempt, no alert, no way back. The task hangs there while your team assumes it's done. By the time anyone spots it, you've missed a day's worth of invoices, leads you'd already qualified, or the first reply to a prospect ready to buy. That isn't just wasted time. It's cash arriving late, and a prospect who heard from a competitor first.

The fix. Give the agent a plan B before it goes live:

• Retry with backoff when the error is temporary, like a timeout or a rate limit.
• Switch to a simpler model when the main one is down or keeps producing garbage.
• Hand the task to a human queue once the retries are used up.
• Record the failure with enough detail that someone can repair it without guessing.

One path through a task makes it a demo, not an agent.

The cost. Fallbacks mean more build time and more moving parts. Retries make a slow task slower. Worse, a careless retry can repeat an action that half-ran before the error, so you send two emails or two invoices. The backup model writes weaker output. And the human queue does nothing unless a named person owns it. Even so, all of that is cheaper than a day of work quietly falling on the floor.

2. Could a newcomer follow your process from a document?

The symptom. Ask how a process really runs today and you hear "ask Sarah." Or a shrug and "we just know." Either way, the agent will be guessing at every step.

This comes up all the time. A company asks us to automate their sales onboarding. When we request the SOP, it doesn't exist. Three people run the process, each a little differently, and none of it is on paper. The agent learns a blend of three inconsistent habits, and its output comes out just as erratic.

The fix. It starts before any AI is involved. Write the process down, then automate it. Layer an agent over a fuzzy process and you don't get automation. You get wrong answers delivered quicker and in larger volumes, each one sent under your company name.

It's also the reason we at Arcgent turn down projects when a client won't document the process. That isn't us being difficult. A written process is what lets an agent keep adding value year after year, instead of becoming a write-off half a year in.

The cost. Writing an SOP eats time from the people who know the work best, and it's the step everyone is tempted to skip. It also surfaces disagreements. If three people do the job three ways, someone has to pick the right one, and that's an awkward conversation. Skip it, and the agent makes that call for you, differently each time.

3. If a customer asks what the agent did, could you show them?

The symptom. One prospect showed me their dashboard for the previous week. It listed 142 completed tasks and 23 failures. Failures with a known root cause: 0. Logging was switched off, there were no traces, and debugging was out of the question.

What you can't see, you can't make better. You also can't stand behind it. Picture a customer emailing to ask why their refund never arrived. "I assume the agent dealt with it" won't cut it. Now they're wondering what else you don't know.

The fix. Give every production agent a full record of its work: what went in, what came out, which decisions it made, which retries it ran and where it broke. Store it where anyone can search and audit it, and give it an owner.

No other part of the build pays you back as much, because it changes what a failure is. With a log, those 23 failed tasks are 23 things to learn from. Without one, they're 23 problems lined up to happen again.

The cost. Storage, some setup and a few decisions. Logs contain customer data, so you have to agree who gets access and how long you keep them. And someone has to read them. A log no one opens is just a pricier way of staying in the dark.

4. Who signs off before the agent does something it can't undo?

The symptom. This is the kind of thing that slips through when nobody is watching:

Companies get into real trouble when no one has placed a checkpoint in front of the decisions that call for human judgment. Moving fast with zero oversight leaves you one bad run from a costly mistake that everyone gets to see.

The fix. A human checkpoint costs little to add and close to nothing to maintain. Decide which actions need a person to look first:

• actions you can't take back
• money moving above an amount you set
• anything that changes how a customer relates to you

Send those to someone through Slack, by email or into a basic approval queue. On its own, the agent covers 95% of the work. Someone on your team signs off on the 5% where a mistake would really hurt.

The cost. Approvals add waiting time. Gate too many actions and people start hitting "approve" without reading, which is worse than having no gate. Keep the list short and choose the thresholds deliberately. The real trade-off was never speed against safety. It's speed against the trust your customers have placed in you.

5. How much of your business can the agent reach?

The symptom. Picture an agent that can read all your data, call any API without limits, send output nobody validated and run as often as it likes. One badly worded prompt is all that stands between you and a very costly problem.

The fix. The agents that last in production have a narrow, clearly defined job:

• They only reach the data and systems the task requires.
• Whatever comes in gets validated.
• Whatever goes out is checked against a schema before it leaves.
• Their permissions cover one workflow and nothing more.
• When asked to go beyond that, they stop and raise a flag rather than improvise.

Senior engineers treat a junior developer's pull request the same way. Nobody hands a new hire root access in week one. Your agent shouldn't get it either.

The cost. A tightly scoped agent says no more often. It reaches the edge of what it's allowed to do, stops, and someone has to decide whether to widen its access. That friction is useful. Each expansion becomes a conscious decision instead of a surprise later.

So what do the agents that last have in common?

The agents still bringing in revenue six months after launch share one trait. They were built to handle failure safely, not only to move quickly.

Fallbacks, a written SOP, logs, human checkpoints and a tight scope. None of it is exciting, and none of it goes viral on LinkedIn. But it's why one client's agent keeps resolving tickets, qualifying leads and getting invoices out the door, while three other vendors were quietly swapped out for an intern working from a Notion doc.

Budgeting for an AI agent? Put the money into the unglamorous half. The clever half is a commodity by now.

The five patterns side by side

Five questions to ask about your agent this week

Take the agent your business leans on most and answer these:

1. If its main API goes down, what does the agent do next?
2. Can you point to the written SOP it follows?
3. Could you pull up every task from the past 7 days, with what went in and what came out?
4. Which of its irreversible actions wait for a human to approve them?
5. What is the narrowest scope that would still let it do its work?

Any question where you can't point at something concrete and say "it's right here" is your project for this month.