Two pitches land in the same inbox, a week apart. Both mention AI. Both sound confident. Both use roughly the same words: strategy, transformation, opportunity. By the second call, it's genuinely hard to tell them apart  until it's time to actually build something, and only one of them is still in the room.

The spectrum nobody mentions upfront

"AI consultancy" and "MVP studio" aren't opposites, and treating them as a clean binary advice on one side, building on the other — misses how this actually works. There's a real spectrum: advice, feasibility analysis, implementation, ownership of what gets built, and ongoing support once it's live. Some AI consultancies genuinely do implement. Some studios stop the moment something ships. The label on the pitch tells you less than where, specifically, that company stops being involved.

Walking the spectrum

Advice is real, and it's not nothing

A good consultancy can save real time by ruling out bad approaches before money gets spent on them, this isn't a lesser service, it's a different one. The mismatch happens when a business needs advice and gets it, then discovers the same firm isn't equipped, or willing, to be the one building and standing behind the result. That's not a failure of the advice. It's a scope that was narrower than it sounded on the first call.

Walking the spectrum with a real example

Picture a company that wants to add an AI-assisted feature to an existing product. An advice-only engagement tells them whether it's technically feasible, roughly what it would take, and what the likely trade-offs are genuinely useful, and genuinely the end of that relationship once the report is delivered. A feasibility-plus-prototype engagement goes further: a working proof of concept, enough to test the idea against real data, but usually not built to production standards and not intended to be. An implementation-and-ownership engagement is different again the feature gets built properly, and the same team is still around, accountable, when it needs to be adjusted after real users start relying on it.

None of these is the "correct" engagement in the abstract. The mistake is assuming a pitch that mentions strategy and transformation implies the third one, when it might only ever have meant the first.

Where it actually matters

The honest differentiator isn't whether a company touches code. It's how far through that spectrum they stay accountable whether they're still answering the phone when something breaks in production three months after launch, or whether that call goes somewhere else entirely.

Most of the confusion clears up in a single follow-up question, asked plainly in that first or second call: what happens after this ships? An advisory-only firm will describe a handoff a report, a recommendation, a clean end point. A firm equipped to implement will describe what they'd be doing three months after launch, specifically, without needing to check with anyone else first. Neither answer is wrong. The problem is only ever assuming one answer when the actual answer is the other, and finding out which one it was after signing something.

What changes once the engagement actually starts

The difference between these two models shows up most clearly the first time something doesn't go as planned. With advisory-only, an unexpected technical obstacle becomes a new conversation who's going to solve this, and is that within scope of what was originally agreed. With implementation and ownership, the same obstacle is simply part of the work already being paid for, absorbed by the team already responsible for the outcome. Neither structure is inherently better. What matters is knowing, before it happens, which version of that conversation is coming.

One question cuts through most of the confusion: if this breaks after it's live, who fixes it, you, someone else you'll have to find, or the people you're talking to right now? Everything else is detail on top of that answer.

Why this distinction gets blurred on purpose sometimes

It's worth naming plainly: some of the confusion here isn't accidental. "Strategy" and "transformation" are comfortable words precisely because they can describe almost any level of commitment, and a pitch benefits from sounding as capable as possible without committing to specifics too early. That's not necessarily dishonest, it's just a reason to ask the plain question directly rather than inferring the answer from the vocabulary being used. A confident pitch and a capable one aren't always the same thing, and the gap between them only shows up once delivery actually has to happen.

ai consultancy