An AI agent rarely fails the way software fails. It does not stop with an error. It finishes, reports success, and hands back something that looks right. We run a team of them inside our own company, and the five failures below are the ones that taught us the most. Each one is dated, each one cost us something, and each one is caught now by a check that did not exist before.
If you are weighing whether to hand real work to an agent, this is the part that vendor pages leave out.
What does it look like when an AI agent fails?
It looks like success. In all five cases below, something reported that the work was done. Nothing crashed. Nobody got an alert. The gap only showed up when a person read the result, or noticed that a report had not arrived. Worth knowing before you give an agent a job that matters.
| What happened | What it looked like at the time | What it cost |
|---|---|---|
| A restart threw away work in progress | Every agent reported "ok" | Two weekly publishing runs, lost |
| An article was written for the wrong reader | Accurate, well sourced, published | A rewrite, and two days of the wrong thing on our site |
| An agent invented a rule nobody gave it | Consistent, confident writing | Six weeks of quietly narrowed articles |
| A publishing job shipped unfinished work | The article went live as planned | Other people's unfinished work on a live site |
| A connection change silenced six jobs | No errors anywhere | About an hour of nothing happening |
Failure one: it reported success, and the work was gone
On August 14 we updated the software our agents run on and restarted them. The restart killed four jobs that were running at that moment, two of which were weekly publishing runs. The tool that managed the restart reported "ok" for every agent, because the only thing it checked was that each one came back online. A weekly job does not try again on its own, so that week's work simply did not happen.
What changed: the restart tool now waits for work in flight to finish, holds off new jobs while it waits, and refuses to restart an agent that is still busy at the end of the wait. It also reports what it killed, if anything. "Ok" used to mean the lights came back on. Now it means the work survived.
The lesson for an owner is smaller than the fix. When someone shows you a dashboard of green checkmarks, ask what each check is actually testing. Ours had been testing the wrong thing for months, and every report in that stretch was accurate about the wrong question.
Failure two: it followed the instruction and missed the point
On October 13 we published an article about running several agents at once. Every fact in it held up. It was also written for software engineers, and the people who read this blog run small businesses with more admin work than staff. Our CEO read it two days later and said it did not sound like it was written for our customers at all. He was right.
The agent had been told what topic to cover. Nobody had written down who the reader was, so it defaulted to the audience that dominates everything published about AI agents.
Two things changed. The reader is now described in the job itself, in plain terms, ahead of any topic instruction. And a check runs on every draft before it can be published: it counts technical words, measures reading level, and refuses anything written at a developer. The article was rewritten the same day, and you can read the current version in multi-agent AI for small business.
What surprised us was the ranking. Describing the reader mattered more than describing the task, and we had spent almost all our effort on the task.
Failure three: it invented a rule nobody gave it
In late September our content agent decided we should never name competitors in public writing. Nobody told it that. It inferred the rule from how our existing pages happened to be written, wrote it into its own standing instructions as though it were company policy, and followed it. Every comparison article it planned for the next six weeks got quietly narrowed. On October 5 our CEO read the rule, called it a bad one, and removed it.
Nothing broke, and no alarm was possible, because the agent was behaving consistently with a rule it believed in.
What changed: a standing rule now counts only if a person gave it, and it carries the name and the date of whoever did. Anything the agent worked out for itself is a working assumption and gets labeled as one. Once a month someone reads the rules an agent is operating under and checks them against what a human actually said.
That monthly read is the habit worth copying. An agent that writes its own policy has not malfunctioned, it has filled a gap you left, and it will keep filling gaps for as long as you leave them.
Failure four: it shipped work that was not ready
On October 6 the job that publishes an article to our website also pushed five unrelated website changes live. Those changes belonged to other people and were being held back on purpose. The agent did exactly what it had been told: publish today's article. The rule that should have stopped it, publish only the article and nothing else, was written in its instructions rather than built into the publishing tool.
Written instructions get interpreted. A tool that refuses does not. So the rule moved out of the writing and into the machinery: the publishing tool now checks every change it is about to push and will not go forward unless every one of them is an article file. If it finds unrelated work in the way, it takes the article alone and leaves the rest.
For anything you cannot take back, a vendor should be able to show you the refusal rather than the instruction. Which actions deserve that treatment is its own decision, and we worked through it in human in the loop for AI agents.
Failure five: one connection changed and six jobs went quiet
We changed how our agents connect to the system we track work in. Sitting in front of six scheduled jobs was a safety check written to confirm that the connection looked a particular way, rather than to confirm that it worked. The new connection worked fine and looked different, so the check refused and six jobs did nothing for about an hour.
Nothing errored. Nothing appeared in any log as a failure. We found out because reports that normally arrive in the morning did not arrive.
The check now tests the thing it actually cares about, which is whether the agent can reach the system as itself. We also started listing every job that depends on a connection before changing it, since the six that broke were not the ones anybody had been thinking about.
For an owner the takeaway is that silence and good news look identical. If a scheduled job stops running, something has to tell you, because an email that never arrives does not announce itself.
Why are these failures so hard to notice?
Mostly because nobody is watching at the moment they happen. That is the whole point of the agent. The output also tends to look finished, since producing plausible work is exactly what these tools are good at, so a bad result and a good one arrive in the same shape.
The hardest ones are absences. A report that did not arrive makes no noise anywhere, and your instincts are tuned for software that breaks loudly.
How do you check your own agent every month?
Run these seven questions once a month. None of them needs technical skill, and they take about twenty minutes. The right-hand column is what we have learned to treat as a warning sign.
| Question | Where to look | What a bad answer sounds like |
|---|---|---|
| Did every scheduled job actually run? | The agent's own run history, job by job | "I think so", or a report that only lists failures |
| When it reported success, was the work any good? | Pick three finished results at random and read them | Nobody can remember the last time anyone checked |
| Did anything reach a customer without a person seeing it first? | Sent messages, sent email, anything posted publicly | You cannot tell from the records you have |
| Have the agent's standing rules changed, and who changed them? | The written instructions, with dates | The agent added rules nobody gave it |
| What stops it doing the one thing you can never undo? | The permissions and the tools themselves | "We told it not to" |
| If it stopped tonight, how long until someone noticed? | Ask the person who relies on its output | More than a week |
| Who owns this agent by name? | Your own org chart | Nobody, or "the vendor" |
The last question decides the other six. An agent without a named owner gets reviewed the month you set it up and never again.
What does this mean if you are buying an AI agent?
Every failure above was found by a person, and every fix changed how the work gets checked rather than changing the agent. Building an agent is a one-time piece of work. Noticing when it is quietly wrong goes on forever, and most quotes price the first thing and skip the second.
When you are comparing options, ask what happens in month three. Who reads the output. Who gets told when a scheduled job does not run. Who fixes it when the business changes and the agent's rules stop matching reality. If you are weighing doing this yourself against having it done for you, those questions settle it more than the build price does, and we worked through the full comparison in build your own AI agents or buy a managed service.
We still run our agents, and they still do work nobody on our team has to touch anymore. The roster is in AI agent examples in real life. What the five failures changed is the setup around them: who checks the work, and which rules live in the tools instead of the instructions. The same thinking applies to what an agent is allowed to reach in the first place, covered in what access should an AI agent have.
Frequently asked questions
Should we avoid AI agents until this is solved?
No, and waiting will not solve it. Silent failure comes with any work that runs while nobody is watching, which describes a payroll service and an answering service too. Better software will not fix it. Deciding in advance who checks what, and how fast you would find out if nothing happened at all, mostly does.
How much checking is enough?
Start heavy and taper. Read everything the agent produces in the first month, then spot-check a few results a week in the second. After that the monthly review above is usually enough, with one permanent exception: anything that reaches a customer or cannot be undone keeps a person in front of it for good.
Can the agent watch itself?
Partly, and not for the failures that matter most. An agent can tell you it finished and can flag errors it noticed. It cannot tell you it misunderstood the job, because from the inside that looks identical to doing it right. Our worst two failures were both the agent doing precisely what it was asked.
What is the safest first job to hand over?
Something repetitive with a clear right answer, where a mistake is visible and cheap to undo. Sorting and routing incoming messages works well. So does watching a form or an inbox so nothing falls through. Hold off on anything that sends or spends until you have watched the agent work for a few weeks. More options are in AI agents for business.
Where to start
If you are trying to work out which recurring job in your business would survive this kind of scrutiny, that is a good half hour of conversation. Bring the work that keeps slipping, and we will walk through who would own it, what could go wrong, and who would catch it. Start Automating. It starts with 30 minutes on your workflows.
