The coding-agent harness taxonomy, version 1

This page is a taxonomy: six terms, each with a permanent identifier (CHT-1 through CHT-6), one definition, a statement of what it owns and what it excludes, and boundary criteria that decide the disputed cases. It is written for researchers and writers who need to cite a definition — in a paper, a benchmark report, or a comparison table — and want the words behind the citation to hold still. Version 1 is dated 2026-08-29, and the stability policy below is what makes the identifiers worth citing. The narrative companion that explains why these layers exist and walks a single command across them is the harness boundary guide; this page is the reference, not the story.

A glossary would not survive contact with how these words are actually used. Two vendor self-descriptions, each recorded with its source on this site's dated harness comparison after its 2026-08-28 fetch: Pi introduces itself as "Pi is a minimal agent harness."; Kiro's documentation describes "One unified agent harness powers every surface (IDE, CLI, Web, and Mobile)". One maker's harness is a terminal runtime; the other's is the engine behind every surface the product ships. Neither is wrong — and neither is usable as a citation. The criteria below classify by the job a component does, never by the word its maker prefers.

Two honesty notes frame everything. No demand estimate backs anything on this page, and no criterion encodes popularity — a term earns its place by discriminating, not by being discussed. And the taxonomy classifies categories of systems, never products against one another; which product serves which job better is the comparison's question, and its verdicts stay on the comparison pages.

Scope and sources

Six terms, and two need a word of justification before they appear. The model term is here because the agent and harness boundaries cannot be drawn without naming the thing both wrap: proposals from trained weights, and nothing more. The evaluation term is here because it is not a layer in the runtime stack at all — it is the instrument beside the stack, holding task populations and grading rules constant so agent systems become comparable — and it earns a term because public writing applies the word harness to evaluation frameworks too.

Each definition normalizes three evidence classes this site already controls: dated public self-descriptions, recorded on the comparison page named above; the committed documentation of this site's own products; and the published harness matrix dated 2026-08-28. The admissibility rule is the taxonomy's spine: a boundary criterion enters only if it discriminates, meaning at least one nameable public system sits on each side of it. A criterion nothing can fail is decoration; a criterion everything fails is broken; both are excluded by construction.

The terms, version 1

• CHT-1 — Model. A model is trained weights served behind an API or run locally; it reads a prompt and proposes the next action. Owns: the reasoning that turns a prompt into a proposal. Excludes: execution — it runs nothing, touches no files, and remembers nothing between calls — and every decision about which work exists. Criteria: swapping a model changes the quality and character of proposals and nothing else; where state lives, which tools exist, and what gets attempted are all decided elsewhere.
• CHT-2 — Agent. The acting loop: a program that gives a model its tool surface — reading and changing files, running commands — carries out what the model decides, and feeds each result back in until the work or its bounds run out. Owns: the loop and the tool surface. Excludes: the weights behind its proposals (CHT-1), the environment hosting it (CHT-3), and the decision that this work deserved a run at all (CHT-5). Criteria: an agent persists across many model calls and takes real actions on a real repository; one API call with no loop and no tools is not one, and prose a human must apply by hand is assistance rather than agency — a distinction this taxonomy leaves to its own owner.
• CHT-3 — Harness. The hosting environment for agent runs: the runtime that builds the prompts a model sees, wires up the tools the loop may call, keeps context and the session alive across steps, records what each run did, and exposes the extension surface — skills, rules, configuration — a team tunes. Owns: everything wrapped around runs it did not choose. Excludes: the weights, the loop itself, the editor a human types into, and the coordination decisions above it. Criteria: when a system also selects work, admits it through gates, or keeps coordination records that must outlive any single runtime, that part of it belongs to CHT-5; and the attestations above are the standing warning — two vendors use this one word for scopes as different as a terminal runtime and an engine behind four surfaces, so the criteria classify, not the word.
• CHT-4 — IDE. The human surface: an editor built for a person to read and change code, which may embed or drive agents but exists for human eyes and hands. Owns: the editing experience. Excludes: headless execution — a CLI that edits files with no editor on screen is not an IDE — and the runtime behind an embedded agent, which is CHT-3 wearing the editor as a serving surface. Criteria: ask who the surface serves; when the primary reader is a human composing code, this term applies no matter how much agency sits inside, and one product can hold this term and CHT-3 at once — the dated matrix records Cursor as an IDE that then grew a terminal CLI plus cloud agents.
• CHT-5 — Control plane. The coordination layer above harnesses: it decides which work deserves a run, bounds the run, isolates its blast radius, gates its landing, and keeps the records that must survive every runtime beneath it. Owns: work selection, admission, integration order, and cross-run truth. Excludes: inference, the acting loop, the human editor, and hosting any single run. The committed README of this site's CLI names the job in its opening line — orchestrating coding agents and the structured development workflows around them — and the dated matrix describes a product with no interface of its own — its shell commands drive agent CLIs already installed on the machine. Criteria: the swap test — replace every harness below it and the work records, gates, and queue must still stand; if replacing the runtime destroys them, they were harness state, not coordination truth.
• CHT-6 — Evaluation. The measurement instrument: a fixed task population plus grading rules that make agent systems comparable — benchmarks, leaderboards, and the scoring frameworks around them. Owns: holding the tasks, the grading, and the published score constant. Excludes: hosting runs anyone chose for their own work; an evaluation standardizes the measurement of runs made against it, which is a different job from hosting yours. Criteria: when a framework supplies the environment, the tasks, and the grader while the submitter supplies only the agent, the framework is this term and the submitted loop is CHT-2, whatever either is called.

