Vendor Evaluation · 4 min

Vendor Roulette: why switching AI vendors keeps you at square one

Third vendor, same starting line. Why each switch resets you to zero, what the previous engagement was supposed to leave behind, and how to make this one the last.

G

If you're evaluating your third AI vendor in two years, the problem is probably not that you keep picking badly. It's that each engagement ended without leaving anything behind, so every new vendor starts from the same blank page — and you pay for the same discovery, the same integration spelunking, the same context transfer, for the third time.

This is Vendor Roulette. It looks like bad luck and it's structural.

What each switch actually costs you

Not just the fees. The expensive part is the reset:

  • Context. Months of learning about your edge cases, your data's quirks, and why that one workflow has an exception — gone with the team that learned it.
  • Calendar. A new vendor needs 4–8 weeks before they're productive. Three vendors is half a year of ramp with nothing shipped.
  • Organisational patience. The most under-counted cost. After two visible failures, the internal appetite to try again collapses, and the third attempt gets less access, less budget, and more scepticism — which makes it likelier to fail too.

It compounds. 95% of enterprise generative-AI pilots deliver no measurable P&L impact (MIT Project NANDA, 2025), and every one of those is a company whose next attempt starts with less credibility than the last.

Why the last engagement left nothing behind

Something should have survived it. Usually four things didn't:

The evals. If nobody built a test set with known-good outcomes, the next vendor has no way to know whether they're better than the last one — and neither do you. This is the single most valuable artifact an engagement can leave, and it's almost never in the deliverables list.

The integration work. Authenticating into your helpdesk, mapping your data, handling the exceptions — that's weeks of work that should be reusable. If it lives inside a vendor's platform rather than your repo, it leaves when they do.

The decisions. Why this workflow and not that one. Why the human checkpoint is there. Which approach was tried and abandoned. Undocumented, the next vendor re-derives it — often re-making the same abandoned choice.

The owner. If the accountable person was on the vendor's side, accountability left with the invoice. This is the one that guarantees a repeat.

The pattern underneath

Vendor Roulette is usually a *scoping* failure wearing a vendor's face. If each engagement was scoped as a project with a delivery date rather than a capability with an owner, then finishing means handing over and leaving — and nothing about that arrangement is designed to leave you more capable than it found you.

That's also why the fix isn't "find a better vendor." It's changing what you're buying. The MIT study found buying from or partnering with specialised vendors succeeded about 67% of the time versus roughly a third that rate for internal builds — so partnering works. It's the *shape* of the partnership that determines whether you keep starting over.

How to make this one the last

  • Demand the artifacts by name. Evals, integration code, prompts, decision log, runbook — in your repo, in your accounts, from week one. Not at handover. Handover never happens on the timeline you imagined.
  • Name your owner, on your side. Someone whose job is affected by the metric, who will still be there when the vendor isn't.
  • Ask what the exit looks like before you sign. If leaving means rebuilding, you haven't bought a capability — you've rented one. The nine questions cover this in diligence detail.
  • Buy something that ends in production, not a phase that ends in a document. A deployed system is a thing that survives a relationship. A strategy deck is not.
  • Carry the last engagement's wreckage in. Whatever exists — a half-built pipeline, an abandoned prototype, notes from the failed pilot — is worth real weeks to the next team. A vendor who doesn't want to look at it is planning to bill you for rebuilding it.

This is most of the argument for the forward-deployed model: the engineers sit inside your operation, the work lands in your systems as it's built, and the Audit → Build → Operate sequence is designed so the operate phase has something real to operate. Where that differs from a traditional consultancy is laid out in our comparison — including the cases where a consultancy is genuinely the better call.

If you're mid-roulette right now, the most useful thing you can do before signing anything is inventory what your previous vendors left behind. Usually it's less than you assumed, and knowing exactly how much less is what makes the next scope honest.

Vendor Evaluation · FAQ

Questions this raises

Why do companies keep switching AI vendors?

Usually because each engagement ends without leaving anything reusable behind — no eval suite, no integration code in your own repo, no record of the decisions, and no accountable owner on your side. Every new vendor then starts from the same blank page, so the pattern repeats regardless of which vendor you pick.

What should an AI engagement leave behind?

Four things: an eval suite with known-good outcomes so the next team can tell whether they're better, the integration code and prompts in your own repository and accounts, a written record of which approaches were tried and why choices were made, and a named owner on your side who remains after the vendor leaves.

What does switching AI vendors actually cost?

More than the fees. You lose the accumulated context about your edge cases and data, you spend another 4–8 weeks of ramp before the new team is productive, and — most expensively — you spend organisational patience. After two visible failures the third attempt typically gets less access, less budget, and more scepticism.

Should I tell a new AI vendor about the failed previous attempt?

Yes, and show them everything that exists — the half-built pipeline, the abandoned prototype, the notes. It's worth real weeks to a competent team. A vendor who doesn't want to look at prior work is planning to bill you for rebuilding it.

Keep reading

Related insights

Vendor Evaluation

Nine questions to ask any AI agency before you sign

The questions that separate a firm that ships from one that demos — what each is really testing, and what a …

Vendor Evaluation

How to hand over an AI system — to a new vendor or in-house

The inventory to collect, the acceptance test that proves the handover worked, and the four things that alwa…

Vendor Evaluation

In-house, freelancer, or agency: who should build your AI agent

You've decided to build custom. The remaining question is who staffs it — and the honest answer depends on t…

Stop reading, start shipping

Put a forward-deployed team on it.

If this is the kind of work you're trying to get into production, a 30-minute discovery call is the fastest path to a scoped plan.