Decide which workflow should be automated

• You are deciding whether a repetitive task should become a workflow, a script, an agent step, or stay manual.
• You want a rule for saying "no" to attractive but fragile automation ideas.
• You care as much about maintenance cost and failure visibility as you do about time saved.

The hardest part of automation is not building it. It is choosing work that deserves to be automated at all.

Teams usually overestimate the value of automating:

• low-frequency tasks
• messy exception-heavy tasks
• tasks nobody truly owns

And they underestimate the value of automating:

• boring repeated data movement
• repeatable repo chores
• operational steps that break concentration dozens of times per week

The right question is not "can we automate this?" It is "if this runs wrong at 4 p.m. on a Thursday, do we know who notices, who fixes it, and how expensive the mistake is?"

Classic workflow automation

This is the Zapier, n8n, Apps Script, and trigger-action category.

• Best fit: stable workflows where a known event triggers a predictable sequence of actions.
• Typical examples: moving leads, creating records, sending internal notifications, filing attachments, or syncing fields between systems.
• Strength: easy to reason about when inputs and outputs are structured.
• Weakness: exception handling gets ugly fast when the workflow was never stable to begin with.

Repo and process automation

This is the GitHub Actions and "automation lives next to the code or process" category.

• Best fit: CI checks, labeling, release steps, scheduled maintenance jobs, and repeatable repo tasks.
• Strength: the automation can live close to the source of truth and be versioned with the work it supports.
• Weakness: teams often hide operational complexity inside YAML or scripts that only one person understands.

AI-assisted automation

This is where an LLM or agent sits inside the workflow for drafting, classifying, transforming, or inspecting.

• Best fit: bounded judgment tasks, text transformation, summarization, triage, or code-related work that still has a reviewable output.
• Strength: useful when the task cannot be expressed as pure deterministic rules.
• Weakness: variance is the whole issue. If the output is hard to review or expensive to get wrong, AI is often the wrong layer to automate.

Deletion or delegation

Many "automation candidates" are really signs that the underlying work should be redesigned.

• Best fit: low-value steps that exist because of habit, duplicated reporting, or fuzzy ownership.
• Strength: often the highest leverage option because the best automation is removing the step entirely.
• Weakness: it requires saying the process itself may be wrong, which many teams resist.

Use the five-part test

Before you build anything, score the workflow on five dimensions:

1. Volume: does this happen often enough to matter?
2. Variance: do the inputs stay reasonably consistent?
3. Reversibility: can you undo a bad run without drama?
4. Visibility: will someone notice failure quickly?
5. Ownership: is there a real person responsible for it after launch?

Good automation candidates are usually high on volume and visibility, low on variance, and reasonably reversible.

If the workflow scores badly on reversibility or ownership, stop there. Do not build the automation yet.

What to automate first

Classic automation is the best first move when the work is structured and repetitive.

• Best for: app-to-app handoffs, routine notifications, record creation, and simple operational glue.
• Under these constraints: the fields are known, failure is visible, and exceptions are limited.
• Downside: people keep stuffing more edge cases into the flow until it becomes unreadable.

Repo automation is the right move when the work belongs with the codebase or release process.

• Best for: tests, release hygiene, labels, scheduled cleanup, deploy gates, and standard repository chores.
• Under these constraints: the owning team reviews the automation like code.
• Downside: hidden operational knowledge can accumulate in scripts nobody revisits.

AI-assisted automation is only worth it when the output remains reviewable and bounded.

• Best for: draft generation, classification, summarization, or agent-like work with strong guardrails.
• Under these constraints: mistakes are recoverable and humans can inspect the result before it matters.
• Downside: teams often over-automate judgment tasks because the demo feels impressive.

What not to automate yet

Do not automate a workflow when:

• nobody agrees how the process should work
• the inputs are highly irregular
• a wrong action is expensive or customer-visible
• the only monitoring plan is "someone will notice"

In those cases, standardize the manual process first or reduce the number of steps before building anything.

Capture the current workflow as it actually happens

Not the idealized version. The real one.

Write down:

• trigger
• inputs
• steps
• output
• exceptions
• failure impact

If you cannot describe the manual process clearly, you are not ready to automate it.

Automate the smallest stable slice

Do not start with an end-to-end fantasy flow.

Start with:

• one trigger
• one action chain
• one visible output
• one fallback path

The goal of version one is not elegance. It is operational trust.

Add monitoring before you expand scope

Every automation needs:

• logs or run history
• failure alerts or visible status
• a named owner
• a rollback or manual fallback

Without that, you have built a hidden failure generator.

Review the automation after two weeks

The right questions are:

• Did it actually run as often as expected?
• Did it reduce interruptions?
• Did it create new cleanup work?
• Did exceptions dominate the runs?

If the answers are poor, simplify or remove it.

Do not automate a broken process

If the current workflow is unclear, political, or full of exceptions, automation usually hardens the confusion instead of fixing it.

Do not put AI where deterministic logic should be

If a rule can be expressed clearly, encode the rule.

Do not introduce model variance just because "AI" sounds more powerful.

This is a bad fit when the real problem is prioritization

Sometimes the task should not be automated because the task should not exist.

Good operators delete unnecessary work before they automate it.

• Choose a default AI assistant for software engineering
• Ship a marketing page fast without design drift