The criteria settling real disputes

Three cases show the criteria doing work that word choice cannot. Each is decided without appealing to any vendor's vocabulary.

• One product, two terms. Is Cursor an IDE or a harness? Both, in different terms: its editor is CHT-4 by the who-is-served criterion, and the runtime inside it that assembles runs is CHT-3. Terms classify jobs; a product may hold several at once, and saying so ends a genre of argument.
• One word, two scopes, one term. Pi's self-description and Kiro's documentation both reach for the word harness — one for a terminal runtime, one for an engine powering four surfaces. Different scopes, same term: both host agent runs they did not choose, so both are CHT-3, and the scope difference is a fact the comparison records rather than a boundary the taxonomy must redraw.
• A product the runtime terms cannot hold. YYLO's CLI fails the IDE criterion outright — no human editing surface — and its hosting is borrowed: the matrix records shell commands driving installed agent CLIs while the product keeps the records and gates the landings. The swap test places it in CHT-5, the coordination term, which is where the committed README's opening line already puts its posture.

Stability policy

The policy is short and contractual. Identifiers are permanent: CHT-1 through CHT-6 are never renumbered and never reused; if a term is ever retired, its identifier is withdrawn with it rather than reassigned to a new meaning. Clarifications that change no classification land as in-place edits, recorded in the changelog with their date. Anything that would move a named system's classification, add a term, or retire one requires a new numbered version with a fresh evidence date — and version 1 remains a citation that still resolves, because this page keeps its changelog instead of overwriting its memory.

Each quarter, every attestation and criterion here is re-checked against the then-current sources behind them; a review that changes nothing records that fact and the version number stands. The site-wide methodology for recurring research assets — the shared changelog, citation, and update-ownership rules — has now shipped as the recurring-research methodology page.

Changelog

• Version 1 — first publication, 2026-08-29. The six terms, their boundary criteria, the admissibility rule, and this stability policy. No earlier version exists, and nothing is superseded.
• In-place edit, 2026-08-29. Linked the failure-and-recovery companion from the closing section now that its route ships. No term, criterion, classification, or attestation changed.
• In-place edit, 2026-08-29. Linked the recurring-research methodology companion from the stability policy now that its route ships. No term, criterion, classification, or attestation changed.

Citing a term

Cite the identifier, not the word. A citation that names CHT-3, a version number, and an evidence date cannot silently drift: any change to what a term means produces a new version, while the old citation still resolves against the changelog. The recommended form for one term:

CHT-3 Harness — coding-agent harness taxonomy, version 1
YYLO, evidence date 2026-08-29
https://yylo.dev/guides/coding-agent-harness-taxonomy

One companion reference now ships beside this one: the failure-and-recovery taxonomy, holding stable classes of what goes wrong for coding agents and the recovery each class calls for. What this taxonomy will never do is score, rank, or recommend — products appear here only as evidence that a criterion discriminates, and product-level verdicts stay with the dated comparisons.