The model is not what you own. Access to Fable, Astra, or the mysterious Argon or whatever runs at the top of the benchmark leaderboard this month is available to anyone with a credit card and an internet connection, which means it is available to your competitors on the same terms it is available to you. What you own, if you build it deliberately, is the layer between the model and your work: the rules, the context, the workflow knowledge, and the interface that shape generic AI output into something that understands how your firm actually operates. That layer has a name. The Harness Engineering framework from this week's source material calls it a harness, and the argument for building one is worth working through carefully, because it reframes the AI investment question in a way that most vendor pitches are structured to prevent you from asking.

What a Harness Is and Why the Distinction Matters

A harness, as the framework defines it, is a domain-specific wrapper around an existing AI tool that forces the model's output to conform to your workflow rather than to the model's general-purpose defaults. The base harness is something like Claude Code: a tool that already encodes a significant amount of capability and behavior before you touch it. The domain harness is what you build on top of that, and it is where the real differentiation lives, because it encodes knowledge that no vendor can replicate: your onboarding sequence, your proposal structure, your project naming conventions, the way your firm distinguishes a preliminary estimate from a design-phase budget.

The McKinsey maker/taker/shaper taxonomy that the framework borrows is useful here, not because McKinsey invented the categories but because the categories are genuinely distinct in practice. Makers build the models themselves, which is OpenAI, Anthropic, and almost no one else. Takers use AI the way the vendor built it, which is fast and requires no engineering, but produces no differentiation because every competitor has the same access on the same terms. Shapers build domain-specific layers on top of existing models, which is where the work is harder but where the advantage actually compounds. For a professional services firm, the shaper posture is almost certainly the right one, and the harness is the mechanism for getting there.

The reason this matters practically is that most AI investment conversations at services firms are happening at the taker level without anyone naming it as such. A firm licenses an AI assistant embedded in its ERP, a principal enables a summarization feature in the project management tool, a PM starts pasting spec sections into a browser tab to get first-pass summaries. All of that is taker behavior, and none of it is wrong, but none of it builds anything the firm retains when the person who figured out the good prompts leaves, or when the vendor changes the feature in the next release.

The Four Layers, in Order

The framework organizes harness engineering into four layers, and the order is not arbitrary. Each layer depends on the one before it.

The first layer is understanding the foundation: why harnesses matter and what the base harness you are building on top of already gives you. This is mostly a thinking exercise, not a technical one, and the most important output of it is a clear sense of what you do not need to rebuild. The video is direct on this point: 90 to 95 percent of what most people need already exists in the base harness, and building from scratch when that is true wastes the one resource a mid-market firm has less of than a large enterprise: time.

The second layer is selecting the domain, which is the decision that determines whether the harness you build will actually be useful or will end up as a clever prototype that nobody opens twice. The guidance here resists the two failure modes that come up most often in practice: building a harness that tries to do everything, and getting stuck because you cannot decide what to focus on. The answer to both is the same: pick the one workflow where you are losing the most time to translation work, where someone is regularly re-explaining context to the model, or where the output quality is inconsistent because the model does not know enough about how your firm works.

For a professional services firm, the natural candidates are client proposal generation, project status summarization, and internal knowledge retrieval, particularly the "where did we document that" problem that plagues any firm that has been operating for more than a few years. The framework's example of an internal knowledge harness, one that restricts the model to answering only from context you supply rather than drawing on its training data, is a useful starting point precisely because it is self-contained, immediately testable, and directly addresses the trust problem that makes AI outputs unreliable in client-facing contexts.

The third layer is building the harness, which the framework breaks into a set of concrete components: rules (direct behavioral instructions), skills (reusable capabilities you build once and call when needed), MCP servers (connections to external tools), context (the knowledge specific to your firm and domain), hooks (behavior that triggers automatically), sub-agents (specialized assistants that handle discrete subtasks), and feedback mechanisms that allow the harness to improve over time. The list sounds long, and it is, but the framework's second rule keeps it manageable: keep it simple. Build the simplest version that solves the actual problem end to end, verify that it works, and extend it from there. A harness that a practitioner uses every day because it is fast and reliable is worth more than an elaborate architecture that requires a developer to maintain.

The fourth layer is the interface, and this is where the framework makes its most counterintuitive argument: the interface is the most neglected and most important layer of the four. The reasoning is straightforward once you hear it. A sophisticated ruleset, carefully curated context, and well-designed skills are operationally inert if the interface that exposes them is awkward to use, requires context switching, or adds friction at the moment a practitioner needs output quickly. The gap between a tool that gets used and a tool that gets abandoned is almost always an interface problem, not a capability problem. The model was probably fine; the experience of using it was not.

The practical argument for a local web-based interface is worth noting specifically because it addresses a cost concern that comes up early in most firms' conversations about building custom tooling. If the interface runs locally and connects to a Claude subscription the practitioner already pays for, the firm avoids paying API credits for every interaction, which changes the economics of iteration meaningfully. The ability to rapidly change the interface during a working session, directly, without a development cycle, is what makes it realistic for a non-developer to own and improve the harness over time rather than filing requests and waiting.

The Karpathy Curve and What It Actually Means for a Services Firm

The framework closes by invoking what it calls the Karpathy curve: the observation that the least interesting part of the AI stack is the model itself, and that the real differentiating work is data curation, task decomposition, and organizational adaptation. This is not a minor philosophical point. It is a restatement of where the work actually is, and it deserves to sit in front of any firm that has spent the last 18 months trying to pick the right model rather than figuring out what to do with the one it already has access to.

For a professional services firm, data curation means knowing which project records are clean enough to feed into a knowledge harness, which proposal archives are worth indexing, and which process documentation is current versus aspirational. Task decomposition means breaking a complex workflow like proposal generation into discrete steps that a model can handle reliably rather than asking it to produce a finished document in one pass and then editing around the model's assumptions. Organizational adaptation means building the feedback loop so that when the harness produces a wrong or incomplete output, that failure becomes a revision to the rules or context rather than a private frustration that the practitioner absorbs and forgets.

A firm that is good at those three things will get more value from a mid-tier model than a competitor will get from a premium one, because the advantage is in the harness, not the model, and the harness compounds in ways that a license does not.

Where to Start

If the harness concept is new to your firm, the practical entry point is narrower than the framework's full scope suggests. Pick one workflow, the most painful one, where someone is currently doing repetitive translation work between raw information and a useful output. Build the simplest harness that addresses that one workflow: a ruleset that constrains the model's behavior, context drawn from your actual documents and past work, and an interface that takes less than ten seconds to open and use. Run it for 30 days, collect the failure cases, and revise the rules and context based on what actually went wrong.

After you have one harness that a practitioner uses without being reminded to, ask whether the interface is genuinely the easiest way to reach it, or whether it still requires more steps than the practitioner's current workaround. Ask whether the context feeding the harness is current, or whether it reflects how the firm worked two years ago. Ask whether the skills you built in the first version cover the 80 percent of cases that show up repeatedly, or whether the harness is still being used as a general-purpose model because the skills do not quite match the real workflow. Those three questions will tell you more about where to invest next than any vendor roadmap will.