An AI adoption framework for 2026: what to expect from a tech partner

TLDR: Most AI adoption frameworks tell you how to run a pilot. The real question in 2026 is what to buy, because people can now generate a working prototype of almost anything in Claude or ChatGPT and still not get it into production. What you should be paying for is not a tool, a model or a stack. It's a partner who can build something specific for your business. Consultancy used to mean bespoke work you stayed dependent on, and SaaS used to mean self-serve software that was the same for all users. In 2026 you should expect to get both at the same time.

Something changed in the past year when talking to potential new clients. They've almost always already tried implementing AI. Somebody in the business has opened up Claude or ChatGPT and asked it to "build me a tool that scrapes Companies House," or "write me a lead scoring model for my pipeline," or "give me a dashboard that reconciles my invoices against my payment providers." And it kind of works. They’ll get back something that runs the first couple of times, but then it will stop working out of nowhere.

This is the actual main AI adoption problem people are facing in 2026. Most adoption frameworks you’ll read about don’t cover it, because they are about getting these pilot schemes up and running, rather than ensuring you’re paying for something that will still work in a few weeks.

SaaS vs consultants, and why its and outdated choice

Historically you had two options: one, you could hire a consultancy. You'd get a bespoke product, built for your business, exactly what you asked for. And then they'd leave, and you'd have a tool you couldn’t change, running on logic you didn’t own, and you'd call them (and pay them) again next year to update it.

Two, you buy some software (SaaS). You'd get software you could run yourself, that had a roadmap and support. And it would be the same software everybody else in your industry bought, so the moment your business had a specific requirement, you were out of luck (unless in some cases you were willing to pay for an ultra-expensive enterprise tier).

What I think you should expect in 2026 is both. Bespoke, and self-serve. Built for your business specifically, and still something your own team can operate without paying a consultant.

What are people looking for in 2026?

The requests we’re getting are much more varied than "we need a reporting dashboard." Some examples include:

A single customer view, so you have all of your customer touchpoint data in one place, one unified list of customers across all sources, and you have a full view of that. Or a single sales source of truth, same thing. Imagine you have five subsidiaries, bringing all that data in together, converting it to the right exchange rate, being able to report on your whole business as a whole.

Subscription reporting, which sounds trivial and is not. Finding out exactly how many active subscribers you have at once, which is surprisingly difficult.

Financial reconciliation, that's quite a big one. So imagine you've got invoices going out every month and payment providers, and there's someone currently manually checking between those two sources to make sure all your payments reconcile. We can automate that and just give you the five that need human attention.

Scraping tools, so if you want publicly available data, like ONS or Companies House or any other database that's available as a website, we can scrape that data for you and bring it into the warehouse.

Lead scoring. Imagine you've got a B2B company, you've got 500 leads in your pipeline. You only have three salespeople. How do you prioritize which ones to go after? So we can score those leads and tell you the ones to go after every day. Same thing can happen for a customer success team. Like you have 200 customers to call every day. Obviously you're not gonna do that. We can prioritize the top 20.

And then mobile apps, which is the one people are most surprised by. So for customers who have an on-the-ground sales team, imagine you're a retailer with physical stores. What tends to happen is the people in the stores don't know who the customer walking into the shop is. So we can build an app that will surface that customer-level data to the salesperson.

So imagine you come into the shop and you say your name. I can look you up on the system and then I can see what you've browsed online, when you last checked out, what emails you've clicked on, what you've purchased from me before, what meta ad you've clicked on, if you've ever contacted our customer success. Anything like that. They'll have all of that knowledge and history behind the app, which means they can then be more informed to make a final sale.

Now, none of those are things you would find on a pricing page. That's the whole point. They're specific to a business, and five years ago each one would have been a six-month project with a systems integrator. What AI has changed is that the build is no longer the expensive part.

Why just a tool doesn’t cut it anymore

Here's the thing about asking an AI to build you a scraping tool. It will do it. What it will not do is know where that data should land, how it joins to the rest of your business, what your definitions are, or who maintains it in March when the source website changes its HTML.

Take net revenue. Say as a business you calculate net revenue as gross revenue minus taxes, minus shipping, minus refunds. If you just asked ChatGPT what's my net revenue, you'd have to explain that to it, every time, and hope whoever asks next explains it the same way.

Whereas if you've connected it into Kleene through MCP, it can read all of your transformation layer. So it can actually read the SQL, read the definitions, read how you calculate metrics. It understands the metadata, and it will just give you what the actual definition is. So because it has all the logic, it just means it's going to be way more accurate.

That's the difference between AI with access to your data and AI with access to your data plus your business logic. The first one gives you plausible numbers. The second one gives you your numbers.

And you only get the second one if somebody has built the transformation layer underneath it, which is unglamorous work that no chat window is going to do for you.

The framework: five things to expect from a partner

1. They start with your problem

A good partner should ask what the problem is, not which models you want to buy. For us, deployment partner essentially means: you give us your problem and we'll find the solution, regardless of what that solution is. Sometimes a solution will be something simple, like an ELT solution. Sometimes it will be something more complex, like a model.

If the first conversation is a feature list, you are buying a product and hoping it fits.

2. They build bespoke, but you can run it yourself

This is where we combine both options from earlier. Our models have a bit of a template, but all of them are fully custom-made to be bespoke to that customer. So if they have a specific input signal, say the currency exchange rate really impacts their sales, we can put that value into the model, which a standard out-of-the-box solution wouldn't be able to do.

