Skip to content Skip to footer

A FRAMEWORK FOR LEADERS: Don’t Pave the Cow Path. Build the Highway First.

Five questions every organization should answer before deploying AI agents

When I was doing my City Planning there was a phrase that I learned: don’t pave the cow path. It refers to what happened when early American cities modernized. Instead of stepping back to design logical, efficient street grids, engineers just poured asphalt over the wandering dirt paths that cattle had made over decades. Fast. Cheap. Immediately regrettable. Those meandering routes got baked into the city’s permanent infrastructure, and some cities are still paying for that decision today.

I think about that phrase a lot when I watch organizations deploy AI agents.

The technology is genuinely remarkable. Agentic AI systems can now execute complex, multi-step workflows autonomously, reading data, making decisions, taking action, and looping back to refine. The business case writes itself: less manual effort, faster turnaround, 24/7 availability, consistent execution. No wonder every leadership team is feeling the pressure to move.

But here’s the thing. An AI agent doesn’t care whether your process is well-designed or not. It will execute whatever you point it at, the broken approval chain, the data that doesn’t reconcile across multiple systems, the policy nobody has updated for many years. It will execute it faster than before, at a greater scale, and without the informal human judgment that was quietly compensating for the gaps.

That’s the cow path problem. And it’s playing out in boardrooms right now.

The organizations winning with AI agents aren’t the ones who moved fastest. They’re the ones who asked harder questions before they moved at all.

I have seen this during AI transformation initiatives with my clients. So I came up with a framework built around five hard questions that companies need to answer to be successful in building Agentic AI Systems. Think of them less as a checklist and more as a conversation you should be having with your teams, your IT function, your people leaders, and honestly, with yourself. Get these five things right before you deploy, and agents become a compounding advantage. Skip them, and you’ve just paved a very expensive cow path.

QUESTION ONE

Do you actually know how this process works?

Not the documented version. The real one.

Every organization maintains two versions of every process. The documented version lives in a portal somewhere, was last updated before a key migration, and describes a clean, linear sequence of steps that nobody actually follows in its entirety. Then there’s the real version, which involves a spreadsheet that a power user built few years ago, a message to the person in finance who knows how to fix the reconciliation error, and a judgment call that one individual makes every Thursday based on many years of experience he has never written down.

City planners call this the difference between the master plan and the desire lines. Desire lines are those unofficial footpaths worn into the grass by people taking the route that actually makes sense, cutting the corner the official path ignored, shortening the distance between two buildings that the planner never expected to be connected. They reveal how people genuinely move through a space, not how they were intended to.

Your processes have desire lines everywhere. And if you build an AI agent on the master plan without understanding them, you’ll get an agent that fails unpredictably, because it’s trying to navigate reality with a map that doesn’t match the terrain.

What to actually do

Before you build anything, spend time with the people doing the work. Not to interview them in a conference room, to sit with them and watch. The questions that matter:

  • Where do you deviate from the official process, and why?
  • What do you check that isn’t technically required, but would cause a problem if you skipped?
  • What would break in your first week if you left tomorrow?
  • Where does the data not add up, and how do you handle that?

The answers are your real process. That’s what your agent will be running. You should understand it completely before you decide whether to automate it, or redesign it first.

⚠️ The Trap

Organizations map the process they wish they had, then build the agent on that map. The agent performs perfectly in testing and fails unpredictably in production, because production runs on desire lines, not master plans.

QUESTION TWO

Is this process worth automating as-is?

Here’s a question that doesn’t get asked enough: what if the most valuable thing you can do is not automate the process, but redesign it?

In city planning, there’s a concept called induced demand. Build a new highway to relieve congestion and within a few years, traffic is worse than before, because the new capacity attracted more drivers. The infrastructure didn’t solve the problem; it scaled it.

The same dynamic shows up with process automation. A fourteen-step procurement workflow that requires four layers of approval didn’t arrive at fourteen steps and four approvals by accident. It got there through accretion, a step added after an incident, an approval layer added after a compliance scare, a data entry point added when two systems stopped talking to each other. Each addition made sense in isolation. Together, they created a process that is more about institutional scar tissue than genuine value.

