What to Make Autonomous First, and What to Leave Alone

Someone in your company opens the same screen every morning. They look at a list, compare two numbers, and take one of three actions depending on which number is bigger. It takes eleven minutes. They have done it four hundred times. They could describe the rule in one sentence while making coffee.

That is your first candidate. Not the forecasting engine. Not the thing you would demo to an investor. The eleven minute task nobody talks about.

Most teams pick the opposite. They start with the most impressive thing they can imagine, because that is the thing worth announcing. Then they spend four months on it, ship something half trusted, and quietly go back to the screen. The mistake was not the engineering. It was the sequencing.

The first one is not about the task

Here is the part that gets missed. The first autonomous thing in a company is not really about saving eleven minutes a day. It is about building the belief that software can be handed a decision and will not embarrass you.

Nobody in your company has that belief yet. They have the opposite. They have a memory of an automation that fired wrong at 2am, or a rule that kept running long after the situation changed. Those memories are the actual obstacle.

So the first one has a job beyond its own output. It has to be so obviously correct, so easy to check, and so boring in its failure mode that the belief starts forming on its own. Once people trust it, the second one is a conversation. The tenth one is a Tuesday.

Pick something where trust can be earned quickly. Frequent, so the evidence accumulates fast. Reversible, so a mistake costs a shrug. And boring, so nobody is emotionally invested in the outcome being clever.

Frequent, reversible, boring

Frequent matters because trust is built through repetition, not through impressiveness. Something that runs forty times a day gives you forty pieces of evidence in a day. Something that runs once a quarter gives you one, and you will not know whether it works until next year.

Reversible matters because your first one will get something wrong. It will. Not because it was built badly, but because the world contains a case nobody thought of. If getting it wrong means an email goes to a slightly wrong segment, you fix it and move on. If getting it wrong means a customer was charged incorrectly, you have spent the trust you were trying to build, and you spent it in the first month.

Boring matters because boring tasks have stable rules. The reason they are boring is that the decision is the same every time. That stability is what makes them safe to hand over. Interesting tasks are interesting because the answer changes, and changing answers are the hardest thing to hand over first.

A fourth quality matters just as much. Checkable. Someone should be able to look at what the software decided and say within ten seconds whether it was right. If verifying takes an hour of cross referencing, nobody will verify it, and unverified means untrusted no matter how correct it actually is.

A test you can run this week

Take your list of candidates and put each one through five questions.

1. Can one person write the rule in three sentences, without saying “it depends” or “usually”?
2. Does it happen at least a few times a week?
3. If it fires wrong, can you undo it in under an hour without calling a customer?
4. Can someone glance at the decision and tell if it was right?
5. Does the person doing it today agree it is repetitive?

If you get five yes, start there. If you get four, it is probably fine. If question one is a no, stop reading the list and go read the next section, because you do not have a software problem yet.

That fifth question is doing quiet work. If the person who does the task today thinks it requires judgement, they are usually right. If they think it is drudgery, they become your best source of edge cases, because they have hit every one of them.

What to leave alone

Saying no is the more valuable half of this. Four categories are worth refusing, some for now and some permanently.

Anything where being wrong is expensive and hard to undo. Sending money. Cancelling an account. Deleting records. Publishing something public. The rule is not that software cannot do these. It is that they should never be first, because the first thing is where you discover what you failed to consider. Discover that on the low stakes one.

Anything touching a person’s money or employment without review. Pay, commissions, refunds above a threshold, performance flags. Software can do the analysis and prepare the decision. A person should still press the button. Not because software is unreliable, but because the person affected deserves a human who owns the outcome, and because you want a place to catch drift before it reaches someone’s paycheque.

Anything where the rules genuinely change case by case. Note the word genuinely. Plenty of tasks look like judgement but are actually three rules in a trench coat. Pull the last twenty instances and see if they resolve to a pattern. Often they do. But some things really are case by case, usually anything involving a relationship, an exception, or a negotiation. Handing those over produces software that is technically working and practically wrong.

Anything nobody can explain clearly enough to write down. This is the one people skip past, and it is the most important. If three people describe the same process three different ways, you have not found a job for software. You have found an unresolved disagreement about how your company operates. Building anything now just encodes one person’s version and makes the disagreement permanent and invisible.

This category is not a dead end. It is a conversation. Get the people in a room, write the rule down, and see if they can all sign it. Sometimes they can, and now you have a candidate. Sometimes they cannot, and you have learned something more useful than any software would have given you.

Sequence, not scope

The pattern that works looks slow and is not. Pick the boring frequent one. Let it run alongside the person for two weeks, doing nothing but showing what it would have decided. Compare. Fix the gaps. Then let it act, with everything it does recorded in a way anyone can look at later.

Two weeks of that will tell you more than two months of planning, because it surfaces the cases nobody remembered before anything is at stake.

We built our own Shopify apps this way. The first thing they ran without a person was not the interesting part of the product. It was the boring recurring check underneath, where being wrong meant a shrug. Everything else came after that one had earned it.

The impressive thing can wait. It will be easier to build once the company already believes.

If you want a second opinion on which candidate to pick, a short call is enough to narrow it.