AI Adoption: Should You Wait for Better Models?

Should you wait for better AI models before you start your AI adoption? In most cases, no. Models will keep getting better and prices will keep falling, which is exactly why the model is the one part to rent loosely. What does not improve by waiting is the work only your company can do: defining the process, collecting real examples and naming an owner. Start that now, and buy the model later.

Should you wait for better AI models before you start?

I get this question in the first ten minutes of a surprising number of conversations, usually phrased as a sensible-sounding plan: "We will look at it again when it has matured." Dutch has a phrase for the posture, de kat uit de boom kijken: wait like a cat in a tree and see how things develop before you commit. It is a respectable instinct in a country with a long habit of not paying for other people's mistakes. I do not think it is a foolish instinct. I think it is aimed at the wrong target.

The argument for waiting is real, so let me state it fairly. Models do get better every few months. They do get cheaper. Early adopters do buy mistakes that later buyers avoid, and a system built around last year's model can feel dated before it has paid for itself. If AI adoption were a purchase, like buying a laptop, waiting for the next generation would be a defensible strategy.

It is not a purchase. AI adoption is mostly a change in how your company works, with a model plugged in at one point. The model is the part that improves while you wait. Almost everything else in the project is a thing your company has to do, and it does not get done by the calendar.

That distinction is the whole essay. If you want the short rule: wait on the model, do not wait on yourself.

What does waiting actually buy you?

Cheaper and better models, and I do not want to understate that. On 30 July 2026, Axios reported that OpenAI had cut the price of its GPT-5.6 Luna model by roughly 80 percent, to 20 cents per million input tokens and $1.20 per million output tokens, and its mid-range Terra model by 20 percent, to $2 and $12, about three weeks after launch. The top model, Sol, was not cut. Treat those numbers as a dated snapshot, not a current price list. By the time you read this they may already be out of date, which is rather the point.

Price falls like that are real, and they are useful for one specific kind of decision: where you are paying for volume. A system that reads ten thousand documents a day feels a price cut. A system that handles two hundred requests a week mostly does not, because at that size the model bill is a rounding error next to the hours people spend on the process around it.

So the first thing waiting buys is a smaller token bill, which in most projects I see is not the biggest line in the budget. The second thing it buys is a better model for the hard cases. That one is worth more, but it has a catch: you only know which cases are hard if you have already run the work on real examples. Without that, a better model is an improvement you cannot measure.

I would add a third thing that waiting buys, and it is less comfortable: the mistakes other people have already made. Waiting while a supplier or a sector peer works out which use cases fail is a legitimate use of time. But it only works if you are paying attention to what they learn, and "waiting" is usually code for not paying attention to anything at all.

What does waiting not buy?

Experience, first of all. When Statistics Netherlands (CBS) asked micro-firms that had considered AI and decided against it why, 71.6 percent named lack of experience, up from 56.5 percent in 2023. Cost came near the bottom. I wrote about those figures in why small businesses do not use AI, including the caveats on the 2025 numbers, which are provisional. The point here is narrower. Lack of experience is the one blocker that does not fall as models improve. It falls only when somebody in your company has run a real task through a real system and counted what went wrong.

Waiting also does not buy you a process definition. In most first conversations I have, nobody can say precisely how a request travels from the customer to the invoice, who handles the exceptions, and what "done" means. A better model does not fix that. It makes the vagueness faster.

It does not buy you examples. A useful AI project needs a few hundred real cases from your own work, each with the correct outcome next to it. Collecting them takes weeks, because the people who know the answer are busy doing the job. No model release shortens that.

And it does not buy you an owner. I have written before that an AI project needs an owner, not a sponsor. A named person with the right to decide does not appear when the technology matures. Someone has to be given the job.

Every one of those four things is a precondition, not a feature. The company that starts them this quarter and the company that waits a year will be using the same new model in twelve months. Only one of them will know what to point it at.

Which parts of an AI project lose value while you wait, and which gain?

I use a simple sorting exercise with clients. Take the project and put each piece in one of two columns: things that lose value as the technology moves, and things that gain value as you use them.

What loses value while you wait

The model choice is the obvious one. A model picked today will probably not be the best fit in a year, and I have argued elsewhere that your strategy should not chase the best model. Prompts written for one model's habits lose value too, as do clever orchestration layers built to compensate for last year's weaknesses. A long volume commitment at today's per-token price loses value, as the Axios example shows, because the price moved within weeks of a launch.

None of that means you should avoid these things. You still need a model to run a pilot. It means you should build them thin, document them, and keep them replaceable. The cost of changing a model should be an afternoon of testing, not a rewrite.

What gains value while you wait

