The Model Is the Easy Part
Why Your Next AI Investment Will Live or Die by the Harness Around It
A frontier large language model, on its own, is just a file on a disk.
I know that sounds reductive. It is meant to. Because somewhere between the keynote demos and the vendor decks and the board papers using the word “transformational” for the fourth time this year, we have lost sight of something fundamental: the model itself is inert. It is statistics. It is a probabilistic engine that predicts what character or token most likely comes next, given what came before. That is not reasoning. That is not sentience. That is pattern matching at industrial scale, and however clever the patterns get, the file on the disk does nothing until something tells it what to do.
This matters, because a great deal of organisational money is currently being committed to AI initiatives on the unspoken assumption that the value lives inside the model. It does not. The value lives in everything you build around the model — the tools you give it, the context you feed it, the guardrails you wrap it in, the feedback loops you design, and the human judgement about what is actually worth solving in the first place.
The industry has started calling this layer the harness. And the people who can engineer it well are about to become the most important hires your organisation makes.
We Have Seen This Movie Before
In 2005, organisations spent serious money on SQL Server. A licence, a box of equipment, a database administrator, and a sense that something important had just been acquired. Some of those investments transformed how businesses ran. Many of them sat in cupboards drawing power.
The difference was never the database. SQL Server in a cupboard is identical to SQL Server in production. The difference was whether somebody in the organisation had done the unglamorous work first: codifying the business logic, deciding which events mattered, designing the relationships between them, and building the interaction layer that let humans and processes actually use what the database stored. The thinking was the hard part. The database was the easy part.
I watched this play out many times. The failure mode was almost always the same. Big money, no clear problem. A capability acquired before anyone could articulate what it was for. The cost was modest because the worst thing the database could do was sit there.
We are running the same pattern now with large language models, and the cost of getting it wrong is no longer modest. SQL Server in a cupboard stored nothing. A misharnessed agent in a cupboard acts. It sends emails. It updates records. It commits to customers. It calls suppliers. The latent technology of 2005 has become the active technology of 2026, and the gap between buying it and being in the shit has narrowed to almost nothing.
I’ll come back to that. First, let’s talk about what the harness actually is.
The Harness, Translated
The clearest way I can explain harness engineering to a non-technical leader is this: it is the work of onboarding.
When a capable graduate joins your organisation, they arrive with credentials, some general knowledge, and a brain capable of doing useful work. They are also, in operational terms, useless. They do not know which contexts connect to which. They do not know who to ask, where the truth lives in your data, what good looks like in your business, or what “in the shit” looks like for your customers. The sharpening of that graduate — turning latent capability into deployed capability — is the work of the team around them. Their manager. Their mentor. The processes that surround them. The organisational scaffolding that says here is the world, here is what matters in it, here is how to act, and here is how we will know if you got it right.
A large language model arrives in your organisation in roughly the same state, with one important difference: it has indexed a startling fraction of the public internet and can produce fluent text on almost any topic you ask about. That fluency is seductive. It makes the model feel ready in a way the new graduate never does. But the underlying situation is identical. The model has no awareness of your organisation, your customers, your suppliers, your data, or your obligations. Whatever it appears to know about your business is either guesswork or hallucination dressed in confidence.
The harness is the onboarding. It is the set of tools the model can call, the context it can draw on, the guardrails that stop it from acting outside its remit, and the evaluation loops that tell you whether the work it did was actually good. Anthropic, OpenAI, and others have started writing about this work explicitly. O’Reilly published a useful piece on agent harness engineering earlier this year that is worth your time if you want the technical detail. But the executive summary is this:
The model is the easy part. The harness is the hard part. And the harness is where almost all of the value — and almost all of the risk — actually lives.
Context Is Not Volume. Context Is Connection.
There is a fashionable response to all of this which goes: fine, we’ll just feed the agent more context. More documents. More data. Bigger context window. Retrieval-augmented this and that.
This misses the point in an important way.
Consider a meat product on a supermarket shelf. At one moment in its life, it was a living animal on a farm. At another, it was in a processing facility. At another, in a chilled distribution vehicle. At another, on the shelf in front of the customer. Each of those is a real context. Documents exist about each of them. An LLM could be fed all of those documents and still have no useful understanding of the business, because the business is not any of those contexts. The business is the relationships between them across time.
That connective tissue — knowing which contexts touch which, what flows between them, what changes when one of them changes, who is accountable at each handoff — is organisational knowledge. It does not live in a single document. It often does not live in any document at all. It lives in the heads of the people who have run the process long enough to understand how it actually works, as distinct from how the process diagram says it works.
This is why pouring more context at a model rarely delivers what people hope it will. The volume goes up, the connections do not. And without the connections, the model is staring at fragments of a system it cannot see.
Building the harness — really building it — means making those connections explicit. It means a human, with deep organisational awareness, deciding which contexts the agent gets to see, in what order, with what authority to act, and against what definition of success. That is not a prompt-engineering job. It is an architecture and leadership job. It is the work senior practitioners have always done, suddenly made executable by the system around them.
Industrial-Scale Cat Memes
We already wasted a great deal of compute and energy moving cat memes around the internet. It was funny. It was largely harmless. It was also, on any honest accounting, a colossal misuse of the infrastructure we had built.
The risk now is that we industrialise the same pattern. We have spent the better part of two years celebrating the fact that AI can produce fluent content quickly, and we are about to discover what happens when an organisation activates that capability without first deciding which content is worth producing, which decisions are worth making faster, and which actions the system is allowed to take on its own. We will produce a great deal of low-value output at unprecedented speed. Some of it will be embarrassing. Some of it will be expensive. Some of it will land us in regulatory territory we did not intend to enter.
This is not an argument against AI. I build with these tools every day. They are genuinely powerful when they are pointed at problems worth solving and wrapped in harnesses worth trusting. It is an argument against the version of AI adoption that skips the problem definition, skips the harness, skips the governance, and goes straight to let’s see what it can do. That version is the cat meme version, except now the cat meme can email your customers.
Capability Density Is the New Constraint
Here is what all of this means for how organisations should be thinking about people.
The constraint on what your organisation can do with AI is not licences. It is not model access. It is not budget. It is not even data, although data matters. The constraint is the number of people you have — or can attract, or can develop — who can do the work I have just described. People who can sit between the business problem and the model, articulate what is actually worth solving, design the harness around it, choose which contexts connect to which, define what good output looks like, and stay accountable for what the system does once it is running.
This is what I mean by capability density. Not fewer people. Not the same output from a smaller team. Not headcount reduction dressed in new language. The industry is already starved of capable people; pretending otherwise is the kind of thing vendors say to sell licences. What I am describing is capability amplification — making the people you already have, and the ones you can bring in, materially more effective by giving them tools they can wield well.
The organisation that wins this decade is not the one with the most AI seats. It is the one with the highest density of people who can do the architectural and leadership work of designing harnesses that actually pay off. Those people are rare. They will become rarer. And they will not, on the whole, be produced by sending your existing staff on a two-day prompt engineering course.
That is the conversation worth having at the board table, in the architecture forum, and in the leadership team. Not which agent platform should we buy. Not how do we get everyone using Copilot. The real question is: do we have the people who can turn an inert model into a system that creates value, and if not, what are we doing about it?
A Webinar for the Leaders Who Need to Answer That Question
I am putting together a two-hour webinar for technology leaders, board chairs, line-of-business leaders, and senior architects who are sitting in front of this question right now and not entirely sure how to answer it.
It is called Leadership OS for the Age of Agents, and it is built on the traits, tasks, tools framework I have been developing through this Substack. The goal is not to make you a harness engineer. The goal is to give you the operating system you need to lead an organisation through the next eighteen months of AI adoption without ending up in the cupboard-full-of-SQL-Server position — or worse, in the shit.
Attendees will walk away with:
A diagnostic for assessing whether your current AI initiatives are problem-led or tool-led, and what to do if the answer is uncomfortable
A framework for distinguishing the work that should be commissioned, the work that should be built, and the work that should not be done at all
A practical approach to capability density — what to look for, what to develop, and how to talk about it with your board without it sounding like a euphemism for headcount reduction
A small set of questions to take into your next vendor meeting that will tell you very quickly whether the people on the other side of the table understand harness engineering or are selling you a demo
Two hours, NZD $149, recording included. Dates and registration link will land in next weekend’s post.
If the argument in this article has stayed with you, the webinar is the next conversation. Bring your hardest current AI decision and we will work it together.
The model is the easy part. The thinking is the hard part. The thinking has always been the hard part. The only thing that has changed is the speed at which not doing it gets expensive.
A free week of Claude Cowork for you there are only three of these available so it will be the first three of you who click the link to redeem. Have fun with this and begin learning how to bridle the pony and go for a much better ride.