You rent the model. You own the harness.

If you are evaluating an AI agent for your product, the most important part is the one nobody demos. Engineers call it the harness: everything built around the model that makes it safe to rely on. The model is the part that reasons. The harness decides what the agent knows, what it is allowed to say, when it must stop, and how you know it is working.

The vocabulary is new. Mitchell Hashimoto gave it a name in early 2026 with a simple formula: an agent is a model plus a harness. The formula matters because of what it implies. You rent the model. Everyone rents the model, and increasingly they rent the same few. What you own is the harness. In most industries that makes the harness the differentiator. In regulated finance it makes the harness the product.

A bad output is a liability, not a bad experience

Consider what a wrong answer costs in different domains. A coding agent that writes a bad function costs a code review. A travel agent that books the wrong hotel costs an apology and a refund. The failure is contained, and the remedy is cheap.

Now put an agent inside a lending product and let it talk to a customer about money. A wrong answer is not a bad experience. It can be an unfair or deceptive practice, a mishandled dispute, a missed adverse action requirement, or advice the company is not licensed to give. The remedy is not an apology. It is a finding, a consent order, or a headline.

This changes the engineering problem at its root. You cannot make a probabilistic system deterministic by asking it nicely. Prompts are suggestions. Regulators do not accept suggestions as controls. So the reliability of the system cannot live in the model. It has to live in the structure around the model, which is to say the harness.

What the harness has to do

Four design problems come up in every regulated deployment we have seen or built. They sound similar. They are not.

First, what the agent knows. The knowledge base is a designed artifact, not a pile of documents. It encodes the domain, the product, the tone, and the boundaries, structured so the right piece surfaces at the right moment.

Second, what the agent may say. Knowing and saying are different permissions. An agent inside a financial product may understand a customer’s full situation and still be limited in what it can surface: licensing rules, suitability, privacy, and timing all constrain the sayable. Separating knowledge from permission is the core architectural move, and most teams skip it.

Third, when the agent must stop. Escalation is not a failure mode. It is a designed outcome with its own triggers, its own handoff, and its own audit trail. Deterministic policy layers sit above the model and do not negotiate: step-up confirmations for consequential actions, hard refusals where the law draws lines, humans where judgment is required.

Fourth, how you know it holds. Evals are the sensors of the harness. In finance the interesting metric is rarely task completion. The interesting metric is behavioral: did the customer understand, did the action match their interest, did the conversation stay inside policy under pressure. You ship with gates, not hope, and the gates measure outcomes.

Governance is load-bearing

The common failure pattern is treating all of this as a wrapper. Build the agent, then send it to compliance for review, then bolt on guardrails where the reviewers object. Wrapper thinking produces two outcomes, and both are bad. Either the launch stalls while governance retrofits what should have been foundations, or the product ships and the risk ships with it.

The alternative is to treat governance as load-bearing design. The policy layer is not a filter on the agent’s output. It is part of the architecture that determines what the agent can see, say, and do in the first place. When governance is designed in from the start, it stops being the department of no. It becomes the reason the product is allowed to exist.

There is a quieter benefit too, and it is behavioral. People can feel the difference between a system that is confident and a system that is trustworthy. An agent that knows when to hold back, confirms before consequential steps, and hands off gracefully earns something no fluent paragraph can: the willingness to come back tomorrow. In financial products, trust is retention.

The part you own

The models will keep improving, and everyone’s models will improve together. Waiting for a smarter model to solve reliability is waiting for a rising tide to build your boat.

The harness is where the durable work is. It encodes your domain, your policies, your risk appetite, and your understanding of the people you serve. It is the part that compounds, the part a competitor cannot rent, and the part a regulator can actually inspect.

We build harnesses for financial products: the knowledge architecture, the context design, the policy layers, and the evals that prove the system holds. It is careful work, and it is the work that decides whether an agent belongs in production at all.

The model is the engine. The harness is the vehicle, the brakes, and the road rules. Nobody ships an engine.