The Silent Failure Manual

How to tell whether an AI agent will do your work — or quietly produce wrong work and report success

Tim Raysby · v1 · 2026-08-07

---

Read this first

You do not need another AI tools roundup.

You need a way to answer one question before you hand a workflow to an agent: if this goes wrong, will anything tell me?

That question is not about model quality. It is not about prompt engineering. It is a property of the workflow, and you can score it in about ten minutes per workflow, on five gates, before you spend a dollar on tooling.

This manual is that scorecard, plus the reasoning behind it, plus four ways I have personally been lied to by software I wrote and operate every day.

Who this is for: anyone about to hand real work — work with your name on the output — to an AI agent. Founders, engineering leads, senior individual contributors, operators of small teams. If you’re evaluating agents for a workflow where being wrong costs something, you’re the reader.

Who should close the tab: if the worst case is a mildly wrong draft that a human reads before it goes anywhere, you don’t need any of this. Automate it. Find out.

What I’m not claiming. I have no clients to quote. Every number in here comes from logs and commits on a system I built and run on my own hardware — not from a client engagement, not from a survey, not from a vendor’s case study. Where I’m uncertain I say so. Where the system failed, I show the failure, because the failures are the part worth paying attention to and I’d rather hand you those than a clean story.

---

Part 1 — How agents actually fail

Software fails loudly. It throws, it crashes, it pages someone. You built your entire intuition for “is this working” on that assumption, and it has been reliable for your whole career.

An agent does not fail like software. It fails like a confident intern who tells you the job is done when it isn’t.

The difference matters more than it sounds. A crash is self-reporting. A confident wrong answer is self-concealing — it arrives in the same shape as a right answer, through the same channel, with the same tone. Your monitoring sees a completed run. Your dashboard sees a green tick. The only thing that would distinguish the two is an independent check on the output, and in most workflows there isn’t one.

Below are the four shapes this takes. I’ve hit all four. Each one ends with a warning sign you can check this week and a rule you can apply immediately.

---

1.1 The confident score

The shape: the system attaches a number to a guess, and the number makes the guess look like a measurement.

What happened to me. I had a component that took each item from an incoming briefing and matched it to whichever of my active goals it was relevant to. It scored matches by semantic similarity against a fixed threshold. The threshold was set to 0.25, back when I first wired it up and everything was scoring zero.

Here’s what I didn’t know: sentence embeddings place any two English technical sentences at roughly 0.75 to 0.85 similarity regardless of topic. Not because they’re related. Because they’re both English, and both technical. The floor is high and the ceiling is close to it.

So a threshold of 0.25 didn’t match nothing. It matched everything.

On one briefing: all 20 items matched a goal. Scores ran 0.763 to 0.836. The margin between the winning goal and the runner-up ran from 0.0004 to 0.033, median 0.0107.

Winners were decided by floating-point noise. And every one of them carried a confident-looking score — 0.81, 0.79 — displayed next to the match, in the same format a correct match would have used. A weather-forecasting item was matched to threat intelligence escalation. On screen it looked exactly as plausible as the correct matches, because the number was in the same range.

The fix was not a better model. It was requiring the top match to beat the runner-up by a real separation. That took the briefing from 20 of 20 false matches to 0 of 20.

Why this is the hardest mode to catch: the output isn’t just wrong, it’s decorated. The score is doing active work to suppress your suspicion. You built the scoring display precisely so you could trust it at a glance, and now it’s the mechanism of the deception.

The warning sign, checkable this week: find anywhere your system ranks or scores something. Pull the last hundred decisions and look at the gap between first and second place, not the winning score. If the gaps are tiny and the winners are confident, your ranker is a random number generator wearing a lab coat.

Rule: a similarity score is not a confidence score. Threshold on the margin, not the magnitude. If a ranking system can’t tell you how much the winner beat the runner-up, it isn’t ranking — it’s sorting noise.

---

1.2 The silent skip

The shape: two different situations share a return value, and one of them is “I couldn’t.”

What happened to me. A scheduling function looked fourteen days ahead for the next open publishing slot. One channel gets eight slots per fourteen days. Once those were claimed, the function returned “nothing available.”

