What is an AI harness?

The problem a harness solves

Most organisations do not have an AI problem. They have an AI sprawl problem. A team in finance wires a model into a spreadsheet, someone in operations builds a chatbot, a data team runs retrieval experiments, and none of it shares a permission model, an evaluation method, or a definition of what the business actually means by a customer.

Each of those efforts works in isolation and none of them compounds. The second use case costs as much to build as the first. Nothing learned in one is available to the next. When something goes wrong, no one can say which component produced the output or whether it was allowed to.

What sits inside a harness

A harness is not one piece of software. It is the set of shared layers that every AI use case in the organisation draws on, built once and governed centrally.

Model and tool routing

Which model handles which step, which tools it may call, and how requests fall back when a model is slow, unavailable, or the wrong fit for the task.

Business context

The organisation's own definitions, data contracts, and domain vocabulary, expressed once so every agent inherits the same meaning of a customer, an invoice, or an active account.

Permissions and identity

What each agent may read and write, acting on behalf of which user, under which approvals — enforced by the platform rather than reimplemented per use case.

Evaluation and feedback

Shared harnesses for measuring output quality, regression suites that run when prompts or models change, and a route for human corrections to feed back into the system.

Observability and audit

A record of what ran, on whose behalf, against which inputs, producing which output — the thing that makes an AI programme answerable to a risk review.

What an AI harness is not

It is not a chatbot, and it is not a model subscription. Buying seats for a frontier model gives individuals a better tool; it does not give the organisation a capability. The difference shows up the moment you need a workflow to run unattended, touch a system of record, or survive an audit.

It is also not a framework you install. The routing, the context layer, and the permission model all encode decisions specific to your business. Frameworks help you build a harness; they are not one.

When an organisation needs one

The signal is usually the third use case. The first two can be built directly and shipped. By the third, the cost of not having shared context, evaluation, and permissions becomes visible: the same integration work is being repeated, and no one can answer governance questions consistently across the three.

The other common trigger is a use case that touches money, identity, or a regulated process — where 'mostly correct' stops being acceptable and the verification layer has to be engineered rather than assumed.