Best Agent Harness: Open Source, Three Questions, Not the Model

What a harness owns

"An agent harness, sometimes called an AI harness, is the runtime scaffolding that turns a language model into an agent that can perform work." That is Microsoft's definition, and it splits the thing in two: a model that reasons, and a harness that acts.

LangChain puts the same split in an equation, "Agent = Model + Harness", and calls the harness "every piece of code, configuration, and execution logic that isn't the model itself". Anthropic describes it as "the software scaffolding around a model: the loop, tools, context management, and guardrails that turn raw intelligence into a working agent."

Concretely, the harness holds the system prompt, the tool and MCP descriptions, the filesystem, sandbox and browser the agent can reach, the orchestration that spawns subagents, and the hooks that compact context and decide when a turn ends. It decides what the model sees, what the agent can touch, and when the work stops.

One field guide untangles a word that buyers keep collapsing. Winder's 2026 comparison stacks four layers: the model reasoning, the harness running a single agent, the framework composing several agents, the platform running many harnesses across a team over time. A shopping list built across two of those layers is why people end up buying a framework to fix a runtime problem.

Who approves a tool call

The first question about any harness is what happens at the moment the agent tries to act. On Kortix the answer is the project's own policy: "Approval gates you set. Off until you set them." That policy sits in the repo beside the agent it governs. A scoped specialist can open with Ask on the steps that touch money, and Allow on the ones that only read.

Codex enforces configured sandbox and approval policies, so it asks the same question with the policy held inside the harness. TrueForge lists approvals as part of the loop it runs. All three let a person stop a call; they differ in where that rule is written and who can change it without a review.

Where the session's work survives

The second question is what still exists tomorrow. Kortix answers it in the repo: "One isolated sandbox per session. Each session has its own isolated machine and branch." The agent works in its own checkout. Work lands through a change request a human approves, so the branch history is the record and the diff is what a reviewer reads.

Codex manages conversation state and carries work across turns, which is what makes a long session feel continuous. TrueForge keeps session state in SQLite on a local install and in Postgres when hosted. Neither answer is wrong; they decide different things about next month. If the state is a branch of a repo you own, git log is the audit trail and the artifact you can hand to someone else. If it is a row in someone's database, your access to it later depends on their product.

Who runs the machine

The third question is whose hardware the agent touches. "Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free." Those are the three answers a security review asks for: managed cloud, your VPC, your own network. With them on the table, the review can end with a topology.

The Codex harness is open source and powers the Codex app, CLI, IDE extensions and third-party clients. Claude Code is an agentic coding tool that runs in a terminal, in IDE extensions, on the desktop and in the web, and Anthropic does not publish Claude Code's harness source. TrueForge splits the difference: one process on a laptop, or a server with Postgres and Redis behind it.

The model comes fourth

The model matters, and it is the one term in the equation a harness will usually let you change. Kortix takes "Any model provider with your own keys", so the harness outlives a model switch instead of being tied to one vendor's roadmap.

Evidence that the harness is doing real work comes from OpenAI's own account of Codex: on ARC-AGI-3, retained reasoning and context compaction raised a model's score from 13.3% to 38.3% while cutting output tokens sixfold. Same model, different scaffolding around it. Anthropic's harness write-up bets the other way, that the harness should shed scaffolding as models improve ("Lean on the model, not the harness"), and that bet is another argument for keeping the harness replaceable.

Where the configuration lives

What outlasts all three answers is the configuration. The Kortix starter keeps everything a harness loads at the root of the repo:

# Project layout — harness-neutral content at the root:
#   agents/<name>.md          one file per agent (`agents.<name>.file`)
#   skills/<name>/SKILL.md    skills, loaded by every harness
#   memory/                   the project brain (the `kortix-memory` skill)
#   tools/<name>.ts           project tools, loaded by every harness (`tools:` below)
#   harnesses/opencode/       files only OpenCode reads (`opencode.config_dir`)
#   harnesses/pi/             files only pi reads (`pi.config_dir`); create it when needed

Source: https://github.com/kortix-ai/suna/blob/dev/packages/starter/templates/base/kortix.yaml. One file per agent, one folder of skills that every harness loads, one folder for memory, one for tools. The harnesses/ directories hold the exceptions, the handful of files that only one runtime reads.

That layout makes the harness a component rather than the product. The agents, the skills and the memory stay where they were.

Matching the answers to a project

Four shapes come out of those three questions.

A repo your team owns, with approvals on, is Kortix: the configuration and the review are already in git. Your own infrastructure means TrueForge, which runs as one local process or a hosted server, or a self-hosted Kortix. A vendor's product surface means Codex or Claude Code. One machine and one person means OpenCode, Goose, Aider or Pi.

Release rhythm deserves a look too, because a harness carries a lot of model-specific behaviour. Seven of the eight projects named here published a release in the week to 27 October 2026: Kortix, Codex, OpenCode, Goose, Pi, TrueForge and Claude Code. Aider is the exception: its latest release is from August 2025 and its repository last took a push on 22 May 2026. If the work has to keep pace with model releases, that gap will cost you more than a missing feature.

The four-project comparison carries the same cells in more detail, and the open-source guide covers the projects whose whole runtime sits in their repo.