The article describes five common failure points in AI automations and shares practical patterns for avoiding issues like duplicate processing and silent errors, based on the author's experience with 30+ production systems.
Every one of these AI automation builds looks different on a sales call. Open them up and they're almost identical. Something lands in an inbox. Someone reads it. They type the information into a system the company already pays for. Claims go into an agency system. Intake goes into records software. Client details go into a CRM. Same basic wiring underneath every time. I run an AI agency, so obviously there's bias here. What I do all day is find the one repetitive process quietly draining money out of a company, put a real number on what it's costing, and build something that takes it off their hands. I've got 30 plus of these in production, and almost every inbox based one has broken in the same 5 places. One of them cost me an entire weekend. I'll flag it when we get there. None of this is clever. That's sort of the point. Create the case first The failure this prevents: duplicates. When something arrives through an inbox, a folder or a webhook, the system immediately creates one case for that item and gives it a permanent ID. Only after that does anything start reading the content. The case is keyed on the message ID plus a hash of the attachment. So when the same email gets forwarded, replied to, or retried after a timeout, we dont quietly process it twice. Without this, the second copy shows up a month later and it's never at a convenient moment. Extract only what you actually need The failure this prevents: confident gap filling. The AI reads the document and pulls out only the fields the destination system needs. Each field gets a confidence score. The model has exactly one job here. Read. That's it. It doesn't decide what happens next, it doesn't write into the destination, and it doesn't get to freestyle. This matters most with photos of forms. Someone snaps a picture of a form on their desk, the text reader misses one important number, and the model fills that gap with something that looks completely normal. So low confidence isn't a prompting problem I try to solve with better wording. It's a routing decision. Send it to a human. Validate against the actual system The failure this prevents: values that look valid and aren't. Before anything gets written, every field gets checked against the system it's about to enter. Does that reference actually exist? Does the name match? Is the date within the allowed window? Is this already an open case? A value can be perfectly well formed and still completely wrong, and no amount of confidence scoring catches that on its own. Only the destination system knows. Write as a draft, not a final record The failure this prevents: the partial write. This is the weekend one. The system never creates the final record straight away. It creates a draft. A person reviews it, approves or corrects it, and every correction gets logged. Heres what I learned the hard way. Sometimes the destination accepts half the data and times out on the rest, or creates the record and drops the attachment. Nothing throws an obvious error. You end up with a record thats half there while your automation is convinced everything worked. So every write now checks itself afterwards. We read the destination back and compare what actually landed against what we tried to send, and the case only closes when those match. An overnight job also hunts for cases marked done with no record behind them, and that has caught a surprising number of quiet failures. Worth queuing your writes here too. When a destination throttles and every retry fires at once, a normal Monday morning starts to look like an attack, and the duplicates it creates are a worse problem than a claim landing 30 seconds late. Put failures into a queue, then watch the corrections The failure this prevents: silent drift. Anything that fails, comes back low confidence, or needs a human goes into an exceptions queue. The team gets a simple daily summary of what came in, what got written, what got held back, and what needs attention. And there's one number I watch more closely than any of that. Human correction rate. A form changes. A label gets renamed. A sender starts putting the reference number somewhere else entirely. The AI keeps returning tidy looking data, your validation keeps passing it, and nothing technically breaks. But humans start correcting the same field more often than they did last month, and that's your warning. I fingerprint the input shape too, but honestly the correction rate moves first.
An agency founder shares lessons from 50+ AI automation implementations, highlighting that most fail due to broken underlying processes, lack of internal ownership, and over-engineering, while the most successful automations are simple, focused, and backed by a named client-side owner.
The author reflects on conversations with people running AI automations, noting a pattern where verification is dropped after initial audits, which may hide silent failures. They ask for concrete stories about automations that were wrong without anyone noticing.
The author shares two years of experience building a platform with AI, identifying six recurring failure modes (Band-Aid, Assumption, Drift, Hallucination, Lack of Common Sense, Path of Least Resistance) and argues that even as models improve, these failure modes persist, becoming harder to detect.
A production system of 8 AI agents autonomously caught and fixed three distinct failure modes overnight, including an infrastructure bug, a platform parsing bug, and a documentation bug, demonstrating a self-improvement loop that treats code and process failures identically.
The article highlights common issues with complex AI workflows, such as lack of documentation and knowledge transfer, and suggests practices like versioning and testing to improve team handoffs.