I don't like the word harness. Say it and most people picture an assistant that drafts your emails and does your shopping. For years I avoided it, and I still feel the allergic reaction when someone says they're building one. Then a colleague made a point I couldn't argue with: everything I've built is a harness. For my EMBA at UCT, for my own business, for the teams I work with. I looked at all of it and had to concede.

So I've made peace with the word, and the biggest AI wins I've seen this year prove the point. They didn't come from chatbots, clever prompts or a list of "guardrails" longer than the Dead Sea Scrolls. They came from AI fenced tightly around a job the business already does. The fence is why it works.

And I mean real work, not slide decks or comparing 2 spreadsheets and calling it transformation. Plenty of harnesses will manage your own bank payments, and they run smoothly because they sit on clean, well-behaved software. But inside the company that built it, the one your banking MCP talks to, things look very different: a quantum entangled mess of custom-built and store-bought systems, each held together by people who know its quirks. Putting AI to work in there is a different monster altogether.

A harness wraps a job that already exists: a process the team runs every month, a reconciliation, a system update someone does 10 times a day. The systems are there. So are the rules, even if most of them live in someone's head or in a spreadsheet nobody else understands.

A known job is what makes it fenceable, because the actions are known too. You decide what the AI may read, what it may write and what needs a human to say yes. You start read-only, watch it work against live data, and only then let it touch anything. Each step earns the next. It's the air cover I wrote about in The AI Executive, built into the tooling instead of promised in a meeting.

The surprise is what the harness remembers. Every team runs on tacit knowledge: the special conditions, the exception everyone watches for, the step you only learn by getting it wrong once. As people use the harness, those rules get written down. Next month the harness knows them. What used to walk out the door with a person stays with the team.

Another big benefit is reach. To find the simplest piece of information while supporting a customer, a person has to go through a legion of systems: one screen for the account, another for the order, another for the ticket. An LLM with a harness looks at all of them at once.

Then there's automation. What used to be a complex n8n flow, box after box of triggers and branches, can now be described in plain English and held in context for the LLM to act on. Written that way, the person who owns the process can change it, not just whoever wired up the boxes.

The build itself is quick, and a harness adds value from day 1. For me that's Claude, through the desktop app, the command line or the SDK, or another LLM with my own harness built around it. The hard part is 2 things: permission and unwinding people's thinking.

Permission means write access to the systems that matter, and mapping how they actually behave. That just takes some consideration and effort.

Unwinding is harder. Most people hand the AI the answer, because they've done the job so long their mind short-circuits straight to the end. The AI copies the shortcut and breaks the first time something changes. So most of my time goes into helping them untangle it: why each step happens, what they check, what makes them stop. Once that's on the table, the harness can do the work instead of mimicking it.

You don't need a perfect use case to start. As I said in Playing To Win: build the muscle, provide the tools and get out of the way. A harness makes that concrete: one team, one known job, one fence, then the next team.

Building software with AI is another story. There, the job doesn't exist yet, so there's nothing to fence. That's the next post.