All articles

Which Tasks to Automate With AI: Six Dimensions That Tell You Before You Build

Six dimensions reveal which tasks to automate with AI, how much autonomy to grant, and where human oversight is non-negotiable — before a line gets built.

Paweł Bazyluk
Paweł Bazyluk Founder Athru IT & partner at Spyrosoft Innovo S.A.

Choosing which tasks to automate with AI is the decision that keeps breaking things in production - and the industry is still treating it as an afterthought. In July 2025, a Replit AI coding agent deleted months of production data for 1,200+ executives and roughly 1,190 companies. The system had been told in all caps not to make further changes. It made them anyway. When asked whether recovery was possible, it initially said rollback was not possible. The data was later recovered manually.

This was not a model failure or a bad vendor choice. It was a task classification failure.

Someone granted a fully autonomous AI access to a high-destruction task without running the diagnostic that would have made that choice obviously wrong. Six dimensions form that diagnostic - complex, complicated, repeatable, high volume, delegateable, and destructive potential - and together they determine not just whether to automate, but how much autonomy to grant and where human oversight stays non-negotiable regardless of how strong the other signals score. These are not theoretical categories. They are the questions missing from every post-mortem - and the framework for how to decide what to automate with AI before the first line gets built.

The Most Consequential Call Before You Build Any AI Workflow: Complex vs. Complicated

The distinction between complex and complicated tasks is the most consequential call you make before building any AI workflow - and the one teams most consistently skip.

A complicated task has many steps and interdependencies. The critical point is that a correct procedure exists and can be documented before execution. Given a sufficiently detailed specification, a capable AI will follow it reliably. The input space is stable. The right answer is knowable in advance. A senior expert can map the procedure end-to-end and hand it to a junior team member - or an AI workflow node - with reasonable confidence.

A complex task is not simply harder; it is irreducibly unpredictable: the input space shifts in ways that prevent any stable procedure from being written. The right answer is only knowable after the fact. The same prompt produces meaningfully different outputs depending on context, ambient conditions, or the particular combination of variables that happens to arrive that day. You cannot write a specification that covers the input space because the input space itself is emergent.

The diagnostic question that separates them: could a senior expert map the correct procedure before execution? If yes, the task is complicated. If no - because the inputs themselves are unpredictable - the task is complex. That distinction determines what AI workflow automation can reliably do.

McDonald's learned this when it terminated its IBM AI drive-thru voice ordering system. The failure is widely reported across multiple outlets. The ordering-input space - accents, background noise, multi-voice families ordering simultaneously, off-menu modifications, adjacent lane crosstalk - proved emergent in the field. No stable procedure could be written to cover what actual customers would say, in the conditions they would say it, across thousands of locations. Taking a food order is, on paper, a bounded procedural task. In practice, the real-world input space made reliable output prediction impossible.

VW's Cariad software division made a larger version of the same mistake. The division treated simultaneous legacy system replacement, custom AI development, and proprietary silicon design as a large complicated engineering problem - an enormous project, but one that could be specified and executed if resourced adequately. It was not. It was multiple complex-domain projects colliding, each with emergent interdependencies the others affected. Trade press reported the result as $7.5 billion in operating losses and 1,600 job cuts.

The automation implication is direct. Complicated tasks can be fully automated with care - the stable procedure is what makes it possible. Complex tasks require iteration, human-on-the-loop monitoring, and feedback loops built into the design from the start.

Organizations that treat complex tasks as merely complicated are likely to "overtrust their outputs and underinvest in feedback loops, guardrails, and human-in-the-loop checkpoints".

That is not a risk to manage. It is a predictable failure mode.

How to Evaluate a Task for AI Automation: Repeatability and Volume

Repeatability is the first filter when evaluating tasks for AI automation. A task is repeatable when it runs the same way every time - same inputs, same steps, same expected output. That consistency is what allows automation to be fully specified. When you cannot fully specify a procedure, the automation breaks exactly where it runs out - at the edge cases, which are also the cases where the stakes are highest.

