These systems fail in a small number of recognizable ways. Learning the list turns a bad afternoon into a ten minute diagnosis, and it is the single most practical thing in this guide.
Work down the list. Each entry is a symptom, the layer from chapter five that owns it, and what actually fixes it. Notice how rarely the answer is a better model.
It cannot reach what it needs, or it reaches too much
Environment. The most common failure by a distance, and it presents as stupidity. The system gives a confidently wrong answer because the correct information was never in front of it. Before touching anything else, look at what it actually retrieved or was actually given access to. The reverse case is quieter and worse: it reached something it should not have, worked correctly, and nobody noticed because nothing broke.
It forgets what it did yesterday
Environment. Every run starts from nothing, so it redoes work, contradicts last week's decision, or loses the thread of a long task. The fix is boring and durable: write state to a file or a table at the end of every run, read it at the start. People reach for elaborate memory systems when a small file solves it.
The output is close, but nobody trusts it unattended
Feedback. Usually correct, occasionally not, no way to tell which. The fix is not a better model. It is a check the system runs itself. Does the total match, does the referenced record exist, is the required field populated. Then route only the failures to a person. This converts an unusable system into a useful one without improving the model at all.
It reports success and the result is wrong
Feedback. The worst one, because it is silent and it erodes trust permanently once discovered. It happens when success means "the step completed without an error" rather than "the thing we wanted is true." Define success as a property of the outcome, verify it, and make the system say so when it cannot.
It keeps retrying and the bill climbs
Flow. Something fails, the system tries again, fails the same way, and loops. The fix is limits everywhere: maximum attempts, maximum steps per run, maximum spend per day, and a hard stop that alerts a person rather than continuing quietly. Set these before launch, not after the invoice.
Something broke three steps back and nobody can find where
Flow. Long runs fail at the end and the transcript is unreadable. Log each step as a separate record with its input, output, and duration, and make failures point at a step rather than a run. This is the difference between a ten minute investigation and an afternoon.
Work runs out of order, or an approval gets skipped
Flow. Two things run at once and overwrite each other, or something proceeds past a gate that was supposed to hold it. The fix is structural: the gate must be a place the work cannot pass rather than an instruction it is asked to respect.
It follows instructions that came from the material it was reading
Environment. Covered in chapter six, and it belongs on this list because it presents as bizarre behavior rather than as an attack. The system starts doing something nobody asked for, and the origin is text inside a document, an email, or a web page. The fix is the triangle: do not let one system read untrusted content, hold private data, and send things outward.
It genuinely cannot do the task
Model, and it is worth naming because it does happen. Everything else is right, the information is in front of it, and the output is still not good enough. Try a stronger model or narrow the task. If neither works, the honest answer is that this is not a good fit yet, and saying so early is more valuable than persisting.
Build these three before you need them
Whatever you ship, ship it with these, because retrofitting them after an incident is done under pressure and in front of an audience:
- A step log you can read without being the person who built it.
- A kill switch that one named person can use in under a minute, tested at least once while nothing is wrong.
- A limit on everything that repeats: attempts, steps, spend, and time.
Revision trail