An open-source agent harness, defined part by part

What the term covers

Wikipedia calls an agent harness, also known as agent scaffolding, "the software infrastructure surrounding a large language model (LLM) that enables it to operate as an AI agent". The entry then lists the work it takes on: "tool use, memory, state persistence, execution environments and feedback loops, as opposed to the model's internal reasoning" (Wikipedia).

Anthropic's engineering post trims that to one line, "the loop, tools, context management, and guardrails that turn raw intelligence into a working agent" (Anthropic). Microsoft's Agent Framework documentation opens with its own version: "the runtime scaffolding that turns a language model into an agent that can perform work" (Microsoft Learn). The documentation then lists the work. A harness drives model and tool calls, manages conversation state and context, applies approval policies, and keeps a multistep task moving.

The three definitions differ in width and agree on the boundary. A model produces text. The harness is everything else a finished task needs.

The model reasons, the harness acts

A language model takes tokens in and returns tokens out. Between two calls it keeps nothing: no open file, no record of a command that failed, no memory of yesterday's work. LangChain's anatomy post turns the gap into a formula, "Agent = Model + Harness", with the second term defined as "every piece of code, configuration, and execution logic that isn't the model itself."

The formula earns its place because it says where to look when an agent misbehaves. A loop that never ends, a tool called with the wrong argument, a task forgotten halfway through: none of that comes from the weights. Two teams pointing the same model at the same repository will still finish different amounts of work, because the turns, the tool list and the rule on asking a person belong to the harness.

Four parts every definition agrees on

• The prompt and the context for each call. LangChain puts "System Prompts" first and adds "Hooks/Middleware for deterministic execution (compaction, continuation, lint checks)". Microsoft persists history after each model call in a tool-calling run, and compacts when a token limit is configured.
• The tools, with the descriptions the model reads to choose one. LangChain names "Tools, Skills, MCPs + and their descriptions"; its sandbox section notes that a harness "can allow-list commands and enforce network isolation".
• The loop and its orchestration. When to take another turn, when to hand a subtask to a subagent, when to stop. LangChain calls it "Orchestration Logic (subagent spawning, handoffs, model routing)"; Microsoft names the bounded version "looping".
• The sandbox and the approval rule. Where code runs, and which calls wait for a person. LangChain counts "Bundled Infrastructure (filesystem, sandbox, browser)" as harness; Microsoft's matrix gives shell execution, file access and "Tool approval" their own rows.

Harness, framework, platform

A harness runs one agent. It holds that agent's prompt, its tools, its loop and its sandbox for the length of a task, and it stops when the task stops. A framework is the library a developer imports to compose several agents, so it works in graphs, handoffs and shared state rather than in one session. A platform runs many agents for a team over months and answers what a single run never has to: who may start which agent, where finished work lands, what it cost and what record remains.

The words blur because products cross the lines. LangChain publishes Deep Agents as a package another application embeds, while Codex ships as an app, a command line and an IDE extension. Both are harnesses, and one arrives as a dependency while the other is a tool you open. The agent harness comparison places the named projects on those layers and shows where each keeps its state.

Where the manifest stops and the harness starts

The starter's kortix.yaml ends with a comment naming what else the same file can hold: a custom sandbox image, your own tools, and triggers. Above it, the worker's block points at its instructions with prompt_file, sets permission for its tool calls, and draws its skills from the skills registry in the same file, which the starter leaves empty. Nothing in the file describes a turn, a subagent or a stopping rule.

The manifest reference states the rule in both directions: "Omitted means none. An omitted skills, subagents, commands, extensions, connectors, secrets, apps or kortix_permissions grants nothing." For a file that writes its grants out like the starter's worker, it adds: "Three keys are open by default: tools is all, permission is allow, and codemode is on."

A session then runs on those terms:

• Every session runs an open-source agent harness.
• One isolated sandbox per session. Each session has its own isolated machine and branch.
• Approval gates you set. Off until you set them.
• Session work reaches main through a change request. Merge is default-deny for agents.

Read that way, the term stops being abstract. The prompt sits in a markdown file the manifest points at, the tools are granted with tools: all, and the rule on asking a person is the permission line on that agent. The sandbox image is named only in the closing comment, as a key you add rather than one the starter sets. The loop is not in the file at all, because it belongs to the harness that reads it. A harness is the code that turns a model into an agent, and a manifest is where its grants get written down; the turns themselves stay in the code.