Every caller in the system treated that identically to “nothing to do.” Skip. Move on. No log line, because nothing had gone wrong as far as any individual caller could tell.

Sixteen approved items sat invisible for up to thirty days. A repair job that ran on a schedule specifically to catch stragglers re-skipped them on every single pass, for a month, silently, because it inherited the same conflation.

Two things here are worth more than the bug itself.

The check existed one layer too early. I was measuring content quality carefully — named axes, real thresholds, genuine rigour. Nothing measured whether an approved item reached a schedule. I was rigorously verifying the part that was already fine. This is extremely common and almost invisible from the inside, because the presence of a check feels like coverage.

Everything about it looked healthy. The scheduler ran. The repair job ran. Both completed successfully every time. Every component reported success, and every component was telling the truth about itself.

The warning sign, checkable this week: search your code for functions that can return a null, a none, an empty list, or a -1 for more than one reason. Every one of those is a place where “I couldn’t” and “nothing to do” are wearing the same coat. Then find the callers and see how many distinguish them.

Rule: “couldn’t” and “nothing to do” must never share a return value. If a function can fail to produce an answer, it has to say so in a way a caller cannot accidentally treat as success. A skip that nobody counts is a skip that runs forever.

---

1.3 The heartbeat

The shape: the thing you’re monitoring is alive, and alive is not the same as working.

What happened to me. I had a process watching a directory for new files. A file was renamed between the moment it was noticed and the moment it was read. That is completely routine behaviour. Editors and sync tools write to a temporary name and rename into place, so you never see a half-written file.

The resulting error escaped into the dispatch layer and killed the observer thread.

The supervising process kept reporting the unit healthy while it observed nothing, for as long as it stayed up.

Every dashboard was green. The process was running. It was definitely running. It just wasn’t doing anything. Nothing anywhere was in a position to notice, because the only health signal in play was “is the process alive.”

This is why I score whether a workflow can be verified separately from whether it can be recovered. Recovery was easy — restart it. The problem was that nothing triggered a recovery, because nothing knew.

The warning sign, checkable this week: take every automated thing you run. Ask what your monitoring would show if it kept running but quietly stopped producing output. If the honest answer is “the same as now,” you are not monitoring it. You are monitoring the operating system’s opinion of it.

Rule: liveness is not an output metric. Count what a thing produced in the last interval and alert on zero. “The process is up” is the weakest possible claim about a system and it is the one almost everyone monitors.

---

1.4 The quiet regression

The shape: the change improved the thing it was aiming at, and quietly broke three other things.

What happened to me. I run a loop that proposes changes to its own instructions, applies them, measures the result against a recorded baseline, then keeps or reverts.

Twenty-one experiments to date. Thirteen reverted automatically. One kept. Three escalated to me because the loop couldn’t reach a verdict. Four still measuring.

The interesting number is not 13. It’s this: six of those thirteen reverts had improved the exact metric they were targeting.

One raised its target axis by 8.33 points. It was reverted, because it dropped a different axis by 2.67. Three others improved their target and regressed two or three neighbours each. The remaining two improved their target but not by enough to clear the bar — one by 0.49, which felt like a win and wasn’t.

A further three were reverted for a reason I’d recommend to anyone: they could not be measured inside the window. Not “measured and found wanting.” Unmeasurable. The gate reverted them on that basis alone.

The one change that survived raised its axis by 0.87 and regressed nothing.

One keep out of twenty-one is not a broken loop. It’s what an honest gate produces. If your improvement process approves most of what it proposes, it is not a gate — it’s a formality with a log file.

The warning sign, checkable this week: take your last five “improvements.” For each, name the metric it was meant to move and the metric you’d have accepted moving down in exchange. If you can’t name the second one, you weren’t measuring — you were confirming.

Rule: measure a change against everything it could break, not just what it was supposed to fix. And if it can’t be measured in the window, revert it. Without that second half, every change that resists measurement accumulates permanently, and your system slowly fills with things nobody can evaluate.

---

1.5 What the four have in common

None of them threw an error. Not one.

In every case each individual component reported success, and each was telling the truth about itself. The scheduler really did complete. The watcher process really was alive. The matcher really did compute those scores. The failure lived in the space between components — in what nobody was checking.

