Harness(ing) AI: From Raw Power to Reliable Output
Spend enough time around frontier AI models, and you start to notice the same pattern. The model itself is the easy part. Everything around it is the hard part.
I've seen very capable engineers paste a prompt into a chat window, get a confident-sounding answer back, and treat it as a finished outcome. It isn't. It's a fast horse with no reins.
That's not a knock on the model. A modern LLM is an incredible thing. It reasons, it writes, it codes, it summarises a hundred-page report in seconds. But raw capability and a reliable system are two very different animals, and the gap between them is where most AI projects quietly fall over.
Which brings me to the racetrack. What do harness racing and LLMs have in common anyway? Well, more than you think!
The Harness Racing Analogy
In harness racing, the horse does the running. It supplies the power. But nobody puts a champion horse on a track and simply hopes for the best. The horse is fitted with a harness, attached to a sulky, fitted with blinkers, and connected to a driver holding the reins. All of that equipment exists for one reason: to take an enormous amount of raw power and point it down the track, at pace, without it bolting into the rail.
The horse has the power. The harness directs it.
This is exactly the relationship between a frontier model and what I've come to think of as an AI Harness: the layer of context, skills, agents, guardrails and templates built around the model to turn raw capability into output you can actually use and trust.
The model is the horse. The harness is everything that makes its power useful, safe, and repeatable.
Harness racing versus the AI Harness: the horse supplies the power, the harness supplies the control. (Image created with ChatGPT 5.5)
The problem with the bare model
Before going further, it's worth being clear about what a bare model actually is.
An LLM is, by its nature, probabilistic. Ask the same question twice, and you can get two slightly different answers. That flexibility is precisely what makes it useful for open-ended work, and precisely what makes it dangerous the moment you need consistency. It has no memory of your environment, no access to your systems, no awareness of your policies, and, outside of its defined guardrails, no concept of what it isn't allowed to do.
On its own, the model is all power and no direction. It will happily produce something plausible, every single time, whether or not it's correct, safe, or in scope.
For a quick experiment, that's fine. Anything you intend to put in front of a customer, a senior leadership team, or a production system is a liability.
Here's the part people get wrong: they try to fix this by writing a more clever, more detailed prompt. A better prompt is a better instruction shouted at the horse. It is not the reins.
The Fundamentals
So, what does a good AI Harness consist of? Five components, each one providing vital context and direction for what, why, and how the model needs to perform.
Context is the relevant information, history and data the model needs to answer your question or complete a task, rather than a generic one. Strip it out, and the model defaults to patterns from its training data rather than the specifics of your environment, your data, or the problem you're actually trying to solve. It guesses in the dark, however eloquently.
Skills are the capabilities, functions, and integrations that let the model do things rather than just talk about them: query a database, call an API, run a calculation, understand solution architecture patterns, or retrieve a document. A model that can only produce text is a clever conversationalist, not a system you can build on.
Agents are specialised collaborators who act on the model's behalf. Think of them as a team of specialists, each focused on a different stage of the workflow and handing off cleanly to the next. One agent retrieves, one validates, one executes. Coordinated, they accomplish what no single prompt could.
Templates are the reusable structures that produce the same quality of result in the same way, every time, so you're not reinventing the setup for every run. This is where consistency and speed come from, and it's the difference between a decent, workable demo and something a team can rely on.
And then there's the component that matters most to anyone reading this from a security background.
Security guardrails are the policies, vulnerability checks, and risk mitigation that keep the model on course and stop it from introducing weaknesses or doing things it shouldn’t. They define what the model is allowed to act on, what it must escalate, and what it must refuse outright. In practical terms, this is your defence against prompt injection, data exfiltration, and a model acting on instructions buried in content it was only meant to read.
For most people building with LLMs today, this is the weakest part of the setup, if it exists at all. For a threat-informed architect, it's the entire point. The guardrails aren't a nice-to-have you bolt on at the end. They're load-bearing.
“The model has intelligence. The harness decides what the model needs to do and how to do it.”
What this doesn't do
I should be clear about one thing, because it’s easy to overhype this type of thing, and the world could do with less hyperbole.
An AI Harness does not make a probabilistic model deterministic. The model retains its probabilistic nature; no amount of wrapping around it changes that. What you get instead is direction: output that is reliable enough, repeatable enough, and governed enough to put into production with confidence. You're not eliminating the model's nature. You're shaping where its power goes.
That distinction matters. The goal isn't a perfectly predictable machine. It's a powerful one you can actually steer.
Building your own harness
If you're moving from experimenting with a model to building something real on top of one, the order of operations matters. Here's roughly how I approach it:
Start with context. Before tuning a single prompt, work out what information the model genuinely needs to do the job well, and how to feed it that reliably. Most "the AI got it wrong" failures are really "we never gave it the right context" failures.
Give it skills, not just words. Decide what the model needs to do, and connect the tools, functions, and integrations that enable it to act. Talking is cheap; doing is where the value is.
Fit the guardrails before you let it run. Define what the system is allowed to do, what it must never do, and how you'll detect when something tries to push it off track. Do this before you hand it any real autonomy, not after the incident.
Template the work that repeats. Once you have a setup that works, capture it so it works the same way every time. Consistency is a key feature, especially when multiple people rely on the output.
Bring in agents last. Only once context, skills and guardrails are solid should you let agents take independent action. Autonomy on top of a weak harness is how avoidable incidents happen: a system acting on its own without the constraints to keep it in scope.
Final thoughts
The frontier labs like Anthropic, OpenAI and Google will keep producing bigger, faster, and smarter models, and that pace isn't slowing down. But a faster model only widens the gap between what it can do and what you or your organisation can accurately, safely and reliably get it to do.
That gap is the work. It always has been. In the same way, good security architecture has never been about owning the best individual control; building well with AI isn't about access to the best model. Plenty of people have that. Far fewer have built the harness around it.
Focus the power, control the output, and you've got something you can put to work at scale. Skip the harness, and what you've really got is raw capability with no direction: impressive in a demo, dangerous in production.
