The missing layer in every Claude Code rollout

Two questions that turn out to be one

Over the last few months I've been asked two things, again and again.

The first comes from operations and IT leaders: which harness should we pick? A manufacturing business wanted help evaluating agent harnesses — Claude Code against the alternatives — before committing.

The second comes from engineering leaders: can you set up Claude Code for our team? Sometimes for the software engineers, sometimes for the whole company.

They sound like different jobs. One is a procurement decision, the other an implementation. But underneath, they are the same question — and answering the surface version of either one is how rollouts quietly stall.

Three layers, and you only own one

Every agent deployment has three layers.

The model is rented. It changes every few months, and you have no say in how.

The harness — Claude Code, Codex, Copilot's agent mode, Antigravity — is the software that lets the model read files, run commands and do work. Harnesses are converging fast. Each one now reads a plain instruction file on arrival, runs sub-agents, calls external tools, and lets you intercept its actions. They are more alike every quarter.

The operating layer is the one nobody ships. It is the written-down account of how your organisation works: what you sell, who decides, what agents may do alone, what must go to a person, and what you've learned. No vendor can sell it to you, because it is yours.

Which is why “which harness?” is the wrong first question. Pick a harness without an operating layer and you get capable agents with no idea how your organisation works. Write the operating layer first, and the harness becomes swappable — and far easier to evaluate.

What the operating layer actually is

In practice it is a small set of plain documents that every agent reads before it does anything. I run my own practice on one, every day, across dozens of agents. It comes down to four sheets. I've put a working version on GitHub — the four sheets, the guardrails and a worked example — so you can start from files rather than a blank page.

The company brain holds who you are and what you know — customers, constraints, hard-won lessons. Without it, every person re-explains the company to the agent at the start of every session, and every explanation is slightly different.

The operating rules hold decision authority: what an agent may do alone, what needs a person, and who that person is. This is where most rollouts are silent, and where most of the risk lives.

The bets register holds what you're trying right now, who owns each bet and how you'll know if it worked. It stops agents — and people — from optimising for the wrong thing.

The learning loop is how the layer improves. When an agent gets the same thing wrong twice, the fix becomes a rule. When a rule goes stale, it retires. The layer has a size cap, because memory that only ever grows eventually poisons every session it's loaded into.

This is memory architecture, not documentation. The question isn't “have we written it down?” but “what does every agent know on arrival, what does it know only for this project, and what does it forget when the session ends?”

One more distinction matters more than any other.

Some rules are preferences: tone, priorities, context. Those live in prose, and the agent weighs them. Others are non-negotiable: never touch production, never send anything externally, never approve your own work. Those should not live in a document the agent is asked to respect. They should be enforced by the harness itself, so a violation is blocked, not regretted. Every serious harness now lets you intercept an action before it happens. That is governance as code, and it is the difference between a policy and a guardrail.

Engineering teams need more than a licence

For software engineers, the operating layer has to sit inside the practices you already trust. The agent works in a branch. Its changes go through the same review as anyone else's. Tests run before anything is accepted. Every change is small enough to read, attributed to a person, and reversible.

The rule that holds it together is simple: an agent never approves its own work. Someone reviews, someone accepts, and that someone is named. Agents make that review cheaper and faster; they never become the person accountable for it.

Teams that skip this get a burst of speed followed by a trust collapse — one bad change nobody can explain, and the licence quietly goes unused.

The part nobody talks about: everyone else

Here is what surprised me. The most interesting demand isn't coming from engineers. It's coming from everyone else.

Product managers, analysts, sales and operations teams are already building prototypes with AI — dashboards, triage tools, small internal apps. And the question I now hear from leadership is: everyone's building something. How do I know which ideas are any good?

The answer is to borrow the engineering principle without the engineering tooling. Software teams solved this decades ago: you propose a change, someone reviews it against agreed criteria, and a named person accepts it. Nobody in sales needs to see any of that machinery. They need the principle.

Anyone can have an idea and prototype it with an agent, inside a sandbox. The prototype becomes a short proposal: what it is, who it's for, what evidence it has. The proposal is graded against a published rubric. The machine does the first pass, and its score is advisory. Then one named owner decides.

Crucially, accepted means promoted, not deployed. A winning prototype earns a place on the backlog and a proper build. It never goes straight into production. That single rule is what makes it safe to let everyone experiment.

Two details make the rubric work. First, it is published, so people know what good looks like before they start building. Second, missing evidence is flagged as a question, not scored as a failure — an idea with no data yet may simply need a week of collecting it.

Whatever is learned on the way — why ideas got promoted, why they got parked — feeds back into the operating layer. The organisation gets a little better at choosing every cycle.

How to build it: four moves

None of this starts with a tool. It starts with how your work actually moves.

This is weeks of work, not quarters. And because the operating layer is written in plain language, it outlives any particular tool.

Back to the harness question

Once the operating layer exists, choosing a harness stops being a debate and becomes a test. Give each candidate your operating layer and a set of your own real tasks, and score them on the things that matter to you.

Does it read your rules on arrival? Can it enforce your guardrails in code, not just in prose? Does it leave a record you can review? Does it fit the review process you already run? And what does it cost at your actual usage?

The harnesses will keep converging, and the models will keep changing underneath them. Write the layer once, in plain language, and it moves with you — whichever you choose.

The short version

Start with the files, not a workshop.