An automation runs while you are not watching, so decide what it may do alone by how hard each step is to undo, not by how capable the tool is.
- Sort steps by how hard they are to undo. Reading and drafting can run unattended; sending, publishing and paying need a human.
- Expect a second run. Retries and duplicate triggers happen, so give any step that is unsafe to repeat a key the chain checks before acting.
- Log what lets you reconstruct a failure. Record what ran, what changed and what was skipped, keep credentials out, and alert on the conditions that mean trouble.
- Place one real checkpoint. Stop the chain at the last reversible moment, with the output held and nothing yet sent.
- Some tasks are better left manual. Rare jobs, rules that keep changing and quiet failures that would be expensive tend not to repay the build and the upkeep.
An agent runs while you watch. An automation runs while you do not. That single difference changes every design decision on this page.
Not "can this be automated." "How hard is this to undo?"
Reversibility, not capability, decides what may run unattended. A trivial task that cannot be undone is more dangerous than a complex one that can.
Sort every step by how hard it is to undo
Three tiers. Put every step of your chain into one of them before you build anything.
- Reversible — reading, listing, drafting, anything written to a scratch location. Safe to run unattended. Getting these wrong costs a re-run.
- Recoverable — edits and deletes where a backup, a version history or a trash folder exists. Safe unattended only if you have verified the recovery path actually works, not assumed it.
- Irreversible — sending, publishing, paying, posting, provisioning. These require a human, every time, with no exceptions that seem reasonable at the time.
The tier is a property of the action, not of your confidence in the automation. An email you are certain about is still an email you cannot unsend.
Before building, label each step reversible, recoverable or irreversible, and keep a human on the irreversible ones however sure you are of the automation.
Can it run twice safely?
Most automations get run twice eventually. A retry after a timeout, a duplicate trigger, someone clicking twice, a scheduler that fires late and then fires again.
An operation is idempotent if running it twice leaves the same result as running it once. Setting a value is idempotent. Appending to a list is not. Sending a message is emphatically not.
Design for the second run, because there will be one.
Where an operation cannot be made idempotent, give it a key — an identifier the automation checks before acting. Has this already been processed? Then stop. This is the single cheapest defence against duplicate-run damage.
Assume the chain will run twice, and make sure the second run finds the work already done and stops.
What to log, and what not to
The purpose of a log is to let you reconstruct what happened when something goes wrong at 3am and nobody watched it happen.
Log: what ran, when, what it acted on, what it decided, what changed, and what it skipped. The skips matter more than the successes — a chain that silently skipped half its work looks identical to one that succeeded.
Do not log: credentials, tokens, full personal records, or the contents of anything you would not want in a plain text file for a year. A verbose log is itself a data exposure, and it is the kind that survives long after the automation is retired.
Logging everything and reading none of it is the most common outcome. Better: log little, and alert on the specific conditions that mean something went wrong — a skip count above zero, a run that finished too fast, a step that failed twice.
Where the human checkpoint goes
"Review the output" is not a checkpoint — it is a hope. A checkpoint is a specific place the chain stops and waits.
It goes at the last reversible moment before something irreversible. Not at the start, where you have nothing to review. Not at the end, where the irreversible thing has already happened.
In practice that means the chain produces its output, holds it, and waits. The drafts exist. The list is assembled. The send has not happened.
One checkpoint placed correctly beats five placed everywhere — because a chain that asks constantly trains you to approve without reading, which is worse than no checkpoint at all.
Put one stop where it counts, just before the first irreversible step, rather than scattering approvals that train you to click through without reading.
How unattended chains fail
Different from agent failure, because it usually happens with no one watching.
Silent drift
The chain still runs, still reports success, but the thing it depends on changed — a page layout, a field name, a file location. It now produces confident nonsense on schedule.
Defence: assert something you know should be true. If the expected count is roughly twenty and it finds zero, that is a failure, not an empty result.
Partial completion
It processed the first forty items and stopped. Nothing errored. The report says "completed."
Defence: compare the count in against the count out, and treat any gap as a failure.
Cascade
One chain feeds another. The first fails quietly, the second runs on stale or empty input, the third acts on the second's output. By the time anyone notices, three systems disagree.
Defence: a downstream step should verify its input rather than trust it. Freshness and volume are both cheap to check.
Treat “completed” as a claim to check: have each chain test what it expected to find, and compare what went in with what came out.
When not to automate
The honest arithmetic, which most people skip:
- Time saved = frequency × duration × how long you will keep doing it
- Cost = build time + maintenance + the cost of it failing quietly for a while before you notice
The second and third terms are the ones people underestimate. Automations rot — the things they depend on change, and every change is a small repair. A chain you touch monthly is a chain you are maintaining forever.
Most things people automate never repay the automation.
Three cases where the answer is simply no:
- You do it rarely. Twice a year does not repay a build plus maintenance.
- The rules keep changing. You will spend more time updating the chain than doing the task.
- A quiet failure would be expensive. If a month could pass before anyone noticed, and a month of it being wrong matters, keep a human in it.
And one case where the answer is yes even when the arithmetic is marginal: when the task is one you reliably do badly because it is boring. Consistency has a value the time calculation does not capture.
This page teaches you what to do. When not to use AI covers the other side — where these tools are worse than doing it yourself, and how to tell in advance.