How to choose a harness

Work through these in order. Each step narrows the list. Links go to the matching tables on the compare page.

1. Start from your host agent

A harness only helps if it supports the coding agent your team already uses. Check the host agents table first. Community ports exist for some harnesses, but they lag behind the original and are maintained by other people.

To cover: what to do if your team uses more than one host.

2. Find the weak stage in your process

Look at where agent-written work goes wrong today: unclear requirements, no plan, missing tests, no review, or the same mistakes repeated. Pick a harness that covers that stage. See stages of work it covers.

3. Decide how much process you want

To cover: the difference between a light harness (a few skills you invoke when needed) and a full methodology (every task goes through brainstorm, plan, build, review). Heavier processes use more tokens and time per task, and pay off on larger changes.

4. Check how it activates

To cover: harnesses that load automatically through hooks or skill descriptions, versus ones you invoke with a command. Automatic activation changes every session, including quick ones. See how it runs.

5. Plan the team setup

To cover: installing per project so everyone gets the same version, adding your own skills, and keeping up with upstream changes. See adopting it.

6. Run a pilot

To cover: picking two candidates, giving each the same real tasks, and what to measure (task completion, review time, rework, tokens used).

7. Roll it out

To cover: onboarding, code review practices for agent-written changes, and when to revisit the choice.