Harness engineering for the enterprise: tools, sandboxes, and the validator that has a name.

By Connie Yang, Co-founder and CEO, Nth AI. Published 2026-06-24.

The model gets the headlines. The harness decides whether it ships. Harness engineering is the layer one step below the loop: the tools an agent can reach, the sandbox it runs inside, and the checks that grade its work. On a laptop the final check is a linter. In the enterprise it has a name, a role, and a signature. Here is what changes when the harness has to be governed.

Last week I wrote that the leverage in working with AI has moved from the prompt to the loop, and that the enterprise version of the loop is the governed one. A few people wrote back with the same question. Fine, but what is actually inside the loop? What is the agent allowed to touch while it runs, and who decides? That question has a name too, and it is the layer directly beneath the loop. Harness engineering.

The discourse has converged on a clean way to say it. An agent is a model plus a harness. The model is the part everyone benchmarks and argues about on launch day. The harness is everything else: the tools the agent can call, the sandbox it executes in, the validators that check its work before and after it acts. Martin Fowler's team put it plainly this year. The harness is not the agent, and it is increasingly the part that determines whether the agent is useful. The model gets the headlines. The harness decides whether it ships.

The lineage, one layer at a time

It helps to see where the harness sits. Prompt engineering is the craft of the single call. Context engineering is filling the window with the right material at the right time. Harness engineering is the scaffolding the model acts through. Loop engineering is the cycle that runs the whole thing until a stopping condition is met. Prompt, context, harness, loop. Each layer wraps the one before it. You cannot have a trustworthy loop sitting on top of an untrustworthy harness, which is exactly the order most teams discover these problems in. The loop is what fails in the demo. The harness is why.

A harness has three moving parts, and the enterprise changes all three.

Tools: the agent's reach is your liability surface

A tool is anything the agent can do to the world beyond producing text. Query a warehouse. Write a file. Call an internal API. Move money. On a laptop, the instinct is to give the agent as many tools as possible, because every tool is a new thing it can accomplish unattended. More reach, more autonomy, more magic.

In the enterprise that instinct is exactly inverted. Every tool you grant is a permission you now have to defend. The agent's reach is not a capability list, it is a liability surface. So the enterprise harness is built on least privilege, the same principle that governs human access. The agent gets the narrowest set of scoped, audited tools the task requires, each one wrapped in the permission model the rest of the company already runs on. Connectors are not open doors. They are specific, named grants that a security team can read, approve, and revoke. The question stops being what can the agent do and becomes what is this agent, in this tenant, on this task, allowed to do, and who signed off.

Sandbox: a laptop trusts its own machine, an enterprise trusts nothing

The second part of the harness is where the agent's actions actually run. On a laptop this is invisible, because the laptop trusts itself. The enterprise does not get that luxury, and the standard for what counts as safe isolation moved sharply this year.

A growing consensus in 2026 is blunt about it. For code an agent wrote itself, a shared-kernel container alone is increasingly seen as insufficient isolation. The security model that was fine for trusted, human-authored workloads looks weaker when the thing generating the code is a model that can install packages and run arbitrary scripts. The serious infrastructure has moved toward stronger boundaries: microVMs and kernel-level sandboxing, per-tenant isolation so one customer's agent can never see another's data or state, ephemeral environments that are created for a run and destroyed after it. The sandbox is not a performance detail. It is the wall that makes it safe to let an agent act at all, and in a multi-tenant enterprise product it is the wall that lets you sell to two competitors at once.

The validator that has a name

The third part is the checking, and this is where the enterprise harness diverges most sharply from the laptop one. There are two kinds of check, and the industry has gotten precise about the difference. A validator runs before the action: it checks structure, schema, types, required fields, permissions. It answers a narrow question. Is this action well-formed and allowed. A verifier runs after the action: it checks the outcome. It answers the harder question. Did the agent do the right thing.

On a laptop, both checks are usually code. The validator is a schema check, the verifier is a test suite or a linter. When the tests pass, the loop is done, and nobody had to be involved. This is the property that makes a coding agent feel like magic. The harness verifies its own work.

The enterprise breaks this in one specific place, and it is the most important sentence in this essay. In the domains we work in, the verifier cannot be a linter, because there is no test suite for whether a lease should be renewed or a portfolio rebalanced or a headcount plan approved. The only competent verifier for a consequential business decision is often a senior human who would otherwise have made the call. So the final verifier in an enterprise harness is not a function. It is a person. It has a name, a role, and a signature.

That is not a weakness of the harness. It is the design. Anthropic's own writing on evaluation lands in the same place from the other side: for the actions that matter, you do not get to skip the judgment, you have to instrument it. The named verifier at the end of the harness is what turns a model's confident output into a decision the organization is actually willing to own. And because that verifier has a name, every approval, every edit, and every rejection becomes a labeled signal you can learn from later. The accountability check and the training signal are the same act.

Laptop harness versus governed harness

Hold the two side by side and the whole difference is visible. A laptop harness maximizes the agent's tools, because reach is the goal. A governed harness minimizes them, because reach is the risk. A laptop harness runs in an environment that trusts itself. A governed harness runs in an environment that trusts nothing and isolates everyone. A laptop harness verifies with a linter and finishes silently. A governed harness verifies with a named human and records the result. None of this slows the agent down on the work that does not matter. It applies precisely and only to the actions that do, which is the entire skill.

How we build the harness at Nth AI

Nexus, the platform we build, creates the governed context an enterprise harness needs in order to operate reliably. It connects fragmented systems and encodes semantic models, ontologies, policies, permissions, and business logic rather than handing an agent raw access. Nexus automates the implementation work required to make those controls usable by agents, while keeping every consequential approval, edit, or rejection attributable to a named human.

This is why the loop I wrote about last week can be trusted to run at all. The governed loop is only as good as the harness underneath it. You cannot let an agent cycle autonomously toward a business decision unless the tools it can reach are bounded, the place it runs is isolated, and the thing that signs off at the end is a person the organization stands behind. Build that harness, and the loop on top of it earns the right to run. Skip it, and you have a very capable model wired to a liability surface, which is the most expensive kind of demo there is.

The model will keep getting better, and every launch day will make it tempting to believe the model is the product. It is not. The harness is where the agent's power is turned into something an enterprise can hold. It is where reach becomes permission, execution becomes isolation, and output becomes a decision with a name attached. That is not the unglamorous part of the work. That is the work.