Skip to content
Practical technology, explained simply

Build with AI · automation

Which tasks are worth automating (and which not)

How to decide what is worth automating, with clear limits, human review, an error log and a simple way to stop it.

Ibrahin·Published on 2 September 2026·3 min read

Text drafted with artificial intelligence. The topic, the angle and the final review are Ibrahin's. How AI is used here

Someone arranging repetitive tasks into a simple flow at their desk
Illustration, not a real screenshot.

Automating is not about making a tool do lots of things. It is about removing repetitive work without losing the ability to review, correct and stop the process. If a task changes every day, has constant exceptions, or can cause damage that is hard to undo, it may not be ready yet.

Short answer

Automate a task that is repetitive, measurable and reversible. Define what starts it, what it is allowed to do, what it has to record, and at what point it must ask for human approval.

Start from the work, not from the tool

For a week, note down a task you repeat: sorting email, copying data between documents, preparing a summary, or flagging a change. Record how long it takes you, how many exceptions come up, and which mistake would be serious.

If the task only happens once a month, is quicker to do by hand, or needs different judgement every time, automating it can add more maintenance than it saves.

The five questions before automating

  1. What event starts the flow?
  2. What information does it need?
  3. What result does it produce?
  4. What happens if it fails or receives odd data?
  5. How do I stop it, and how do I undo the last change?

If you cannot answer the fifth, do not connect the flow to real data yet.

Design a small version first

A first version should do one single thing. For example, sorting messages into a folder without deleting or replying to them. That way you can check whether it recognises the categories correctly and fix the rules before granting more permissions.

Separate the preparation from the irreversible action. The tool can draft an email, but sending needs approval. It can identify duplicate files, but deleting needs review. It can prepare a payment, but not execute it without confirmation.

Set limits and permissions

Give the automation only the access it needs. A task that sorts a mailbox does not need permission to delete messages, manage accounts or read every document. Use a test account where you can, and keep real data separate from the experiment.

Do not put tokens, passwords or keys in a spreadsheet, a prompt or a shared document. Keep secrets in the system meant for them, and review them when an integration stops being used.

Log every run

A flow with no log is hard to fix. Record, without including sensitive data:

  • when it started;
  • what result it produced;
  • whether it asked for approval;
  • what error it hit;
  • which version of the rules was active.

The log is what tells you whether the automation helps or simply moves the errors somewhere else.

Test the cases that can go wrong

Do not only test the happy path. Try an empty message, a file in a different format, a duplicate, incomplete data, and an interruption. Check that the flow stops and leaves an explanation you can understand.

In my own project, the problem was not that the automation would not work; it was that it could work on the wrong interpretation. That is why I added analysis, build and review stages, and a pause whenever the content needed a human decision. Stopping in the right place is a feature too.

When not to automate

Do not automate yet if:

  • the task decides about someone’s health, money or rights;
  • the input information is not classified;
  • you cannot review the outputs;
  • a mistake would be hard to undo;
  • the process changes faster than you can maintain it;
  • nobody knows who answers when something goes wrong.

You can automate a safe part and keep the final decision manual.

Common mistakes

Starting with the most dangerous action

Sending, deleting, paying or publishing should be the last step, not the first.

Confusing speed with quality

A fast flow that produces repeated errors does not save time.

Keeping no evidence

If you do not know what happened, you cannot fix it or prove it.

Leaving permissions in place forever

Revoke integrations and access you no longer need.

What I would do

I would pick a reversible task, test it with made-up data, measure ten runs, and keep an approval step before any public action. I would only widen the flow after seeing its mistakes, not after seeing it work once.

Final checklist

  1. Is the task repetitive and measurable?
  2. Can the first result be undone?
  3. Is there an approval step before it acts?
  4. Does the flow log its errors?
  5. Can I stop it right now?

Sources

Review

Responsible for publication: Ibrahin. Date: 2026-09-02. Last checked: 2026-09-02.