The Model Reasons. The Harness Decides What Matters.
What the Claude Code architecture reveals about institutional AI governance.
Most organisations that deployed an AI tool this year spent the majority of their effort on one question: which model. A smaller number extended that conversation to which tools the model should have access to. Almost none asked the question that actually determines whether the deployment can be trusted.
What is built around the model?
For most institutions, the harness, the permission infrastructure, the boundary enforcement, the session governance, and the recovery architecture, is simply not part of the deployment conversation. The investment went into the reasoning layer. The governance layer followed later, partially, or not at all. A system deployed that way carries a governance gap that senior leadership has not priced.
What a harness is and why it matters
In architecture, a harness is the infrastructure of constraint surrounding a capable component. It determines what that component is permitted to do, under what conditions, and what happens when it exceeds its boundary. The harness does not replace the component’s capability. It governs the conditions under which that capability is trusted to operate.
This concept is not new. Regulated industries have applied it for decades. A payments authorisation system has a capable decision engine at its core. Around it sits the fraud detection layer, the velocity checks, the decline rules, and the exception handling. That surrounding infrastructure is the harness. Remove it and the decision engine still works. It just cannot be trusted to work safely, at scale, under pressure.
The same design philosophy governs the AWS Nitro System, where even the hypervisor cannot initiate outbound network connections, and nuclear reactor control systems, where the default state of the control rods is shutdown and sustained operation requires continuous active permission.
The principle applies directly to AI systems. A model can reason. It can generate code, produce analysis, and operate tools. The question that determines whether it can be deployed responsibly has less to do with how well it reasons and more to do with what surrounds it: what it is permitted to do, what it is prevented from doing alone, and what the system does when the model’s judgement is wrong.
Most current AI governance conversations focus on model selection and tool selection. The harness, the constraint architecture that determines whether the deployment is trustworthy, receives a fraction of the attention and a fraction of the investment. That is the gap this post examines.
The Claude Code Architecture
Researchers at MBZUAI published a source-level analysis of Claude Code in April 2026, examining every line of its TypeScript codebase. Their finding is structural, not evaluative.
The core of the system is a while-loop. It assembles context, calls the model, dispatches tools, evaluates results, and repeats. That loop, the reasoning engine, accounts for 1.6% of the codebase.
The remaining 98.4% is the harness.
Not supporting features. Not configuration files. First-class runtime infrastructure, designed before the model loop that sits inside it. Five subsystems, each a deliberate architectural commitment.
The permission system. Seven operating modes. The default state is deny. Every tool call routes through a permission gate before execution. The strictest rule in the evaluation chain wins. An ML-based classifier handles ambiguous cases. A four-stage authorisation pipeline, pre-filter, PreToolUse hook, rule evaluation, and permission handler, processes every action before the model can execute it. The model never directly touches the filesystem, the shell, or the network. It reasons and proposes. The harness decides what it is permitted to do.
Context management. A five-stage compaction pipeline treats the token budget as a hard infrastructure constraint. Budget reduction, snip, microcompact, context collapse, and auto-compact run continuously. Context is managed as a scarce resource with engineering discipline comparable to memory management in an operating system.
Subagent delegation and isolation. When delegated work spins up a subagent, it does not inherit the trust established in the parent session. It receives its own context window and its own permission context, rebuilt from scratch. The architecture treats inherited trust as a risk. Session permissions are not restored on resume for the same reason. The cost of re-establishing trust is accepted deliberately, because stale trust decisions are more dangerous than the friction of replacing them.
Extensibility with risk boundaries. Four mechanisms: MCP servers, plugins, skills, and hooks. Each carries different context and risk budgets. The extensibility is graduated, with PreToolUse and PostToolUse hooks wrapping every external call.
Session persistence. An append-only transcript model designed for auditability from the first write. Every action, every tool call, every subagent sidechain is recorded in a separate, replayable transcript. The storage model was designed as the foundation for institutional trust: what the system did is always recoverable.
Source: arXiv:2604.14228v1. MBZUAI. April 2026.
The researchers describe this design in precise terms: model judgement operating within a deterministic harness. The model reasons. The harness enforces. Probabilistic guidance, what the system is asked to do, lives in configuration files. Deterministic enforcement, what the system is actually permitted to do at execution time, lives in the permission architecture. Conflating these two layers is the governance mistake most institutions are currently making.
Why this architecture decision produced a different outcome
It is worth pausing on what this architecture made possible, because it reveals why the harness question matters beyond governance.
Claude, the model, existed first. Anthropic built the reasoning engine over several years. When they then built Claude Code, a product designed to operate autonomously on a developer’s codebase, writing code, running commands, and modifying files, they faced a decision that every institution deploying AI faces. How much authority to give the model. And how to make that authority governable.
They chose to encode the governance within the architecture itself. Not as a policy document alongside the product. Not as a review committee that approves deployments. As the structure of the product. Deny-first defaults. Seven permission modes. Independent enforcement layers. Trust rebuilt from scratch every session. The model’s capability was not reduced. The conditions under which that capability could execute were made explicit, deterministic, and auditable.
The result is instructive for any technology leader considering what trustworthy AI deployment looks like. Claude Code reached a billion dollars in annualised revenue within six months of its public launch in May 2025. By February 2026, that figure had reached two and a half billion. It now accounts for approximately four percent of all public GitHub commits worldwide. The Pragmatic Engineer survey of fifteen thousand developers in February 2026 found it was the most-used AI coding tool, with a 46% “most loved” rating. Enterprise subscriptions quadrupled since the start of 2026. Seventy percent of Fortune 100 companies now use Claude.
That adoption was driven by trust, not benchmark supremacy. Consumers trusted it to operate on their personal codebases. Enterprises trusted it to operate within regulated environments. The architecture earned that trust. The deny-first permission system, the subagent isolation, the append-only auditability, the session-scoped trust that is never inherited. These governance structures are the reason the product could be deployed at all in environments where the consequence of failure is real.
The lesson for institutions is simpler than the architecture: recognise the sequencing. The harness was not added after the product succeeded. The harness is why the product succeeded. That is a fundamentally different investment thesis from the one most organisations are operating under, where capability is deployed first and governance is funded from whatever budget remains.
What fills the space when the harness is absent
Early in my career, I saw the consequences of a platform where multiple channel applications shared a single database.
The boundary existed in the architecture diagram. Every domain had a defined scope. Every team understood, in principle, where their ownership ended. What had never been built was any infrastructure to enforce that boundary at runtime. No permission model specifying what each application could read, write, or modify under what conditions. No governance over what crossed the seam between domains. No recovery path when behaviour leaked from one channel into another domain’s data.
What I observed was predictable in hindsight. Behaviour filled the space where governance had not been built. Teams optimised for the shared resource, not for their domain. Changes in one channel produced unexpected results in another. The coupling traced back to a foundation design failure. No boundary enforcement. No guardrails. No constraint architecture governing what each part of the system was permitted to do alone.
The applications were capable. That was never the problem. Capability had been deployed without the infrastructure that determines what capability is allowed to do. Ownership existed on paper. Trust was inherited by default. The boundary declared in the diagram and the boundary enforced at runtime were two different things, and the gap between them is where every failure I witnessed originated.
The Claude Code architecture is the structural answer to exactly this failure mode. Replace the channel applications with AI agents. Replace the shared database with a developer’s codebase. The deny-first permission system, the subagent isolation, the session-scoped trust: these are precisely the harness components that were absent in the shared database system. The foundation design failure I saw play out in a pre-AI world is now being repeated at AI speed, in organisations deploying capable models without the constraint infrastructure to govern them.
The question that has not been asked
The AI governance conversation in most institutions is running well behind the deployment conversation. Frameworks exist. Committees meet. Policies are drafted. The question largely absent from those conversations is whether any of it translates into deterministic enforcement at the point of execution.
A governance document tells the model what it should do. A permission architecture tells the system what the model is allowed to do, regardless of what the model decides. One is probabilistic guidance. The other is structural constraint. Most organisations have built the first and described it as the second.
The MBZUAI researchers identified this as a recurring design choice, not an implementation detail. The harness is what makes the model trustworthy at all.
For CIOs, CTOs, and the executives who approve AI investment, the question worth asking goes beyond which model the organisation deployed. The question is what surrounds it. What the model is permitted to do. What happens when an agent carries permissions beyond its scope. Whether the recovery architecture exists before it is needed. Most institutions cannot answer those questions with precision today. Governance architecture gaps do not stay invisible. They surface at the moment the system is most under pressure, and someone is asking what happened.
The decision that precedes deployment
Claude, the model, was built first. When Anthropic then built a product around it for consumers and enterprises, they made the governance architecture the product’s structural foundation, not its compliance layer. The model loop sits inside the harness. The decision about what the system is not permitted to do alone preceded the decision about what it could be trusted to do. That sequencing is the investment decision, not the model selection.
Most institutions have the sequencing reversed. Capability is deployed first. Governance follows later, partially, and under pressure. Retrofitting a deny-first permission architecture onto a system already running in allow-first mode becomes a risk event, with a timeline determined by when the gap becomes visible, not by when the organisation chooses to close it.
Capability stopped being the scarce resource some time ago. The question worth asking is whether your institution has built the infrastructure that determines what its AI is trusted to do, before it is trusted to do it.
Trust in what a system can do begins with what it cannot do alone.
If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.