And because it's linked into the whole app, you can deploy it when you want, you can refresh it when you want. Bespoke does not have to mean dependent.

3. It refreshes on a schedule you control

What we find is a lot of agencies especially, they have MMM partners, but they just do a one-off MMM model. They have a report that's 30 pages that gets sent to the customer, and then they never see it again, or they have to run it again in a year's time.

4. The AI can read your whole stack, not just your data

We’ve touched on this above, but it's the one most people have not thought to ask about yet. Plenty of tools will pipe your data into an AI. Far fewer will give the AI your transformation layer, which is where your definitions actually live.

5. They are still there after go-live

We're consulting-led, so all of our models come with a kind of steer co, a series of meetings after the deployment. So once the model's live, we won't just leave you alone with it. We'll walk you through it, we'll tell you how to experiment with it, how to change things, how to move money around, and we'll have a very consultative, heavy-touch approach to helping you identify and understand what the model is saying.

What this looks like when it's working

The clearest version I can give is a company we work with very often. They could have done the reporting side on their own, the full ELT, but we've now become so engrossed in their whole data pipeline. So we pull data from their CRM and we upload it into their ERP, and then we pull data from the ERP and write it back into the CRM. So we have become the middle tool to all of their different software solutions.

Sticky, sticky. And that's something they wouldn't be able to do on their own, because it's more complex a build.

Which capabilities to build, in what order

It usually depends on what the business is. I'd say pretty much every company needs marketing, which is why those are so popular.

Demand forecasting is actually another one. I'd say demand forecasting would work for absolutely anyone. And it's really powerful because it allows you to then manage your stock, manage your workforce, or whatever your kind of supply need is.

Then inventory management is the next logical step after that, because then you understand your demand, and inventory management helps you identify your supply. And again, if those two models are orchestrated together and talking to each other, that's where it becomes really powerful.

On that last point, the orchestration bit is worth understanding because it changes what a set of models is worth. Take marketing. You've got MMM, which is your top-of-funnel marketing, so for impression-based, reach-based analytics that don't have any clicks attached to them. Then you've got your digital attribution, which is the bottom of the funnel, and that's very click and conversion-based. Those two models alone will only give you a picture of the top of the marketing funnel or the bottom of the marketing funnel. But as soon as you put the orchestration layer in, the two models speak to each other and they inform each other, which means you get the full-funnel marketing picture. So you'll understand how to move your spend between top of funnel and bottom of funnel as well, rather than in silos.

Ian has written about how the orchestration layer works across the wider set of models if you want the version that goes past marketing.

How we've structured this, for what it's worth

We've tried to productize our offering to make it easier to understand and give you certain examples. We've split it into four categories.

One is SaaS consulting, so that's essentially anything that requires SQL and data engineering within the Kleene app. Then data science consulting, which is completely bespoke data science builds. Any data science need you have, we have a team on hand that we can deploy. Then KAI analytics, which are the more common solutions for data science. Again, they're still bespokely made, but they come with a template and are more easy to deploy. And then, of course, we've got our Kleene SaaS on top.

You can take as many as you want. In an ideal world you buy them all. And a lot of them will have overlapping things. There's single source of truth of customers, and sales, there is a little bit of overlap there. But also, if you buy two or three of them from us, that means we can do economies of scale and reduce the price wherever the work doesn't need to be duplicated.

The bit I find interesting

Most of our clients focus consulting on things they couldn't have done themselves. It's either because of resource constraint on their side, or they don't have the skills in house that they need to build those models.

What's changed is how much now falls into "could be built." An app that tells a shop assistant who just walked in used to be a serious engineering programme. Reconciling two payment sources automatically used to be a person's job description. Scoring 500 leads every morning used to be someone's spreadsheet.

None of those are hard any more, if the data underneath is in order and somebody owns the deployment. That's the whole reason the partner question matters more than the tool question. The constraint moved. It used to be whether the thing could be built. Now it's whether anyone will run it.

FAQ

What is an AI adoption framework?
A structure for deciding how to bring AI into a business. Most versions focus on running pilots and measuring outcomes. The version in this article focuses on what to buy, because generating a prototype is no longer the difficult part, and getting one into production and keeping it running is.

Why do I need a deployment partner if AI can build the thing?
Because a prototype in a chat window is not a system. It has no connection to your live data, no schedule, no owner, and no knowledge of how your business defines its metrics. A deployment partner builds the thing and then runs it.

Can a bespoke build also be self-serve?
Yes, and that is what to look for. Bespoke used to mean dependent on whoever built it. If the build sits inside a platform you have access to, you can deploy and refresh it yourself while it stays specific to your business.

What should I ask a potential tech partner?
What happens on day 90. Whether the build is theirs to change or yours. Whether your AI can read your metric definitions or only your raw data. And what support exists after go-live rather than during implementation.

Which AI capability should we build first?
Marketing models for most businesses, because nearly everyone needs them. Demand forecasting works for almost any company, and inventory management is the logical next step once you understand demand.

If you want to talk about it

I'd rather talk about a problem than a product, so if you have something you have been trying to build and cannot get into production, that's a useful conversation.

Book time with us here and we'll tell you whether it's an ELT job, a model, a bespoke build, or whether you're closer than you think and don't need us for it.