Automate that process and you haven’t fixed it. You’ve induced demand, more transactions flowing through a fundamentally inefficient system, faster than before, with less opportunity for the humans who previously caught the errors.

The question isn’t ‘how do we automate this?’, it’s ‘what should this process be, and then how do we automate that?’

The redesign test

For every step in your process, ask one question: if we were designing this from scratch today, with modern tools, real-time data, and agents as the execution layer, would this step exist?

  • If yes, it belongs in the automated workflow.
  • If no, it’s legacy bloat. Cut it before you build on it.
  • If you’re not sure, that uncertainty is itself the answer, it means the step exists because of history, not because of logic. Make the decision explicitly.

This conversation is harder than it sounds. Cutting steps means confronting the reasons they were added, risks that were real at the time, political agreements that don’t show up in the process documentation, compliance requirements that may have changed. That’s exactly why it needs to happen before deployment, not after an agent starts executing the bloat at scale.

💡 The Highway Principle

You wouldn’t widen a road with a dangerous intersection before fixing the intersection. Redesign first, then automate. In that order.

QUESTION THREE

Is your data infrastructure ready for autonomous decisions?

Think of data as the city’s utility network, the pipes, cables, and fibre that everything above ground depends on. You can design the most elegant streetscape imaginable, but if the pipes beneath it are misaligned, the water pressure is inconsistent, and three different utility companies have competing maps of what’s down there, nothing above ground will work reliably.

That’s the data situation in most enterprises. And it is the single most common reason agentic deployments fail quietly, not with a dramatic error, but with a slow accumulation of decisions made on the basis of information that didn’t quite add up.

AI agents don’t have the informal human ability to sense that something feels off. An experienced employee looking at two conflicting data points will hesitate, cross-check, maybe make a phone call. An agent, unless explicitly designed to do otherwise, will pick a source and proceed. At scale, that confidence becomes a liability.

⚠️ The Confident Wrong Answer

When agents encounter missing or conflicting data, they often interpolate, filling the gap with inference rather than admitting uncertainty. This is how organizations end up with 10,000 correctly executed decisions based on a flawed premise. Design explicit escalation paths for data uncertainty. It’s not a limitation to hide; it’s a control to build.

QUESTION FOUR

Who’s accountable when the agent gets it wrong?

Every city has a building that wasn’t supposed to look like that. A road that floods every heavy rain because the drainage was miscalculated. A park that nobody uses because it was designed without talking to the neighborhood. At some point, someone approved each of these things, and the question of who owns the problem tends to get complicated fast.

Agentic AI creates the same accountability challenge, but at a different speed. When a human employee makes a bad decision, there’s usually a trail: an email, an approval, a conversation someone remembers. When an agent executes 10,000 decisions autonomously over a week, the trail exists but the ownership is murky. The vendor points to the configuration. IT points to the process owner. The process owner points to the data quality. The customer has already had the experience.

Here’s the honest question: right now, today, if your deployed agent made a systematically wrong decision for two weeks before anyone noticed, who would catch it, how, and what would they do?

If the answer is uncertain, you don’t have a deployment problem. You have a governance design problem that a deployment will make very visible, very quickly.

Map your accountability before you deploy

This isn’t about building a blame matrix. It’s about designing a city with functioning emergency services before the residents move in. Accountability architecture is what allows you to scale an agentic system with genuine confidence, because when something goes wrong, the response is fast, clear, and doesn’t require an incident review to determine who owns the problem.

QUESTION FIVE

Are your people ready to live alongside agents, and to push back when needed?

Here’s something city planners figured out the hard way: you can design the most brilliant urban environment in the world, but if the community it’s meant to serve doesn’t understand it, doesn’t trust it, or finds ways to work around it, the design has failed. The Pruitt-Igoe housing complex in St. Louis was architecturally celebrated and operationally catastrophic, in large part because it was built for an imagined community rather than the actual one.

