Why AI Transformation Needs Builders, Not Just Advisors

Research from Boston Consulting Group puts the number at around 4%: the share of companies that generate substantial value from their AI investments. The exact figure varies by study and by how "substantial value" gets defined, sometimes it's 4%, sometimes 10%, sometimes "fewer than a third." The order of magnitude stays consistent. (source)

Think about what that means in practice. Companies have bought in. They've hired consultants, approved budgets, built roadmaps, briefed boards. The investment is real. And in the majority of cases, it hasn't produced a working AI system, just a document describing one.

The usual explanations reach for the usual culprits: data quality problems, skill gaps, cultural resistance to change. Those are real. But they're typically symptoms of something earlier and more structural, something rooted in how AI transformation gets packaged and delivered as an engagement.

Most companies hire advisors to "do AI strategy." Advisors produce a roadmap. The roadmap requires execution capacity the company doesn't have. The advisors move to their next engagement. The roadmap sits. The AI transformation fails.

The fix isn't a better strategy document. It's hiring partners who build.

How AI Transformation Actually Fails

Here's the sequence that plays out more often than it should.

A company decides it needs an AI transformation. They hire a consulting firm or a fractional CTO to build an AI strategy. The firm delivers a roadmap: a maturity assessment, a set of prioritized use cases, a governance framework, recommendations on vendors and build-versus-buy decisions. The document is thorough. The board presentation looks good.

Then nothing happens.

The roadmap requires execution capacity the company doesn't have. Pilots stall because the internal team can't manage vendor relationships and validate outputs while also running normal operations. The recommendations are sound but generic. They weren't designed against the company's actual constraints, so implementing them means solving problems the document never described.

The consulting firm is on to the next engagement. The company is left with a strategy and no path to execution.

This is the delivery gap, not a technology gap. The advice and the work exist in two separate engagements, and nobody owns the translation between them. The advisory firm delivered what they were contracted to deliver. The company didn't get what they actually needed: a working system.

The companies that have been through this, the ones who come into new AI conversations already bracing for disappointment, aren't wrong to be skeptical. They learned something real. The question is what that learning points toward.

Why the Advisory Model Is Structurally Misaligned

The advisory model for AI transformation isn't broken by accident. It's broken by design.

Advisory firms are built to deliver a specific product: a recommendation, a roadmap, a framework. That's what they're set up to scope, staff, and bill for. The incentive is to produce a high-quality deliverable the client can point to as the output of the engagement.

Implementation is a different business. It requires different staffing (hands-on technical work rather than strategic analysis), different engagement structures (longer timelines, ongoing accountability), and different economics (outcome-based rather than deliverable-based). Advisory firms generally don't do implementation, not because they can't, but because the economics don't fit their model.

Here's how this plays out:

Vague recommendations that can't be actioned. "Develop an AI governance framework" sounds reasonable in a strategy document. In practice, it requires months of legal review, cross-functional alignment, and operational design work that the advisory engagement never scoped for.

Playbook outputs that assume execution capacity the company doesn't have. A maturity assessment with a recommended priority sequence is useful. Implementing it requires technical talent the company is already short on. The advisory firm knows this, they often say so in the recommendations. They still deliver the document.

Hand-off to implementation vendors who weren't part of the strategy design. When the company tries to execute, they hire a separate implementation team. That team wasn't in the room when the strategy was written. Requirements get lost in translation. The advisory firm's assumptions about the technical environment turn out to be wrong. Pilots fail. Blame gets distributed.

This isn't a moral failing of advisors. It's a structural feature of the model. The fix isn't to find a better advisory firm. It's to hire partners who build.

What the Builder Model Actually Looks Like

The alternative to advisory-only AI transformation isn't "no strategy." It's strategy plus delivery, with accountability for the outcome.

A builder partner operates differently across four dimensions:

Scoped to delivery, not recommendations. Success is defined by working systems, not by documents produced. The engagement is structured around shipping something that runs in your actual operations, not around producing a roadmap that describes something that might run eventually.

Embedded in operations. Builder partners work with your actual team, not above it. They're in the implementation decisions: which tool to use, how to handle the edge case, what to do when the vendor's API behaves unexpectedly. The strategy was designed with these constraints in mind because the same people who designed it have to make it work.

Hands-on with technology. They can build the workflow, not just describe what should be built. This matters because the gap between "what should we automate" and "what can actually be automated given our stack and constraints" is exactly where most AI projects stall. A builder closes that gap directly.

Responsible for outcomes. They stay until the system works, not until the contract ends. If the AI workflow doesn't actually reduce manual work in your environment, the engagement isn't done.

The builder model doesn't transfer all technical decisions to the external partner. It means the external partner has skin in the game on delivery, not just on the quality of the advice. That's a meaningful structural difference, and it produces meaningfully different results.

How to Tell If You're About to Hire an Advisor Instead of a Builder

Before you sign an AI transformation engagement, ask these five questions explicitly.

Does the scope conversation start with "what should we do?" or "what should we build?" The first is advisory. The second is builder-oriented. If the firm is asking about goals and problems, that's directional. If they're immediately asking what output you want, which system, which workflow, which operational change, that's builder territory.

Does the engagement end with a document or a working system? Ask directly: "What does success look like at the end of this engagement?" If the answer is a roadmap, a framework, or a set of recommendations, you're hiring an advisor. If it includes something running in your environment, even a validated pilot, you're in builder territory.

Is there a plan for integrating with your existing stack? Advisory engagements tend to describe a future state that assumes you can build or buy whatever the strategy requires. Builder engagements start with your existing environment, your CRM, your project management tools, your data layer, and design around constraints, not ideal states.

Does the firm have hands-on technical capability, or are they coordinating vendors? Ask specifically who will be doing the work. "We have technical resources" can mean anything from "our team includes engineers who have shipped AI workflows" to "we work with implementation partners." The first is builder. The second is advisory wrapped in technical language.

Is the success metric "delivered the roadmap" or "the AI system is running"? These sound similar but produce very different behaviors. If the incentive is to deliver a document, the firm will optimize for the document. If the incentive is a working system, they'll push through implementation, handle edge cases, and stay engaged until validation is complete.

Advisory engagements aren't always wrong. If you need pure strategic guidance, architecture decisions, governance frameworks, technical due diligence, they're the right tool. But if you're trying to transform how your operations run using AI, you need a builder, not an advisor.

What Praxica Does Differently

Praxica operates in the builder lane of AI transformation.

Strategy is part of every engagement. But strategy without delivery is what most companies have already tried, and it's the structural reason the 4% stat exists. Praxica is built around a different premise: the engagement doesn't end with a roadmap.

The accountability structure reflects that. If the system doesn't work in your actual operations, the engagement isn't done. The team that designs the AI workflow also builds it, validates it, and iterates until it produces the expected outcome in your environment. Not in a demo, not in a controlled test, in the context where it actually has to run.

The work falls in this lane: AI workflow automation for ops and lead generation, internal tool prototyping and deployment, AI-augmented reporting, process automation that connects your existing stack. Scope is built around what ships.

If you've been through an AI transformation that produced beautiful documents and no working systems, the builder model is the alternative worth evaluating. The questions in the previous section are a reasonable place to start before you sign anything.