This month one US government letter took two of the most capable AI models on the planet offline for most of the world, in hours, with no appeal. There are enough folks debating the ‘real reasons’ behind the takedown, and I’m ashamed to say it’s probably more political than it should have been. But the incident isn’t the point here.
It was a keen reminder that anyone relying on someone else’s LLM timetable can be left out in the cold, fast.
Think about your bus being cancelled. The operator pulled it, not you. You still don’t get to work, you’re still late, and on Monday morning you’re still the one explaining it. The dependency was theirs to cut. The accountability stayed with you. That’s exactly where you stand when your whole operation runs through a model someone else can just turn off. So, what’s the alternative?
Think about this - the model is just the brain. The ‘harness’ is how the work gets done. You rent the first. You own (and control) the second.
What is the harness?
The harness is everything you build around a model, to turn raw capability into reliable work. Orchestration, context, routing, evaluation layers, the review step, the rules for what an agent’s allowed to do and when it has to stop. The model (your LLM) supplies capability. The harness supplies reliability, judgement and control.
Most teams pour their attention into picking the cleverest model and treat everything around it as duct tape. That’s bonkers. Adding the LLM isn’t the final step in making AI work for a business - it’s barely even the first. Bolt agents onto a pipeline in a vanilla way and it won’t scale gracefully, it’ll fall over the moment the work gets real. The part that scales is the harness. And tokenisation, liability and governance are the factors that take an AI architecture beyond the pilot phase.
Why the model isn’t really that important
Frontier models (GPT 5.6, Fable 5, Opus 4.8, Kimi K3, Qwen 3.7, and so on) are HUGELY powerful. Beyond specialist multimodal, coding, research or governance tasks, all of them are functional for most current work. A solid model with GOOD harness context and framework is more powerful than a vanilla frontier model - that’s because capability and operational predictability ship differently.
I split any AI architecture into two modes.
The first is capability-gap builds. These fulfil something the native model can’t do well enough (yet). Sometimes this ‘MOAT’ depreciates with every release, and sometimes it disappears overnight - a price change, an API tweak, a policy shift, a letter from the government, or the model simply advancing to do certain tasks natively. This is also why commercial alignment architecture is the MOST important phase in any AI project. A model dependency is a ‘capability-gap build’. If it’s rented, the lease terms aren’t yours.
The second is operational encoding. This captures how your agents actually run: your processes, your tech stacks, your standards, your sequencing, your definition of good. Models get cleverer, but they don’t know how YOU operate. Operational encoding compounds. It’s the part you own.
The harness bit is the operational encoding. Once you really see this split, it gets hard to unsee: teams keep pouring investment into the rented thing, and treating the owned thing as basic plumbing.
You don’t scale your company with execs and founders
No business runs every task through its most senior, time-stretched people. You’d go broke and nothing would ship. You hire for the work: doers for the routine, specialists for the unknown parts, founders and execs for where you need them. Unless you’re deliberately in startup mode - where you wear every hat - the words that matter are consistency, delegation and compliance.
Agentic systems are no different. Run a frontier model on routine work and you’re putting your most expensive person on operational duties: slow, costly, and a single point of dependency you don’t need. Distributed agentic operations means routing routine work and reasoning to capable, cheaper models, and reserving the frontier for the work that actually requires it. The practical part is easy now - pointing an agentic coding tool at a local model takes minutes, not a research project.
The hard part is confidence, not the routing
Comparatively ‘routing’ is easy. Trust is the problem. Send routine work to a cheaper doer and how do you know the output’s “any good” without you or your expensive model checking everything, which hands the cost straight back?
That’s where the harness earns its money. The quality-management, evaluation and review layer is what lets you trust a lighter model’s output without a senior model babysitting it. Confidence in results is a built artefact for this sort of thing - from setting the right expectations and providing the right context, to constantly evaluating the credibility of the output, and the inputs, to guard against drift. A harness that can’t tell you whether its own output’s good is just automation with extra bells and whistles.
I didn’t just design this on a whiteboard
This isn’t theory I’m throwing around from the outside. We sketched plenty of it on a whiteboard - but it didn’t stay there. I run it live, and not only in this consultancy, but across startups that are replacing bought-in software with connected architecture, and the same shape keeps turning up.
The foundational work is the harness. That’s the big build - the process, the standards, the sequencing encoded so the work runs the same way every time. Get that right and the model layer becomes simple to evolve: which LLM, which routing, local or cloud, those are afternoon decisions, not rebuilds. When I’ve changed the model layer underneath my own setup, the migration cost less time than documenting it! Not because swapping models is trivial, but because the harness was built to outlast any one LLM. Get used to becoming LLM agnostic. Change the model underneath and it’s a change of supplier, not a restart.
There’s no single right harness
I’m wary of anyone selling the ‘correct architecture’, including me. The right harness is shaped by context - what the business looks like, what the work is, what it’s worth, risk profiles, what failure costs, who’s accountable. The harness inside a learning platform looks nothing like one running a content production pipeline, which looks nothing like one sitting inside a corporate global Microsoft framework. I’m working on all of these levels, but what I run internally is built for how I operate. It’d be wrong for a 10-strong business or a 10,000-strong enterprise. The framework isn’t a blueprint to copy. The way of defining it, and the vision we align to it, all move as the technology (and business) does - it’s a moving target by design, which is why I’m shipping the thinking as it evolves, instead of waiting for a ‘finished version’ that’ll never exist.
Most harnesses work the same way
Here’s what I keep noticing across everything I build. Strategy, visual content, 3D geometry - the work looks wildly different at the delivery stage, but like manufacturing and engineering, the principles are the real foundations - the digital infrastructure barely changes. Context in, routing, generation, an evaluation layer, review, an output you can stand behind. Same shape, different payload. Most harnesses, across most domains, work the same way.
That’s the opportunity and the warning in one. Build the harness properly and the pattern travels - what you encode for one kind of work carries into the next. And as AI settles into being a utility, the model itself stops being something you control. A vendor, a regulator or a market can move it without asking you. So be clear about which parts of your stack you actually own. The model isn’t one of them. The harness is. Build for that.
