.png?2026-07-26T13:26:23.738Z)
Your most capable people will find value in AI whatever you do.
They will find the workarounds. They will tolerate the odd wrong answer and know when to check. They will work out which tasks suit it and quietly avoid the ones that do not. Give them nothing but a login and they will still come back in three months with something useful.
But that only reaches the people who were always going to find their way. The pattern we see often is a couple of visible enthusiasts, a lot of quiet uncertainty, and a pilot that does not spread beyond the people who started it.
A harness is what reaches everyone else.
What a harness actually is
Everything wrapping the work that makes a good outcome the default rather than the reward for being careful.
What the system is allowed to reach, and what it is not. Which tools are available in a given task, and which are deliberately absent. What gets checked automatically before anything is sent, filed or paid. Where the work stops and asks a person. And what happens when something fails, rather than only what happens when everything goes right.
A useful way to hold it: a decent model with a well built harness will generally beat a strong model with a poor one.
Why it decides who benefits
Think about what your careful, capable people are doing when they use AI well. They are holding a set of rules in their head. Do not put client data in that one. Check the numbers, not the prose. This tool is fine for a first draft and not for anything final. Always read it before it goes out.
Those rules are the harness. Your most experienced people carry it around with them. Everyone else does not, and asking them to is asking them to be as experienced and as cautious as your best people, which is a lot to ask.
Putting the rules into the system rather than into people's heads is the difference between "you can use AI if you are careful" and "here is the tool, and it will not let you do the wrong thing."
What this looks like in practice
Often it is unglamorous, and often the blocker is access rather than capability.
We had a summarisation task stall because only the host of a meeting could download the transcript. That is a harness problem rather than an AI problem. Somebody needed to decide who is allowed to reach that information and make it reliably available to the task.
The same is true of the checks. If a piece of work must never go out without a person reading the figures, that check belongs in the flow of the work rather than in a policy document.
Built for you, specified by you
This is the one capability in the series where the split is awkward, so it is worth being precise.
Someone else builds this. It involves permissions, integrations and engineering, and it is not something a marketing team assembles between campaigns.
But nobody outside your department can specify it. Only you know which checks matter, which steps must never be skipped, which decisions need a name against them, and where a person has to look before something goes out. That knowledge is rarely written down. It lives with the people who have been doing the work.
So the useful preparation is not technical. It is being able to answer three questions about any piece of work you want to put AI into: what must never happen, who needs to approve what, and what should the system do when it is unsure.
Answer those and the build is straightforward. Leave them open and the decisions get made for you, by whoever builds it.
Part of the series that starts with The jargon is complicated. The capabilities underneath are simple. Next: Process Engineering, rethinking the work rather than just speeding it up.
Get the next one
Enjoyed this? More like it, twice a month.
Practical AI and data perspectives. No hype, no filler.