What a harness system is

Most platforms build AI agents. We build the environment agents run inside.

The distinction sounds subtle and is not. It is the difference between shipping an engine and shipping a vehicle with brakes, instrumentation and a driver's seat.

Borrowing the word

In engineering, a harness is a test rig. It is the surrounding apparatus that lets you run a component under controlled conditions: it feeds the inputs, observes the outputs, enforces the limits, and cuts power when something goes out of range. Software engineers know the term from test harnesses — the code around the code under test.

The essential property is that the harness is not the system under test. It does not need to be smarter than what it contains. It needs to be dependable in a way the contained system is not.

That is exactly the right relationship to a language model. The model is powerful, general and statistically unreliable in ways that cannot be fully removed. The layer around it can be narrow, explicit and auditable. Trying to make the model itself trustworthy enough to act unsupervised is the hard path. Wrapping it in something that decides what its output is allowed to become is the tractable one.

What the layers are

A harness composes six things that most stacks leave scattered:

The language model understands natural language, extracts structure from messy input, proposes actions and talks to people. This is what it is genuinely excellent at.

Tools do things: query a database, call an internal API, write a record, send a document. They are the only path from reasoning to effect, which is what makes them the natural control point.

The domain model — ontologies, classifiers, reference data — describes what exists in this business and how it relates. It is what the previous post in this series argued RAG cannot substitute for.

Policies state what is permitted: which agent may invoke which tool, against which data, on whose behalf, up to what threshold, in which jurisdiction.

Verification checks results before they become actions: does the proposal satisfy the domain constraints, do the cited sources exist and say what is claimed, is the output well-formed for the system that will consume it.

The human decides where a decision needs an owner. Not by reviewing everything — that destroys the economics — but at the points the policy marks as consequential or the verification marks as uncertain.

A harness is what makes these one execution system rather than six integration projects.

What the harness knows

Concretely, the harness holds the answers to questions that today live in prompt strings and tribal knowledge:

• which agent is allowed to perform which action, and on whose authority;
• which data a given task is allowed to touch, and which it must never see;
• which outputs must be verified before they leave, and against what;
• which rules take precedence when two of them apply;
• when a case must stop and wait for a person;
• and how a completed decision is explained afterwards — the chain of evidence, checks and approvals that produced it.

Notice that none of these are model capabilities. You cannot fine-tune your way to "this agent may not touch payroll data". It is an architectural property, and it belongs to a layer that exists whether the model behaves or not.

Why this is an operating-system-shaped problem

An operating system does not do the useful work. It arbitrates: it decides which process gets the CPU, which memory it may address, which syscalls it may make, and it isolates the failures of one process from the rest. The applications are where the value is; the OS is why the machine stays up when an application is wrong.

Agents are heading to the same place. An organisation with three agents can govern them by hand. An organisation with three hundred — built by different teams, calling each other's tools, touching overlapping data, some vendor-supplied, some assembled by a business unit last quarter — cannot. It needs a place where identity, permission, verification and audit live once, for all of them.

That place is a harness.

Where we actually are

An honest note, because this series is about architecture and it would be easy to read it as a product datasheet.

Cradle today implements the parts of this closest to execution: local model orchestration, agent routing, grounding in your own documents, a two-tier risk gate on responses, and human approval before anything leaves the perimeter — all running on your own hardware. That is a working harness in the narrow sense.

The full picture described here — a first-class policy engine, a verification runtime, domain packs and ontologies as shipped components — is the target architecture, not the current release. We describe it publicly because we would rather be judged against a stated design than market a finished system that does not exist. The architecture document keeps the two columns explicitly separated.

---

Next: The neuro-symbolic runtime — how the neural and symbolic halves actually interleave at execution time.