Your Model Is Brilliant. Your Harness Belongs to Someone Else.

15 Nov 2026 · DATAFORT

The models have got good. Embarrassingly good. Good enough that the default enterprise AI strategy has quietly become: open the chat window, paste in the task, and go and make a coffee.

And sometimes that’s fine. Sometimes it’s the right answer. But notice what’s actually happening. You’re taking the most capable reasoning engine your business has ever had access to, and running it inside a harness someone else designed, for someone else’s problem, with someone else’s assumptions about security. Then you’re surprised when the output reads like it was written for someone else.

It was.

This is the third piece in a loose series. First I argued most workflows don’t need an agent. Then I covered how to stop the ones that do from being talked into something expensive. This one is about the bit in between, the part most businesses never think about: the harness. The scaffolding around the model that decides what it sees, what it can touch, and what happens to what it says. Get that right and an average model looks brilliant. Get it wrong and a brilliant model looks like an intern on their first day.

What a harness actually is

A large language model, on its own, is a function. Text in, text out. Stateless. It doesn’t know your company exists. It can’t read a file, call an API or remember yesterday. Everything that makes it look like a colleague is built around it, and that surrounding code is the harness.

Strip any serious AI product down and you’ll find the same six parts:

• Context assembly. What goes into the prompt on each call. The system prompt, retrieved documents, conversation history, examples, the current state of the task. This is where the model learns who you are, or doesn’t.
• Tools. The functions the model can ask to call, their names, their descriptions and their parameter schemas. Badly described tools get badly used. Every time.
• Control flow. Who decides what happens next. A fixed pipeline in your code, or a loop where the model chooses until it decides it’s done.
• Policy and guardrails. The deterministic checks between “the model wants to” and “it happened”. Permissions, limits, approvals, data rules.
• Validation. Schema checks, business rules and tests on what comes back, before anything acts on it.
• Memory and state. What persists between steps and sessions, where, and who can see it.

When you use ChatGPT, Claude, Copilot or any off-the-shelf agent, all six are already built. Somebody made sensible choices about each one. Sensible for the average customer. You are not the average customer, or at least your board would prefer you weren’t.

And this isn’t a stylistic preference. It shows up in the numbers. A 2026 paper titled “Stop Comparing LLM Agents Without Disclosing the Harness” ran three models through three harnesses on a slice of the SWE-bench coding benchmark. Swapping the model within a fixed harness moved scores by 2.5 to 5 percentage points. Swapping the harness around a fixed model moved them by 8.5 to 13. Small study, and the authors say so. But the direction is hard to ignore. The bit you build around the model can matter more than which model you bought.

Generic in, generic out

In the New Luddites piece I pointed out that a model’s natural output sits near the middle of its training distribution. Competent. Plausible. Average. The harness is how you drag it off the middle and towards you. Use a generic one and nothing does the dragging.

Ask an off-the-shelf assistant to draft a proposal and you’ll get a perfectly good proposal. For a company that doesn’t exist. It doesn’t know your pricing model, the three clauses your lawyers always strike, the way you scope fixed-price work, or that you’d sooner lose the deal than promise a go-live date before discovery. It can’t know. Nobody put it in the context window.

A harness you design fixes that structurally rather than by heroic prompting:

• Retrieval over your material, not the internet. Your past proposals, your won and lost bids, your delivery playbooks, chunked and indexed so the model sees the five most relevant examples on every call.
• Your examples as few-shot anchors. Two or three of your best outputs in the prompt do more for tone and structure than a page of adjectives about “our brand voice”.
• Your tools, described in your language. A get_client_rate_card(client_id) tool backed by your actual rate card beats a model guessing day rates from what it read on Reddit.
• Your rules as validation. If every proposal must include a data processing clause, a validator checks for it and sends the draft back. You don’t hope. You check.

The model is the same one your competitors are paying for. Identical weights, identical training data, identical price per token. If all you do is type a task into it, so are your results. The only part of the stack that can carry what makes your business different is the part you build.

Your security policy is not in their harness

The generic harness has a security model. It just isn’t yours.

It doesn’t know that client data from your regulated customers mustn’t leave the UK. It doesn’t know which SharePoint folders are board-only, that contractors can’t see payroll, or that anything over £5,000 needs two signatures. It doesn’t know your data classification scheme exists. Its idea of a guardrail is a polite refusal tuned for the general public, which is lovely for stopping someone asking for a bomb recipe and useless for stopping a junior analyst pasting the M&A pipeline into a prompt.

In your own harness, policy becomes code that sits in the path of every call:

