Blog post

Assessing Tasks for Automation in 2026

The classic framework for choosing what to automate is due for an update. Applying the theory of constraints to knowledge work reveals why context outputs matter.

September 8, 2026 · 9 min read

Cans of beer in the production line
Photo by cottonbro studio on Pexels

Knowing which tasks to automate has historically been one of the most difficult assessments to make in knowledge work. For many years, the technology industry has borrowed the assessment framework from manufacturing, or some form thereof. The classic framework for evaluating a task for automation goes something like this:

  • Does the task happen often enough to justify automation? (repetitive)
  • Can the decision points be reduced to fixed logic? (rule-based)
  • Does the task absorb enough time to justify automation? (high bandwidth)
  • Is the task prone to human error? (error rate)
  • Is the underlying system stable enough to justify automation? (robust)

And now with the advent of agentic task delegation and LLM-based automation, the number of tasks that can be automated has exploded. Within the right context, the rule-based prerequisite (no. 2) for automation is effectively eliminated, opening up uncountable new automation use-cases.

The Theory of Constraints

But, just because we can automate a task or system, doesn’t necessarily mean that we should automate it. In an assembly line, prioritizing tasks for automation is done by applying the theory of constraints. The theory of constraints states that you should focus all automation efforts on only the task which is the limiting factor on the assembly line; the bottleneck. Automating any other step in the process only serves to pile up work at the true bottleneck, causing rippling disruption throughout the system. In order to apply the theory of constraints in knowledge work, we must first understand the nature of our system’s constraints; we need the ability to identify our bottleneck. While we tend to think of bottlenecks as process inefficiencies (tasks that take too much bandwidth), they can also take the form of context deficiencies. These context constraints fall in one of several categories:

  • Data quality and access
  • Problem-space understanding
  • Solution or system understanding

Intersecting Systems

Applying the theory of constraints on an assembly line is relatively simple and intuitive. But workflows in knowledge work are invariably more complex. Every deliverable may be traceable to something like an “assembly line”, but we tend to work within a tangled web of assembly lines. Because of the interconnectedness of these systems, it’s very difficult to tell when the contextual output of one assembly line may become important contextual input in another, intersecting assembly line. For example, here is a scenario typically seen as a slam-dunk use-case for AI: An executive wants a monthly report based on sales data. Historically, the “assembly line” for this deliverable looks like this:

DBA configures data access and is the expert on architecture and data access. Data analysts access and become familiar with the data as it exists. Executives get the data insights that they need.

The simple, AI-driven assembly line looks like this:

The executive can receive their deliverable faster and cheaper, but the contextual outputs of the system are lost.

This seems like an obvious win. We get the same deliverable, often faster and perhaps even higher quality. Using fewer man-hours means we produce this a lot cheaper as well. However, this only holds up if viewing the report as the only product in the assembly line. In the human-driven line, we have also produced:

  • Deeper understanding of data security and access control (DBA – solution context)
  • Deeper understanding of the limitations of the data platform and needs of the data analysts (DBA – problem context)
  • Deeper understanding of the available data and how it can be wielded (Data analyst – solution context)
  • Deeper understanding of the types of problems executives wish to solve with the current data (data analyst – problem context)
  • Deeper understanding of data health, accuracy, ingestion, & relevance (whole system – data quality context)

In isolation, these context products, or contextual outputs of the system may not be of any value. But the value of these products increases and compounds with each intersecting assembly line. Without the contextual outputs being captured, we may quickly create a new bottleneck in an intersecting assembly line. Consider a simple complication and how it impacts each of these systems: at the same company, an engineering team wants to measure conversion rates and average sales against feature implementation and application versions:

New requests, or “intersecting assembly lines”, benefit from the contextual outputs of human-driven systems.

Of course, it’s very possible to do this with an AI agent-driven data system, but you can see how the context needed to execute balloons quickly. Before implementing this simple dashboard, the following context must exist somewhere:

  • Does the necessary data exist?
  • Is the necessary data accessible?
  • Is there an existing interface for receiving/viewing the surfaced data?
  • Can the database/data pipelines support the new traffic?
  • Will the surfaced data produce insights of value?

The point of this thought exercise is not to prove that AI-driven systems are not capable of gathering complex context. Rather, it is to show that context outputs of one system often become valuable context inputs to another, and automating away context outputs can cause invisible bottlenecks to appear. Humans are particularly good at applying cross-system context, whereas AI agents and LLM-based tools work best when the scope of their context and intent is focused and limited. Not to mention, AI tools must be explicitly exposed to the context they consume to make decisions, and at some layer of the agentic onion, it must be a human supplying or exposing the critical context. And the more that the human understands about the problem space and existing system, the more precise and effective they can be at supplying that initial context.

The human, who could only have gained their mastery of the task’s problem-space and solution system by working with it deeply, is the best candidate for designing its automation.

This inherent tension is an extension, perhaps the logical conclusion, of The Ironies of Automation, a seminal 1983 research paper by Lisanne Bainbridge speculating on the impact of machine and computer-based automation. If you have gotten this far in my write-up, you simply must read it.

Conclusion and Practical Advice

Let’s bring this back to automation and our framework for assessing a task for automation. I suggest that the obsolete “rule-based” automation prerequisite be replaced with the following:

Is the contextual output of the task disposable, isolated, or condensable?

Not quite as snappy as the original, but I think it serves an important purpose. The more interconnected a given system is, the more important it is that the system is understood. Otherwise, gaining critical insight on system failures, novel problems, and system improvements becomes much more difficult and expensive. Essentially, a system that is stable and/or isolated might be a good candidate for agentic automation. In an ideal automation scenario, we have minimal “intersecting assembly lines” and can tolerate the contextual output being lost or otherwise condensed.

Other heuristics to lean on:

  • Prefer deterministic automation whenever possible.
  • Only use agentic automation if you can answer yes to one of the following questions: Can the failure modes of the automated system be predicted and simulated? Does the context exist for the system to be fixed upon failure?
  • Ensure the humans responsible for automation can refine their knowledge such that they can create improvements or novel extensions to the system in the future.
  • Ensure that the cost of validating, monitoring, and coordinating the task does not exceed the savings of automating it.

The best professional advice I can leave you with is this: choose your friction. AI is often seen as the great toil eliminator. With the right prompt, skill, or agent, we can automate away almost any task. However, we should seek not to eliminate all toil from our work but rather maximize the time and intensity of our most valuable forms of toil. Seek out the work that makes you grow.

Cognitive Catalyst

Want more? Sign up for the newsletter.

A fortnightly newsletter for businesses and professionals prioritizing human skills in an AI-augmented future.