Open Source · Self-described harnesses · Updated daily via GitHub Actions
Open-source projects that describe themselves as an agent harness, sorted by what each one actually is: runtimes that execute the agent loop, coding-agent harnesses, and control planes that sit above them. The word is used loosely, so the Role column says what you are getting. See the harness engineering guide, or the agents index for ready-to-run agents.
A model on its own only predicts text. Everything that turns it into something that can do work — running tools, keeping state between steps, deciding what it may and may not do, checking results, recovering when a step fails, and recording what happened — is the harness. It is the difference between a demo that works once and an agent you can hand real work to.
Lately “harness” has become a popular label, and it is used for very different things: a runtime that executes the agent loop, a coding agent, a layer that governs other agents, even a research codebase. This index lists projects that call themselves a harness and says, in the Role column, what each one actually is.
Every entry has a role. Use the Role filter to isolate one — or read on for what each means.
Executes the agent loop for you — model calls, tools, state, sandboxing and approvals — so you supply the task and the tools, not the loop.
A harness built around a coding agent: repository access, a shell, edit-and-test cycles, and often a terminal or editor front end.
Sits above or around other agents and harnesses: long-horizon state, governance, enforcement, observability, credentials, parallel supervision.
Built for several people sharing one agent, for example in a chat workspace, rather than a single user at a terminal.
A harness applied to security work such as vulnerability research. Run only against systems you own or are authorized to test.
Reference code for papers and experiments on harness design. Valuable for ideas; not usually built to run in production.
Builds a harness from scratch to show how the pieces fit. The best way to understand one before choosing one.
Curated lists and resources on harness engineering, for discovery rather than as a tool you run.
Three words for three layers that products routinely combine.
The thing a user runs to get work done. Many agents ship with a harness built in, so the two words often describe the same product.
A library for building agents of your own. A framework gives you parts; it does not decide what an agent is allowed to do. See the frameworks index.
The execution and control layer around a model: permissions, isolation, state, verification, recovery and observability. See the 11-layer architecture.
Eight capabilities that separate a harness from a prompt loop. Not every project needs all of them; the ones you skip should be a choice.
Can you say what the agent may do — allow, deny or ask first — per tool and per path? A harness that acts on everything the model asks for is a prompt loop with extra steps.
Does work run in a sandbox, container or worktree, or directly on your machine with your credentials? Isolation decides how bad a mistake can be.
Does it checkpoint, so a crash or a rate limit resumes the interrupted step instead of starting over? Long tasks need this more than any other feature.
Does anything check the work — tests, review passes, schema checks — before it is accepted? A harness should not take the model’s word that a step succeeded.
How does it decide what the model sees each turn, and what persists between sessions? Context management is where most long-running agents quietly fail.
Can you see every step and replay a failure, and can you measure whether a change helped? Without this you are tuning by feel.
Are tools, skills and plugins first-class? Look for open protocols such as MCP rather than a private extension format you would have to rewrite.
Does it work with more than one model provider, including local models? That decides cost, privacy and how easily you can move.
Everything around a model that lets it do work reliably: tool execution, state, permissions, isolation, verification, recovery and observability. The model proposes; the harness decides what actually happens and checks the result.
No. A framework is a library for assembling agents. A harness is the control and execution layer around a model or agent, and can be built with or without a framework. Many products blur the two, which is why this index shows a Role for every entry.
It is a useful word for “the part that is not the model”, so it has spread quickly and now covers runtimes, coding agents, governance layers and research code. Judge a project by what it does — the capabilities listed above — not by whether it uses the word.
Often a control plane adds what a built-in harness lacks: state that survives across sessions, governance across several agents, or central enforcement and audit. Control planes in this index are designed to run on top of other harnesses.
Build A Harness is this site’s own open-source visual canvas for designing a harness and running it on several agent frameworks. Read the harness engineering guide for the discipline, and the 11-layer architecture for the layered model.
By hand: open source, actively maintained, and describing themselves as a harness — then read against the project’s own documentation to assign a role, and verified against the live GitHub API when the list is reviewed. Projects that only borrow the word are left out. To suggest an addition, open an issue or pull request on the buildaharness-pages repository.
Stars, forks and topics are refreshed daily via GitHub Actions — the freshness indicator in the nav bar shows the age of the current data pull. The list itself is reviewed by hand periodically.