A founder runs an automation that sends a welcome email and sets up the account for every new paying customer. It runs every night. Someone makes a small change on a Tuesday afternoon, and an access key quietly stops working. The nightly job still starts. It finds nothing it is allowed to touch, finishes in four seconds instead of its usual ten minutes, and reports Success.

Nobody looks at it for nine days. Then a customer writes: “I paid a week and a half ago. Where’s my account?” The founder opens the dashboard. Every run for nine days is green. Eleven customers never got onboarded, and two have already asked for refunds.

Nothing crashed. No alarm could go off, because nothing happened.

Why the checkmark lied

A recent DevOps.com piece describes this exactly. An agent that does the wrong thing leaves evidence: a bad record, a wrong email, a complaint. An agent that does nothing and reports success leaves a green checkmark, “the one signal your incident process is built to trust.”

Almost every safety net we build assumes something arrives. An approval step reviews outputs. A review meeting looks at what exists. A feedback loop needs a result to learn from. A job that produces nothing never reaches any of them. It doesn’t fail the review. It never gets there.

The common reaction is “we need better monitoring.” The same article argues this is the wrong reflex, and we agree. More logs and traces give you more detail about the job. This failure is only visible in the result. A perfectly detailed record of a job that did nothing is still a record of nothing.

Our position, which some tool vendors won’t like: a “done” status is the agent’s opinion of itself. You wouldn’t accept that from an employee on payroll, and you shouldn’t accept it from software.

Count the world, not the report

The fix is one move. Stop asking “did the run error?” and ask “does the thing it was supposed to change show the change?”

For our founder, that means a separate check that doesn’t depend on the agent at all. Every morning it counts how many customers paid yesterday and how many welcome emails and accounts exist for them. If the numbers don’t match, it raises an alarm.

Two details from the source are worth stealing:

• Treat suspicious speed as a failure. A ten-minute job that finishes in four seconds didn’t get efficient. It skipped the hard part. That should trigger the same alert as an error.
• The checker must fire because work was due, not because the agent reported in. A reviewer that only wakes up when the agent calls it inherits the agent’s silence. No run, no review. The check runs on a clock the agent doesn’t control.

Make the checker boring, too. Plain, fixed steps that do the same thing every time. A separate piece we read this month makes the point well: use a simple scripted robot for stable, repeatable work, and save AI reasoning for the parts that genuinely change. Counting rows is not a job for AI. Don’t ask the thing being checked to check itself.

The part that actually broke: nobody knew who to wake

Here is the uncomfortable truth behind our story. The tool wasn’t the problem. Access keys expire, and agents misbehave. That’s normal.

The real failure was that no one had been named as the person who gets woken up. The agent’s builder assumed the founder would notice. The founder assumed the builder would. A dashboard existed, and it was green. Nine days is what happens when responsibility belongs to everyone.

Verification costs money, and the source is honest about that: you are paying to confirm work you already paid for. It’s cheaper than eleven lost customers.

The one habit

Before any agent goes live, write one sentence for it and put a name on it. This is the only artifact you need:

Every [day/hour], there should be at least [N] [orders / emails / records] in [place]. If there aren’t, [one named person] gets a text by [time].

Rules for the sentence:

1. It counts things in your actual product or inbox, not things the agent says it did.
2. “Zero” counts as an alarm when you expect more than zero.
3. The named person is a human with a phone, not a team channel, and they know it’s them.
4. It runs on a schedule, independent of the agent.

If you can’t write the sentence, that tells you something. The source says a run with no declarable effect deserves hard questions. If you can’t say what the agent should change in the world, you can’t know when it has stopped changing it.

What to do this week

List every automation or agent that touches a paying customer. For each one, write the sentence above. You’ll likely find that two or three have no obvious count to check and no obvious owner. Those are your nine-day-outage candidates.

Build the counters first and the fancy dashboards never. A number that says “11 expected, 0 delivered” is worth more than a month of green.

Sources

• https://devops.com/the-agent-failure-your-approval-gate-cant-catch/
• https://devops.com/quality-debt-is-the-new-technical-debt/

Fractional CTO — from €4,000 / month, 4–6 days a month, 30 days notice. hands-on engineering and architecture every month: the technical co-founder you have not hired yet.

It starts with a free product teardown: two hours on what you are building, what already exists, and what is actually blocking launch. You leave with a written plan and a realistic number, whether or not you work with us. Book a teardown · What it costs