• Pre-call controls. Classify what’s about to go into the context. Redact or tokenise personal data before it reaches the model. Route sensitive workloads to a model hosted where your data residency rules allow, or a self-hosted one, and everything else to whichever API is cheapest this month.
• Tool-level authorisation. Tools run with the user’s permissions, not a god-mode service account. If Sarah can’t open the HR folder, neither can the agent working for Sarah.
• Pre-execution hooks. Every proposed tool call passes through your policy engine first. Plain Python rules, or a proper policy-as-code engine like Open Policy Agent if you’re feeling grown up. Allow, deny or escalate to a human. The model doesn’t get a vote.
• Post-call controls. Scan outputs for data that shouldn’t be leaving: account numbers, client names in the wrong context, links to unapproved domains.
• Your audit trail. Every prompt, retrieval, tool call and decision logged into your SIEM, under your retention policy, where your auditors can actually reach it. Not in a vendor’s dashboard that keeps 30 days and exports to CSV if you ask nicely.

None of this is exotic. It’s the same identity, authorisation and logging discipline you already apply to every other system that touches your data. The only new idea is that the model is one more untrusted component in the middle of it. If that sounds familiar, it’s the whole of the last article in a paragraph.

Orchestrated or agentic, it’s still your harness

“Build your own harness” doesn’t mean “build your own agent framework”. Please don’t. The world has enough of those, most of them abandoned on GitHub with 400 stars and a README promising a v2.

It means owning the decisions, whichever shape you pick.

An orchestration harness is your code walking the model through the solution, step by step. Extract, then check, then classify, then draft, then validate. Each step gets a narrow prompt, exactly the context it needs and nothing more, and a schema for the answer. It’s the deterministic spine from the first article in this series. It suits processes you can draw on a whiteboard, and that turns out to be most of them.

An agentic harness gives the model the loop, but you still design everything around the loop. Which tools exist and how they’re described. What gets loaded into context, and when. How long-running tasks get summarised so the context window doesn’t fill with junk. Where the step budget, token budget and timeout sit. Which actions need a human. The model chooses the path. You chose the map, the vehicle and the speed limit.

Both can sit on whichever foundation suits you: a framework like LangGraph, a vendor agent SDK, or a few hundred lines of plain Python calling an API. The framework is plumbing. The design is the asset.

When off-the-shelf is the right call. I’m not a zealot. If the task is genuinely generic, use the generic tool. Summarising a public report. Tidying an email. Brainstorming names for the summer party. Writing a regex you’ll test anyway. There’s nothing uniquely you to inject, no sensitive data in play and no policy to enforce, so building a harness would be expensive vanity. The test is simple. Would a bright temp with no access to your systems and no knowledge of your clients do this just as well? If yes, use the chat window. If no, the thing they’d be missing is exactly what your harness needs to provide.

Building one without boiling the ocean

The good news: a useful harness is weeks of work, not a transformation programme. Here’s the order I’d do it in.

1. Build the evals before the harness. Collect 50 to 200 real examples of the task, with what a good answer looks like, ideally drawn from your own past work. This is your test suite. Without it, every prompt change is a vibe and every model upgrade is a gamble. With it, you can measure. Boring. Essential. Skipped by almost everyone.
2. Engineer the context, not the prompt. Most of the gains live in what you put in front of the model, not in clever phrasing. The right three documents beat the whole SharePoint. Bigger context windows don’t fix this. Models still pay less attention to material buried in the middle of a long context, and you pay for every token either way. Curate ruthlessly.
3. Design tools for a reader who takes everything literally. Clear names. Descriptions that say when not to use the tool. Narrow parameters with types and limits. Return values that are short and structured, not 40KB of raw JSON for the model to wade through. A well-designed tool set is the single biggest quality lever in an agentic harness.
4. Put policy in code from day one. The hooks, the authorisation, the logging. Retrofitting security into a harness that’s already in production is like fitting a seatbelt at 70mph.
5. Keep the model swappable. Wrap model calls behind your own interface. When a cheaper or better model lands, and one lands roughly every six weeks, you run your evals against it, compare, and switch with a config change. No rewrite. Prompt caching, batching and routing simple steps to small models all live here too, and they can cut your bill dramatically without anyone noticing.

That last point is the quiet strategic win. A business that owns its harness owns the asset that compounds. The context, the tools, the evals and the policy layer get better every month. The model underneath is a commodity you can swap out. A business that rents the whole stack is rebuilding its workflows every time a vendor changes its product.

The model is rented. The harness is yours.

Here’s the uncomfortable bit for anyone whose AI strategy is a stack of enterprise chat licences. You and every one of your competitors have access to exactly the same models. Same weights. Same price. Same knowledge cut-off. The model is not your advantage, and it never will be.

What you feed it is. What you let it touch is. What you check before you trust it is. Your clients, your processes, your rules, your hard-won sense of what good looks like. None of that is in the model. All of it can be in the harness.

So by all means let the model get on with it. Just make sure it’s getting on with it inside something you designed.

Sources

• Stop Comparing LLM Agents Without Disclosing the Harness (Zhang et al., arXiv, 2026)