Agentic AI deployments fail in a very similar way. The technical architecture can be exemplary. The process can be clean, the data trustworthy, the accountability clear. And still, if the people working alongside the agent don’t understand what it’s doing, don’t trust its outputs, or feel like it was imposed on them rather than designed with them, it won’t work. Two failure modes appear almost every time. The first is resistance: employees who quietly route around the agent, maintaining parallel processes, treating its outputs as advisory at best. You end up with two systems running simultaneously, which costs more than the original. The second is over-trust: employees who treat agent outputs as authoritative without applying the critical scrutiny that genuine oversight requires. The agent makes a mistake. Nobody catches it. It compounds.

Both are predictable. Neither is inevitable with the right preparation.

Building a community around the system

  • Involve affected teams in the redesign before deployment, not after.
  • People who help shape the system are far more likely to trust it, and far more likely to catch the edge cases a purely technical design would miss.
  • Be specific about what changes and what doesn’t. Vague communication about AI deployment creates fear. Specific communication about roles, oversight responsibilities, and escalation paths creates clarity.
  • Train for skepticism, not just operation. The most valuable skill in a world of AI agents is knowing when to question the output. That’s not a natural tendency, it needs to be actively cultivated.
  • Design oversight that is genuinely meaningful. A human who is nominally ‘in the loop’ but lacks time, context, or authority to intervene is not oversight. It is liability dressed as governance.
  • Watch for automation bias, the tendency to accept what the machine says because overriding it feels like extra work. This is cultural, which means it requires cultural management.
💡 A Useful Six-Week Check

Survey the people working alongside the agent. Are they using its outputs as a starting point for their own judgment, or as a replacement for it? The difference tells you whether your oversight design is working or decorative.

 

THE FRAMEWORK AT A GLANCE

Your Pre-Deployment Readiness Map

Think of this as a site survey before construction begins. No engineer breaks ground on a building without understanding the soil conditions, the utility lines, the flood risk. These five dimensions are the equivalent site conditions for an agentic AI deployment. All five need to be solid. A strong score on four out of five is not a green light, it’s a map of where the work still is.

A note on sequencing: this matrix isn’t an argument for waiting indefinitely. It’s an argument for knowing where you are. An organization that is ready on four dimensions and not the fifth knows exactly what to fix and where to focus. That’s a far better position than one that deployed without asking these questions and is now discovering the gaps in production.

ONCE YOU’RE READY

Building the Highway: A Four-Stage Approach

Cities aren’t built all at once. You start with the infrastructure that makes everything else possible, the water mains, the power grid, the arterial roads. Then you layer in the secondary streets, the buildings, the public spaces. Each stage depends on the one before it being sound.

Agentic AI scales the same way. The organizations that try to jump straight to a fully autonomous, multi-agent ecosystem before they’ve proven out a single reliable deployment are the ones who end up demolishing and starting over eighteen months later. The ones who move through stages, deliberately, with clear measures of success at each, are the ones whose capability genuinely compounds.

Most organizations attempting to begin at stage three are the ones that end up reversing course. The discipline of moving through the stages is not timidity. It’s how resilient infrastructure gets built.

A FINAL THOUGHT

The Highway Doesn’t Build Itself

The cities we admire most, the ones that function well, that feel liveable, that hold up under pressure, weren’t the ones that grew fastest. They were the ones that invested in the infrastructure nobody sees: the drainage systems, the utility grids, the zoning frameworks that took years to establish. The visible city is only as good as the invisible foundations beneath it.

Agentic AI is no different. The visible transformation, the autonomous workflows, the faster decisions, the compounding efficiency gains, is only as good as the foundations you build before the first agent goes live. The process clarity. The data infrastructure. The accountability design. The human readiness. These are the invisible foundations. And like a city’s utilities, they’re far cheaper to build correctly the first time than to fix after the streets are already paved.

So yes, build the highway. Absolutely build it. The destination is worth it.

Just don’t mistake speed of deployment for progress. The organizations winning with agentic AI in three years will mostly be the ones who asked the harder questions now, did the unglamorous work first, and built something solid enough to actually carry the load.

Don’t pave the cow path. Don’t rush the foundation. Build something worth building, and then build it to last.