One hundred and five firms in this directory list AI strategy consulting as something they sell. One hundred and thirty three list integration work. Thirty-seven list both. The distance between the first number and the last is where most AI budgets go to die, because the firm that writes your roadmap is usually not the firm that can build what the roadmap describes, and the roadmap almost never says so.
AI strategy consulting is the most frequently sold advisory service in this market and the easiest one to sell badly. It has a clean scope, a short timeline, a senior-looking deliverable and no operational risk attached. A firm can complete the engagement, invoice it, collect a reference and leave, and nothing it produced has yet met a real user, a real permission boundary or a production dataset. Six months later the client has a document and the same processes it started with.
One Hundred and Five Firms, Thirty-Seven Overlaps
Read those directory counts as a market signal rather than a statistic. Strategy work and build work are listed as separate specialities because, for most firms, they are separate payrolls. A strategy practice employs people who are good in a room with a chief operating officer. A build practice employs people who have spent years with queues, identity providers, data migrations and the particular misery of a legacy system that reports success on failure.
Thirty-seven firms carry both labels and some of those carry the second one aspirationally. You can see how separately the two are listed by opening the AI strategy consulting category and the AI integration category and comparing which firms appear on each. The practical consequence for a buyer is simple and expensive: the quality of the advice tells you almost nothing about the capacity to deliver it, and the sales process is not designed to surface the difference.
The Deliverable Nobody Can Run
A strategy engagement usually ends in some combination of a current-state assessment, a prioritised list of use cases, a target architecture diagram, a business case per use case and a phased plan with quarters on it. Every item on that list is legitimate work. None of it is executable.
The failure is specific and it repeats. The roadmap names a use case, say automated triage of inbound claims, and scores it high on value and medium on effort. It does not say which of the four systems holding claims data has an interface, whether the field the model needs is populated in most records, who may approve a decision the model makes, or what the team does the day it is confidently wrong about a claim worth real money. Those four unknowns are the project, and the score was made without them.
So the client approves a plan built on estimates, the build team discovers the four unknowns in week three, the effort estimate doubles, and the phase that was going to prove the value gets deferred into a quarter that never arrives. Research published through MIT Sloan Management Review has found consistently that organisational and process factors, rather than model capability, separate the companies getting value from AI from the ones still piloting. A roadmap is a process artefact, and a roadmap that has not been tested against the systems it describes is the weakest kind.
Four Trades Called Strategy
The phrase covers at least four different transactions. They have different buyers, different price points and different reasons to be worth paying for. Sorting out which one you are actually buying is the first useful thing a buyer can do.
| What is being sold | What you hold at the end | When it is worth buying |
|---|---|---|
| Executive education, sold as strategy | A shared vocabulary and a leadership team that stops asking for the wrong things | When the board is making decisions on vendor marketing and nobody internally can referee |
| Portfolio triage | A ranked list of candidate use cases with the weak ones killed on the record | When eleven departments are each running a pilot and none can be compared to another |
| Technical feasibility, written as strategy | A verdict on whether your data and systems can support the thing you want, with the evidence attached | Before any build contract is signed. This is the one buyers skip and the one that saves money |
| Governance and risk framing | A policy you can show a regulator, an auditor or a customer, with named owners | When the sector is supervised, or when a customer contract has started asking |
The third row earns its fee most reliably and is bought least often, because it is the only one that can come back with the answer nobody wants. A verdict that the claims data is too sparse to support automated triage saves a year of build budget and reads like a failure in a status report. The same logic runs through every delivery category here, which is why what you are actually buying under the phrase custom AI belongs before the first invoice.
Where the Handover Goes Wrong
Assume the strategy work was good. The handover is still the most dangerous moment in the engagement, and it fails in three predictable ways.
The first is that nobody who has to meet the estimates ever owned them. A build partner has no obligation to the effort scores in a roadmap and will re-estimate from scratch, which is correct behaviour and also means the business case the board approved is gone. The second is that the firm interviewed the people who describe the process rather than the people who perform it, so the roadmap documents the process as written rather than as run, and the gap between those is where the exceptions live. The third is that nobody wrote down the evaluation criteria, so the build team has nothing to test against and invents its own target.
All three are avoidable, and all three are avoided the same way: by requiring the strategy engagement to produce something a build team can be held to. That is a scoping decision made before the statement of work is signed, not a conversation to have at the handover meeting.
Five Questions That Sort a Firm in One Meeting
Ask these in the first conversation and listen to the shape of the answer rather than its content. A firm that has done this work answers all five briefly and without rehearsal.
- Who writes the effort estimates, and have they built this? If the people scoring effort have never shipped the kind of system being scored, the scores are opinion. Ask to speak to the engineer who will do the feasibility work, not the partner who will present it.
- What will you look at, and what will you take our word for? A firm that will inspect the actual tables, run row counts and check field completeness is doing feasibility. A firm that will interview process owners and write down what they say is doing something else, which is sometimes what you want and is never a substitute.
- What does the deliverable contain that a build team could be held to? The answer should include a sample of real inputs with acceptable outputs, the integration points named system by system, and the permission model. If the answer is a roadmap and a business case, you are buying a document.
- What would make you recommend we do nothing? Every honest advisory practice has a version of this answer ready. A firm that cannot describe the conditions under which it would advise against the project is a firm whose recommendation carries no information.
- Who owns the output, and can we hand it to a different builder? Ask specifically about the assessment artefacts, the evaluation sample and the architecture work, in writing. A strategy firm that expects to win the build is not disqualified by that, but you should know it before the recommendation arrives.
Question four separates advisers from vendors faster than anything else on the list. Question one is the one buyers skip, and it is why the solo-versus-firm decision covered in our guide to consultants and consultancies matters more in strategy work than anywhere else: a single experienced practitioner who has shipped production systems will frequently produce a more executable assessment than a team of five who have not.
What Should Be in the Room When It Ends
A strategy engagement worth its invoice leaves five things behind. Write them into the statement of work as deliverables rather than hoping they arrive.
- An evaluation sample you own. One or two hundred real inputs from your business, paired with the output an informed person would accept. It is the only instrument that will later tell you whether a build is working, it takes the longest to produce because somebody with domain knowledge has to sit down and write the acceptable answers, and it is the asset most often left behind in a vendor's account.
- The integration inventory, system by system. Which systems hold the data, which of them have an interface, which fields are actually populated, and who administers each one. Named systems and named owners, not a box diagram.
- The permission model. Which identity system decides what a given user may retrieve, and whether that check happens before documents reach a model or after an answer has been produced. Only the first is defensible.
- The exception taxonomy. The list of cases the process handles by hand today, with rough frequencies. This is the single most useful page in any assessment and the one most often missing, because it comes from the people doing the work rather than the people describing it.
- The recommendation against. At least one use case examined and declined, with the reason. An assessment in which every candidate scored well was not an assessment.
The last three cost almost nothing while the firm is still on site and are nearly impossible to reconstruct afterwards. The NIST AI Risk Management Framework treats mapping context and measuring outcomes as core functions rather than optional additions, and that is the right instinct: a system you cannot measure is a system you cannot maintain, and the measurement has to be designed before the build.
Buying the Second Half First
The sequencing that works for most buyers inverts the usual order. Instead of commissioning a full strategy programme and then shopping for a builder, buy a short, paid feasibility engagement on your two strongest candidate use cases, with the five deliverables above as its scope and a fixed fee. Two to four weeks is usually enough. Then take what it produces to build partners and ask them to estimate against it.
Three things follow. The estimates are made against inspected systems rather than interview notes, so they survive week three. Every firm is quoting on the same specification, so their numbers mean something next to each other. And a negative verdict costs a few weeks instead of a few quarters, which is the cheapest good news available in this market.
Geography matters more for this stage than for the build. Exception interviews and data inspection want people in the building, which is why being in the same city has a different answer for assessment work than for delivery, and why regional demand concentrates on city pages like Atlanta and Denver. Expect a fair share of the surviving use cases to belong in process automation rather than anywhere near a language model, where the arithmetic in our ROI guide is the honest comparison.
Comparing AI Strategy Firms Against Your Own Brief
If you want to compare firms against your own requirements rather than reading sales pages, describe your project on the matching page and the directory will rank the closest listings by the services each firm names and where it works. You can also browse the full directory or start from what to buy across the AI service categories if the brief is not settled yet.
If you run a firm doing this work and your listing is missing, add your profile and name strategy and integration separately if you do both. Buyers filter on exactly those words, and the thirty-seven firms carrying both labels today are the ones getting found for the combination.
Questions Buyers Ask
What is AI strategy consulting?
It is advisory work that decides what a business should build with AI, in what order, and whether its data and systems can support it. The output is an assessment and a plan rather than a working system. The term covers four distinguishable trades: executive education, portfolio triage, technical feasibility, and governance and risk framing.
How long should an AI strategy engagement take?
A focused feasibility engagement on two candidate use cases is usually two to four weeks. Multi-month strategy programmes exist and are occasionally justified in large regulated organisations, but length is a poor proxy for value: what matters is whether the deliverable can be handed to a build team as a specification.
Should the firm that writes the strategy also do the build?
Sometimes, and you should know its intention before the recommendation arrives. Only thirty-seven of the one hundred and five firms listing strategy work in this directory also list integration, so a single firm covering both honestly is the minority case. Ask to speak to the engineer who ran a production deployment rather than the one who built a pilot.
What is the most common way AI strategy consulting wastes money?
Producing effort estimates that nobody who has to meet them has agreed to. The build partner re-estimates from scratch, the approved business case stops being true, and the phase meant to prove the value is deferred. Requiring an evaluation sample and a system-by-system integration inventory as deliverables is what prevents it.
Do we need an AI strategy before doing anything at all?
No. A small number of businesses with one obvious, well-understood process should go straight to a scoped build. Strategy work earns its fee when several candidate projects are competing for the same budget, when the data situation is genuinely unknown, or when a regulator or customer contract requires a documented position.
Sources
- The listing counts for the AI strategy consulting and AI integration categories, and the thirty-seven-firm overlap, were read from this directory's own database on 6 October 2026. The per-category totals can be checked against the category pages and the directory.
- NIST AI Risk Management Framework, on mapping context and measuring outcomes as core functions of governing a deployed AI system.
- MIT Sloan Management Review, on the organisational and process factors that separate companies getting value from AI from those still piloting.
- US Census Bureau Business Trends and Outlook Survey, which tracks reported AI use by American businesses by sector and firm size.
- Stanford HAI AI Index, for background on adoption and on the pace at which model capability and pricing change.
- OECD AI Policy Observatory, for the governance and policy context that shapes the risk-framing engagement.
Related reading on this site: what you actually own when a consulting engagement ends, the work an integration agency does after the demo, and the first-time buyer's checklist.