What's in this issue and why it matters

The report arrived every Monday at 7am. Clean. Formatted. On time.

For fourteen weeks, nobody questioned it. Then a board member asked one specific question — and nobody in the room could answer it. Because nobody had looked at the actual data since the automation went live.

This week: what workflow automation actually does to oversight, why a running workflow is not the same thing as a working one, and five questions to ask before your next process goes live unsupervised.

Read time: 4 minutes.

Before the automation, someone spent three hours every Monday compiling the status report. Chasing teams. Reconciling numbers. Formatting the deck.

Three hours. Every week. Gone.

The AI-powered reporting workflow replaced all of it. Reports arrived at 7am, every Monday, without anyone touching them. The steering committee stopped asking questions. The dashboard answered them before they could be raised.

Fourteen weeks in, a board member asked about one metric. Customer activation rate for week nine.

The VP pulled up the latest report. Read out the number.

"That doesn't match what the customer team told me Thursday," the board member said.

Silence.

The reporting workflow had been pulling from a misconfigured data source for eight weeks. Every report since then had been wrong. Clean. On time. Wrong. And because the report arrived so reliably, so professionally — nobody had thought to verify it.

Eight weeks. Fourteen reports. Decisions made on bad data.

That is not an automation failure. That is what happens when you automate a process and mistake the running of it for the oversight of it.

Here is what the automation removed that nobody noticed at the time.

When someone spent three hours compiling that report manually, they were also — without realizing it — reviewing it. A number looked off. They called someone. They verified. That check was built into the inefficiency.

The automation removed the inefficiency. And the check went with it.

This is the specific risk nobody puts in the implementation plan. Automation is excellent at repeating a process. It is not good at knowing when the process is producing the wrong result. It does not pause. It does not question. It does not call anyone on a Friday afternoon when something looks different from last week.

You still have to do that. The workflow cannot do it for you.

The organizations getting this right do one thing differently. They separate the automation of the task from the oversight of the output. The workflow runs. The review of what it produced is a separate, scheduled, human activity. Two things. Both necessary. Never the same thing.

The organizations that struggle treat the running workflow as proof that everything is fine.

It isn't. It is proof the workflow ran.

Those are not the same.

Understand what's happening:

1/ McKinsey, Superagency in the Workplace 2025 🔗 https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/superagency-in-the-workplace

What it says: Enterprises are scaling automation faster than governance can keep pace. Productivity gains are real. So are the oversight gaps.

My take: McKinsey is more comfortable with the upside than the failure modes. Read this for the scale of what's happening. Read something else to understand what can go wrong.

2/ Gartner, Hyperautomation and Its Failure Modes 🔗 https://www.gartner.com/en/information-technology/insights/hyperautomation

What it says: Connect enough automated workflows together and failure becomes hard to trace. The more tools in the chain, the harder it is to find where it broke.

My take: Build audit points into the design. Not the post-mortem. Every handoff between automated tools is a place where a wrong input compounds silently into a wrong output three steps later.

Make sense of the debate:

3/ HBR, When Automation Goes Wrong 🔗 https://hbr.org/2023/09/when-automation-goes-wrong

What it says: Most automation failures are design failures. Processes got automated before anyone mapped the exceptions — the edge cases that a human used to handle with judgment nobody documented.

My take: This is the most useful framing on this list. The workflow did not fail. The design failed to account for what the human used to catch during execution. That is a program management problem, not a technology problem. Most teams treat it as the latter and miss the real fix.

Act on it:

4/ Deloitte, Intelligent Automation: Getting Governance Right 🔗 https://www2.deloitte.com/us/en/pages/deloitte-analytics/articles/intelligent-automation.html

What it says: Automation governance needs three things working together: oversight of the process, monitoring of the output, and a documented exception pathway. Most organizations have the first. Few have all three.

My take: The exception pathway is where most programs are weakest. What happens when the workflow hits something it was not designed for? In too many programs: it handles it badly and nobody finds out until the damage is done. Write the exception pathway before you automate the process.

Do not run these in the post-mortem. Run them in the design phase.

1. What does this workflow do when the input data is wrong? Not incomplete. Wrong. Does it fail visibly — or proceed silently?

2. What is the exception pathway? When the workflow hits something outside its design, who gets notified? Write a specific name. Not a team. Not a role. A person.

3. What human check exists for the output — separate from the workflow itself? How often? By whom? What are they specifically looking for?

4. What would wrong look like? Describe it in one sentence before the automation goes live. If you cannot describe it, you cannot catch it.

5. What is the rollback? If this workflow produces incorrect output for four weeks, how do you identify it, stop it, and correct the downstream impact?

If your team cannot answer questions two and three — the exception pathway and the human check — the workflow is not ready to run unsupervised.

Your reporting workflow is running. The reports are arriving. They look clean.

When did someone on your team last verify that the number in the automated report matches what is actually happening — not because something looked wrong, but as a routine check?

If the answer is "not since the automation went live" — that is not confidence in the system.

That is the oversight gap the automation made invisible.