Low Value Work Stops

Part of "The Operator's View: AI Workforce" Part 2, Article 9 (4 min read)

When Low Value Work Stops Getting Done

What disappears as systems optimise

AI systems optimise for efficiency, as they do, not all work is treated equally. Tasks that are repeatable, measurable, and high confidence are prioritised. Tasks that are ambiguous, low impact, or difficult to evaluate are deprioritised.

Over time, low value work begins to disappear from the system, this does not happen through decision, it happens through optimisation.

In operations, we see this pattern and it is familiar. When teams are under pressure, essential but low visibility tasks are delayed. Documentation, maintenance, and edge case handling are pushed aside. Not because someone decided to cut them. Because the system stopped rewarding them.

The same dynamic applies here.

As optimisation increases:

These gaps are rarely visible in reporting, that is because reporting reflects completed work, not omitted work.

This is not a new failure mode. It has a name.

Goodhart's Law states that when a measure becomes a target, it ceases to be a good measure. The original formulation, from economist Charles Goodhart in 1975, observed that any statistical regularity tends to collapse once pressure is placed on it for control purposes. Research extending this principle into automated systems finds the effect intensifies as optimisation speed increases, the faster a system can act on a metric, the faster unmeasured work is abandoned.

In AI driven environments, this plays out structurally. The system is not choosing to neglect low visibility work. It is doing exactly what it was designed to do: optimise for what it can measure.

Peer reviewed research on AI deployment in high stakes operational environments identifies this as a distinct risk category; termed invisible automation. It is defined as weaknesses or gaps in processes that maintain awareness of what automated systems are and are not doing. The gaps are not visible in outputs, they are visible only in what is missing from them.

The pattern is also documented in practical IT systems. Once a task is automated, it tends not to be reviewed again, and the underlying process steps are forgotten. Then problems accumulate undetected because everyone assumes the system is handling it.

Systems appear efficient while resilience declines.

Over time, this creates hidden exposure. I have covered this in previous articles, that organisation reports strong performance on everything it measures. The risk sits in what it stopped measuring and what the system quietly stopped doing.

I read many articles on pointing out problems, as my nature and roles have always been about how do we improve or fix what looks like a problem:

How to fix? Operators need to actively identify what is not being done.

Now this is harder than it sounds. Its not like you can find omitted work by looking at what completed. Your more likely to find it by examining the boundaries of what the system was designed to measure, and then looking at what sits just outside those boundaries.

You could in practice, try asking a different set of questions.

For example let’s assume standard reporting asks: how many tickets were resolved, what was the handling time, what was the satisfaction score. These are output measures; they tell you what the system processed.

The questions that bring to surface omitted work are different:

These are gap questions, not efficiency questions. They are designed to bring to surface the work that the system is not completing or is completing in a way that generates more work downstream.

The distinction matters because AI assisted support systems are particularly susceptible to this failure mode. A response can be generated, delivered, and closed without resolving the underlying issue. The ticket is counted as handled but the problem continues. Then the customer returns and the queue grows in ways that do not show up cleanly in any single metric.

This is not a failure of AI capability, more correctly, it would be a measurement design problem. The system is reporting on what it did, as it was designed to do. Nobody is systematically reporting on what it failed to do, what it deferred, or what it created.

Closing that gap requires a layer of analysis that sits above the operational system, one that correlates outputs against downstream behaviour rather than treating each interaction as complete in isolation. It looks at whether a resolved ticket stayed resolved. Whether a deflected contact returned through a different channel. Whether response patterns in one category are driving volume growth in another.

That kind of analysis is not available inside the tools that generate the responses. It requires an external view, one that treats the AI system's output as an input to a quality control process, not as the end of one. This is why experienced professionals and operators are going to be more valuable as investment in AI continues.

Efficiency does not remove work, what it does do, is it changes what survives inside the system. The operator's job is to see what didn't.

References

Continue the series Previous: AI is Coordinating — Next: AI Takes Control

Stay Connected: If you're interested in discussions on AI or how AI is actually delivered; across infrastructure, energy, networks, materials, and supply chains, please subscribe:
https://digitalbackbone-be8806.beehiiv.com/

Footnote: This article is part of a series exploring topics:
AI is constrained by physical infrastructure, and increasingly shaped by economic behaviour at scale

Disclaimer: The views expressed in this article are my own and are intended for general information and discussion purposes only. They do not represent the views of any employer, organisation, or client.

© 2026 Rodney Terry – Digital Backbone. All rights reserved.