What Not to Let Run Unattended

What stops you letting anything run on its own is not the worry that it might get something wrong. It is the worry that it might get the same thing wrong forty times before you next look at it.

If that is why you still click everything yourself, you are not the only one. It is also the right instinct, and it deserves a better answer than reassurance.

Here is why the instinct is right. A person doing a job badly notices. They feel the friction on the second one and stop. A rule doing a job badly feels nothing at all. It applies the same flawed instruction to every item that comes past, at whatever speed the trigger fires, and the first you hear about it is a reply from somebody on the other end.

So the useful question is not whether your setup is good. It is what happens if it is wrong.

One question decides it.

Before you switch anything on, ask this. If this runs wrong a hundred times before I notice, what happens?

If the answer is a folder of drafts I delete, build it. If the answer is a hundred messages sent to real people, it needs your hand on it. That is the whole safety model, and there is no second, cleverer one hiding behind it.

Three kinds of action, and only one is dangerous.

• Reading and summarising. Fully reversible, because nothing was changed. The source stays exactly as it was and you get a separate summary. Safe to run freely, and this is where every first automation should live.

• Drafting and saving. Reversible, because a draft can be deleted. Safe to automate, on the condition that it stops there and waits. The worst outcome is a tidy-up.

• Sending, deleting, buying. Not reversible. Once it has happened it is done, and it happened while you were somewhere else. Never automate these. Your hand, every time, after you have looked.

Climb in that order, and take your time on each rung. Your first flows read and summarise. Your next ones draft and hold. The committing actions stay manual for a lot longer than you will want them to, and that patience is the entire difference between a helper and a machine that surprises you.

The review step goes where the risk is, not at the end.

Think of a countdown. Every check runs on its own, system after system, and the one irreversible act still waits for a person to press it. Your review step is that button, and it belongs immediately in front of the point of no return.

Drafting an email is reversible. Sending it is not. So the flow drafts and stops, and you supply the one irreversible click yourself, after you have read it.

The mistake I see most often is a review placed at the end, after the action, arriving as a notification. That is not a review. That is a receipt.

Free Claude toolkit. The companion pack for my Claude book is free: ready-made Project instruction templates, and more than five hundred numbered prompts you can copy and paste. No card, and you can leave the list in one click. Get the toolkit →

Keep a log you will actually open.

Anything that runs while you are elsewhere has to leave a trace, or you are trusting it on faith. The log can be plain: a dated note per run, the folder of drafts it produced, one line added to a tracking sheet.

It does two jobs at once. It catches a problem in week one rather than month three, and it earns your confidence on evidence instead of hope. After a fortnight of opening the log and finding it behaved exactly as designed, you know something you could not have known by reasoning about it.

The less you watch, the sharper the wording has to be.

This is the part that catches people out. Automating a job does not let you write a looser brief. It forces a tighter one.

When you are reading every answer, a fuzzy instruction is survivable, because you catch the drift as it happens. Left alone, that same fuzzy instruction repeats its fuzziness on every single run and nobody catches anything.

So write the behaviour as absolutes rather than preferences. Three lines is usually enough.

• Allowed. Read the connected source and prepare a draft or a summary.

• Stop. Never send, delete, buy, or change the original. If the input is unclear, skip it and flag it.

• Review. Hold every final action for me, and log what you did on each run.

Those three lines sit above your ordinary brief and they do not move. Everything else about the flow can be adjusted week to week. These are the ones you write once and then leave alone.

What this will not do.

None of this makes an automation correct. It makes it survivable. A perfectly safe flow can still hand you a useless summary every morning for a month, and the only cost of that is your attention, which is a real cost and not one this rule addresses.

It will not protect you from an action that is reversible on paper but not in practice. A message posted to a team channel can be deleted, and everybody has already read it. You are the one who knows which of your actions are like that, and no rule can know it for you.

And it will not stay a small decision. The list of things Claude can reach keeps getting longer, and each new connection quietly widens what an unattended flow could touch. The rule does not change. The surface it applies to does, so it is worth reading your permissions again every few months.

One thing to do before the next post.

Take the automation you have been considering and write down its single most dangerous step. Just that one. Then ask the hundred-times question about it. If the answer makes you uneasy, you have found exactly where the review point goes, and you can build the rest of it today.

If it turns out the flow is really one repeating job rather than a chain of steps, a Skill is the smaller thing to build first, and it carries the same guardrails.

If you want the whole system rather than one piece of it, that is what I wrote Claude AI Bible (7 Books in 1) for. Seven books in one volume, with the reversibility table, ten ready-made automation templates written in the read-and-prepare shape, the failure rules in full, and more than five hundred numbered prompts to copy.

This post is part of my Claude series. The one that started it is Why Claude Gave You a Great Answer on Monday and a Flat One on Tuesday.

Tomasz