The harness is a component of an open-source AI Operating System

An agent harness is the software around a model that turns it into an agent that can do work. In Kortix, the open-source AI Operating System, the harness is one component. The grants that decide what an agent may touch sit in the project's manifest, in git. The loop inside the harness is converging across vendors. The grant surface is where companies still differ, so it is the part worth choosing on.

The definitions name the parts and leave the list unowned

Microsoft's Agent Framework documentation defines an agent harness as "the runtime scaffolding that turns a language model into an agent that can perform work". The same page lists what the scaffolding drives: model and tool calls, conversation state, and approval policies. LangChain draws the boundary wider. "A harness is every piece of code, configuration, and execution logic that isn't the model itself." Anthropic names the loop, the tools, context management and guardrails. Wikipedia calls a harness "the software infrastructure surrounding a large language model (LLM) that enables it to operate as an AI agent", and counts scoped permissions and approval tiers among its parts.

All four describe a harness that holds permissions. Microsoft composes its harness from building blocks it already had: a chat client, a pipeline, context providers, middleware. The harness applies the approval policies, and the application's UX collects input such as tool approvals.

Wikipedia records one attempt to place the line. Birgitta Böckeler at Thoughtworks separates an inner harness shipped with the model's builder from an outer harness the user assembles out of instruction files, MCP servers and skills. A builder's harness is a product, while the outer harness is a set of files a team maintains and a set of rules the team writes. Whether those files sit somewhere the company controls, or somewhere the tool controls, is the question the definitions leave open.

The loop is the part vendors give away

Anthropic's harness guidance argues for taking scaffolding back out as models improve. Hand the model code execution so it filters its own tool output, let skills replace a long system prompt, and let compaction replace a retrieval layer. The same economics show up from the platform side at OpenAI. "The reusable part is the agent loop." OpenAI publishes that loop as a harness other applications build on. The jobs it lists: conversation state, streamed execution, tools, sandbox and approval policies, work carried across turns.

Those jobs are now table stakes. A bash tool, a file editor, subagent spawning, compaction and MCP connections appear in Microsoft's capability matrix, in the Deep Agents feature list and in Claude Code's own documentation. Convergence is what turns a loop into a component, and a component is priced by what surrounds it.

Kortix treats the loop that way. The harness sits behind an adapter, and the harness boundary README states the rule that keeps a swap contained:

An unknown id fails the boot.
There is no per-request switching: one box, one harness, for the life of the box.

The manifest's runtime: selects nothing, so the loop is resolved when a box boots and the grants are read from the manifest either way. A loop can change without the permission list changing, and a migration that would reopen a security review stays a code change.

Four options, and where the boundaries live

Dr. Phil Winder's comparison of agent harnesses keeps four layers apart: the model reasons, the harness runs one agent, a framework composes several, and a platform runs many harnesses across a team over time. For a client team, Winder writes, the harness is the smaller decision; the larger one is the agent it runs, which carries the tools and permissions it gets.

The shapes differ in where the permission list lives, and that decides who can read it. Kortix runs the harness inside the operating system, so the boundaries belong to the project rather than to the harness. Your agents, the skills they share, your company memory, and every connector live in one git repo, and the grants sit in its manifest. A change to what an agent may do arrives as a commit.

Claude Code runs in the terminal, the IDE, the desktop app and the web. It reads a CLAUDE.md at the project root and keeps its settings with the project. Its Agent SDK gives a team control over orchestration, tool access and permissions, so the boundary is enforced in code the team writes. Anthropic does not publish Claude Code's harness source, which makes the boundary configurable and not inspectable.

Codex ships an open harness that applications embed. OpenAI exposes it through an exec mode, an SDK and an app server that handles approval requests. The boundary sits in the host application, which decides "where an agent runs, which files or tools it can access, which actions require approval".

LangChain's Deep Agents is "the batteries-included agent harness" as a library. Sub-agents, pluggable filesystem and sandbox backends, and human-in-the-loop approvals that can approve, edit or reject a call before it runs all come with it. Its boundary is whatever the code around it says.

The last column matters most in a review. A boundary kept in your own source is reviewable by the engineers who own that source and by anyone who joins later. A boundary kept in a product is reviewable through the product's documentation and by whoever configured it.

What a harness will not settle

A harness compensates for what a model cannot do yet, and Anthropic notes that those assumptions "grow stale as Claude gets more capable". Benchmarks inherit the same problem. Anthropic reports BrowseComp accuracy rising from 45.3% to 61.6% when the model was allowed to filter its own tool outputs. The gain came from the harness change, with the same model underneath.

The permission list has a limit of its own. Approval gates you set. Off until you set them. The list ends up describing what the company decided, and the harness cannot promise more than that.

Where the decision lands

One isolated sandbox per session. Each session has its own isolated machine and branch. Session work reaches main through a change request. Merge is default-deny for agents.

So the question for a buyer is where the list lives, and who can read it before the agent runs. A harness can be swapped later, and the grants decide what the replacement gets access to.

Two related reads: Kortix vs OpenHands on the record a coding harness leaves, and what the OpenAI Agents API changes for teams on who runs the loop when a vendor hosts it.

If you want the harness to be a component of a system you own, start at Kortix.