Seventy agents write things, and I can’t name the one that can’t be undone
Last night I counted my own cron jobs. One hundred and seventy-five of them, spread over ten jobs files. Seventy start an agent. Fifty-one of those have something in their prompt or script that writes, sends, posts, commits or deletes. And when I asked myself the only question that actually matters — which of these can’t be undone? — I had no answer. Not because the answer is complicated, but because the question was never asked when those jobs were built.
That is a strange place to arrive at. The system is green. The watchdog is quiet. The reports come in on time. And still, “my scheduled agents are under control” is a statement of intent, not a measurement.
The proof arrived at five in the morning
This morning a check found something I should have seen months ago. One job — the monthly photo overview — was scheduled as 0 22 28-31 * *. Four chances per month. It had no idempotency check at all: every run posted the same slug. WordPress doesn’t complain about that. It silently renames the slug to -2, -3, -4 and keeps them all. August: four identical overviews. September: four. October: two — only because a power failure ate the third run.
Every single run exited 0. The agent reported “published”. The watchdog, which watches for failures, saw nothing to report. The site simply grew a post that already existed. A duplicate is not an error — it’s a success with the wrong cardinality, and nothing in my monitoring stack was built to notice the difference.
The only thing that could have caught it was reading the site. Not the logs. The logs were perfect.
The fix is small, the conclusion is not
The patch took ten minutes: before posting, ask the site whether the canonical slug already exists. If it does, skip and exit 0. If the check itself fails — network, HTTP error — do not publish, exit 1. Fail closed, because “I couldn’t check” and “it doesn’t exist” are not the same answer. Three measurements proved it: the dry run skipped, a nonexistent slug still went through, and the post count didn’t move.
But the real finding is bigger than one script. My approvals are organised per platform, not per action. That is a list of channels, not a model of consequences. A job that rewrites a config and a job that publishes a blog post look identical from the outside: both “run”. One of them I can roll back with a git command. The other one touches a public site that other people read.
So here is what I am doing this week, deliberately small: one column per agent job — read, draft, reversible, irreversible — filled in from the prompt and the script, with writes to logs, jobs and webhooks counted as writes. Then count how many sit in that last tier. I don’t need a framework. I need to know which of the seventy can hurt something that doesn’t have an undo button.
The uncomfortable part
An unattended agent has no prompt that carries its authority. Whatever permission it needs has to be designed in advance — per trigger, per action tier, bound to the payload, with an audit trail and a kill switch living outside the model. Otherwise the model is both the actor and the judge of whether the action was allowed. Those are two jobs that should never be done by the same party.
I’ve been running this setup daily for months and I only just wrote the list of what it’s allowed to break.
How do you keep track of that in your own automations? Do you know off the top of your head which of your scheduled jobs can’t be undone — or would you, like me, have to go and count?
Wat vond je van dit bericht?
