I have automated forty things. Thirty-six of them were not worth automating. I want that ratio on the table before we start, because everything else written on this subject is written by somebody still in the excited part, and I am well past the excited part. I am ten. I have watched the excited part come and go several times.
An agent is a program you can hand a goal to instead of a sequence, and it will work out some of the sequence itself. That is the whole idea, it is genuinely new, and it is genuinely useful. It will also do the wrong thing forty times in a row at three in the morning while you sleep, cheerfully, and file a report saying it went well. Both halves are true, and which half you get is decided almost entirely by what you point it at.
So we are not building something clever. We are building something small, boring and reversible, and then we are going to see whether it survives a month. That is the only test that counts.
First, the task has to qualify
Most tasks people want to automate should not be. Here is the filter, and it has saved me more hours than any agent I have ever built.
A task is ready when all four are true
- It repeats. Not “it might repeat” — you have already done it at least five times and you can name the last three.
- It is rule-shaped. If the decision can be written as a sentence beginning with “if”, it qualifies. If the decision is taste, it does not, and no amount of instruction will make it so.
- The inputs arrive in the same shape every time. A form, a folder, an inbox, a column. Not “wherever it happens to be that week”.
- Being wrong is cheap. A draft you can delete, a file in a staging folder, a message that waits for a human. Nothing that spends money, sends itself, or removes anything.
That last one is not caution for its own sake. It is the condition that lets you eventually leave the thing running unsupervised, which is the entire point of the exercise.
Write the procedure down by hand. Yes, on paper.
Before you open anything, write the task out as though you were teaching it to somebody who has never seen it. The trigger. The inputs. The steps in order. Where the result goes. What should happen when something is missing.
If you cannot get that into ten lines, you do not understand the task well enough to hand it over, and no amount of clever instruction will cover the gap. Every automation I have abandoned was abandoned at this step, six weeks late.
The paper version also gives you the thing everyone skips: a definition of finished. An agent with no definition of finished will keep going.
The build, in the order that survives
-
Start with somebody else’s agent.
Do not build the first one. Find a ready-made agent that already does something close, run it on your real inputs, and watch where it goes wrong. Twenty minutes of watching will teach you more about your own procedure than a day of designing, and it answers the only real question early: whether this is worth doing at all.
-
Give it one job.
One trigger, one output. The moment you catch yourself writing “and then it should also”, stop. That is the second agent, and it can wait until the first one has become boring.
-
Put a human approval step in the middle.
The agent prepares; you press the button. This feels like it defeats the purpose. It does not. It is how you find out what the thing actually does, while it can still be stopped.
-
Scope the keys down.
Read-only access wherever read-only will do, and its own account rather than yours wherever it will not. An agent holding your full credentials is not an assistant. It is a co-signer.
-
Make it check its own output before anything leaves.
Confirm the result has the fields you expect, in the format you expect, and refuse to continue if it does not. Most agent failures are not dramatic. They are a blank field passed downstream in silence and discovered a month later.
-
Log every run, with the input and the output.
You cannot debug a thing you cannot replay. A plain text file is enough. You will read it constantly in week two and never again after month two, which is exactly the correct amount.
Then leave the approval step in place for a fortnight. If you find yourself approving every run without reading it, take the step out. If it catches something even once, you have your answer and the step stays.
Step one is the step people skip, because building is more entertaining than borrowing. If you would rather run an agent somebody else has already debugged and find out whether your task survives contact with reality, MuleRun is a marketplace of ready-made agents you can point at a job and watch work. Renting one for a week is a much cheaper answer to “is this worth automating” than a weekend of building it yourself. Browse ready-made agents on MuleRun
Some links on this page are affiliate links. If you sign up through them, HowTo: Tech Edition earns a commission at no extra cost to you. It does not change the four qualifying conditions above, and it does not make a task worth automating.
The four ways it will fail, in order of likelihood
Watch for these, because none of them announce themselves
- Silent failure. It stops, and nothing tells you. The fix is to make it report on success as well as failure, even if the report is one line in a file you glance at on Fridays.
- Drift. A column moves, a form gains a field, a page is redesigned, and the agent carries on confidently with nonsense. The fix is the output check from step five.
- Confident invention. Asked for a value that is not there, a language model will often produce a plausible one rather than nothing. The fix is to say explicitly what to do when a value is missing, and to make “leave it blank and flag it” a legal answer.
- Quiet cost. Runs that were nothing at ten a day are not nothing at ten thousand, and a retry loop can find that number overnight. The fix is a hard daily cap, set before the first live run.
The arithmetic nobody does out loud
A task that takes five minutes a week costs you about four hours a year. If the automation takes a weekend to build and an hour a month to nurse, you have not saved four hours. You have spent thirty and acquired a hobby. There is nothing wrong with the hobby. Just do not file it under productivity.
The tasks genuinely worth it have an unpleasant shape rather than a long one: the short thing that must happen on a schedule you resent, or the mechanical thing you always end up doing while tired. Automating the job you dread is worth more than automating the job that takes longest. Nobody puts that on a slide, because it is not impressive.
Start with one. Keep the approval button longer than you want to. Read the log in week two. If the thing is still running a month later without occupying any of your attention, you have automated something. If it is not, you have learned what you actually do all day, which is the more useful of the two outcomes and the one nobody is selling.
Tested on the folder-sorting agent I built to file my mom’s receipts, which ran perfectly for eleven days and then filed a birthday card as a utility bill. That is where the output check in step five came from, and I have never removed it since.