Cut process complexity before you add AI agents

Last updated: July 2026

Automating a broken process does not fix it; it hardens the breakage and executes it faster. Before deploying AI agents on a workflow, delete the steps that should not exist. The case for that sequencing is stark: MIT research found 95% of enterprise GenAI pilots deliver no measurable P&L impact, and the stalls trace to workflow fit, not model quality.

Key takeaways

• MIT's NANDA initiative found 95% of enterprise GenAI pilots deliver no measurable P&L impact; the tools stall because they do not learn from or adapt to the workflows they sit in (Fortune, 2025).
• Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.
• Only 21% of organisations using gen AI have redesigned any workflows, yet McKinsey finds fundamental workflow redesign is the organisational change most correlated with EBIT impact.
• The advice is 36 years old: Michael Hammer's 1990 rule, "don't automate, obliterate," applies with more force to agents than it did to the enterprise IT it was written about.
• Across the agent projects we shipped in 2025-26, deleting process steps before building removed roughly a third of the planned integration scope. The cheapest engineering hours are the ones you never buy.

Why does automating a broken process make it worse?

Because automation is an amplifier. Michael Hammer made the argument in 1990 in Reengineering Work: Don't Automate, Obliterate: companies were embedding outdated processes in silicon and software instead of eliminating them, and the heavy IT spending of that era disappointed accordingly. Agents raise the stakes on the same mistake. A script executes a bad process rigidly, so its failures at least look identical. An agent executes a bad process at volume and with variation, working around obstacles a human would have questioned, and producing confident output at every broken step. This is why simplification sits at the front of the production patterns in our pillar guide to agentic AI workflow services: the process is the specification, and agents inherit its bugs.

Why do agent projects inherit process debt?

An agent has to encode every rule of the workflow it runs, including the rules nobody wrote down. Every undocumented approval, dormant exception branch, and duplicate handoff becomes an integration to build, an evaluation case to test, and a failure mode to monitor. That cost structure explains the cancellation data. Gartner attributes its 40% cancellation forecast to escalating costs and unclear business value, which is what happens when a team discovers mid-build that the process has twice as many rules as anyone believed. The MIT finding rhymes: pilots stall when tools fail to fit how work actually flows. Complexity is not just a drag on the process. It is the line item that kills the project.

What should you delete before you build?

Map the full workflow with the people who run it, then work through four categories of candidate deletions before writing any agent code. The order below reflects how often each category shows up in the workflows we map, most frequent first.

Approvals that never say no

If an approval step approves more than 99% of what reaches it, it is not a control. It is a log with latency. In the workflow-mapping sessions we run before agent builds, these are the first candidates found and the easiest to remove: replace them with a notification and an audit trail, and reserve genuine approval for the cases that historically got rejected.

Handoffs that only move information

A handoff earns its place when the receiving party transforms the work or adds a judgment. A handoff that only relocates information adds queue time and an error surface, and once an agent arrives it calcifies into an API boundary someone has to build and maintain. Collapse those steps first; each one deleted is an integration you never pay for.

Exception branches nobody can explain

Ask the process owner when each branch fires. If no one can answer, an agent cannot either, and the branch will surface later as an unexplained eval failure. Either document the trigger precisely or retire the branch and let the exception route to a human queue. A named queue beats a mystery rule.

Outputs nobody reads

Reports, status emails, and reconciliation files with no downstream consumer are pure waste today and worse tomorrow, because an agent will generate them tirelessly and at cost. Deletion beats automation on every metric that matters here. If the output vanishes for a month and nobody asks, it was already gone.

How do you know a process is simple enough for an agent?

Three tests, applied in order. First, the process fits on one page, exceptions included; if it cannot be described, it cannot be delegated. Second, it has a named owner who can state what a correct outcome is, because that statement becomes the evaluation set. Third, the exception rate is known, because that number sets the human-review threshold and the staffing behind it. McKinsey's State of AI research shows why the bar is worth clearing: only 21% of organisations have redesigned workflows when adopting gen AI, yet redesign is the change most correlated with EBIT impact. The one-page version of the process is the redesign.

Isn't this just business process reengineering again?

The diagnosis is the same; the economics are not. Reengineering in the 1990s meant multi-year consulting programmes because mapping and rebuilding processes was manual and slow, and many efforts collapsed under their own weight. The agent era inverts the cost curve. The build itself forces the map to exist, because every rule must be written down to be delegated, and a simplification pass beforehand is a two-week exercise, not a two-year one. Simplification stopped being a transformation programme and became a delivery phase, which is exactly how our product engineering practice treats it: deletion is scoped, scheduled, and signed off like any other milestone.

What does this look like in practice?

A composite from our production work. A document-heavy invoice workflow arrived for automation with twelve steps, four of them approvals. Mapping showed two approvals that had never rejected anything and two handoffs that only moved files between teams. We deleted those four steps before building, cutting the agent's integration scope roughly in half, and shipped against the five steps that remained. The agent now routes 2-3% of documents to human review, a ratio that is only manageable because the redundant approval layers went first; run through the original twelve steps, the same volume would have buried the review queue.

The lesson generalises beyond agents, and it is the process-side twin of the team-design argument in building autonomous teams with less process and more impact: fewer steps means fewer handoffs, clearer ownership, and less for any system, human or agent, to inherit.

Gartner's cancellation window runs to the end of 2027. Between now and then, every enterprise agent budget will quietly fund one of two things: encoding a process as found, or encoding a process worth keeping. The deletion audit that decides which takes about two weeks. Schedule it before the agent budget is committed, not after the eval suite starts failing.