How to choose an AI consultancy in 2026 — 7 questions to ask

TL;DR The 2026 AI consultancy market is full of recently-rebranded marketing agencies. Use these seven questions to separate teams that can actually ship production AI from teams that will deliver a slide deck and a Zapier flow. The questions probe technical depth, ownership terms, and post-launch reality.

Key takeaways

The seven questions to ask

Run these in your evaluation call. Strong consultancies answer concretely. Weak ones answer in marketing language.

1. Show me a system you shipped in the last 90 days

What's it doing in production right now? Who's the client (named or anonymised)? Which models? Which tools does it call? What was the engineering team size? If they can't show recent production work, they're not building AI — they're consulting about it.

2. Will I see a working prototype inside 2 weeks?

In 2026 there's no excuse for 4 weeks of discovery before any code is written. A competent consultancy will scope the smallest useful working agent and ship it in sprint 1 so you can react to something real instead of a Miro board.

3. Which models have you built on in the last quarter?

You want a multi-model answer — Claude Opus 5 for X, GPT-5.5 for Y, Gemini 3.1 Pro for Z. A consultancy that only mentions one model is either underexposed to the field or has a vendor relationship to defend. Single-model shops will pick the wrong tool for at least one of your workloads.

4. Is the architecture MCP-native?

If they don't know what MCP is, end the call. If they do but say 'we use our own integration layer instead', that's vendor lock-in dressed up as expertise. MCP-native architecture is the 2026 default; departures from it need a strong technical justification.

5. Who owns the source code, prompts and infrastructure?

The right answer: you do. Source code in your private repo, prompts as version-controlled files, infrastructure as code in your cloud account. If the consultancy answers 'it lives on our platform with a per-seat licence', walk away — you're buying a SaaS, not a custom build.

6. How do you handle hallucination and out-of-policy outputs?

Strong answer: retrieval-augmented generation with citations, structured output validation, automated evaluation suites, human approval gates on high-stakes actions, weekly regression testing. Weak answer: 'GPT-5.5 is much better now, it doesn't hallucinate much'.

7. What does post-launch look like?

You want a clear ML-ops offering: monitoring (Sentry, Langfuse), weekly evaluation runs, prompt and model updates, a maintenance retainer with a fixed price. If they go silent on this, they're a build-and-leave shop and your AI agent will rot inside 6 months.

Questions that separate builders from resellers

Most of the market resells a platform with a services wrapper. That is not disqualifying, but you should know which you are buying, because it determines what happens when the platform's roadmap and your needs diverge.

  • Who owns the source code, prompts and infrastructure at handover? If the answer is anything other than 'you do', you are renting.
  • What happens when a better model ships next quarter? A team that cannot answer this concretely has not built for it.
  • Can I see the evaluation set? Any serious build has one. Its absence means nobody can prove a change improved anything.
  • What is the rollback plan when the agent does something wrong? 'It will not' is the wrong answer.
  • Which parts are your platform and which are bespoke? Fine either way, but the answer should be immediate.
  • Who maintains this in six months, and what does that cost?

Warning signs

  • Accuracy quoted as a single percentage with no mention of what was measured or on what data
  • No discussion of failure modes — every real deployment has them and honest teams lead with them
  • Pricing that does not distinguish build from running cost
  • Reluctance to name which models they use, or claims of a proprietary model that turns out to be a prompt
  • Case studies with impressive percentages and no baseline
  • No mention of UK data handling when your data is UK-regulated

What a good engagement looks like from your side

The uncomfortable truth is that most failed AI projects fail on the client side, and the pattern is predictable: no named internal owner, a workflow that was never actually defined, and data nobody wanted to look at closely.

Before you brief anyone, write down the workflow as it exists today including the exceptions, name one person who owns the outcome, and be honest about the state of the data the agent will read. A consultancy can fix a lot, but it cannot supply organisational clarity you do not have.

Frequently asked

What's a fair price range for an AI consultancy in 2026?

First production project: £6,000–£28,000 fixed-scope for a working system in 4–10 weeks. Monthly retainer for ongoing operation: £400–£1,800. Anything materially higher needs to justify itself with strong technical track record. Anything materially lower is probably a Zapier shop with AI marketing.

Should I prefer a UK consultancy or a remote one?

Remote is fine if their delivery process is mature — async demos, recorded handovers, written architecture docs. UK-based matters mostly for data residency, GDPR alignment, and time-zone overlap during incidents. For most projects, expertise and process matter more than postcode.

How do I sanity-check technical claims in a sales call?

Bring a technical person to the second call. Ask them to walk through one architecture decision in depth — say, how they'd handle a tool call timeout in an agent loop. The depth and specificity of that answer is the truest signal of whether they can ship in your environment.

How do I tell a builder from a reseller?

Ask who owns the code, prompts and infrastructure at handover, and ask to see the evaluation set. Builders answer both immediately. Resellers hedge on ownership and often have no evaluation set, because the platform's behaviour is not theirs to measure.

What should I prepare before approaching a consultancy?

The workflow written down as it actually is, exceptions included; one named internal owner accountable for the outcome; and an honest assessment of the data the agent will read. Most failed projects fail on these three, not on the technology.