Is Harness The Hedge?

Hello, and welcome to Offcuts: a podcast and newsletter about AI and commerce. Read and listened to by people at Stripe, Shopify, Dr. Martens, Loewe, H&M, and Mercedes-AMG F1. Brought to you by the team at ROIROI - engineering, design, performance marketing and AI for consumer brands.

We ran our first Claude for Commerce webinar a couple of weeks ago. One question kept coming up in different forms across the session: what happens if the model you have built everything around disappears, gets restricted, or becomes unaffordable?

This edition is my attempt to answer this question.

So. Fable 5 is back. Let the token burning recommence. But let’s not forget it was restricted for users outside the USA. The decision was not commercial. It came from the US administration, as part of a broader set of export and technology controls shaping which AI products can operate where. Goldman Sachs then barred its Hong Kong bankers from accessing Claude. JPMorgan followed days later with the same restriction for its Hong Kong staff. All three trace to the same geopolitical pressure point: US-China tension playing out through Hong Kong’s unique regulatory position.

But filing this under geopolitics and moving on lets most operators off the hook. The trigger here was political. The next trigger might be a pricing change that makes your current usage uneconomical, a model update that quietly degrades performance on your specific workflows, or a provider shifting focus away from your use case. The structural exposure is the same regardless of what pulls it.

Every brand reading this has made, knowingly or not, a significant bet on a single AI lab continuing to price, distribute, and develop its product in a way that suits them. Goldman Sachs and JPMorgan found out what happens when that bet gets called.

The answer to this is not to avoid Claude, or to run every model simultaneously, or to treat AI strategy as inherently too risky to pursue.

The answer is to build a harness.

This one is for ​Heads of Growth, Marketing Directors, Heads of Ecommerce and founders working in ecommerce or retail brands who have started with Claude and want to go further.

Save your seat →

Most people building with AI have never been given a clean term for the layer that sits around the model itself. The harness is that layer. A simple framing: Agent = Model + Harness. The model is the reasoning engine. The harness is everything else.

To dive deeper, we can split the harness into two halves. Guides are the feedforward controls, the rules, instructions, and context that steer the model before it acts. Sensors are the feedback controls, the checks, validators, and review loops that catch problems after it acts. You need both. Feedback without guides and the model keeps making the same mistakes. Guides without feedback and you never find out whether your rules are actually working.

In practice, the guides side of a commerce brand’s harness looks like this. A portable instructions file that defines how the model should behave, what it should prioritise, and what it should never do. Externalised business context, your catalogue, your customer segments, your processes, your tone of voice, stored as structured documents outside any platform’s memory rather than accumulated inside a conversation history. And deterministic logic kept outside the model entirely: your margin calculations, your discount rules, your replenishment thresholds running in code that the model calls as a tool rather than attempts to compute itself. The model’s job is to reason and communicate. The arithmetic belongs somewhere more reliable.

The sensors side looks like this. Tool connections that retrieve live data rather than relying on numbers pasted into a prompt that will be wrong by tomorrow. MCP, the Model Context Protocol now supported across providers, is the clearest path here: the connection to your ecommerce platform, your ERP, your marketing suite is built once and any model that speaks the protocol can use it. And a human review loop, not everywhere, but at the points where the output has commercial consequences before it is acted on. Full automation with no human checking is a trap regardless of which model sits behind it.

The distinction matters because my sense is that most brands have drifted into building inside the model rather than around it. Not by design, but because the native tools are good and the path of least resistance is to use them. Instructions accumulate inside a Claude Project. Context builds up across months of conversation history. Workflows quietly start assuming specific Claude behaviours. The model stops being a component and starts being the system.

Adam, Operations Lead at Hylo Athletics, got asked about this on our Claude for Commerce webinar, this was his respons: “I’ll be honest, we don’t have a great answer for right now.” But what Hylo has done in practice points in the right direction. Instructions files kept in formats that travel. Business context stored outside any single platform. Claude used project by project rather than as the infrastructure everything depends on. “Should Anthropic suddenly change their complete strategy,” Adam said, “we can make that change. It’s obviously going to be uncomfortable, but we can make it.”

That is probably the most realistic position most brands can aim for right now.

A properly built harness has five components. Understanding each one is the starting point for building AI that does not collapse when something outside your control changes.

The first is portable instructions. Every AI build depends on instructions: how the model should behave, what it should prioritise, what tone it should use, what it should never do. These instructions should exist as standalone documents that you own, outside any platform’s memory. A one-page instructions file you can paste into any model in five minutes is a harness asset. A set of preferences that have built up inside a single platform’s project memory over months is a liability. If you cannot locate your instructions as a file right now, you have a portability problem.

The second is externalised business context. The model needs to understand your business to be useful to it: your catalogue, your customer segments, your processes, your tone of voice, your product rules. This context should not live inside conversations. It should exist as structured documents, updated regularly, that you load into any AI session rather than rebuild from scratch each time. Think of it as your company manual for the model. The brands that have built this properly can onboard a new AI tool in an afternoon. The ones that have not spend weeks re-explaining context they already explained somewhere else.

