TL;DR
“Which AI agent should we use?” is the wrong question, because “harness” now means two different things: the runtime you buy (Claude Code, opencode, Cursor) and the context layer you build (skills, rules, agent docs). Benchmarks show the same model scores differently across runtimes — but as a consultant walking into a different pre-chosen stack every engagement, I’ve learned the second harness matters more. Pick the harness you can leave, and keep your workflows in a portable layer that survives the tool.
Originally published at portfolio.hagzag.com
The Harness Is Chosen Before I Arrive
Every engagement starts the same way. I walk in as a consultant, and the AI decision has already been made — usually by procurement, security, or whoever got budget approval first. One client standardized on Cursor. Another is all-in on Claude Code. A third runs everything through Bedrock because that’s what their AWS enterprise agreement covers, and a fourth is a Vertex shop for the same reason on the Google side.
Nobody asks me which harness I prefer. The harness is a constraint, like the cloud provider or the CI system.
And here’s the uncomfortable part: if my skills, hooks, and slash commands only live in .claude/, I’m useless at the Cursor shop. If my workflow is a pile of .cursor/commands, it evaporates at the Claude Code client. I’ve spent months building an agentic workflow — versioned skills, CLAUDE.md schema layers, MCP server profiles — and the first time I sat down at a client that used a different runtime, I realized I’d built a one-trick pony. The knowledge was mine; the format belonged to a vendor.

“Harness” Means Two Different Things Now
The industry has quietly overloaded the term, and the confusion is costing teams real decisions.
The harness you buy is the runtime: the agent loop, tool dispatch, sandbox, permissions, context compaction. This is what Artificial Analysis benchmarks and what The Tool Nerd’s top-10 list ranks — Claude Code, Codex, Cursor, opencode, Pi, Cline, Goose.
The harness you build is everything you layer on top: the AGENTS.md constitution, the safety rules, the feature docs, the codified skills, the scoped subagents. The Activepieces team wrote an excellent 6,000-word breakdown of this layer, and their core claim matches my experience exactly: the bottleneck isn’t model capability, it’s the tribal knowledge you did or didn’t encode.
When someone asks “which harness should we choose?”, they’re usually asking about the first kind. The leverage is almost always in the second.
What the Benchmarks Actually Say
The runtime does matter — measurably. Artificial Analysis now publishes a harness comparison that holds the model constant (Claude Opus 4.7) and runs it through Claude Code, Cursor CLI, and opencode. Same brain, different scores. The harness is doing real work: prompt assembly, tool ergonomics, context management all move the needle on their composite index across DeepSWE, Terminal-Bench v2, and SWE-Atlas-QnA.
You can read that data as “opencode is the best harness” — and there’s a defensible version of that argument. Opencode is MIT-licensed, model-agnostic, the most-starred open-source coding agent of 2026 (~176k stars), and it performs competitively while letting you swap the underlying model freely. If a benchmark tells you the runtime is somewhat interchangeable, the rational move is to pick the runtime that doesn’t lock you in.
But notice what that argument actually proves: the deltas between good runtimes are real but modest, while the delta between a harnessed and unharnessed codebase is dramatic — Activepieces reports first-try success on routine features going from roughly 20% to 70% after building their context layer. No runtime swap gives you that. Your feature docs and skills do.

The Portability Test
So here’s the selection criterion I now apply before anything on a leaderboard: can my built harness survive leaving this runtime?
This is where the open projects earn their keep — not necessarily as daily drivers, but as portability tests. OpenHarness (HKUDS) is a readable Python implementation of the full harness pattern — agent loop, 43 tools, permissions, hooks, subagents — that deliberately consumes the same formats the commercial tools use: SKILL.md directories compatible with anthropics/skills, Claude Code plugins, CLAUDE.md discovery, and skill loading from .agents/, .claude/, and .openharness/ alike. It even bridges providers: Anthropic API, OpenAI-compatible endpoints, Copilot OAuth, local Ollama.
If your skills load and run in a second, independent harness, they’re portable knowledge. If they don’t, they’re vendor config. That’s the whole test. The Activepieces symlink trick — one canonical .agents/ folder, symlinked into .claude/, .cursor/, and whatever drops next month — is the same principle applied defensively.
For my own hagzag-platform monorepo, this reframed everything. My blog-post skill has been through four versions; my meeting-summary and vblog skills encode workflows I use weekly. The moment I treated them as Markdown-first artifacts in a tool-neutral layout rather than “Claude Code configuration,” they became assets I carry between clients regardless of which runtime procurement picked. The consultant’s moat isn’t knowing a tool. It’s carrying encoded workflows that run on any of them.
What I’d Do Differently
I built tool-first, and I paid for it. My early skills assumed Claude Code’s exact invocation model; my slash commands leaned on its specific plumbing. Rebuilding the same agentic workflow for a second runtime at a client site is dead time nobody bills for — you’re re-deriving your own tribal knowledge in a new dialect. If I started today, I’d write every skill as if three harnesses would consume it, keep runtime-specific glue in a thin adapter layer, and verify portability against an open implementation before calling anything “done.”
The trade-off is honest: the lowest-friction experience today usually comes from going deep on one vendor’s harness, and portability costs you some of that polish. I accept that cost, because I’ve seen what the alternative costs.
Conclusion
Choose your runtime harness on pragmatic grounds — benchmarks, licensing, whether it fits the client’s existing model access through Bedrock or Vertex. Opencode’s numbers and license make it a strong default if the choice is yours; often it isn’t, and that’s fine. Then put your real investment where the compounding happens: skills, rules, and docs in a format that any harness can load.
The model is rented. The runtime is chosen for you. The only harness you actually own is the one that fits every horse.
Discussion