Stop Automating Your Old Process. Redesign It for Agents

Thirty-six years ago, Harvard Business Review ran an article called “Reengineering Work: Don’t Automate, Obliterate.”

Michael Hammer’s argument was that companies were taking the processes they already had and laying technology over the top, which reliably produced a faster version of the same problem. The instruction was in the title. Don’t automate the existing process — get rid of it and design the one you’d build now.

That ran in the most mainstream management publication there is. We did it anyway. We did it with ERP, then again with RPA, and the projects that failed mostly failed the way Hammer said they would.

Most of the enterprise AI agent deployments being described to me today are the same project. Different technology. Same approach.

I’ve seen this movie before

When RPA was the hot technology, the pitch was simple: take the work a person does, describe it to a bot, and let the bot do it instead. On paper that made sense. In practice, most organizations pointed their bots at processes they hadn’t looked at critically in years — undocumented exceptions, inconsistent inputs, and approval steps that existed because someone, once, didn’t trust someone else in the chain.

The bots that worked were the narrow ones. Well-defined, clean data, process steps that actually needed to exist. A small fraction of the work.

The ones that failed automated the cow path. They produced a faster, more expensive version of the same broken process.

AI agents are more capable than RPA. They handle variation and ambiguity that would have stopped a bot cold. But capability still has prerequisites, and the most common mistake I see right now is organizations deploying agents to traverse the same path faster, when the question on the table is whether the path needs to exist at all.

The numbers suggest the transition is already stalling in the familiar place. Deloitte’s Tech Trends 2026 cites its 2025 Emerging Technology Trends survey: 38% of organizations are piloting agentic solutions and 11% are running them in production. Deloitte’s own explanation for the gap is that enterprises are trying to automate processes designed for humans rather than reimagining the work. Anyone who lived through RPA will recognize the shape of that. The pilot works, and then it meets the process.

The constraint question

Here is the question that changes the analysis: which steps in this process exist because of human constraints, and which exist because of actual business requirements?

They are not the same thing, and in most processes they aren’t labeled.

The approval routing every invoice over $5,000 to a manager — is $5,000 a meaningful risk threshold, or did the person who designed the process in 2009 not trust the AP clerk who had just quit? The overnight consolidation batch — does the business need daily timing, or could the system not handle real-time queries and a human not stay up all night? The three-day review queue — does thorough review take three days, or can a human only process so many files per shift?

Agents run continuously. They have no shift patterns and no attention fatigue, they process in parallel, and they pick up exactly where they left off. When an agent replaces a human in a workflow, the constraints that shaped that workflow don’t disappear on their own — you have to eliminate them deliberately. Most organizations aren’t doing that. They plug the agent into the existing slot and wonder why the ROI disappoints.

Value stream mapping for the agent era

The method that works here isn’t new. Process improvement practitioners have done value stream mapping for decades: map a process end-to-end as it actually works rather than as it’s documented, identify where value is added versus where time is merely consumed, and redesign the flow around the constraint you’ve removed.

Applied to agents, the questions become:

1. Map the process as it actually works today — including the informal steps, the workarounds, the “we always do it this way” steps that appear in no SOP.
2. For each step, ask whether it exists because of a business requirement or because a human was doing the work.
3. For every step that exists because of a human constraint, ask what happens if you eliminate it entirely.
4. Redesign the process for agent capabilities, placing human judgment at the points that genuinely require it.

The output isn’t a slightly improved version of the old process. It’s a different process that happens to produce the same result.

What this looks like in finance operations

Month-end close was designed around shift patterns. Transactions close at end of day, journals are prepared in the morning, consolidation runs overnight because the team can’t work continuously. An agent can. Design the close for agents and the monthly calendar stops being the organizing principle — the close stays current, and human judgment goes to the entries that require it.

Tax workflows were built on handoffs and review queues. A partner reviews what staff prepared; staff prepared what clients sent; clients send when they get around to it. Each step waits for the one before it because a human processes one thing at a time. Agents work in parallel. They can take the file as documents arrive, keep a running status of what’s complete and what’s missing, and surface the handful of items needing professional judgment while the rest of the return keeps moving.

One caution before you redesign anything

Every process has steps that exist because a person is quietly absorbing variance — an input arrives in the wrong format, a field is blank, a vendor changes a template, and someone fixes it without ever recording that they did. None of it is in the SOP, because the people doing it don’t think of it as work.

For an agent, that’s a live failure mode, and it was one of the top five categories of breakage I had to fix in bot deployments. So for every step you eliminate, decide explicitly what the agent does when the input isn’t what it expects: handle it, or stop and ask a human. An agent that keeps going on bad input produces plausible output at speed, and nobody notices until the month is closed.

The question to carry in

Before any agent deployment, ask a different question than the one on the project charter. Which steps in this process exist only because a human was doing the work — and what would we build if we designed this from scratch for an agent?

Hammer’s instruction is thirty-six years old and it has never once been the easy option. Automating what exists is faster to approve, cheaper to scope, and easier to explain to a steering committee. That is why the cow path keeps getting paved — first by hand, then by software robots, and now by agents, which we are calling transformation.

The organizations that get genuine value from agents will be the ones that stop and ask whether the path needs to be there at all. Deployment count is a vanity metric.

—

What’s the process in your operation where you suspect the steps exist more for historical reasons than business ones? That’s usually where the redesign conversation starts. I’d be interested in what you’re finding.