Why did your AI automation break without anyone noticing?

Green does not mean right

A workflow step usually reports two states: it ran, or it threw an error. Almost everything that goes wrong with an AI system lands in neither. The call succeeded and returned nothing. The model answered confidently and wrongly. The provider returned a success code with a rate-limit message inside it. The scraper got a page, and the page was a block screen. Every one of those looks like a green run in the log.

This is why the first sign is a person. Someone downstream notices the numbers look off, or a customer asks about an email they never got. By then the wrong data has been sitting in the system for weeks and nobody can say since when.

Four ways it happens

• Empty is indistinguishable from correct. A search that finds nothing and a search that is being blocked return the same shaped result, and nothing raises an error either way. Reading a stated yield or success rate against its usual range is the only way to catch it, because there is no exception to catch instead.
• A silent blend. Brain, the planning system OCTYN runs its own work on, is built around one rule: it never mixes two projects into one answer. There is no automated check for that yet. Today, catching a blended answer still depends on the person who asked noticing it themselves, which is the honest, dated state of that system.
• Schedules that only look at today. On 2026-08-10, the craft retailer's outreach system had 115 follow-ups come due across an unattended weekend, and the next working day already held 93 against a daily cap of 60. Nothing raised an error. The schedule now moves overflow forward when a follow-up is created, and moves weekend dates onto the next working day.
• A model taking an action it cannot take back. On 2026-08-12, a company had already replied naming the right person, and a separate step in the same system saw an old shared inbox go quiet and queued a first-touch email to a third person at the same company. It was stopped sixteen minutes before it would have sent. The rule now is that the moment anyone at a company replies, that company belongs to the conversation, not the cold sequence.

The fix costs less than the failure

None of the above needed a big monitoring system. It needed someone to decide, in advance, what the system looks like when it is working, and then to check that one number.

Three things carry most of it. Pick one number per pipeline that only moves when the pipeline is healthy, and read it on a schedule. Make anything destructive refuse before it can proceed, so a mistake becomes a visible error instead of missing rows. And keep a model away from anything that cannot be undone: on the craft retailer's system, sending has no model in it at all, because a reasoning-driven sender was tried first, and it made things up, sent the wrong thing, and then reported a send that had not happened.

The replacement is a small, plain service that checks for due emails every minute, marks each one as it goes, and confirms every send. Boring on purpose. The interesting part of a system should never be the part that can do damage.

How to tell from the outside

You cannot check a system you did not build, but you can ask what it does when something goes wrong, and the answer arrives fast either way. Ask what the last silent failure was and how it was found. Anyone who has run a system in production has one. An answer of none usually means it has not run long enough, or nobody was looking.