That’s the whole thesis, and it’s why the scorecard scores workflows rather than tools:

The gap between a workflow you can safely automate and one that will burn you is almost never model quality, prompt quality, or engineering care. It’s whether anything independent checks the output.

---

Part 2 — The five gates

Five questions. Each scored 0, 1, or 2. Ten points possible per workflow.

Score fast. Ten minutes per workflow, first instinct, then go back and apply the honesty checks — which is where most of the value is, because self-scoring fails in one predictable direction and the checks are aimed at that direction.

Gate	The question
Documented	Can the process be written down?
Deterministic	Are the judgment calls encoded as rules?
Verifiable	Is there an automatic check on the output?
Recoverable	What does undo cost?
Delegatable	Does a named human own the output?

---

Gate 1 — Documented

Can someone who has never done this follow a written description and produce the right result?

0	It lives in someone’s head. The person who does it can’t fully explain why they do it that way.
1	Partly written. The happy path is documented; the exceptions aren’t.
2	Written down, current, and complete enough that a competent stranger could execute it.

Why it’s first: an agent cannot run a process nobody can describe. This sounds obvious and gets skipped constantly, because the person evaluating the workflow is usually the person who knows it best, and to them it feels documented.

How you’ll score yourself too kindly: you’ll score 2 because a document exists. The questions that actually matter are when was it last true, and does it cover what happens when things go wrong. A runbook that describes only the happy path is a 1. Most of the value an experienced human adds to a workflow is exception handling, and that’s exactly the part that never gets written down — which means it’s exactly the part the agent won’t inherit.

The fast test: hand it to someone competent who has never done it. Don’t answer questions. Count the questions they’d have needed to ask.

---

Gate 2 — Deterministic

Are the judgment calls encoded as rules, or left to fuzzy interpretation?

0	Fuzzy throughout. “You just get a feel for it.”
1	Rules exist, but a model still makes the final call somewhere in the chain.
2	A model may propose. Code decides. The decision itself contains no model.

The distinction that matters: a model may propose; code disposes. Models are excellent at generating candidates and terrible at being the last word, because the failure mode of a model asked to decide is a confident, plausible, unverifiable answer — which is exactly the shape of failure this manual exists to prevent.

My highest-scoring workflow does this and it’s the reason it scores 10. A model proposes a change to the system’s instructions. A threshold decides whether it lives. The keep-or-revert decision contains no model at all. The model gets to be creative; it does not get to grade its own homework.

How you’ll score yourself too kindly: you’ll score 2 because you wrote rules down. Trace the actual chain and find the last point where a judgment is made. If a model is sitting at that point, you’re a 1, no matter how many rules precede it.

A second trap, and I fell in it: a fixed numeric threshold is only deterministic if the threshold is correct. My matcher had a rule. The rule was 0.25. It was deterministic and it was catastrophically wrong for months, and the determinism made it harder to spot, because deterministic things feel principled. Rules need calibration evidence, not just existence.

---

Gate 3 — Verifiable

Is there an automatic way to check the work was done right — one that does not rely on the agent’s own report?

0	The agent’s report is the only check.
1	A check exists, but it wouldn’t catch the way this actually breaks.
2	Output is checked against something independent of the thing that produced it.

This is the gate that decides everything. If nothing independent checks the output, the agent’s claim of success is your verification. Part 1 is four stories about what that claim is worth.

How you’ll score yourself too kindly — and this is the single most common error in the whole scorecard: you’ll score 2 because a check exists. The question is not whether a check exists. It is whether that check would catch the way this workflow actually breaks.

My content pipeline scored its drafts on named quality axes with real thresholds. Genuine rigour. And sixteen items sat unshipped for a month. Every check I’d built verified the part that was already fine. A check pointed at the wrong layer is worse than no check. It converts your uncertainty into false confidence.

The fast test — the pre-mortem question: it’s six weeks from now and this workflow has quietly produced wrong output the entire time. Write down what broke. Now ask: which of my existing checks fires? If none of them do, you’re a 0 or a 1, whatever the check count says.

What counts as independent:

• Recomputing the result by a different method and comparing
• Checking against a known-good reference output
• A downstream assertion on state (“if this was approved, it must now be scheduled”)
• Counting output volume and alerting on zero
• A sampled human review with a fixed ratio, tracked

