Harness v2 rebuilds an agent team factory on three execution modes

Two install routes that leave different things on disk

Two install paths are documented and they do not end in the same place. The marketplace route registers a plugin source and installs the plugin:

/plugin marketplace add revfactory/harness
/plugin install harness@harness-marketplace

The other route copies two directories straight into your home Claude config:

cp -r skills/harness ~/.claude/skills/harness
cp -r skills/evolve ~/.claude/skills/harness-evolve

The second command lands evolve under the name harness-evolve, while the evolve command elsewhere on the page is written /harness:evolve, and the page does not say whether that name survives a copy install. It does say no environment variables or experimental flags are required, which reverses the CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 dependency v1 carried. Count what the copy path skips too: the repository ships a .claude-plugin/ directory, a CHANGELOG.md, CONTRIBUTING.md and a docs/ folder, and none of those are touched by those two lines. The repository also has no GitHub releases, so either route installs whatever main happens to hold.

The execution mode comes from control flow, not team size

v1 knew two execution modes and both were built on the experimental TeamCreate API, which the page states no longer exists. What ships now is three. Workflow orchestration runs deterministic Workflow scripts built from pipeline(), parallel(), schemas and budgets, aimed at enumerable fan-outs, verification loops and large scale. Persistent agent collaboration uses named agents with SendMessage and shared task lists, keeping context across turns. Sub-agent delegation is one-shot parallel dispatch.

The factory picks from the shape of the control flow rather than the size of the team, and mixes modes per phase when that fits better. That mixing has a price: sub-agent delegation is documented as fire-and-forget where only the results come back, so any step that needs iterative negotiation has to land in persistent mode instead, and the page names no override for forcing a different mode on a given phase.

Blanket model pins are forbidden, so every agent gets its own tier

v1 pinned every agent to model: "opus". v2 drops that and selects a tier per agent from fable, opus and sonnet, judging by the task's complexity, duration, autonomy and latency needs, and it forbids unjustified blanket pins. The migration note tells you to remove blanket model: "opus" pins on the way over. What you get in exchange is a harness with mixed models inside it: cost and latency now differ per agent, and the page documents no flag for reading the tier that was chosen or for pinning one yourself.

Six architecture patterns are offered, Pipeline, Fan-out/Fan-in, Expert Pool, Producer-Reviewer, Supervisor and Hierarchical Delegation, each mapped to its best v2 execution mode. So the tier arrives attached to a structure you did not hand-pick either, and you find out about both from the generated files rather than from a decision you made.

Phase 0 detects v1 artifacts and rewrites the migration for you

The pipeline is eight numbered phases, and phase 0 is the one that reaches into your repository before you answer a design question:

Phase 0: Audit existing harness (new / extend / maintain — v1 artifacts detected here)
Phase 1: Domain analysis (incl. control-flow shape of the work)
Phase 2: Execution mode & team architecture design
Phase 3: Agent definitions (.claude/agents/)
Phase 4: Skill generation (.claude/skills/)
Phase 5: Orchestration & CLAUDE.md pointer
Phase 6: Verification & testing
Phase 7: Maintenance — evolution via /harness:evolve

Phase 0 tags the work as new, extend or maintain, and it is where v1 artifacts get spotted. The rewrite that follows is mechanical: remove TeamCreate, TeamDelete, broadcast and flag references, convert fan-outs to Workflow scripts, rewrite the remaining collaboration with named agents plus SendMessage, and drop blanket model pins, with more detail in docs/migration-v1-to-v2.md. The page describes no preview step between the audit and the rewrite and does not say which files are modified in place, so keep a copy of a .claude/ directory that already holds work.

/harness:evolve is a skill you have to copy separately

Phase 7 handles maintenance, and it leans on a command that v1 only described in prose. /harness:evolve captures the delta between your initial and current harness, generalizes the feedback you hand it, and feeds that back into agents, skills and orchestrators. In v2 it ships as a real skill, and it is the second directory in the copy install path. Its trigger is one sentence, issued after you have used the generated harness:

하네스 회고해줘 / evolve the harness with this feedback

Skip that copy and phases 0 through 6 still hand you a team, but the maintenance phase has nothing behind it. Nothing on the page tells you a harness left alone improves on its own, so treat evolve as a separate install decision from the factory itself. The same split applies to the factory trigger, which is also just prose you type:

build a harness for this project
design an agent team for <domain>

Everything lands in .claude/ plus a CLAUDE.md pointer

The output is a fixed directory shape and a stub pointer:

your-project/
├── .claude/
│   ├── agents/          # agent definitions (who)
│   │   ├── analyst.md
│   │   ├── builder.md
│   │   └── qa.md
│   └── skills/          # skills (how) + one orchestrator (who-when-in-what-order)
│       ├── analyze/SKILL.md
│       └── build/SKILL.md
└── CLAUDE.md            # minimal pointer: trigger rule + change history

Agent definitions are markdown files named for the role, skills are SKILL.md files written for context efficiency through Progressive Disclosure, and one of the skills is the orchestrator that decides who runs when and in what order. CLAUDE.md is described as a minimal pointer carrying a trigger rule and change history, which means the factory writes to a file your project also owns. Neither the page nor the phase list says how an existing CLAUDE.md is merged, only that one gets generated, so plan on reading the diff before you keep it.

The only benchmark here is v1 data with n=15

The repository publishes one measurement, under the heading Prior results (v1). A controlled A/B across 15 software engineering tasks reported mean quality moving from 49.5 to 79.3, a 15 out of 15 win rate and 32 percent less output variance, with n=15 and author-run stated in the line itself, pointing at revfactory/claude-code-harness for the code behind it. The page tells you to treat these as author-measured numbers and run your own pilot before making an adoption decision, and that instruction carries extra weight in v2: both the execution modes and the model policy changed underneath those tasks, and no v2 evaluation appears anywhere in the repository. Pin a specific Git commit for a reproducible snapshot and compare commits when updating. Verification tooling does ship, in the form of trigger evals, dry runs and with-skill versus without-skill A/B testing, so you can build that comparison yourself inside a generated harness.

Editorial conclusion

Take Harness when you want a Claude Code agent team drafted from a domain description and can review the generated .claude/ files before they land in your repository. Check first what your existing CLAUDE.md and .claude/agents/ already hold, because the audit phase runs before you approve a design, and treat the published numbers as motivation rather than evidence for v2. Leave it alone if you need a tagged release to pin, a documented way to override the chosen execution mode or model tier, or proof that the current plugin is what was measured.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. revfactory/harness on GitHub