Volume is the second signal. Building, maintaining, and monitoring an automated workflow costs real engineering time. That overhead is only justified when the task runs often enough for the savings to compound. FloQast's Agent-Readiness framework makes the arithmetic concrete: automating a process that happens 5,000 times a month delivers far more value than automating one that happens only 5 times. Frequency multiplies every efficiency gain - and every failure - alike.

Invoice processing shows both dimensions aligned. Vendor cost data suggests manual processing runs $12-30 per invoice, dropping to $1-5 automated - a 60-80% reduction at scale. Research drawing on Stanford-MIT NBER Working Paper W31161 shows comparable automation deployments produce a 14% agent productivity increase. Those numbers only compound at high volume. At five invoices a month, the math never closes.

Either dimension alone fails the ROI test. High volume without repeatability means the automation breaks most often on the edge cases that arrive most often - you have maximized both exposure and failure rate simultaneously. Repeatability without volume means the engineering overhead outlasts the savings; you end up maintaining automation for a task that almost never runs.

Contract negotiation is the instructive counterexample. It may occur at high volume across a legal or sales operation, but it scores low on repeatability: each negotiation draws on different inputs, creativity, and contextual judgment that no stable procedure can capture. FloQast's framework identifies it as a low-candidate task for exactly this reason. Automating high-volume, non-repeatable tasks is one of the most expensive - and most common - AI automation task selection mistakes.

AI Task Delegation Criteria: The Junior-Employee Proxy Test

Repeatability and volume answer whether automation is worth building. Delegatability answers a harder question: how much should the AI do without anyone checking?

The test is a proxy. Would you trust a competent but junior employee to execute this task without reviewing each output? If not, the AI should not run it without human review either. This is not an AI capability question. It is a task question. Some work carries judgment requirements, accountability weight, or contextual sensitivity that cannot be delegated - to anyone - without oversight.

Google DeepMind's "Intelligent AI Delegation" framework maps eleven dimensions for agentic AI task suitability decisions, with reversibility, criticality, verifiability, and subjectivity doing the most work. Reversibility is the clearest gate. Reversible actions - adding a tag, categorizing a ticket, drafting a document for review - can run fully autonomous with an audit log. Partially reversible actions - publishing content, sending email to a segment - warrant human-on-the-loop monitoring. Irreversible actions - deleting data, executing financial transactions, sending legal communications - require explicit approval before execution. These thresholds determine where human oversight of AI actions is non-negotiable.

Once the autonomy level is set, five implementation patterns cover the options:

  • approval flows
  • confidence-based routing
  • escalation paths
  • feedback loops
  • audit logging

These are not belt-and-suspenders overhead. They are the mechanism for matching oversight model to reversibility profile.

The economics close the argument. Partial automation - where AI assists rather than replaces judgment - is often the rational long-run outcome, not a transitional phase. The cost of moving from partial to full automation is often orders of magnitude larger than staying at partial. The delegation test is not only about safety. It is a cost question.

When Destructive Potential Overrides Every Other Signal

Destruction potential is not a variable in the automation decision. It is a hard gate. If wrong output destroys data, executes financial transactions, creates legal obligations, or exposes the company to liability, that score does not get weighed against efficiency gains. High destruction potential combined with any meaningful complexity means the task should never run fully autonomous, regardless of how cleanly it scores on every other dimension.

Three incidents show what happens when teams ignore that gate.

Air Canada's customer service chatbot told a passenger he could apply for a bereavement fare refund up to 90 days after his ticket purchase. The policy did not exist - the chatbot invented it. The customer followed the chatbot's instructions and was denied. Air Canada argued the chatbot was "a separate legal entity" and the company bore no responsibility for what it said. The BC Civil Resolution Tribunal rejected this, held Air Canada liable for negligent misrepresentation, and awarded damages to the plaintiff. The precedent established: chatbot misrepresentations carry the same legal weight as human ones.

