What makes an enterprise agentic harness

What a harness actually is

Here is the one-sentence version, worth stealing for your next roadmap discussion:

“Everything else” is not vague. It is six questions, and every agent you ship answers all six — deliberately, or by accident.

The six questions every shipped agent answers — deliberately, or by accident.

That machinery is the harness. The model is one component inside it — the part that generates text. The other six answers are engineering, and all of them are yours.

Here is the uncomfortable part. Every agent already in production at your company has answers to all six. If nobody made those decisions explicitly, the answers are whatever fell out of the integration work — a default chunk size, an implicit retry, a stop condition that is really just a token limit.

It matters more than which model you pick

This is measurable, and it has been measured.

Hold the model constant and change only the harness. On SWE-bench Pro, Claude Opus 4.5 moves from 45.9% under one scaffold to 55.4% under another — 9.5 points from infrastructure alone. In a controlled grid across models and harnesses, harness variance measured 7.80× model variance.

And the finding that should change how you run evaluations: across nine model-pair comparisons, there were six rank reversals. Which model was “better” depended entirely on what it was wrapped in.

If your team is evaluating two vendors’ agents or two foundation models and the harnesses differ — and they always differ — you are measuring a model and an integration, and attributing the whole result to the model.

SearchUnify’s platform is built LLM-agnostic for exactly this reason: you can swap language models as they improve without rebuilding the retrieval infrastructure underneath.

That only works if the retrieval infrastructure was the real asset. Which is the argument.

Four agents. One substrate. Four different harnesses.

Below are four agents in the SearchUnify Agentic AI Suite, and the retrieval substrate they all run on. Each one gets the same treatment: what the job actually requires, what the model contributes, and what the surrounding system has to contribute for the thing to work at all.

Watch the shape of the two columns as you go. The model column is short, and it barely changes. The harness column is long, and it is different every single time.

That asymmetry is the whole argument.

AI Knowledge Agent

Knowledge capture has a brutal economics problem: the moment a case is resolved is the only moment the knowledge is fresh, and it is also the moment the agent least wants to write documentation.

So the model drafts the article from the case. That part is genuinely easy now.

Everything that makes the draft safe to publish is not the model.

The model writes a draft. The harness decides whether that draft is allowed to become knowledge.

Note what the harness is doing there. It caps how much of the case the model may even see — two fields for a title, five for the body. It scores the result against the KCS Content Standard Checklist, a deterministic rubric with named dimensions, rather than asking the model to grade its own homework. It runs a duplicate check with similarity scores and a human override. It inherits publish permissions from Salesforce or ServiceNow or Zendesk rather than inventing its own. And it forces a decision the model cannot make: is this article attached to the case as a Reference or as the Resolution?

A generic RAG template answers questions. It does not know what a duplicate article costs you three years later.

SUVA — the L1 support assistant

SUVA’s job is to resolve routine customer questions unaided, and hand over cleanly when it cannot. The model understands the question and writes the answer.

The model produces the sentence. Everything that makes it correct, permitted and escalatable is harness.

Two harness decisions on that panel deserve singling out.

The model never searches. Retrieval is federated across connected sources by the platform, under role-based access, so the model only ever reasons over content the person asking was already allowed to see. Permission enforcement happens at retrieval, not as a filter on the output. Those are very different security postures and only one of them survives an audit.

“Defines what ‘resolved’ means — and asks the question.” SUVA’s deflection metric is counted when a user clicks Yes on “Was this issue resolved?” That is self-reported confirmation, not verified resolution. Change the prompt, change the threshold, change when it fires — and your deflection number moves without the model changing at all.

AI Agent Partner

This one is interesting precisely because of what it refuses to do.

The job is to make a human support agent faster. The model summarises long case histories and drafts two things from one context: a reply the customer can read, and a technical solution the agent can act on. It shifts tone, translates, rephrases.

The model drafts. The harness decides what it saw — and refuses to let it act.

And then it stops. The drafted response goes to the clipboard. The one narrow write to the system of record is a text comment the human explicitly clicks to add.

That is not a limitation anyone should apologise for. It is a deliberate harness decision, and it is the right one for a surface where being wrong touches a customer relationship. The interesting engineering is upstream: masking PII before the agent ever sees a draft, ranking experts from actual closed-case history rather than a skills matrix, running a documented fallback chain when a resolution field is empty, and capping regeneration at four attempts while retaining the last good version.

AI Case Quality Auditor

Manual QA samples. A human reviews 2% of closed cases and extrapolates. Everyone knows the sample is biased and nobody has the headcount to fix it.

The model scores ten parameters from one to ten, detects sentiment at open and close, reads cases against uploaded compliance policy, and writes coaching.

Coverage is a plumbing property, not a model property. So is calibration.

But look at what makes the headline claim true. Reviewing every closed case is not a model capability. It is an Apex trigger that fires on every Status == Closed transition and posts to a webhook. Coverage is a plumbing property.

So is trustworthiness. Two of the ten parameters are SLA measures that come from CRM configuration, not model judgment. The weightings must sum to 100% and are set by an administrator. The scoring prompt itself is exposed as editable configuration, which means the evaluation logic is inspectable rather than buried in weights. And overriding a score requires the right permission, a mandatory written justification of at least ten characters, and the original score is retained rather than overwritten.

