Agent Harness Landscape
Use this map to separate four questions that product lists often merge: which model generates, which runtime owns the tool loop, which repository configuration controls local behavior, and which orchestrator coordinates multiple runs. A project can be valuable without being a runtime harness.
The broad directory below normalizes the 160 projects and 12 categories in Best of Agent Harnesses, then adds 33 guide supplements discovered through direct project research. It uses the upstream snapshot at commit ece3146, dated 2026-08-23. The strict map applies an additional test: does the product own the cycle that plans, acts through tools, observes results, and decides what happens next?
An agent harness is the runtime around a model that assembles context, exposes tools, applies permissions, executes the action loop, records state, and handles failure. Simon Willison's concise definition, "models using tools in a loop", identifies the behavioral boundary. The 2026 Agent System and Harness Design survey expands that runtime into six responsibilities: observation, context, control, action, state, and verification. The SWE-agent paper names the coding-specific interface between the model and computer the agent-computer interface.
Comparison requires a second boundary: every outcome belongs to a model-harness pair under a disclosed task set and budget. In a controlled 300-run study across two models and three harnesses, The Scaffold Effect found up to a 40-times difference in tokens per solved task, while pass-rate differences stayed within 0 to 8 percentage points and were mostly not statistically significant. A harness can strongly affect cost and failure behavior without being the main accuracy bottleneck.
This page answers which layer and which project. Agent Harness Engineering documents the components inside a runtime harness. Loop & Graph Engineering covers feedback, topology, state transitions, stopping rules, and judgment boundaries. Agent Tools: Beyond Claude Code provides deeper product profiles. The glossary separates runtime harnesses from repository harnesses and evaluation harnesses.
Choose the right entry point
| Question | Canonical page |
|---|---|
| How does the loop, context, tool, hook, permission, and recovery machinery work? | Agent Harness Engineering |
| How should a loop or executable workflow graph be designed and bounded? | Loop & Graph Engineering |
| Which runtime or adjacent project fits a particular job? | This Agent Harness Landscape page |
| What does a named coding-agent product support in practice? | Agent Tools: Beyond Claude Code |
| How should a repository prepare instructions, setup, state, and verification for any runtime? | Repository Harness Engineering |
| How should a shortlist be evaluated and instrumented? | Agent Evaluation and Observability |
| Which systems optimize a harness rather than run tasks directly? | Harness Optimizers and Meta-Harnesses |
These pages are linked but deliberately not merged. The engineering reference explains stable mechanisms. This map is a dated evidence snapshot whose projects, licences, features, and GitHub signals need a separate refresh cycle.
本篇目录
- Interface, Execution, and Loop Ownership Are Separate
- 160 Projects Does Not Mean 160 Runtime Harnesses
- The Twelve-Category Map
- Core Coding Harnesses
- Orchestrators: Products Above the Runtime
- Harness Optimizers and Meta-Harnesses
- Four Layers, Four Responsibilities
- Complete Project Directory
- How to Pick a Harness
- How to Test-Drive the Shortlist
- Machine-Readable Access
- Related Reading
- Limits of This Map