I read the intake evaluations for 21 agent harnesses. All of them solve the same problem: running an agent. None of them solve the problem of verifying one.
That is the hole. Every harness on the market can launch a loop, fetch context, and emit code. None of them define "done" as something you can check. The survey that collected these 21 candidates is blunt about it: support must be mechanical, or it is theater.
The 21, in three tiers
The survey sorts the candidates by how Flow's discipline layer would actually integrate with them — not by marketing claims, but by mechanism. Four criteria from the qualification SOP drive the tiers: mechanical enforcement (does the host honor a gate?), context hygiene (does the context arrive intact?), runtime portability (does the runner work there?), and shell awareness (can the agent parse an exit code?).
Tier 1 — Native fit (3): Cursor (~/.cursor/skills), Zed Agent (~/.agents/skills), Trae (Dual A/B). The host already has a skills directory. The runner drops in. Friction is low.
Tier 2 — Project rule fit (16): Roo Code / Cline (.roomodes / .clinerules), Windsurf (Cascade), Aider (test hook), OpenHands (Docker), Copilot VSCode Agent, Goose (.goosehints), Amazon Q Developer /dev, Devin (DEVIN.md, cloud sandbox), SWE-agent (Docker/ACI), GitLab Duo Workflow, Sourcegraph Cody, Augment Code, Tabnine Chat, Plandex, PearAI, AutoCodeRover. Each has a plausible hook point — a rules file, a hooks mechanism, a container boundary. Each hook point needs verification.
Tier 3 — Deferred halves + historical: Copilot CLI, Zed Inline, Amazon Q CLI, GitLab Duo Chat, Tabnine Inline — deferred halves of 5 candidates already counted in Tier 1/Tier 2 (Zed, Copilot, Amazon Q, GitLab Duo, Tabnine), not counted again. And two historical: Void (deprecated), Mentat (archived). The archived ones are in the survey anyway, because forgetting what died is how you repeat it.
Tiers describe integration friction, not quality. The tier just answers one question: what does it cost to make this harness honor a gate?
The one hole: exit codes
Here is the mechanism the survey proposes, and the hole it exposes. Real support means the host agent actually invokes the runner — bash skills/flow/runner/flow.sh <command> — parses the exit code, and halts when a gate fails (exit ≠ 0).
The illusion version is simpler and far more common: drop a prompt file that says "follow Flow" into the repo, and the agent nods along. The agent has no bash execution. Or it has bash, runs the gate, gets exit code 1, and hallucinates that the gates passed. The file exists. The enforcement does not.
Prompt file ≠ enforcement. That sentence is the entire article.
Take Devin, candidate 10. Devin's sandbox is isolated in the cloud. The global path ~/.claude/skills/flow does not exist inside it — hypothesized ENOENT. So the runner must be vendored in the repo at skills/flow/runner/flow.sh. Whether Devin honors exit codes and halts its autonomous loop on a gate failure is a hypothesis. The survey flags it "Live Host Trials Pending." Nobody has run it yet.
The hole is not a bug in any one harness. It is the gap between "I gave the agent the rules" and "the rules can stop the agent." One is a document. The other is a mechanism. Twenty-one harnesses, and the survey's honest read is that none of them ship verification as a first-class concept.
Support Thật vs Illusion
The survey's framing, restated:
| Thật (real support) | Illusion (marketing theater) | |
|---|---|---|
| Invocation | Agent calls the runner directly | A prompt file sits in the repo |
| Exit code | Parsed; non-zero halts the loop | Ignored or never read |
| Gate failure | Work stops | Agent declares success anyway |
| Evidence | Receipts written to disk | Vibes |
If your harness integration cannot produce row 1's behaviors, you do not have an integration. You have a README suggestion.
Try it yourself
The runner is one command, no setup:
npx @manhquy/flow-skill@latest
Source: github.com/manhquydev/flow-skill (MIT). A 75-second demo with English narration and subtitles in 5 languages is on flowskill.io.vn.
Honest limitations
Three things this article cannot claim:
- This is desk research. Every verdict above comes from intake evaluations, not live trials. The survey repeats "Live Host Trials Pending," "hypothesized," and "unverified" throughout. I will not launder that into certainty.
- No candidate is designated "Verified Supported." That designation requires passing the Four-Point Live Verification Protocol in the survey's section 1.3. None have been run yet.
- FlowSkill is a discipline layer, not an agent runtime. Per ADR-0001 in the survey: "Flow owns the gates and the receipts, never the runtime." We do not replace your harness. We stand next to it with a kill switch and a paper trail.
Provisional verdicts are still useful — they tell you where to spend trial time first. Tier 1 first, Tier 2 with hypotheses, Tier 3 after something changes. But provisional is the honest word, and it stays until the trials run.
Why this matters now
Agents are getting better at producing code that looks finished. That is exactly why verification matters more, not less. The better the output looks, the easier it is to accept without checking. Every harness vendor is racing on generation. Almost nobody is racing on gates.
I write about this weekly in Proof over vibes, the FlowSkill newsletter — verification debt, gate design, and what the live trials find once they run. If "done" should mean something you can check: https://flowskillharnes.substack.com
Numbers in this article: 21 candidates: 3 Tier 1 + 16 Tier 2 + 2 historical; 5 Tier 3 entries are deferred halves of candidates already counted, from market-harness-survey.md (2026-10-14); 0.34.2 changelog entry (2026-10-15); tier criteria from docs/harness-qualification-process.md. Source repo: github.com/manhquydev/flow-skill.
Top comments (1)
The prompt-file vs enforcement split is the right line, and exit codes are the cheapest mechanism that actually implements it. Two extensions from having hit this myself. First, exit 0 is not evidence. A gate that returns 0 tells you the runner did not object, not that the agent did what it claims it did, so the receipt has to be written to disk by the runner rather than summarized by the model; the vibes/receipts distinction collapses the moment the narration comes from the same agent being judged. Second, halting only works if the agent cannot route around the gate: no bash, or a second tool that performs the same write, and the gate becomes advisory. Fail-closed at the tool boundary, not in the prompt. Wrote a longer version of that argument here: dev.to/galagent/give-your-agent-pe...