Every language model rests on one foundation: predicting the next word. To do that well, it learns the patterns behind language, and from those patterns comes its ability to reason and decide. What we point that ability at is up to us. Most of the industry points it at completing tasks. I have pointed the same capability at a different order: eliminate first, automate what cannot be eliminated, then seek human assist.

A HackerNoon piece by Vasudev Gupta traces the evolution of LLMs through exactly this lens: what we train them to do. First predict the next token, then be a helpful assistant, then reason before answering, and now act until the job is done. Each leap came from changing the objective, and the deliverable has moved from an answer to finished work. It is an accurate account. But one objective is absent from it, and from almost every enterprise AI roadmap I see: elimination.

The objective nobody trains for

An agent rewarded for finishing the task will finish the task. It will never conclude that the task should not exist. Reaching that conclusion takes a different objective: extract the pattern behind recurring work, trace it to its cause, and remove the cause.

Without that objective, the generative AI evolution leads to one place: task automation. We get faster, cheaper execution of the operating model we already have, including all the work that never needed doing.

Four cases: the answer was there, but only when asked why

I have put real operational scenarios to models, both frontier and open weight. The pattern is consistent.

The deletion ticket. A user at a manufacturing company raised a ticket to delete a line item they were not allowed to delete. The RPA-era answer was to automate the deletion. BPOs still sell that service, and agentic AI companies now convert those bots into agents, sold as a service or as the agent itself. Nobody asks the real question: is the permission model right? If the user should be able to delete it, fix the role. If not, the ticket should never be raised.

The no-action monitoring ticket. An alert created a ticket assigned to a human, who simply waited until it auto-closed. The model’s disposition was to automate, since no human was needed. When I asked why it was a ticket at all, it agreed: configure the wait in the monitoring tool and delete the alert.

The disk space batch failure. A full disk kept breaking a batch process. The model produced a script to check space, clean up and rerun. When I pointed out that an earlier batch step creates a huge file that is never moved, it agreed the fix belonged inside the batch process itself.

The campus Wi-Fi. A large campus area network had engineers stationed on site, running to every Wi-Fi issue. The model proposed automating the ticket at the controller level, so each ticket would trigger a reset. The elimination disposition is different: configure the wireless controller to detect a failing access point and restart it when it is safe to do so. That check-and-act capability already exists in the controller. When I pointed this out, the model agreed.

In every case the model could reach the elimination answer. It only got there because a human asked why. The capability is present. The default is not.

The hidden cost of automating symptoms

Look at what each default answer produces: a bot, a script, an agent. Each is a new artifact that someone must own, monitor, patch and eventually migrate. Each elimination answer produces nothing new. It rewires a platform the enterprise already pays for: a role permission, an alert setting, a batch step, a controller capability.

This repeats across every layer: business process, application, data and infrastructure. Work was first set up for humans, then scripted, and is now being converted into agents. Each wave carries the previous wave’s unexamined work forward and adds its own maintenance cost. Few organizations count that cost, because it is spread across teams and budgets.

Why this is a training problem

Models default to automation for reasons built into how they are trained:

  • Pretraining data. Decades of RPA, BPO and agent-vendor material make “automate the ticket” the dominant pattern in the corpus.
  • Human feedback. RLHF rewards answering the request as framed. The ticket says fix it, so fixing it is rated helpful. Questioning whether the ticket should exist can read as unresponsive.
  • Agentic reinforcement learning. Agents are rewarded for completing tasks. A closed ticket is a cheap, verifiable reward. A ticket that never recurs plays out over months and across systems, so nobody trains on it.

The HackerNoon article makes the point that progress comes from designing data that teaches the right objective. Elimination needs exactly that data:

  • Preference pairs where rewiring the existing platform ranks above automating the symptom.
  • Rubrics that reward asking why the work exists, checking native platform capability first, and avoiding new artifacts to maintain.
  • Outcome rewards drawn from historical operational data: did the pattern stop recurring?

Enterprises already hold this data in their tickets, logs and process history. Very few use it this way.

Why no enterprise has an elimination office

If elimination is the better objective, why does nobody fund it? Because almost no one in the decision chain is paid for work that disappears.

  • Service providers. BPOs bill per FTE or ticket, agent vendors per agent or consumption, integrators per build. Elimination shrinks every one of those revenue lines.
  • Platform vendors. Pointing customers to capability they already own generates no upsell, so account teams pitch new AI add-ons instead.
  • Budgets. Boards ask for an AI strategy, so funding flows to visible agent programs. A ticket that never happened cannot be demoed.
  • Silos. The four cases above span access, monitoring, batch and network teams. Each automates within its lane. Nobody owns a cause that cuts across them.
  • Metrics. Managers are often measured on team size, and providers on SLAs and ticket volume. Elimination makes both look smaller.
  • Perceived risk. Rewiring a production platform feels invasive. An agent on top feels safe and reversible, even though it costs more to run over time.

There is a precedent. ITIL problem management has existed for decades and is essentially elimination, yet it remains one of the least funded practices in IT. Lean made eliminating waste central to manufacturing, but that discipline never carried over into IT operations.

The case for an elimination office

LLMs, MCP servers and agents will not deliver their full value until someone asks whether the work should exist. That question needs an owner. An elimination office would:

  • Own the “should this exist?” decision before any automation is funded: eliminate first, automate what cannot be eliminated, then human assist.
  • Work from historical intelligence across tickets, logs and process data, not workshops and opinions.
  • Be measured on demand removed and business outcomes moved, not tasks automated.
  • Report to the CFO or COO, who own cost and performance outcomes, with change management built in so elimination reads as removing waste, not headcount.
  • Pair with outcome-based commercial models, so providers are paid for results rather than activity.

The HackerNoon article closes by asking what we reward agents for. My answer: reward them for work that never has to happen. The model already knows the answer. It just was not trained to ask.

Part of an ongoing series on enterprise intelligence: building intelligence into every process, application, data layer and infrastructure so it drives peak business performance. Earlier: the intelligence hiding in your own data and why peak business performance starts with what you eliminate.