What does not count:

• The agent saying it’s done
• The agent grading its own output
• A second model asked to check the first one, with no ground truth anywhere
• The process still being alive

---

Gate 4 — Recoverable

If this is wrong, what does undo cost?

0	Irreversible. Money moved, an email sent, data destroyed, something said in public.
1	Undoable with real effort, or partly undoable.
2	Revert is cheap, fast, and the default posture.

Undo cost is the only gate I treat as a veto rather than a factor — see Part 3. A workflow that’s unverifiable and unrecoverable is how you find out from a customer.

How you’ll score yourself too kindly: you’ll score 2 because you could undo it. Have you ever actually undone it? Under time pressure? Recovery paths that have never been exercised are theories, and the median untested backup restore is a bad afternoon.

The fast test: actually do it. Take a real item through the workflow and reverse it, with a timer running. The number you get is your true recoverability score, and it’s usually worse than you’d have guessed.

Note on partial recovery: my file watcher restarts fine, so recovery is trivial — but anything that arrived while it was dead is simply gone forever. That’s a 1, not a 2. Being able to restore the process is not the same as being able to restore the work.

---

Gate 5 — Delegatable

Does a named human own the output, and can the agent earn trust gradually?

0	No owner, no gate. It runs and the output goes wherever it goes.
1	An owner exists, but the gate is nominal — approval without inspection.
2	Named owner, real gate, and a path for the agent to earn more autonomy from evidence.

How you’ll score yourself too kindly, and this one cost me a month: you’ll score 2 because a human approves each item. I approved all sixteen of the items that then sat unshipped for thirty days.

Approval felt like handling. So it replaced the question “did this actually ship?” instead of prompting it.

A human in the loop raises confidence whether or not it raises verification. When those two come apart, the gate is worse than no gate — because it retires your suspicion.

Ask what the approver is actually inspecting, and whether they’d catch this workflow’s real failure mode. An approver looking at content quality will never catch a delivery failure. They’re not being careless. They’re looking at the wrong layer, and the gate’s existence is what convinced everyone the layer was covered.

On graduated trust: the strongest version of this gate isn’t “a human checks everything forever.” It’s an agent that starts fully gated, and earns wider autonomy from recorded evidence — with escalation when it can’t decide. Mine escalated 3 of 21 experiments to me rather than guessing. Escalation is not a failure of autonomy; it’s the thing that makes autonomy safe to grant.

---

Part 3 — The verdict

Add the five scores. Then apply the overrides, which beat the total.

The bands

Total	Verdict
9–10	🟢 Safe to automate now
6–8	🟡 Fixable first — usually one or two specific gaps
0–5	🔴 Do not hand this to an agent

The two overrides

These are not factors to weigh against the total. They’re gates, and I state them as rules because hedged advice is how people talk themselves back into a bad automation.

Override 1 — A 0 on Verifiable caps the workflow at “fixable first,” whatever the total.

If nothing independent checks the output, the agent’s own report is your check. A workflow can score 2 on everything else and still be uncontrolled: well documented, fully deterministic, cheap to undo, clearly owned — and producing wrong output that nobody will notice, because “notice” was never built.

Override 2 — A 0 on Recoverable is a veto. Full stop.

Not a factor. Not something a strong score elsewhere compensates for. If the action cannot be undone, an agent does not get to take it unattended until that changes. Undo cost is the only property here that turns a bad day into a permanent one.

The multiplier the gates don’t know about

The five gates measure the workflow. They know nothing about what it costs when it’s wrong. That’s yours to supply, and it’s why the worksheet asks for one line on blast radius per workflow.

A wrong number in an internal report and a wrong email to your largest customer can score identically on all five gates. They are not the same decision. Where the cost is high, require a 2 on Verifiable and a 2 on Recoverable regardless of the total — and where it’s genuinely low, stop reading and go automate it.

What to do with each verdict

🟢 Safe now. Automate it. Then go to Part 5, because “safe now” is a statement about today and drift is real.

🟡 Fixable first. This is where most workflows land and it’s good news — the gap is usually one specific missing check, not a rewrite. Part 4 is the fix paths. In my own audit, both yellow workflows needed the same thing: an output check. Each was an afternoon.

