Definition

What is an AI harness?

Claude Code, Codex, Cursor. That's the harness. The vendor builds it. You still have to own the architecture and skills that sit on it. Those three are the operating environments Anthropic, OpenAI and Cursor ship and maintain with the model. What the company still writes is the architecture and the skills packages that sit on that harness: how work is structured, what the model is allowed to do, and how changes reach production. 1AYM is a consultancy that designs that layer so an organisation can use first-party vendor harnesses without being locked to one vendor's stack.

AI harness. The operating environment a model vendor builds and maintains with the model, on which an organisation places its own architecture and skills packages.

Who builds the harness

The harness is the vendor's product. Anthropic maintains Claude Code. OpenAI maintains Codex and the ChatGPT tooling around it. Cursor maintains the harness that ships with its editor. Each one is updated on the vendor's schedule, against the vendor's model, with the vendor's evaluation and support behind it.

A company that sets out to build a competing harness is taking on that maintenance load as well as the work that sits on it. The useful question is not how to replace Claude, ChatGPT or Cursor. It is what has to sit on those harnesses so the organisation can use more than one of them, and so the second team does not start from a blank page.

What sits on a harness

The vendor harness runs the model and the tools it ships with. It does not know the company's permission model, its definitions, or the way its engineers are allowed to ship. That layer is architecture and skills packages, written once and reused across the first-party harnesses the teams already have.

Architecture
How work is split, which harness is used for which job, and where the company's systems of record sit relative to the model.
Skills packages
Reusable instructions, tools and context that a vendor harness can load, so a workflow is not rewritten for each team and each tool.
Guardrails
What the model may read and write, on whose behalf, and which actions need a person.
Route to production
Review, CI and the same path every other change already takes, so AI-assisted work is not a side channel.

What an AI harness is not

It is not a product 1AYM sells, and it is not a reason to leave Claude, ChatGPT or Cursor. Those vendors already ship the harness. Replacing them with a house-built equivalent means owning the runtime as well as the work that sits on it.

It is also not a framework you install. The architecture, the skills packages and the permission model encode decisions specific to your business. Frameworks help you wire calls; they are not the environment the model vendor maintains, and they are not a substitute for it.

When the architecture matters

The first team can work directly in Claude Code, Codex or Cursor and ship. By the third, the same integrations, permissions and review rules are being rewritten, and nobody can say whether the three setups agree.

The other common trigger is work that touches money, identity or a regulated process, where the vendor harness is the right runtime and the company still has to specify what may proceed.

The cost of leaving the skills layer unowned is measurable rather than theoretical: on one platform we hold the lead architect role for, over 80% of skills had grown past the description limits before the rebuild, and re-architecting the estate cut the average cost per session by 60%. That is skills debt, priced.

Related questions

Is an AI harness the same as an agent framework?

No. An agent framework is a library for constructing agents: orchestration primitives, tool-calling conventions, memory abstractions. An AI harness is the environment the model vendor ships and maintains. A framework might run inside a harness, or beside one; it is not a substitute for Claude Code, Codex or Cursor, and it is not the architecture and skills packages the company still has to write.

Do we need to build our own harness?

Almost never. The vendors already maintain one. The work is to put architecture, skills packages, guardrails and CI on the harnesses the engineers are already using, so the company is not rewriting that layer for each tool and each team. Building the runtime first, in place of Claude, ChatGPT or Cursor, tends to produce a second maintenance burden the business never needed.

Does using a vendor harness lock us into one model provider?

It can, if the architecture and the skills are written for one tool only. Treating those as a layer that sits on the harness, rather than inside one vendor's product, means the same packages can be aimed at Claude Code, Codex or Cursor as the work requires. Model choice stays a decision; it does not become the platform.

Further

We build these systems for a living. See the engagement files for what that looks like in practice, or write to us if yours is the next one.

Last reviewed · 1AYM