Knight Capital is the financial scale. A deployment error activated legacy "Power Peg" code that had never been removed from production. The system ran fully autonomous - no human checkpoint, no kill switch in practice - and executed 4 million+ orders across 154 stocks in under 45 minutes. Losses reached approximately $440M. The firm required emergency capital and was acquired within months.

The Replit incident from the opening of this article belongs in the same category: explicit instructions violated, months of production data deleted for 1,200+ executives, no human gate between the agent and the database.

The Google DeepMind delegation framework names what all three cases lacked: "liability firebreaks" - human checkpoints that exist precisely because the cost of a wrong autonomous decision exceeds any efficiency gain from removing them.

For high-stakes, irreversible tasks, human oversight in AI workflows is not a design preference. It is the only architecture that holds.

Which Tasks to Automate With AI: An Invoice Processing Walkthrough

The six dimensions are not useful as a checklist. They produce a decision when combined.

Invoice processing is the profile subject because it is cross-industry, familiar to engineering managers, and scores clearly across all six dimensions - a combination that makes it a strong AI workflow candidate. The walkthrough also shows that "automate it" is too blunt an answer. The framework produces something more precise.

Complex? No. Invoice processing follows a defined procedure: extract fields, validate against the purchase order, route to the appropriate approver. Edge cases exist - damaged OCR, disputed amounts, first-time vendors - but they are bounded and categorizable. A finance expert can map them before execution. That makes this complicated, not complex. The input space does not shift unpredictably.

Complicated? Yes. Multiple steps, interdependencies, conditional logic. Requires domain expertise to specify correctly - but it is fully mappable. What can be mapped can be automated with care.

Repeatable? Yes. Every invoice follows the same path: document in, validated fields, PO match, approval routing, payment or rejection out. The steps do not change based on who submitted the invoice or what day it is. That stability is what allows a workflow to be fully specified.

High volume? Yes. Vendor cost data suggests manual processing runs $12-30 per invoice, dropping to $1-5 automated - a 60-80% cost reduction at scale. At 5,000 invoices a month, that gap compounds quickly. At five invoices a month, the engineering overhead outlasts the savings.

Delegateable? Yes. A junior accounts payable clerk can execute this process unsupervised with a clear brief and escalation rules. The AI should meet the same bar. Reversibility is partial: approvals can be unwound upstream; issued payments are harder. That matters for how the autonomy is structured, but it does not veto automation.

Destructive? Medium. Errors cause vendor friction and payment delays - real costs, not trivial ones. But they are not data loss, legal liability, or financial-market events at the scale of Air Canada or Knight Capital.

The combined profile produces a specific operating architecture. Standard invoices: full automation. Edge-case invoices - ambiguous PO match, damaged OCR, first-time vendor, disputed amount: confidence-based routing to human review. High-value approval decisions: human-on-the-loop monitoring.

The counterexample matters. Contract negotiation may run at comparable volume in a legal or procurement operation. But the framework produces a different answer from dimension one: no stable procedure exists for negotiation - the outcome depends on the other party, prior relationship, and contextual judgment a junior employee could not replicate unsupervised. Complex, not complicated. Add high destruction potential - every committed clause is a legal obligation - and low delegatability. The verdict from dimension one is already clear: no full automation, regardless of volume.

The Six Questions Before You Build

Every AI workflow automation failure has the same autopsy: someone built before they asked the questions.

Before you build, run the diagnostic:

  1. Is the task complex or complicated - does the right answer only emerge from execution, or can an expert map the procedure in advance?
  2. Does it run the same way every time - same inputs, same steps, same expected output?
  3. Does the volume justify building and maintaining it?
  4. Would you trust a competent but junior employee to run it unsupervised?
  5. What breaks if the output is wrong - data, transactions, legal commitments, customer trust?
  6. Does destruction potential override every other signal regardless of how the others score?

The teams that get AI automation right are not the ones with the best models. They are the ones who treated evaluating tasks for AI automation as step zero - before they wrote a line.

Sources11