A chatbot has judgement but no persistence; it forgets when you close the tab. Workflow automation has persistence but no judgement; every decision was written as a rule in advance. An always-on agent has both. My rule: if the decision fits in an if-statement, write the if-statement. Use an agent only where the rule would be longer than the judgement.
Part of the Always-on agents series, post 4 of 33.
I automate almost everything in my company and very little of it is an agent. That is not modesty, it is the result of one expensive mistake and of running jobs that have to work at 3am. The headlines this autumn, which I went through in the previous post, make everything sound like an agent. Most work is not, and the cheapest way to lose money on this is to put a model where a rule belongs. Here is how I sort it.
The three tools, side by side
| Chatbot | Workflow automation | Always-on agent | |
|---|---|---|---|
| Holds a goal between runs | No | Yes, as a fixed recipe | Yes, as state it carries |
| Starts itself | No, you open it | Yes, on a trigger or clock | Yes, on a trigger or clock |
| Makes a decision you did not write down | Yes | No | Yes |
| Fails by | Forgetting | Doing the wrong thing perfectly, forever | Doing something plausible you did not want |
| Costs | Per conversation | Almost nothing per run | Per decision, every run |
| Examples | ChatGPT, Claude in a tab | cron, Zapier, n8n, Huginn, Node-RED | dots, Spark, OpenClaw, Hermes, Leo |
The middle column is where I live. Two of the three jobs that run my company every morning are workflow automation with no model in them, and I keep them that way on purpose. The rest of this post is about why.
What automation without judgement does: 107 identical posts
This is the mistake. A while ago a script was written to refresh the older posts on this blog. It had a trigger, a template and no judgement, which is the definition of workflow automation, and it did exactly what it was told: it rewrote every post that was not on a short exclusion list. The exclusion list was seven filenames. The blog had far more than seven hand-written posts. The result was 107 posts that were byte-identical past the title, about 449 words each, all opening with the same sentence, with publish dates picked at random and a word count in the metadata that claimed 1,500.
Nobody noticed for a long time, because the pages existed, loaded and looked like posts. When I finally measured them in Search Console, only 11 of the 107 had ever been indexed. All 107 together drew 345 impressions and 3 clicks in 90 days, about one percent of the site's traffic, and 95 of them sat at exactly zero. On 20 September 2026 I put a noindex tag on all 107 and left the sitemap entries in place so Google would re-crawl them and see the tag, and a daily job has been finishing the cleanup since.
The lesson I took is not that automation is dangerous. It is that automation with no judgement does the wrong thing perfectly, forever, and the only defence is a guard that checks the thing you forgot. That script now refuses to touch any file that does not contain its own boilerplate sentence, and the watchdog emails me if a new post ever matches it.
What judgement without persistence does: the chatbot
The opposite failure is quieter. A chatbot in a tab will give you a good answer and then forget the question. I used one for weeks to draft social captions before I noticed that every session started from zero: same brief, same corrections, same output. Nothing happened between sessions, nothing improved, and the moment I stopped typing, the work stopped. That is fine for a draft. It is useless for a channel that has to post every day.
The tell is simple. If the thing cannot act while you are asleep, it is not doing a job, it is helping you do one. Helpful is not nothing. It is just not what the headlines are selling.
Where I actually put the model
Look at the three jobs that run this site each morning.
- The publisher, 09:05: no model. It reads a list of posts and dates that I wrote, checks the storage bucket to see what is already live, uploads what is due, updates the sitemap and the index. Every decision in it is an if-statement, and the if-statements are the point: I want to know exactly what will happen tomorrow morning.
- The watchdog, 09:40: no model. It asserts five things about the blog, including that the rewriter guard still exists and that the 107 are still noindexed, and emails me only when one fails. A model could do this. A model could also decide that a broken page is fine. Rules cannot.
- Leo, every hour: a model, in one place. The agent I actually sell watches what an audience is responding to, picks a clip from a library, edits it and books it on the calendar. Which trend, which clip, and whether to post at all are judgements I could not write as rules, because the inputs change faster than I could rewrite them. That is the only job of the three where a model earns its cost.
There is a fourth script I want to mention because it is the perfect counter-example. A sitemap generator in the repository rebuilds the whole file from the blog folder. Run it, and it silently drops the 24 non-blog pages. So I never run it. I append sitemap entries by hand, or rather, the publisher appends them with one rule. A decision that would take a model to get right, which pages are not blog posts but matter, is exactly the kind of decision I would rather not delegate at all.
The if-statement test
Before I give any job to a model, I write the decision down as a rule and look at it.
- If the rule fits on one line, I ship the rule. Publish what is due. Alert when a check fails. Retry on a 5xx. These never need judgement.
- If the rule would be longer than the judgement, I use a model, once, in that one place. Which of forty clips fits a trend is a paragraph of taste, not a rule.
- If the inputs change faster than I can rewrite the rule, I use a model and I log every decision. Trends change hourly. The log is how I find out when the model is wrong.
- If getting it wrong is irreversible, I do not automate it at all. Deleting pages, sending money, emailing a list. Those get a human and a confirmation.
The reason this matters for always-on agents specifically is cost and trust, which I went through in the pricing post. An agent pays for every decision and can make a plausible wrong one at 3am. A rule costs nothing and can only make the wrong decision you wrote. I know which failure I would rather debug.
A ten-minute audit of what you already run
I did this exercise on my own company after the 107-post mistake, and it took one coffee. It is worth doing before you buy any of the agents in the headlines, because most people discover they already run a dozen automations and zero agents, and that the dozen are where the risk is.
- List everything that runs without you: every scheduled job, every Zapier zap, every script on a timer, every vendor feature that posts, emails or edits on your behalf.
- Next to each one, write whether a model makes any decision inside it. For me the answer was yes exactly once.
- For every job with no model, write down the one thing it would do wrong perfectly if its input changed. Then add the guard that checks for that input. This is the step that would have saved my 107 posts.
- For every job with a model, write the rule you would replace the model with. If you can finish the sentence, replace it. If you cannot, keep the model and add a log you will actually read.
- Count the jobs that can do something irreversible. Those get a human in the loop today, before anything else on this list.
So which one do you need?
If you want to ask questions and get drafts, a chatbot, and you already have one. If you want something to happen reliably whenever something else happens, workflow automation, and the free tools have done this unattended for a decade. If you want something to pursue a goal while you are away and make calls you did not script, an always-on agent, and you should read the permissions post before you connect it to anything that matters. The whole series is on one page; the definition I use is in the first post, and the one job where I let a model decide is here.
Sources
- Leo AI, Every company shipping always-on agents in 2026 (accessed October 20, 2026)
- Google, Search Console URL Inspection API documentation (accessed October 20, 2026)
Written by Lera Leonteva. The 107-post figures are from my own Search Console export of 20 September 2026 and the cleanup job's state file; I have not reproduced them anywhere else.