What to automate first, and what not to
Most teams pick their worst job to automate first. Three tests that predict whether a job will work unattended, and the ones that reliably fail.
The instinct is to automate the job you hate most. That job is usually the one you hate because it needs judgement, arrives in an unpredictable shape, and matters when it goes wrong, which is a precise description of the worst possible first candidate.
Better selection criteria exist, and they are not about how annoying the work is.
The three tests
A job is ready to run unattended if all three hold. Failing any one is a reason to wait rather than to push.
| Test | The question | Failing looks like |
|---|---|---|
| Repeatable | Does the same decision get made on structurally similar inputs? | "It depends what came in" |
| Definable | Can you say what a finished run looks like, without "appropriate"? | "Just handle it sensibly" |
| Recoverable | If it gets one wrong, what does it cost? | "We would have to call the customer" |
Notice none of them mentions difficulty. A hard job that is repeatable, definable and recoverable is a better candidate than an easy job that is none of those.
Scoring some real jobs
Applied to work most teams have, using kits from the directory where one exists:
| Job | Repeatable | Definable | Recoverable | Verdict |
|---|---|---|---|---|
| Morning brief of your day (Executive Daily Briefing) | Yes | Yes | Yes, you just read it | Start here |
| PR digest (Engineering Pulse) | Yes | Yes | Yes | Start here |
| Support triage to drafts (Support Inbox Triager) | Yes | Yes | Yes, drafts wait | Second |
| Logging meetings to CRM (CRM Scribe) | Yes | Yes | Mostly, entries can be edited | Second |
| Deciding refunds | Yes | No | No | Not this |
| Handling an angry escalation | No | No | No | Not this |
| Negotiating a renewal | No | No | No | Not this |
The pattern in the top half: the output is read by you before it matters. That is the practical form of recoverable, and it is why read-only and draft-producing jobs dominate any sensible first fleet.
Why the job you hate is the wrong first pick
The jobs people most want gone share a profile. They are unpleasant because they need judgement, land in unpredictable shapes and carry consequences. Every property that makes a job hateful also makes it a bad automation candidate.
Automating it first produces the outcome that poisons the whole idea for a team: a worker that half-works on the hardest job in the building, needs constant correction, and convinces everyone this technology is not ready. The technology was fine. The job selection was not.
Start with something you are mildly indifferent to and that happens every day. You are buying evidence about how workers behave on your data, and evidence is cheaper to collect on a job where being wrong does not matter.
The volume question
The third filter, after the three tests, is whether the job happens often enough to be worth configuring.
| Frequency | Worth a worker? |
|---|---|
| Several times a day | Yes, clearly |
| Daily | Yes |
| Weekly | Usually, if it takes real time |
| Monthly | Rarely. You will spend longer tuning than doing |
| Once | No |
A useful sanity check: a worker takes about a minute to install from a kit and a week or two of attention to trust. If the job does not consume more than that over a quarter, do the job.
What "recoverable" really means
This is the test people apply loosest, so it is worth being concrete. Recoverable means a wrong output can be corrected before it has consequences, or corrected cheaply after.
| Output | Recoverable? |
|---|---|
| A summary you read | Yes, trivially |
| A draft awaiting send | Yes |
| A task created on a board | Yes, delete it |
| A CRM field updated | Mostly, but other people may act on it first |
| A message sent to a customer | No |
| A payment, a refund, a commitment | No |
The interesting row is the CRM one, because it looks recoverable and behaves differently. A wrong field can be edited, but between the write and the edit somebody may have read it and acted. Anything feeding other people's decisions is less recoverable than its undo button suggests.
The failure mode: automating a process nobody agreed on
The subtler mistake is automating a job that is repeatable, definable and recoverable, and that three people currently do differently.
Writing the instruction forces the decision they have been avoiding, and now the worker is doing it one way at scale. If that way is wrong, it is wrong consistently and constantly, which is worse than three humans being inconsistent in ways that get caught in conversation.
The tell is a disagreement surfacing while you write the instruction. That is not a blocker to work around, it is the actual finding: the process was never agreed, and automating it will not settle the argument, it will just pick a side and scale it.
The reasonable objection
"By these criteria I should only automate trivia. The real value is in the hard jobs."
The value is in the hard jobs eventually, and the criteria are about order, not permanent exclusion. A job that fails "definable" today can pass it in three months, once you have watched a worker do the adjacent easy job and learned what your instructions keep missing.
The sequencing argument is also about your own calibration. After a month of reading receipts you will have a much better sense of where a worker is reliable and where it confidently invents, and that sense is what makes it safe to point one at something that matters. Skipping straight to the hard job means making that judgement with no evidence.
When the answer is not a worker at all
- The rules are complete and stable. A flowchart is cheaper, faster and exact. Use code.
- The output must be exact. Money, quantities, identifiers.
- The work is a conversation. Negotiation and escalation are not tasks to hand off.
- The volume is tiny. Under a handful of items a week, do it.
- Nobody owns the process. Fix that first; automation will not.
A reasonable first fleet
Three workers, all in the top half of the table, all read-only or draft-only:
| Worker | Apps | Level | Why first |
|---|---|---|---|
| Executive Daily Briefing | calendar, email, tasks | Read | Zero blast radius |
| Engineering Pulse | github | Read | Zero blast radius, different data |
| Support Inbox Triager | email, tasks | Write, drafts | First real judgement, still reversible |
That is three of Free's five worker slots and roughly 155 tool calls a day against its 500. The cost of finding out whether this works for you is a plan that is $0 and about two weeks of reading.
FAQ
What should I automate with an AI agent first?
Something repeatable, definable and recoverable, that happens at least daily, and that you are mildly indifferent to. A daily digest or a read-only summary is the canonical first choice, because the worst case is an output you disagree with.
Why not automate the job I find most painful?
Because the properties that make a job painful, needing judgement, arriving unpredictably and mattering when wrong, are the same properties that make it a poor unattended candidate. Automating it first tends to produce a half-working worker and a team convinced the technology is not ready.
How do I know if a job is well enough defined?
Try to state what a finished run looks like without using the word "appropriate". If your success criterion needs it, the judgement is still in your head rather than in the instruction, and a worker will resolve it differently on different days.
Is a weekly job worth automating?
Usually yes if it takes real time, since a kit installs in about a minute. Monthly jobs rarely repay the tuning, and one-off jobs never do; open an assistant instead.
What if two people do the job differently today?
That disagreement is the finding rather than an obstacle. Automating an unagreed process picks one side and scales it, so settle the process first. A worker will not resolve the argument, it will just make one answer constant.