The harness is the moat
Last month I gave a talk at the AWS Community Meetup in Sydney. The argument fit in three lines.
The model is the commodity. The harness is the moat. The tokens are the bill.
I want to spend some time here on what that actually means for engineering teams, because I think the implication is more practical than it first sounds.
Every serious team now has access to essentially the same frontier models. Opus, GPT, Gemini, open weights. The capability gap between them, on most tasks, has closed to the point where model selection is not the deciding variable anymore. That is a real shift. A year ago you could make a meaningful call on which model to use for a given task. That window is mostly gone.
Grady Booch wrote that a fool with a tool is still a fool. He was talking about software engineering broadly, but it applies here with unusual precision. The model is the tool. Everyone holds it now. What separates teams is not the tool. It is what they built around it.
That is the harness.
A harness is everything between your problem and the model call. It is the context management layer that decides what the model sees and in what order. It is the routing logic that determines which model handles a given step. It is the verification layer that checks whether output is plausible before it propagates further. It is the retry logic, the fallback behaviour, the cost controls, the observability hooks that tell you what happened when something breaks. It is the orchestration that turns a sequence of model calls into something that actually works.
The model is stateless. It has no memory of what came before and no understanding of what comes after. The harness carries all of that. Without it, you do not have an agent. You have a very expensive autocomplete.
Sakana AI’s Fugu is a useful example. It maintains a pool of frontier models and dynamically assembles them per task, assigning roles: Thinker, Worker, Verifier, routing work between them based on what each step requires. Technically, Fugu is a harness. It presents as a model. That framing is deliberate, and it tells you something about where value is actually being created.
We built something we call Atlas at Lawpath, a multi-agent runtime on Bedrock AgentCore. The models it uses are not unusual. What took time was the orchestration layer: knowing when to hand off between agents, how to maintain context across a long document workflow, when to escalate to a human, how to verify output before it reaches a user. That layer is the product. Swapping the underlying model barely changes it.
This is where engineering craft comes back in.
Building a good harness requires the same instincts good software engineering always required. Knowing when to abstract and when not to. Understanding failure modes before they show up in production. Writing systems that behave consistently at the edges, not just in the happy path. Treating observability as a core requirement rather than something you add later.
The harness is stateful in a way models are not. It has to manage context size, cost, latency, and correctness simultaneously. Getting that wrong is expensive, in tokens and in trust. Getting it right compounds.
The model vendors want you to think model selection is the primary question. It is easier to benchmark models than to evaluate harness architecture. But the engineers I respect in this space are mostly not asking which model to use. They are asking how to decompose the problem, how to verify outputs cheaply, how to keep context cost under control as workflows get longer.
Those questions do not have benchmark answers. They require engineering judgement.
The diagram I kept returning to in the talk is the simplest one. Model, harness, context. The model is replaceable. The context is ephemeral. The harness is the only thing that persists and reflects the engineering work your team has actually done.
That is where the moat is.
I gave this talk at the AWS Community Meetup in Sydney in June 2026. Slides below if you want the full version.