🔴 Do not automate. Not “never.” Not yet. Name the gate that’s failing, fix that, rescore. The mistake isn’t having red workflows; it’s automating one anyway because it produced plausible output during the trial. Mine did that for months.

---

Part 4 — The fix paths

For everything in “fixable first.” Take the cheapest rung-move first — not the most important-sounding one. You are trying to move workflows across a line, not to build a perfect system.

Raising Documented

• Write it while doing it, not from memory. Memory documents the happy path only.
• Document the exceptions first. They’re the part that carries the value and the part that never gets written.
• Have someone else run it from your doc and log every question they had to ask. Each question is a missing paragraph.
• Cheapest useful artifact: a one-page description of what the workflow does, what it produces, and the three things most likely to go wrong.

Raising Deterministic

• Find the last decision point in the chain. If a model sits there, move it earlier — let it propose, and let code choose.
• Turn preferences into thresholds, and write down where the threshold came from. A number with no calibration evidence is a guess with a decimal point.
• Recalibrate thresholds against real data periodically. Mine was correct the day I set it and wrong for every day after, because the data changed and the number didn’t.

Raising Verifiable

This is the highest-leverage gate. Options, roughly cheapest first:

• Alert on zero. Count what the workflow produced in the last interval; alert if it’s nothing. Nearly free, catches the heartbeat failure completely, and almost nobody has it.
• Assert on the downstream state. Not “did the step run” but “is the world now how it should be.” If this was approved, it must now be scheduled. This one assertion would have saved me a month.
• Keep a small reference set. Ten to thirty inputs with known-good outputs. Run them on a schedule. Diffs are your regression alarm.
• Recompute by a different route and compare. Expensive, and unbeatable where the stakes justify it.
• Sample and review at a fixed ratio. Not “we spot check sometimes” — a tracked percentage with the results recorded, so the sampling itself is auditable.

One discipline that matters more than the technique: point the check at the layer that actually fails. Write the failure down first, then design the check that would catch that. Checks built without a named failure mode reliably end up verifying whatever was easiest to measure.

Raising Recoverable

• Put a window between decide and act. Schedule the send for later instead of sending now. A gap of even an hour converts irreversible into reversible for almost nothing.
• Cap blast radius per run. An agent that can touch five records is recoverable; the same agent with no cap is not. This is the cheapest single control here.
• Make revert the default posture, not the exception. My improvement loop reverts unless a change proves itself. Thirteen of twenty-one reverted. That ratio is only survivable because reverting is normal and costs nothing.
• Exercise the recovery path once, with a timer. If it’s never been run, you don’t have it.

Raising Delegatable

• Name the owner. One person, by name, accountable for the output being right.
• Make the gate inspect the failure mode, not the output that’s easiest to eyeball. Give approvers the specific question — “is this scheduled?” not “does this look good?”
• Grant autonomy in steps, and only on evidence. Start with the agent proposing and a human doing the work. Then let the agent do it and check every run. Then check a sample. Only then does it run on its own and escalate when it is unsure.
• Build the escalation path before you widen autonomy. An agent that cannot say “I don’t know” will guess. The guess arrives with a confident score attached.

---

Part 5 — The watch

Everything above is a decision made once. This part is for workflows already running, because a green score is a statement about the day you made it.

The weekly ten minutes

For each automated workflow, four questions:

1. What did it produce this week? A number. Compare it to last week. Zero is an alarm, and so is a number that hasn’t moved in a way the volume can’t explain.
2. What did it skip? Not what it failed — what it declined to do. Skips are where silent failures live, and unlogged skips are invisible by construction.
3. What did it escalate? Zero escalations from a system handling real variety means the escalation path is broken, not that everything was easy.
4. Has anything about the inputs changed? Calibrated thresholds decay against drifting data. That’s how a correct rule becomes a wrong one without anybody editing it.

Two habits worth more than the ritual

Revert by default; keep only what measurably improved. Not because most changes are bad. It’s that the cost of being wrong runs one way. Revert a good change by mistake and you lose one improvement. Keep a bad one by mistake and you keep a worse baseline, and every future comparison is measured against it. The asymmetry is enormous, and it does not feel enormous in the moment.

