Paving the Cow Paths: Why Automating Broken Processes Makes Things Worse
Created on 2026-02-06 09:36
Published on 2026-03-07 10:00
The process maturity dimension that organizations consistently underestimate
In the early days of American road construction, engineers faced a practical problem.
Where should roads go?
Surveying virgin territory was expensive and time-consuming. But there was a shortcut. Cattle had already worn paths across the landscape. These paths connected important points. They avoided obvious obstacles. They were already there.
So engineers paved the cow paths.
The result was roads that wandered inefficiently across the countryside. Roads that curved where no curve was needed. Roads that climbed hills that could have been avoided. Roads that encoded the wandering logic of cows into permanent infrastructure.
Those roads still exist today. Boston’s famously confusing street layout follows paths that cattle walked centuries ago. The inefficiency of cows became the inefficiency of cities, preserved in concrete.
I see this pattern constantly in AI transformation.
Organizations take their existing processes, broken as they are, and layer AI on top. They pave the cow paths. They encode dysfunction into AI systems that will run for years.
If you automate a mess, you get a faster mess.
This article is about process maturity: the dimension of AI readiness that determines whether AI amplifies your effectiveness or amplifies your dysfunction.
The Process Maturity Problem
Process maturity is weighted at 15% in my AI Readiness framework. This weight understates its impact.
Process problems do not just cause process failures. They cause failures that look like technology failures, data failures, or adoption failures.
The AI that “does not work” is often AI deployed on broken processes.
The integration that “is too complex” is often integration with processes that were never designed.
The adoption that “is not happening” is often people resisting processes that make no sense.
When I investigate AI initiatives that failed, process problems appear repeatedly. But they appear in disguise, attributed to other causes.
The invisibility problem:
Processes are invisible until you look for them.
People do their work. They follow patterns. They know what to do next. The work gets done.
But ask how the process works, and confusion emerges. Different people describe different steps. Edge cases are handled inconsistently. Nobody can explain why certain things are done certain ways.
The process exists as collective habit, not as explicit design.
This invisibility means process problems are rarely surfaced before AI deployment. Everyone assumes the process is fine because the work gets done. They discover the process is broken when AI exposes the inconsistencies that human judgment was masking.
The human compensation problem:
Humans are remarkably good at compensating for broken processes.
The step that makes no sense? The experienced worker skips it when appropriate.
The information that is missing? The skilled employee knows where to find it.
The exception that the process does not handle? Someone figures it out.
Human judgment fills the gaps in process design. Work gets done despite process dysfunction because people compensate.
AI cannot compensate. AI follows the process literally. Where humans improvise around dysfunction, AI executes dysfunction.
The broken process that worked with humans fails with AI because the human compensation is gone.
Designed Versus Accidental Processes
Not all processes are created equal. The distinction between designed and accidental processes determines AI readiness.
Designed processes:
A designed process was intentionally created.
Someone analyzed what needed to happen. They determined the best sequence of steps. They specified who does what. They documented the approach. They trained people to follow it.
Designed processes have characteristics:
They are documented. You can find the process description. It matches what people actually do.
They have rationale. Someone can explain why each step exists. The reasoning may be outdated, but it exists.
They are consistent. Different people doing the process do it the same way. Variations are minimal.
They have owners. Someone is responsible for the process. They monitor it. They improve it.
Accidental processes:
An accidental process evolved rather than was designed.
Someone started doing something. Others copied them. Variations emerged. Workarounds accumulated. Over time, a process existed that nobody designed.
Accidental processes have different characteristics:
They are undocumented. There is no process description. Or the description is outdated. Or different descriptions contradict each other.
They have no rationale. Nobody can explain why things are done this way. “We have always done it this way” is the only answer.
They are inconsistent. Different people do it differently. The same person does it differently on different days. Variation is the norm.
They have no owners. Nobody is responsible. Problems are noticed but not addressed. Improvement does not happen.
The distribution:
In most organizations, the majority of processes are accidental.
Core processes, the ones that are audited, regulated, or customer-facing, may be designed. Everything else probably evolved.
The processes that organizations think about when discussing AI are usually the designed ones. The processes that AI actually touches often include accidental ones.
AI deployed on designed processes has a chance. AI deployed on accidental processes will fail.
How to Identify Accidental Processes
Before deploying AI, you must identify which processes are accidental. This is harder than it sounds.
The documentation test:
Ask for the process documentation.
If it exists, ask when it was last updated. If the answer is years ago, the documentation probably does not match reality.
If it exists and is recent, ask three different people who do the process whether the documentation is accurate. If they disagree, the documentation is aspirational, not actual.
If documentation does not exist, the process is almost certainly accidental.
The variation test:
Observe multiple instances of the process.
Watch different people doing the same process. Watch the same person doing the process on different occasions.
Note variations. Do they follow the same steps? In the same order? With the same inputs? Producing the same outputs?
Significant variation indicates accidental process. Designed processes produce consistency.
The rationale test:
Ask why each step exists.
For designed processes, someone can explain the reasoning. “We check this field because errors here caused problems with billing.” “We get this approval because of the regulatory requirement.”
For accidental processes, rationale is absent. “I do not know why. It is just what we do.” “That is how I was trained.”
Steps without rationale are symptoms of accidental evolution.
The exception test:
Ask what happens with exceptions.
Designed processes have exception handling. “If this condition exists, do this instead.” The exceptions are anticipated and addressed.
Accidental processes improvise with exceptions. “We figure it out when it happens.” Different people handle exceptions differently.
Improvised exception handling indicates accidental process design.
The ownership test:
Ask who owns the process.
For designed processes, ownership is clear. Someone is responsible. They monitor performance. They make improvements.
For accidental processes, ownership is diffuse or absent. “Everyone is responsible.” Or “IT handles the system.” Or silence.
Absent ownership indicates accidental process.
The Automation Decision
Having identified accidental processes, you face a decision.
Do you automate the process as it is? Or do you redesign before automating?
When to automate as-is:
Automation without redesign makes sense when:
The process is stable. It has worked this way for years. There are no significant complaints or problems.
The process is peripheral. It is not core to value creation. Improvement would yield limited benefit.
Redesign resources are unavailable. You lack capacity for meaningful redesign.
Time pressure is extreme. Business need requires immediate automation.
In these situations, paving the cow path may be acceptable. You accept embedded inefficiency in exchange for speed.
But do this with awareness. Document that you are automating a suboptimal process. Note the inefficiencies for future remediation. Do not pretend the process is good just because you chose to automate it.
When to redesign before automating:
Redesign before automation makes sense when:
The process is core. It directly affects customers, revenue, or key operations. Inefficiency here matters.
The process is problematic. There are known issues. Workarounds are common. People complain.
AI will amplify the dysfunction. The speed of AI will make process problems worse, not just faster.
Redesign resources are available. You have people who can rethink the process, not just encode it.
In these situations, redesign first. Create a designed process. Then automate that.
This takes longer. It requires more investment. But it produces AI that amplifies good process rather than bad process.
The hybrid approach:
Sometimes full redesign is impractical but full automation is unwise.
In these cases, focus redesign on critical elements.
Which parts of the process most affect outcomes? Redesign those.
Where is variation most problematic? Standardize there.
What exceptions need handling? Design for those explicitly.
The hybrid approach targets redesign where it matters most, then automates the improved but imperfect process.
What AI-Ready Processes Look Like
Let me describe what processes need to look like for AI to succeed.
Clear inputs and outputs:
AI-ready processes have defined inputs and outputs.
What information enters the process? In what format? From what source?
What result does the process produce? In what form? To what destination?
Ambiguity about inputs and outputs creates AI failures. The AI does not know what to expect or what to produce.
Explicit decision points:
AI-ready processes have explicit decision points.
Where do choices occur? What criteria determine the choice? Who has authority to decide?
Implicit decisions, choices made without awareness that a choice is happening, cause AI problems. The AI does not know a decision was needed.
Defined handoffs:
AI-ready processes have defined handoffs between steps.
When does one step end and another begin? What triggers the handoff? What information passes between steps?
Undefined handoffs mean AI does not know when to act, when to stop, or what context to carry forward.
Exception handling:
AI-ready processes have designed exception handling.
What happens when standard conditions do not apply? How are exceptions recognized? Who handles them? What is the resolution path?
AI that encounters exceptions it was not designed for fails ungracefully. Designed exception handling prevents this.
Feedback loops:
AI-ready processes have feedback loops.
How do you know if the process worked? How do errors get identified? How does improvement occur?
AI deployed without feedback loops does not improve. Errors persist because nobody catches them.
The Handoff Problem
Processes that involve AI create handoffs between human and machine. These handoffs are where most process failures occur.
Human to AI handoffs:
When does human work end and AI work begin?
What triggers the handoff? Does the human explicitly invoke AI? Does AI activate automatically based on conditions?
What information passes to AI? Does AI have what it needs? Is context preserved?
How does the human know the handoff occurred? Are expectations set about what AI will do?
Unclear human-to-AI handoffs produce confusion. People do not know when AI is engaged. AI does not have what it needs. Expectations are wrong.
AI to human handoffs:
When does AI work end and human work begin?
What triggers the handoff? Does AI complete and return to human? Does AI encounter limits and escalate?
What information passes to human? Does human have context about what AI did? Are AI uncertainties communicated?
How does the human know to act? Is the handoff visible? Is the call to action clear?
Unclear AI-to-human handoffs produce dropped work. AI completes but humans do not know to act. AI escalates but humans do not know why.
Designing handoffs:
Handoff design should be explicit.
Document the trigger: What causes the handoff?
Document the information: What passes from one to the other?
Document the signal: How does the recipient know to act?
Document the expectation: What should happen next?
Handoff design is often omitted. Process design focuses on what happens within steps, not what happens between them. This creates exactly the gaps where AI deployment fails.
Common Process Failures in AI Deployment
Let me describe the failures I see repeatedly.
The “faster mess” failure:
Organization automates a broken process. The AI accelerates the dysfunction. Problems that occurred daily now occur hourly. Errors that affected dozens now affect thousands.
The AI is blamed. The process is the problem.
This failure is predictable but common. The pressure to deploy AI quickly leads to paving cow paths.
The “missing handoff” failure:
AI does its part. The work sits waiting for human action. Humans do not know work is waiting. Or humans expect different work than AI produced.
Nothing technically failed. The handoff was never designed. Work disappears into the gap between AI and human.
This failure is invisible until it accumulates. Then suddenly there is a backlog nobody knew existed.
The “exception avalanche” failure:
AI handles standard cases. Exceptions go to humans. But more cases are exceptions than expected. Humans are overwhelmed with AI escalations.
The process assumed exceptions were rare. Reality is that exceptions are common. The AI handles the easy cases, leaving humans with only hard cases at high volume.
This failure produces burnout and bottlenecks. The AI appears to be generating work rather than reducing it.
The “context loss” failure:
AI processes a request. It passes to human for judgment. Human lacks the context AI had. Human makes poor judgment because information was not passed.
AI knew things it did not communicate. Human decided without knowing what AI knew.
This failure produces bad decisions that look like human error. They are actually handoff design errors.
The “invisible variation” failure:
Process was standardized for AI automation. But variation still exists. Different teams do it differently. AI was trained on one variation.
When AI encounters other variations, it fails. The teams doing it differently are confused why AI does not work for them.
This failure reveals that standardization was incomplete. The process looked consistent from headquarters. It was not consistent in practice.
Quick Wins for Process Improvement
Full process redesign takes time and resources. Here are quick wins that improve process maturity without major investment.
Quick win 1: Document actual state.
Document how processes actually work, not how they should work.
Observe real work. Interview real workers. Capture reality.
This documentation becomes the baseline for improvement. It reveals variation and dysfunction. It enables informed decisions about what to automate.
Documentation alone does not fix processes. But it makes process problems visible, which is the first step.
Quick win 2: Identify process owners.
Assign clear ownership for processes AI will touch.
One person, not a committee, is responsible for each process. They can explain how it works. They can approve changes. They are accountable for performance.
Ownership creates someone who cares about process quality. Without ownership, nobody addresses problems.
Quick win 3: Define handoffs explicitly.
For processes that will involve AI, design handoffs explicitly.
Document human-to-AI triggers. Document AI-to-human triggers. Document what information passes. Document how recipients know to act.
This can be done for specific AI deployments without redesigning entire processes.
Quick win 4: Map exception handling.
Identify what exceptions occur. Document how they are currently handled. Decide how AI should handle them.
Some exceptions: AI escalates to human.
Some exceptions: AI handles with specific logic.
Some exceptions: AI rejects and routes elsewhere.
Explicit exception handling prevents the exception avalanche.
Quick win 5: Create feedback mechanisms.
Establish how you will know if AI-enabled processes are working.
How are errors identified? How are they reported? How do improvements happen?
Feedback mechanisms enable learning and improvement. Without them, problems persist indefinitely.
Process Maturity Assessment
How do you assess process maturity for AI readiness?
Maturity Level 1: Chaotic
Processes are entirely accidental. No documentation. No consistency. No ownership.
AI deployment at this level will fail. Processes must mature before automation.
Maturity Level 2: Documented
Processes are documented but may not be followed consistently. Documentation may be outdated. Variation exists but is recognized.
AI deployment at this level is risky. Selected processes may be ready. Careful assessment is needed.
Maturity Level 3: Standardized
Processes are documented, consistent, and followed. Variation is minimal. Ownership exists.
AI deployment at this level is viable. Designed processes can be automated successfully.
Maturity Level 4: Optimized
Processes are designed, measured, and continuously improved. Handoffs are explicit. Exceptions are handled. Feedback loops function.
AI deployment at this level accelerates already-effective processes. Maximum value is achieved.
Assessment approach:
For each process AI will touch, assess maturity level.
Level 1 processes: Do not automate. Mature to at least Level 2 before considering AI.
Level 2 processes: Assess carefully. May be ready for automation. May need improvement first.
Level 3 processes: Ready for automation. Design handoffs explicitly.
Level 4 processes: Fully ready. AI will amplify effectiveness.
Most organizations have a mix. Knowing which processes are at which level guides deployment decisions.
The Redesign Investment
Sometimes process redesign is the right investment.
When redesign pays:
Redesign pays when the process is important enough and broken enough that improvement justifies investment.
Calculate the cost of process dysfunction. Errors. Delays. Workarounds. Rework.
Compare to the cost of redesign. Analysis. Design. Training. Transition.
For core processes, the calculation often favors redesign. The ongoing cost of dysfunction exceeds the one-time cost of improvement.
How to redesign for AI:
Redesign for AI is different from redesign for humans.
Design for consistency. AI needs predictable inputs and outputs. Eliminate variation that humans could handle but AI cannot.
Design for explicit decisions. Make choices visible. Define criteria. Create decision points that AI can execute or escalate.
Design handoffs first. The interfaces between human and AI are critical. Design them explicitly before designing what happens within steps.
Design exception handling. Anticipate what will go wrong. Create paths for exceptions. Decide what AI handles and what humans handle.
Design feedback loops. Build in measurement. Create mechanisms for error identification. Enable continuous improvement.
What redesign produces:
Good redesign produces processes that are better for humans and ready for AI.
Humans benefit from clearer processes, better documentation, explicit exception handling.
AI benefits from the consistency, clarity, and explicit design it requires.
Redesign for AI is often good process improvement regardless of AI.
If you automate a mess, you get a faster mess.
The cow paths of American roads still wind inefficiently through cities today. The dysfunction of cattle wandering became the dysfunction of infrastructure, encoded permanently.
AI deployment on accidental processes does the same thing. It encodes dysfunction into systems that will operate for years. It amplifies inefficiency rather than eliminating it.
The alternative is process maturity. Understanding which processes are designed and which are accidental. Improving processes before automating them. Designing handoffs explicitly. Handling exceptions deliberately.
This work is not as exciting as AI deployment. It does not generate the announcements and demos that executives enjoy.
But it is the work that determines whether AI deployment succeeds or fails.
What processes are you planning to automate? Are they designed or accidental?
The AI Readiness Scorecard includes process maturity assessment alongside the other five dimensions of the Human Layer. It takes ten minutes and shows exactly where your process gaps are.
Comment “SCORECARD” below and I will send you access.
Paving cow paths is fast. Building good roads is better. Know which you are doing before you start.