90% AI, 10% Human

A few years ago, when I was still working as a real estate broker in Dubai, the most valuable person on any team was the one who could call through a database quickly and never forget to follow up.

I look at that now from the other side of the table, and I can see the skill disappearing. Not becoming less important — disappearing. A machine does it, and it does it without getting tired.

That is the shape of the change, and it is not confined to property. Every business I have looked inside since runs on the same fuel: a database of people, a queue of conversations, a set of promises somebody has to remember. Wherever that is true, the same thing is about to happen.

The work does not get faster — it moves

The convenient way to talk about this is efficiency: the same job, done sooner. That framing is comfortable and it is wrong.

What actually happens is that a category of work leaves the human entirely. Updating records. Moving a deal between stages. Creating the task, archiving the contact, writing the follow-up that says nothing except "I have not forgotten you."

Roughly ninety percent of the operational layer can go. What stays is the ten percent that was always the job: the conversation where somebody decides, the moment where a person needs to be persuaded rather than informed, the judgement about which of two bad options is less bad.

The people who struggle with this are not the ones who cannot use the tools. They are the ones whose sense of their own value is built on the ninety percent.

You are not operating a chatbot

Until recently, changing how your company works required somebody in the middle: a developer, an integrator, a technical person who could translate what you meant into something a machine would execute.

That layer is thinning fast, and this is the part most owners have not registered yet.

The constraint is no longer technical skill. It is the willingness to describe your own processes precisely enough that they can be handed over — which turns out to be much harder than it sounds, and has nothing to do with programming.

This is why I do not think automation should be delegated downward in a company. The person who knows which ten percent actually matters is the one running the place. Hand the decision to someone junior and you get a faster version of the wrong process.

The uncomfortable part

Everything above sounds like an argument for buying software. It is not.

A system built by an outside contractor encodes what the contractor understood about your business on the day they asked. Businesses do not hold still, and neither does what you need from them. Six months later you are back with a change request, waiting in someone else's queue.

What I have found to work is narrower and less glamorous: the people who run the process build the thing that runs the process. Not because they become engineers, but because the distance between "I know what is wrong here" and "I fixed it" collapses to nothing.

That is a change in who holds the pen, not a change in tooling.

What this does not promise

I am not going to tell you this makes companies rich, and I would be careful with anyone who does. I have watched enough of my own automations produce clean reports over quietly broken work to distrust the genre.

What I will say is narrower. The routine leaves. What remains is the part of the work that was always yours — and most people, when they finally get it back, discover they had been doing it in whatever time was left over.