The third is tool connections over in-prompt data. When you paste your current stock levels into a prompt, you are giving the model a number that will be wrong by tomorrow. When the model connects to your inventory via a structured tool call, it retrieves the current state every time it needs it. MCP is the clearest path to this for most brands. It allows a model to call your systems directly without the data having to be manually copied into each conversation. The connection is built once. Every model that speaks MCP can use it.

The fourth is logic outside the model. AI models are not calculators. Asking a model to compute your contribution margin, apply your discount rules, or run your replenishment logic introduces unnecessary variability. These calculations should happen in deterministic code that the model calls as a tool. The model decides what to do and communicates it clearly. The maths happens somewhere more reliable.

The fifth is a human review loop. The right question is not whether to include a human in the loop but where. For low-stakes, high-volume tasks, the review can be lightweight and periodic. For decisions with commercial consequences, the review should happen before the output is acted on. Building this in from the start is easier than retrofitting it after something has gone wrong.

When these components are in place, swapping the model becomes a contained operation rather than a rebuilding exercise. The instructions travel with you. The business context is in your files. The tool connections speak a protocol that multiple models support. The logic runs outside the model anyway. And the review loop applies regardless of which model produced the output.

This is the practical payoff that most pieces about model dependency miss. Build the harness because it makes your AI reliable and production-ready. Model independence is what you get as a side effect. Most brands have demos. The harness is what turns them into something that runs at the fiftieth attempt as reliably as the first.

In practice, swapping the model looks something like this. You take your instructions file and load it into the new platform. You bring your business context documents across. Your MCP connections, if built properly, reconnect without rebuilding from scratch. You run a sample of your usual workflows through the new model and check the outputs against what you would expect. You adjust the instructions where the behaviour differs. That last step is unavoidable: Claude and Gemini will not respond identically to the same instructions, and some tuning is always needed. But tuning a portable instructions file is an afternoon. Rebuilding context that existed only inside one platform’s memory, if it is even recoverable, is weeks.

The practical test for whether your harness is working is straightforward. Pick one workflow you run regularly. Try running it in a different model using only the assets you own: your instructions file, your context documents, your tool connections. If it mostly works, your harness is doing its job. If it falls apart, you have found exactly the gap that needs closing, and you have found it on your own terms rather than under pressure.

Running two models in parallel occasionally, Claude for some tasks and Gemini or another provider for others, is the most reliable way to surface those gaps before something forces your hand. Dependency builds up quietly. The workflows that seemed model-agnostic when you built them sometimes turn out to rely on specific behaviours you did not notice you were relying on. Parallel use makes that visible. A forced migration makes it expensive.

You might be asking, why would I listen to a luddite like you? Understandable. So in order to add some real world technical depth to the question of harness, I asked our engineering team whether there is a major risk in building an entire AI strategy around one model, and if so, how do you actually mitigate it?

Szymon, one of our senior engineers, was direct: “We hear a lot about a fully automated AI development process, but relying entirely on it right now is a trap. We see companies like Uber burning through massive amounts of tokens, which I strongly believe is the direct result of forcing full automation too early or simply a lack of foundational engineering knowledge in how to orchestrate these models efficiently.” His own systems are built with a decoupled AI layer, meaning the underlying model can be swapped without the rest of the system noticing. He does not see vendor lock-in as a critical risk precisely because the human oversight and architectural decisions sit above the model, not inside it.

Michal, our CTO’s, approach is more personal but points at the same thing. “Models, agents, and tools should be easily replaceable, but it’s often better to keep skills and knowledge organised outside as simple text files. If, in the worst case, Anthropic doesn’t work, you can always switch to other alternatives or even use local models.” He summarises each day as Obsidian notes, capturing conversations, decisions, and updates outside any AI platform. He also runs two agents in parallel as standard practice, Claude and Gemini, specifically to avoid dependency building up unnoticed.

Piotr, another senior engineer, landed on the simplest framing: “All of the main AI agents offer similar functionality. We can build a flow that is kind of vendor agnostic. The most important thing is understanding what we can do and how to customise that for a use case we are solving and a reality we are in.”

Three engineers, three different framings, the same underlying position. The intelligence should live in the harness. The model is what executes it.

There is a version of this that ends with a reassurance: build the harness and you will be fine. That is mostly true but slightly wrong. The harness is the right architecture. Goldman Sachs and JPMorgan are the reminder that the conditions under which you build AI are not static, and that the brands which treated the model as the product rather than a component of a larger system are the ones that will feel it most when something changes.

The good news is that none of this requires starting over. It requires auditing what you have, identifying what is trapped inside a single platform, and moving it out systematically. Most brands are closer than they think to a portable AI architecture. They just have not checked recently.

Hi, I’m Tim. I’m the CEO of ROIROI, a technology and performance agency. We connect engineering, design, paid media and AI for consumer brands. I also host Offcuts, a weekly podcast and newsletter exploring the same themes. Outside of work, I’m usually cycling, swimming, running or in a sauna-cold-plunge trying to recover from all three.