The frontier AI companies are, understandably, building for enterprise. That is where the seat counts are, and it is where a twelve-month procurement cycle is normal. The effect on everyone else is that a business of thirty or three hundred people is left to work out from headlines what any of it means for them.
And the headlines say adopt AI or die. On a long enough horizon that may even prove correct. As advice, on a Tuesday, to a managing director with a real business to run, it is worth nothing. It creates urgency without direction, which is the worst combination available.
The questions people actually ask
When you sit down with a founder or an MD, the panic is not what comes out. What comes out is a short list of entirely reasonable questions.
Where do we begin? How do I trust it? Will it genuinely help, or is it just another thing to manage? And what happens when it gets something wrong?
Notice that only the first of those is about technology. The rest are about adoption, accountability and what happens on a bad day — which is exactly the part the noise skips. The industry talks about capability. The work is change management.
The answer is duller than the headlines
Start with one process that costs you real money. Not the one that demos well; the one that quietly eats hours or margin every week.
Keep a named person responsible for it. Not a committee, and not the system.
Enforce the limits that matter in the system itself, not in a prompt. A prompt is a request. A spend cap, a permission boundary and an approval step are enforcement, and the difference between the two only becomes obvious on the day something goes wrong.
Then let the automation earn more freedom, slowly, and only after it has performed reliably and produced evidence you can go and inspect. Trust that has not been earned in public is just optimism with a dashboard.
Bending the business around the software
We were recently brought into a business to improve the integrations between several systems and make the whole thing run more efficiently. A sensible brief, and not an unusual one.
It became clear fairly quickly that two of those systems were not fit for purpose in the first place. The business had spent years bending itself around the software — the classic square peg and round hole — and every process had grown a workaround to accommodate a tool that had never quite fitted.
Connecting those systems more neatly would have worked, in the narrow sense. It would also have made the workarounds permanent and given them an API. The right answer was to work out what the ideal workflow actually looked like, decide deliberately which parts should stay human, and build around that. Not the other way around.
That is a harder conversation to have in week one. It is also the entire value of the exercise.
The advantage will not be access
The time and cost required to build software shaped around one specific business is falling, and falling quickly. Which means access to the technology is not going to be anybody's advantage for very long.
The advantage will be the ability to take a complex, inconsistent and frequently illogical human workflow — the one that lives in somebody's head and three spreadsheets — and turn it into a dependable system that the people who use it understand and trust.
That is a translation problem far more than an engineering one, and it is the part of this work we find most interesting.
None of this is about automating everything because it can be automated. It is about banking small wins, letting them compound, and earning enough trust along the way that the next step is an easy conversation rather than a fight. A business changes one dependable step at a time.
So a question worth sitting with: what is one process in your business that only works because somebody remembers how?