Sample deliverable
Agent Readiness Audit — my own system
Prepared by Tim Raysby · 2026-08-07 · scope: 5 workflows · published 2026-08-23
I sell an audit that scores workflows on whether an AI agent can safely run them. Before selling it to anyone, I ran it on the system I operate every day. This is the unedited result, including the workflow that scored a 4 and the one I automated anyway before it was ready.
Every number here comes from a log or a commit, not a recollection.
How the scoring works
Five gates. Each scored 0, 1, or 2. Ten points possible.
| Gate | The question | 0 | 1 | 2 |
|---|---|---|---|---|
| Documented | Can the process be written down? | Lives in someone's head | Partly written, gaps | Written down, current |
| Deterministic | Are the judgment calls encoded as rules? | Fuzzy throughout | Rules exist, model still decides | A model may propose; code decides |
| Verifiable | Is there an automatic check on the output? | The agent's report is the only check | A check exists but doesn't cover the failure | Output checked against something independent |
| Recoverable | What does undo cost? | Irreversible | Undoable with effort | Revert is cheap and default |
| Delegatable | Does a named human own the output? | No owner, no gate | Owner exists, gate is nominal | Owner, gate, and graduated trust |
Two hard rules that override the total
- 01
A 0 on Verifiable caps the workflow at “fixable first.” If nothing checks the output, the agent's own report is the check — and an agent's report is the least reliable artifact it produces.
- 02
A 0 on Recoverable is a veto. Undo cost is not a factor to weigh against the others. It's a gate. Irreversible plus unverifiable is how you find out from a customer.
Executive summary
Automated prompt tuning
Every change is measured against a baseline; revert is the default
Code changes to the system
Cheap to undo, human gate on every merge; test coverage is uneven
Content drafting → publishing
Quality is checked; delivery isn't
Inbound file monitoring
The only health signal was liveness, and liveness lied
Routing items to active goals
Nothing checked the routing against reality; it ran automatically anyway
Bottom line: the two workflows I built a measurement loop around score 9 and 10. The three I didn't score 4 to 6 — and all three failed in the same direction. Not one of them errored. Each kept running, kept reporting success, and quietly produced wrong work for between a day and a month before I noticed.
The pattern is the finding: the gap between my best and worst workflows is not model quality, prompt quality, or engineering care. It's whether anything independent checked the output.
A · Safe now
10 / 10
Automated prompt tuning
What it does: proposes a change to its own instructions, applies it, measures the result against a recorded baseline, then keeps or reverts.
If done wrong: the system degrades itself continuously, and each degradation silently becomes the new baseline.
| Gate | Score | What I found |
|---|---|---|
| Documented | 2 | Every experiment writes a record: which quality axis, the baseline average, the minimum sample size required, the measured result, the final state |
| Deterministic | 2 | A model proposes the change. A threshold decides whether it lives. The keep/revert decision contains no model |
| Verifiable | 2 | Measured against a pre-recorded baseline on a named axis, with a minimum sample size before any verdict |
| Recoverable | 2 | Revert is the default state, not the exception |
| Delegatable | 2 | When it can't reach a verdict, it escalates to me rather than guessing |
Evidence: 21 experiments to date. 13 reverted automatically. 1 kept. 3 escalated to me. 4 still measuring.
The finding worth stealing: six of the thirteen reverts had improved the number they were aiming at. One raised its target axis by 8.33 points — and was reverted, because it dropped a different axis by 2.67. Three more improved their target and regressed two or three others. The rest improved their target but not by enough to clear the bar.
Three further changes were reverted for a reason I'd recommend to anyone: they couldn't be measured inside the window. Not “measured and found wanting.” Unmeasurable. The rule is that unmeasurable means revert, and it is the single highest-value rule in this system. Without it, every change that resists measurement accumulates permanently.
The one change that survived raised its axis by +0.87 and regressed nothing. A 1-in-21 keep rate is not a sign the loop is broken. It's the number I'd expect from an honest gate, and it's the reason I trust this workflow more than anything else I run.
B · Safe now
9 / 10
Code changes to the system
What it does: proposes and applies changes to its own code.
If done wrong: it breaks itself, or edits the rules that constrain it.
| Gate | Score | What I found |
|---|---|---|
| Documented | 2 | Every change carries a written rationale explaining the trade-off at the time |
| Deterministic | 2 | A policy file the system is structurally not permitted to modify; the constraint is enforced in code, not requested in a prompt |
| Verifiable | 1 | 18 test files. Coverage is uneven — not every change has a check that would catch its own regression |
| Recoverable | 2 | Version control. Every change is one command from gone |
| Delegatable | 2 | Human gate on every code change. No exceptions, and the gate is real — it has blocked things |
Verdict: safe, and the one point it's missing is honest. The tests that exist are good; they don't cover everything. I'd rather report a 1 than round up.
Supporting evidence: a separate adjudication ledger shows 25 decisions on proposed changes — 14 approved, 10 rejected, 1 applied. A gate that never rejects anything isn't a gate. Ten rejections is what “real” looks like.
C · Fixable first
6 / 10
Content drafting → publishing
What it does: drafts content, scores it against quality axes, routes it to me for approval, then schedules and publishes it.
If done wrong: either bad content ships, or good content silently never ships.
| Gate | Score | What I found |
|---|---|---|
| Documented | 2 | The pipeline stages and the quality axes are written down |
| Deterministic | 1 | A model drafts. Scored rules gate the draft — but the scheduling logic made a judgment call nothing reviewed |
| Verifiable | 1 | Draft quality is scored. Draft delivery was not checked at all |
| Recoverable | 1 | A published post can be deleted. It cannot be unpublished |
| Delegatable | 1 | I approve every item — and the approval gate turned out to be part of the problem |
What went wrong: the function that found the next open publishing slot looked fourteen days ahead. One channel gets eight slots per fourteen days. Once those were claimed, the function returned “nothing available” — and every caller treated that the same way it treated “nothing to do.” Silently. Skip.
16 approved posts sat invisible for up to 30 days. A repair job that ran on a schedule re-skipped them on every single pass, for a month, without logging that it had.
Two things here are worth more than the bug:
The check existed one layer too early. Content quality was measured carefully, on named axes, with real thresholds. Nothing measured whether an approved post reached a schedule. The system was rigorously verifying the part that was already fine.
The human gate made it worse. I approved those sixteen posts. 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 — and when the two come apart, the gate is worse than no gate, because it retires your suspicion.
Gaps to close
- Verifiable Nothing confirms an approved item reached a schedule → assert on the post-approval state; count approved-but-unscheduled as an error, not a silence · S
- Deterministic “No slot available” and “nothing to do” share a return value → separate them; return the unschedulable items explicitly · S (done 2026-08-07)
- Recoverable Publishing is one-way → widen the window between schedule and send · M
D · Fixable first
5 / 10
Inbound file monitoring
What it does: watches for new files and turns them into work items.
If done wrong: work silently never arrives, and nothing anywhere reports a problem.
| Gate | Score | What I found |
|---|---|---|
| Documented | 1 | The mechanism is understood; the failure modes were not written down |
| Deterministic | 2 | No model involved. Pure rules |
| Verifiable | 0 | The only health signal was liveness. Nothing checked that watching produced anything |
| Recoverable | 1 | Restarting recovers the watcher; files that arrived during the outage are simply gone |
| Delegatable | 1 | No owner was checking output; the process supervisor was trusted instead |
What went wrong: a file was renamed between the moment it was noticed and the moment it was read — routine behaviour for editors and sync tools, which write to a temporary name and rename into place. 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.
That sentence is the whole reason I score Verifiable separately from Recoverable. The process was alive. Alive was the metric. Alive was true, and meaningless.
The rule: liveness is not an output metric. If the only thing your monitoring can tell you is that a thing is running, you are not monitoring it. Count what it produced in the last hour and alert on zero.
Gaps to close
- Verifiable No output metric → alert on zero items produced per interval, not on process death · S
- Recoverable No replay of what was missed → scan on startup for anything that arrived while down · M
E · Do not automate
4 / 10
Routing incoming items to active goals
What it does: takes each item from an incoming briefing and matches it to whichever active goal it's relevant to.
If done wrong: unrelated work gets attached to the wrong objective, with a confident score attached to the mistake.
| Gate | Score | What I found |
|---|---|---|
| Documented | 1 | The matching approach was written down; the calibration assumptions were not |
| Deterministic | 1 | A fixed numeric threshold — which is only deterministic if the threshold is right |
| Verifiable | 0 | Nothing ever checked a match against reality. Not once |
| Recoverable | 2 | Routing is advisory; a wrong match costs attention, not data |
| Delegatable | 0 | It routed automatically. No confirmation step, no named owner on the output |
What went wrong: matches were scored by cosine similarity against an absolute threshold. Sentence embeddings place any two English technical sentences at roughly 0.75–0.85 similarity regardless of topic. The threshold had been set to 0.25 back when everything was scoring zero — so instead of matching nothing, it matched everything.
On one briefing: all 20 items matched. Scores ranged 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 being decided by floating-point noise, and every one of them carried a confident-looking score. A weather-forecasting item was matched to threat-intelligence escalation. It looked exactly as plausible on the dashboard as a correct match, because the number was in the same range.
Requiring the top goal to beat the runner-up by a real separation took that briefing from 20 of 20 false matches to 0 of 20.
Verdict: this should never have been running unattended. A 0 on Verifiable and a 0 on Delegatable is the exact combination the scorecard exists to catch, and I shipped it anyway — because it produced output that looked right, every day, for months. Fixed 2026-08-07.
The rule: a similarity score is not a confidence score. If a ranking system can't tell you how much the winner beat the runner-up, it isn't ranking. Threshold on the margin, not the magnitude.
The fix-list, ranked
Safety first, then cheapest lift.
| # | Fix | Workflow | Lifts | Effort | Why it matters |
|---|---|---|---|---|---|
| 1 | Require a real separation between top match and runner-up | E | Verifiable, Deterministic | S | Turns 20/20 false positives into 0/20 · done |
| 2 | Separate “couldn't” from “nothing to do” at every boundary | C | Verifiable | S | This exact conflation hid a month of work · done |
| 3 | Alert on zero output per interval, not on process death | D | Verifiable | S | Liveness has already lied once |
| 4 | Assert approved items reach a schedule | C | Verifiable | S | Closes the layer the quality checks skipped |
| 5 | Add a confirmation step before routing acts on a match | E | Delegatable | S | Restores the owner the workflow never had |
| 6 | Replay what arrived during a watcher outage | D | Recoverable | M | Currently unrecoverable by design |
| 7 | Widen the gap between scheduling and publishing | C | Recoverable | M | Publishing is the only one-way door here |
| 8 | Extend test coverage to regressions, not just behaviour | B | Verifiable | M | The only point B is missing |
Recommended sequence
- 01
Keep running unattended: A and B. They earned it by being measured.
- 02
Fix, then trust: C and D. Both need one small thing — an output check — not a rewrite. Fixes 3 and 4 are an afternoon.
- 03
Do not run unattended: E, until fix 5 lands. The scoring fix removed the false matches; it did not give the workflow an owner.
The order matters. Every instinct says to start with E because it was the most embarrassing — but E is advisory and cheap to undo, while C publishes to the outside world and can't be taken back.
What I'm not claiming
- — I have no external clients yet. This scorecard is my own system, audited by me. Treat it as a worked example of the method, not as third-party validation.
- — Two of the three failures above were found and fixed on 2026-08-07 — the same day I finished this scorecard. I am not presenting a system that has been clean for a year. I'm presenting one where the failure mode is understood and the detection is improving.
- — The scores are mine. Nobody graded my grading. The most common way to fail this audit is to score yourself too kindly, and I have no way to prove I didn't.
- — Verification runs on 100 days of logs, from 2026-04-24 to 2026-08-07. That's 100 days out of 106. Six days are missing, and I'd rather say so than write “every day.”
What this is a sample of
This is the deliverable format, run at full depth on five workflows. The real one runs against everything you have.
If you want to score your own workflows against the same five gates, the Scorecard is free and runs entirely in your browser — nothing you type leaves the page.
If you'd rather I ran the whole thing on your workflows — every candidate scored, the ones you graded generously dug into, a ranked fix-list you own — that's the Audit. Two weeks, fixed scope.
— Tim