That last detail is the one I would put on a slide. Every override is a calibration signal. Without the justification and the retained original, you have a score. With them, you have a measurable record of where your judge and your humans disagree — which is the only way to detect drift before a quarter of scores are quietly wrong.

We have evidence for why that matters. In our own research on a public open-web benchmark, an LLM-based judge we built reached 0.70–0.72 balanced accuracy — statistically tied with a simple logistic gate using no language model at all.

An LLM judge that is never calibrated against human decisions is an expensive way to reproduce a cheap classifier. The machinery around it is what makes it worth the money.

Agentic Search — the one underneath the other four

This is the exception, and it is worth naming. Agentic Search is not a fifth peer; it is the substrate the other four inherit. Its harness is federated retrieval, permissioning and orchestration — which is precisely why the four agents above do not each need their own.

Every interaction refines retrieval routing — so the agents improve without the model changing.

The model’s contribution here is real but narrow: embeddings, cross-encoder reranking, query rewriting, generation, and acting as judge over assembled context.

Everything that makes it enterprise-grade is the harness. Ingestion gating, so low-signal content never enters the index in the first place. A context envelope built from 20+ signals — role, case history, sentiment, prior turns — assembled before anything is retrieved. Retrieval-mode selection per query: semantic, keyword, hybrid, or graph. Guardrails applied at the prompt rather than as filters on the output, which is the difference between preventing a bad answer and catching one.

And a loop controller that decides a single retrieval pass was insufficient and goes again.

And the part that matters most here: every interaction refines retrieval routing, so the agents improve while the model stays exactly the same.

You cannot share the stop condition

Four agents, four genuinely different harnesses, and a substrate underneath. So where is the shared platform?

It is real, and it is underneath all of them. One index across 100+ sources. One permissions model. One provenance and citation layer. One memory architecture, session and long-term. One observability and analytics plane. Nobody should build permission-aware federated retrieval four times.

But notice what is shared and what is not.

Go back to the six questions. Every one of these agents answers all six — and the answers diverge completely while the questions stay identical.

What it sees: two case fields for a knowledge draft. 20+ context signals for a search query. An entire closed case for a quality audit.

When it stops: when the article passes a duplicate check. When the customer says yes. When the human clicks. When the trigger fires.

Whether it was right: a content standard checklist. A self-reported resolution. A human’s clipboard decision. A ten-parameter weighted rubric with a retained original.

That is what a shared substrate actually buys you. Not one harness — one set of primitives that each harness fills in differently, and one set of components underneath so you are solving the specialisation problem rather than rebuilding connectors.

You can share the index, the permissions, the provenance, the observability.

Those are the specialisation, and they are the part that decides whether the agent is useful or merely fluent.

What it looks like when the machinery is right

The reason to care about any of this is that the difference shows up in operational numbers rather than benchmark scores.

In one enterprise knowledge programme, time to resolve fell 73%, from 30.6 days to 8.3. Time to publish fell 90%, from 22 days to 2.25 days. 1,363 articles were created in six months, with a 400% increase in contributor participation. That last number is the one that matters, because it means the workflow stopped being a tax on the agent — which is a harness outcome, not a model outcome.

In a self-service deployment, success rate rose to 77%, up from 62%. A before-and-after on the same population, which is rarer and more meaningful than an absolute figure.

In an agent-assist rollout: first-response time down 92.7%, closed case volume up 77.5%, agent productivity up 16%.

In another knowledge programme: 57% more knowledge created, 46% less time to publish, 37% more agents contributing.

None of those outcomes came from picking a better model. Every vendor in every one of those evaluations has access to the same frontier models you do.

Where this goes next

If the best harness differs per model — six rank reversals in nine model-pair comparisons — then a hand-built harness is not a one-time asset. It is something you revalidate every time you change a model underneath it.

That sounds like a burden. It is actually the roadmap.

An automatically optimised harness recently scored 76.4% on TerminalBench 2, the only auto-optimised system in a field of hand-engineered entries. If the harness is where capability lives, the harness is what you optimise — and the same tuning machinery that found the right stop condition by hand can search for it far faster.

So the direction is clear enough: harnesses that tune their own retrieval routing, their own thresholds, their own stop conditions, against real outcomes rather than a designer’s intuition. Parts of this already exist. Every interaction refining retrieval routing, so agents improve while the model stays fixed, is a small version of exactly that.

The engineering problem it creates is the interesting one:

Every mechanism that makes a harness work — the memory, the verification pass, the stop condition, the judge — is a mechanism that can be tuned. Which means the thing measuring success has to be more trustworthy than anything it measures.

Our own research says that is where the work is. Across ten optimisation runs and roughly 78 configurations on an internal corpus of 396 product documents, exactly one produced a confirmed held-out gain. On public academic retrieval benchmarks across eight domain proxies, a well-regarded reranker was significantly negative in six of eight.

Most things do not work. That is not discouraging — it is the reason the machinery that reliably tells you which ones did is worth building, and worth owning.

Part two is about how you build an evaluator you can trust enough to optimise against.