Treat unmeasurable as failed. Three of my thirteen reverts were changes that simply couldn’t be evaluated in the window. Reverting those is what keeps the system honest. Otherwise every change that resists measurement survives by default, and the system fills up with things nobody can assess.

Run the scorecard again in three months

Scores drift downward on their own. Volume grows past a threshold nobody revisits. Documentation goes stale. The person who owned the output changes teams. Nothing broke — the workflow just quietly stopped being the one you scored.

---

The worksheets

Six sheets. Print them or copy them into a spreadsheet.

---

Worksheet 1 — Workflow inventory

Every workflow you’re considering handing to an agent. One line each. Don’t filter yet.

#	Workflow	What it produces	Who owns the output today

---

Worksheet 2 — The scorecard

One page per workflow.

Workflow: ______________________ What it does, in one line: ______________________ If it’s wrong, what does that cost? ______________________

Gate	Score (0–2)	Evidence — why this score, not the one above it
Documented
Deterministic
Verifiable
Recoverable
Delegatable
Total	/10

Honesty checks — answer before you finalise:

• Documented: when was the doc last true? Does it cover the exceptions?
• Deterministic: where’s the last decision made — and is a model sitting there?
• Verifiable: would my existing check catch the way this actually breaks?
• Recoverable: have I ever actually undone this? How long did it take?
• Delegatable: does the approver inspect the failure mode, or just the output?

---

Worksheet 3 — Bucket verdict

🟢 Safe to automate now	🟡 Fixable first	🔴 Do not automate

Apply the overrides before filling this in: a 0 on Verifiable caps at 🟡. A 0 on Recoverable is a veto.

---

Worksheet 4 — Ranked fix-list

Cheapest rung-move first, except where safety reorders it.

#	Fix	Workflow	Gate it lifts	Effort (S/M/L)	Why it matters

---

Worksheet 5 — Silent-failure pre-mortem

One per workflow. This is the highest-value sheet in the manual — do it before you finalise the Verifiable score, because it usually changes it.

It is six weeks from now. This workflow has been quietly producing wrong output the entire time. Nothing errored. Nothing paged anyone.

1. What broke? (Be specific. Not “it failed” — the mechanism.)

   ---

2. How would I have found out? ______________________
3. Which of my existing checks fires? ______________________
4. If the answer to 3 is “none” — what’s the cheapest check that would have?

   ---

5. How long would it have run before someone noticed? ______________________

---

Worksheet 6 — The weekly watch

One row per automated workflow, per week.

Workflow	Produced	Skipped	Escalated	Inputs changed?	Action

Alarms: produced = 0 · skipped > 0 and unexplained · escalated = 0 for a workflow handling real variety · any threshold older than the data it was calibrated on.

---

Where to go from here

You now have the method. It’s the same instrument I use in a paid engagement, and for most technical operators a weekend with these six sheets is genuinely the whole job. If you stop here, you got what this is worth — that’s the point of giving it away.

I ran it on my own system first, and published the result including the failing grades. Five workflows: two green, two yellow, and one red that I had been running unattended for months at a 0 on Verifiable and a 0 on Delegatable. I didn’t catch that one with the scorecard. I caught it when it finally broke in a way I could see, and only then went back and scored it honestly. That’s the most useful thing I can hand you, and it’s also the honest argument for the next paragraph.

If you want a second pair of eyes on your scores, that’s the scorecard review — send me up to three completed sheets and I’ll send back a recorded walkthrough of where I’d score them differently, which bucket each belongs in, and what to fix first. $199, five a month, because I do them on evenings and weekends.

If it’s one workflow and you’d rather I scored it myself, that’s the one-workflow review. I run the five gates on it, hand back the scored map and the ranked fix-list, and walk them with you on one call. $1,200, about a week.

If you’d rather I ran the whole thing on your workflows and handed you the map, that’s the Agent Readiness Audit — two weeks, fixed scope.

And if you never buy anything: run the pre-mortem sheet on one workflow this week. It’s the cheapest hour in this document and it’s the one that changes people’s scores.

— Tim

Corrections and disagreements welcome. If something in here is wrong I’d rather know.