Automating a Broken Process Just Makes It Fail Faster

Most people do not have an automation problem. They have a process problem wearing an automation costume.

Automating a broken process means handing a flawed, undocumented workflow to software so it repeats that flaw at machine speed. The work still gets done wrong. It just gets done wrong faster, more often, and in more places at once. That is the reframe for this week, and it is the reason a lot of solid operators spend a weekend building something that quietly makes their Monday worse.

I spent 16 years doing enterprise automation work before I ever ran my own systems. The pattern never changed. The builds that failed were almost never the ones with bad code. They were the ones where nobody could explain the process in plain English before we started.

Key takeaways

• Automating a broken process does not repair the process. It repeats the same errors at higher speed and larger scale.
• Gartner predicted in June 2025 that over 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.
• A 2025 MIT Media Lab report, The GenAI Divide: State of AI in Business 2025, found that only about 5 percent of integrated AI pilots produced measurable profit and loss impact.
• The CLEAR Check is a five step review you run before any build: Count the steps, Locate the failure, Eliminate the waste, Agree on the standard, Run it clean once.
• Only automate a process you have already run manually, start to finish, without fixing an exception by hand.
• Tools like n8n and Microsoft Copilot Studio execute the process exactly as written, which is why the written process has to be correct before the build starts.

Why automation makes a bad process worse

A manual process has a hidden safety feature: you. When something looks off, you pause. You notice the duplicate invoice, the client who already replied, the lead that came in twice. You fix it without ever writing the fix down.

This is the most expensive of the common AI automation mistakes, because it hides. Automation removes that safety feature and keeps everything else. The software does not pause. It does not notice. It runs the same sequence at 3 a.m. on a Sunday, six hundred times, with no one watching.

Speed is a multiplier, and a multiplier works on errors exactly as well as it works on results.

The industry data lines up with this. Gartner predicted in June 2025 that over 40 percent of agentic AI projects will be canceled by the end of 2027, pointing at escalating costs, unclear business value, and inadequate risk controls. A 2025 MIT Media Lab report found that only about 5 percent of integrated AI pilots produced measurable profit and loss impact, and named brittle workflows and misalignment with daily operations as the core barrier. Neither of those findings is about the models. Both are about the work the models were pointed at.

If you already built something and it is limping, that is a separate decision. Knowing when to kill an automation is its own skill, and it usually costs less than patching a build that was wrong at the blueprint stage.

The CLEAR Check: five steps before you automate anything

This is the pre flight review I run on any process before a single workflow gets built. It takes about an hour. It has saved me weeks.

C: Count the steps

Write the process out, every step, in order, as if you were handing it to someone on their first day. Not the version in your head. The version on paper.

Most people discover their “simple” intake process has 19 steps and four of them only exist because of a tool they stopped using last year. If writing it out feels slow, that is the point. You can create SOPs with AI to speed up the drafting, but the steps have to come out of your head first.

L: Locate the failure

Find the exact step where the process actually breaks. Not where it feels painful. Where it breaks.

Those are different things. The step that feels painful is usually the boring one. The step that breaks is usually a handoff, a place where information moves from one person, tool, or inbox to another and something gets dropped. Automating the boring step feels great and changes nothing. Automating the handoff is where the real gain shows up.

E: Eliminate the waste

Delete every step that exists only out of habit. This is the cheapest improvement available to you, and it is free.

Ask one question on each step: if this step disappeared tomorrow, what would actually break? If the honest answer is “nothing, it would just feel weird,” cut it. A process you cut by a third before automating is a build that costs a third less to make and a third less to maintain.

A: Agree on the standard

Decide what “done correctly” means, in writing, before anything runs on its own. An agent cannot meet a standard you have never stated.

This is where most solo operators stall, because the standard lives in judgment they have never had to explain. That judgment has to become text. While you are writing the standard, write the exceptions too. Clear AI agent escalation rules are what turn “the agent handled it” into “the agent stopped and told me,” which is the difference between a system and a liability.

R: Run it clean once

Execute the revised process manually, start to finish, one time, with no hand fixes. If you had to step in and correct something, the process is not ready.

A clean manual run is your proof that the written version matches reality. When it passes, the safest next move is to run the build in shadow mode before it gets send access to anything a client can see.

Example scenario: the intake that broke at scale

