Open source agent harness: the layer decides what you own

Three shapes share one name

Microsoft's documentation states the object plainly: "An agent harness, sometimes called an AI harness, is the runtime scaffolding that turns a language model into an agent that can perform work." LangChain's anatomy post puts it shorter. "Agent = Model + Harness", where the harness is "every piece of code, configuration, and execution logic that isn't the model itself."

Scope follows from those two sentences. A harness owns the system prompt and the tools, with their descriptions. It owns the filesystem, the sandbox, the orchestration that spawns subagents, and the hooks that compact or continue a run. It also owns the approval rule and the place where session state survives.

None of which tells you what to install. An open-source harness list puts a terminal coding agent beside a Python package beside a company-wide system. Then it scores them on features they do not both have.

Dr Phil Winder splits the field into four layers in his 2026 comparison: the model reasons, "the harness, which runs one agent", the framework composes several, and the platform "runs many harnesses across a team over time, with durable execution, cost attribution and governance". His verdict on the choice is blunt: "Which one you pick matters less than which layer you need, and no feature grid answers that."

A coding CLI, a runtime you embed, a team layer

Coding agents are the shape most people meet first. OpenCode calls itself "The open source coding agent", and its latest release, v1.19.4, landed on 22 October 2026. Goose is "an open source, extensible AI agent that goes beyond code suggestions"; aider is "AI pair programming in your terminal". In this shape a person supervises: you sit at the prompt, you read the diff, and the run ends when you close the window.

Embeddable runtimes are the second shape. Deep Agents is "The batteries-included agent harness", a Python package you wrap a product around. TrueForge runs the same idea as a service. It lists what the loop covers: model calls, MCP tools, skills, sandboxing, approvals, context management and session state. It exposes them through a chat UI, an HTTP API with a TypeScript SDK, and an embeddable UI SDK. Here the harness is a dependency and your application is the product.

The third shape runs many sessions of many harnesses for a group of people, and keeps the configuration, the permissions and the record of what happened. Kortix lives at this layer, where the harness is one part of the repository rather than the product.

Where a list goes quiet

Open the README and the seam appears quickly.

TrueForge ships two deployment modes, and each brings another decision. Local mode is "one process, SQLite" and, in the project's own words, "for your machine only", "not a production or internet-facing setup". Hosted mode adds Postgres and Redis. Its sandbox is a named service, "Daytona today; more providers planned". Pick TrueForge and you have also picked a database pair and a sandbox vendor.

Deep Agents is one package on a longer stack. It is built on LangGraph, and the README points to LangSmith for "first-class tracing, evaluation, and deployment". The harness is open. The operations layer around it is a product you buy.

OpenClaw inverts the picture. It is "an open-source AI assistant that runs on your own computer", with one Gateway for sessions, tools and channels, and its README says "Models and agent harnesses (Claude, Codex, local models) are plugins you can swap without changing anything else." The assistant and its gateway are open. The harness it swaps in need not be: Anthropic does not publish Claude Code's harness source, and its own engineering post argues that harnesses should hand scaffolding back as models improve.

Openness belongs to a layer. A product name hides which one, and that is the part a feature grid cannot score.

What a team layer has to own

A terminal agent never has to answer who may run which agent, or where finished work lands. A team layer answers both, for every session, all day.

In Kortix the answer starts in the repository. "Your agents, the skills they share, your company memory, and every connector live in one git repo, versioned, diffable, and shared by the whole company." The starter manifest is the whole layout. Agent files, skills and memory sit at the root, shared by every harness, and one folder per harness holds the files only that harness reads. Tools are declared once, for every agent.

What the manifest does instead is configure the team. One agents: map per project names each agent's file. Each entry says what that agent may reach, from connectors and secrets to permissions and skills. The behaviour sits in the agent's own markdown file, so changing an agent leaves the manifest alone.

Two more properties belong to this layer rather than to any harness. Each session gets "an isolated sandbox per session, on its own branch", and the work it produces goes through "a change request a human approves". Neither is a feature of a model or a loop. Both are what make many agents safe to run for a group of people. And "you can run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free."

Five questions for any open-source harness

Ask these in order and the layer falls out of the answers.

1. 1.Where does the configuration live: a file in your repository, or rows in a vendor's database?
2. 2.What runs the box, and can you run it yourself when the hosted option goes away?
3. 3.Who approves a tool call, and is the policy per agent or global?
4. 4.What survives the session, and where does it survive it?
5. 5.Can you change harness without rewriting your agents?

A coding CLI answers 1 with a dotfile and 5 with a migration. An embeddable runtime answers 2 with a dependency you can pin. A team layer has to answer all five in public, which is why the answers are worth reading before the feature list.

A short way to decide

If you want a partner in your terminal today, take a CLI and pick it on provider support and speed of the loop.

If the agent is your product, take a runtime you import, and check which database and which sandbox it assumes before you commit.

If a group of people will run many agents, with review and a record, you want the team layer. It holds the repo, the sandbox and the change request. The harness is the smaller half of that decision. The configuration you keep is the larger one. How the harness shapes compare covers the project-by-project view.