Rent the model, own the harness: how to build a model-agnostic AI agent

Developers have Claude Code or Codex. Office workers have Claude Cowork or ChatGPT Work. Each of these is a harness: the scaffolding around an AI model that lets it do real work, with tools, context and rules. The person installing solar panels on a roof has nothing built for their work.

At Werk we built one for teams on the move, and our first decision was to keep it separate from the model: the model understands and proposes, and the harness decides what it reads, what it touches and what gets recorded. Four practices make that possible: talk to models through an interface of your own, have each agent ask for a level of work instead of a model, give every model the same format, and put what stays the same first. This post starts a series on how it is built. Why Werk exists is in Why we built Werk.

What the model does and what the harness does

Take a four-second voice note recorded on a roof: "Done with the Novak job." Getting that sentence recorded correctly takes two different kinds of work.

The model understands the request: a job is finished, and of the cards in front of it, Novak's is the one being named. The harness does everything else. It chooses which cards to show the model, checks that this person may change the card, records the change once even if the message is processed twice, and tells whoever needs to know.

A study published on arXiv in 2026 read the source code of eleven coding harnesses, including Claude Code, Codex, Gemini CLI, Hermes and Pi. It defines a harness as what connects a model to tools, context, safety, orchestration and extensions. Put simply: the model understands and proposes. The harness decides what it reads, what it touches and what gets recorded.

The same study found that none of the eleven harnesses studied imports a general-purpose agent framework; all of them run hand-written loops. Anthropic reached the same conclusion in Building effective agents (2024): the most successful implementations it saw did not use complex frameworks, and its advice is to start by calling model APIs directly.

How to keep the harness separate from the model

If the harness makes the decisions, it should not depend on any one model. Models improve every few months, no model is best at everything, and no cloud service is up 100% of the time, as providers report openly on their status pages, such as Anthropic's and OpenAI's. These are the four practices that keep the Novak note working whatever model is behind it.

We arrived at them by reading the code of more than fifteen open-source projects (MIT or Apache 2.0), such as Codex, Gemini CLI, OpenHands, Aider and Pi, and the documentation of others. We took ideas, not code.

The first is to talk to models through an interface of your own. No part of the harness calls a provider directly: the provider is configuration. We work with the major providers in the industry, and moving from one to another is a configuration change we measure before we make it.

The second is that each agent asks for a level of work, not a model. The agent that marks Novak's card as done does not know which model serves it. It declares the level it needs, and our battery of test cases decides, agent by agent, which model fills that slot.

The third is a format every model reads the same way. We follow what the industry recommends, for example the guides from Anthropic and OpenAI: each kind of data inside its own tag, so the model knows where each piece starts and ends. The conversation, the cards and the voice note reach any model in the same shape.

The fourth is to put what stays the same first and what changes last. Each agent's instructions are identical on every message; the Novak note is not. With the stable part first, the provider reuses what it has already processed, so the answer arrives sooner and costs less: with DeepSeek Harness, one user measured a 98% cache hit rate across 650 requests. Cache optimization deserves a post of its own, and we will write it.

What no SDK can solve for you

Agent SDKs such as the OpenAI Agents SDK and the Claude Agent SDK are a great way to start: they handle the cycle of calling the model, running tools and repeating. We studied them closely, along with LangGraph, the Vercel AI SDK, Pydantic AI and Mastra. But the hardest part of the Novak note is not in that cycle.

It is in what belongs to a team. Novak's card lives in a record that several people share, each with their own permissions. If Werk asks which of two cards was meant and the answer comes back as "the second one," that answer has to stay tied to what that person saw on screen. That depends on each product, and the good SDKs say so plainly: Mastra's documentation recommends binding an approval to the exact arguments the approver saw.

A personal agent is not enough either. Hermes Agent and OpenClaw, two of the open-source projects we read, are built for one person. Hermes says so in its security policy: it is a single-tenant personal agent, and everyone with access is equally trusted. For a personal agent, that is the right call. On a team, each person sees their own work and what the project shares, and the model never decides who sees what.

That is why we built our own harness, and why the next part of this series covers its central piece: the router, which receives the Novak note and hands it to the right agent.

The model changes, the harness stays

Because the important decisions live in the harness, the model can be chosen, compared and replaced when a better one comes along. The harness is what is yours: what each agent reads, what the code checks before touching the record, how an error is caught and how it is fixed without breaking something else.

Models will keep getting better. With a well-separated harness, each improvement reaches daily use on its own: a voice note understood better, the right card, the notice to whoever needs to know.

Teams that use Werk do not have to do anything to benefit. The harness does that work.