Example scenario, not a client case. A one person service business gets four inquiries a week. The owner reads each one, checks the calendar, sends a booking link, and moves the email to a folder. Fifteen minutes each. Annoying, but fine.

They automate it exactly as it stands. The agent reads the inbox, sends the booking link, files the email. Inquiries climb to twenty a week and three problems arrive at once.

1. Repeat inquiries get a second booking link, because the manual process relied on the owner recognizing a name.
2. Out of scope requests get booked, because nobody ever wrote down what “a fit” means.
3. Filed emails never get read again, because the folder step existed to make the inbox look clean, not to do anything.

The build worked. The process did not. Run the CLEAR Check on that same intake and you delete the folder step, write a two line fit standard, add a duplicate check at the handoff, and automate five steps instead of nine. Same tool. Different outcome, because the thinking happened before the build instead of after the complaint.

Your action steps this week

1. Pick one process you have been meaning to automate. One. Not the whole business.
2. Write every step out by hand today. Count them. Note the number.
3. Mark the step where information changes hands. That is your likely failure point.
4. Cut every step that would break nothing if it vanished.
5. Write one sentence defining “done correctly” and one sentence defining when the process should stop and come to you.
6. Run the revised version manually one time this week with zero hand fixes. Only then open the automation tool.

There is a mindset piece under all of this, and it is worth naming. Holding a process in your head feels like control. It is the opposite. A process that only exists in your head cannot be handed to anyone, human or agent, which means you are the single point of failure. I had to let go of doing everything myself before any of my systems got useful, and writing the process down was the first move, not the last.

Frequently asked questions

What does automating a broken process mean?

It means building software around a workflow that still has errors, missing decisions, or undocumented steps in it. The automation faithfully reproduces every flaw, so the result is the same bad outcome arriving faster and more often than it did when a human ran it.

Should I fix my process before automating it?

Yes, in almost every case. Fixing the process first is cheaper than rebuilding an automation, because a process change costs you an hour of thinking while a rebuild costs you the original build plus the fix plus the errors that shipped in between.

The exception is small and specific: when you genuinely do not understand where a process breaks, a short observation build that only logs and reports, and takes no action, can show you. That is diagnosis, not automation.

How do I know if my process is actually broken?

Try to run it once exactly as written, with no improvising. If you had to make a judgment call that was not on the page, the process is incomplete, and incomplete is the form “broken” takes in a one person business.

Two other signals: you cannot state the step count without guessing, and you cannot explain the process to someone else in under five minutes.

Can an AI agent fix a bad process on its own?

No. An agent can suggest improvements when you ask it to review a written process, and that is worth doing. It cannot decide what your business considers correct, because that standard is yours and it has never been written down for the agent to read.

How long should I run a process manually before automating it?

Long enough to see the exceptions, which usually means a handful of real runs rather than a set number of weeks. A process you have run three times cleanly, including at least one awkward case, is ready to hand over.

To recap

Automating a broken process is not a tooling failure, it is a sequencing failure. The process comes first, the build comes second, and reversing that order is what turns a weekend project into a month of cleanup.

Run the CLEAR Check: Count the steps, Locate the failure, Eliminate the waste, Agree on the standard, Run it clean once. Then build. The tools are ready when you are, and the market data says the operators who lose are not the ones with the weaker stack, they are the ones who automated a mess.

Command starts with knowing what you are actually running. Write the process down this week, and you will know.

If this is the way you want to build, subscribe to the blog and follow @AllenDavis-AI. One system breakdown at a time, no hype.

References

Gartner. (2025, June 25). Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027 [Press release]. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

Microsoft. (2026). Microsoft Copilot Studio: Create AI agents. https://www.microsoft.com/en-us/microsoft-365-copilot/microsoft-copilot-studio/

Schaffhauser, D. (2025, August 26). MIT report: Most organizations see no business return on gen AI investments. Campus Technology. https://campustechnology.com/articles/2025/08/26/mit-report-most-organizations-see-no-business-return-on-gen-ai-investments.aspx

VERIFY BEFORE PUBLISHING

• MIT figure: the 5 percent and 95 percent numbers were confirmed through Campus Technology’s reporting on The GenAI Divide: State of AI in Business 2025, not by fetching the original PDF. Confirm the primary report before publishing, and confirm whether it is attributed to MIT Media Lab or the MIT NANDA initiative, since coverage differs on that point.
• Delete this entire VERIFY BEFORE PUBLISHING section before the post goes live.