Three eras, one constant
Software as a service sold a tool, and a seat for everyone who touched it. It was a genuine advance. You no longer bought a server or a licence you had to install. But the tool sat there until somebody opened it, and that somebody was you.
Automation builders sold the connections between those tools, and with them the job of repairing the connections whenever a third party changed an API. The promise was that the work would flow by itself. The reality was a second job maintaining the pipework, and it fell to the same person.
AI chat sold advice. Instant, articulate, enormously confident advice, and no ability to act on a word of it. It could tell you precisely what to write to the client who had gone quiet. Somebody still had to open the inbox and write it.
Three eras, three real improvements, and one thing that never moved. The software kept getting better and the person stayed on the hook.
The unit is changing
What has actually been on sale all this time is capability. The ability to do a thing, licensed by the month, with execution left to the buyer. That works when the buyer has people whose job is execution.
A business of three does not have those people. The owner is the sales team, the account manager, the bookkeeper and the person who remembers that the renewal is due. For them, capability is not the scarce resource. Attention is.
So the unit that matters is not capability. It is completed work. Not a place to raise an invoice, but the invoice raised, sent, followed up and reconciled. That is a different product, and it cannot be reached by adding features to the old one.
Why the smallest businesses feel it first
Large organisations absorbed this problem with headcount. Operations teams, finance teams, an administrator per department. The software never had to do the work because there was always somebody whose job was to make the software work.
A small business has no such absorption layer, which is why the same tools that feel efficient at scale feel like a second job at three people. The gap is not a matter of taste or sophistication. It is structural, and it has been there since the first business application shipped.
What it looks like in practice
You do not onboard a new hire by handing them a dashboard and a tutorial. You tell them what needs doing. They go and do it. They come back when they need a decision that is genuinely yours to make, and they tell you what they did while you were not watching.
That is the relationship. It is not a metaphor for a better interface, it is a description of a different product. The work arrives finished, and the things you are asked about are the things that actually require you.
Why this is not simply more agents
The obvious way to build this is to give a model access to the business and let it decide and act in a loop. It is also the reason most of this category will not be trusted with anything that matters, because a system built on probability does not stop when it is unsure. It guesses, and the guess goes out in your name.
An employee you cannot trust with the work is not an employee. It is a very fast intern with the keys to everything. The architecture is the whole argument, and we have written it out separately.
Start with one thing it can take off your hands.
You don't have to move your business across. Pick the job that annoys you most, the chasing, the invoicing, the inbox and let it take that one first.