The written-down process gains value, because the first time you describe it you find three versions of it. The set of real examples with correct answers gains value every time you add to it, and it is the single asset that lets you change supplier without starting over. The list of exceptions gains value too: I have said before that the exception list tells you more than the happy path. So does a named owner with a decision right, and so does a team that has seen the system get something wrong and learned to catch it.

Look at the second column again. None of it depends on which model you use, and all of it compounds with time spent, not with time elapsed. The cruel thing about waiting is that the clock on that column only runs when you are working.

Is wait-and-see still the safe Dutch default?

For a long time it was, and I want to be careful about how far this argument travels. The numbers below are Dutch, from CBS, and I am not claiming they describe Flanders.

CBS reported in December 2025, as Accountant.nl summarised, that about one in six Dutch companies now uses AI, double the share two years earlier, with three quarters neither using AI nor having considered it. The movement was fastest in the mid-sized band. Among companies with 50 to 250 employees, use rose from 20 percent in 2023 to 45 percent in 2025. Sector differences were large: information and communication reached 54 percent, while horeca, transport and storage, and construction sat at 6 to 7 percent.

Read that as a founder, not a statistician. The safe, observe-first position has quietly moved. For a company of a hundred people in a services sector, the cat has been out of the tree for a while, and a lot of your peers are already on the ground. If your sector is horeca or construction, the picture is different and the case for waiting is stronger, because there are fewer examples to learn from.

I do not want to overread this. "Uses AI" in a statistical survey covers everything from a chat window to a wired-in workflow, and a high adoption share does not tell you whether those companies got value from it. My suspicion, which the CBS figures do not test, is that many firms adopted the chat window faster than the workflow (see also the CBS adoption data). A peer that has "adopted AI" may have done very little.

But that cuts the other way too. If your peers are mostly doing very little, then the opportunity is not that you are behind but that the bar is low and the learning is available to anyone who starts. The risk of waiting is not that you miss a deadline. It is that the people in your sector who do start accumulate the second column while you accumulate nothing.

When is delaying AI adoption the right call?

Sometimes it is. More often than people expect, I tell them not to start yet, and the reasons are consistent.

Wait when the process itself is about to change. If you are replacing your ERP next year, or merging two teams, or redesigning how orders flow, then automating the current process automates something that is about to disappear. Do the redesign first, then automate.

Wait when nobody can be named as the owner and nobody will agree to be. This is not a technology reason. It is a common reason that a project fails after launch, and it is a reason to fix the organisation before you buy anything.

Wait when you cannot legally or contractually use the data the project needs. Privacy and contract questions have known answers, and I would rather you resolved them properly than started and discovered them in week six. That is a case of waiting for a lawyer, not for a model.

Notice what these reasons have in common. In every one, you are waiting for something inside your own company. I have never met a company where the honest answer to "why are we waiting?" was "because the model is not good enough yet", and I have met many who said it anyway. The model is the most convenient reason, because it puts the delay outside your control.

You are not waiting for the model. You are waiting for yourself. That is a perfectly good thing to be doing, as long as you say so out loud and put a date on it.

How do you start in a way that survives the next model release?

Start small, and start with the second column. In practice that means five things.

First, pick one task, not a platform. A repeated, well-understood piece of work that somebody on your team can describe in a paragraph. Run it for four weeks with a human checking every output, and count the exceptions. That counted list is worth more than any demo, and it begins to answer the lack-of-experience objection with evidence.

Second, write the examples down. The first fifty real cases, with the correct outcome beside each, become your evaluation set. You keep a copy. Whoever holds that set can change supplier; everyone else starts over. This is also what makes a model change a test run rather than a project, and it is the answer to the day the price list or the best model changes under you.

Third, keep the commitment short. Pay per use, or sign for months rather than years, and keep the model behind a thin layer you control. If a model gets cheaper in the middle of your contract, you want to be able to benefit, and if a better one arrives, you want to try it on Friday.

Fourth, name the owner before the build starts, with the right to say stop. I learned this the hard way, from projects that worked technically and went quiet within a quarter.

Fifth, decide in advance what a good result looks like, in numbers your finance person would accept, and measure it from week one. If that is hard to do, you are not ready to start, and that is worth knowing.

If it helps to have a second pair of eyes on which task to start with, that is a normal first conversation for us, and the AI implementation page describes how we work. The conversation is mostly about the second column.

What should you do this quarter?

Skip the strategy deck. Pick one process that hurts, find the person who knows it best, and ask them to write down what happens, step by step, including the awkward cases. That document is the first asset you own. It will outlive every model you try.

Then find fifty real examples, and name an owner. After that, choose a model, because by then you will know what you are choosing it for, and that makes the choice a lot easier.

And if the honest conclusion is that you should wait, say what you are waiting for, who is responsible for it, and the date you will look again. A date turns waiting into a decision. Without one it is drift, and the model will keep improving either way.

Frequently asked questions