Selecting an agent harness: capability requirements
Verify whether a base harness can support the operating pattern your worker agent needs before comparing cost.
A cost comparison is meaningless if one candidate cannot support the worker you are trying to build.
A tax analyst needs reliable document tools, deterministic review checks, and an approval path. A code-review worker needs repo context, policy hooks, and a way to run tests or inspect diffs. A marketing worker may need brand memory, research tools, publishing checks, and customer-specific instructions. If the base harness cannot express those requirements cleanly, a lower token count does not help.
The failure usually appears late. A hook does not fire where a policy check needs to run. Web access exists, but only through an extension that was not part of the deployment plan. A skill loads in one harness and is ignored by another. A subagent model exists, but it cannot use the tool context your workflow depends on.
Those are not feature-list details. They decide whether the worker can run in production.
Part 2 checks the capability requirements for the same five candidates: Claude Code, OpenCode, Codex CLI, DeepAgents, and Goose. All five clear the basic bar we tested. That moves the selection conversation from "can this work?" to "what does this capability cost, and how much control do we get?"
In this post
The capability check should be run against the tool, not copied from a feature-list screenshot.
All five harnesses support the core production bar we tested: MCP, skills, hooks, subagents, code execution, shell access, and web access.
Capability parity does not make the harnesses interchangeable. It moves the selection work to overhead, portability, tool-loading behavior, memory footprint, and per-task cost.
Capability requirements
A production worker agent usually needs more than a prompt and a model. It needs a way to connect tools, run code when the job calls for it, hand work to specialized helpers, and enforce operating rules around the workflow.
For this series, we used a seven-part bar.
| Capability | What it lets the agent do | Why it matters for selection |
|---|---|---|
| MCP | Connect tools through the Model Context Protocol. | Lets the agent reach real systems without hard-coding every integration into the harness. |
| Skills | Load reusable instruction bundles. | Keeps domain process, tool usage, and style guidance outside the base prompt. |
| Hooks | Run code at lifecycle points. | Lets teams enforce checks, logging, formatting, approvals, or policy before and after actions. |
| Subagents | Delegate work to another agent. | Helps split review, research, planning, or execution into separate contexts. |
| Code execution | Run code in a controlled environment. | Needed for analysis, test generation, data work, and many engineering agents. |
| Shell | Run commands against a project or workspace. | Needed for build, test, inspection, file operations, and repo-native workflows. |
| Web | Search or fetch external information. | Needed when the agent must reason over current docs, dependencies, or public references. |
Skills, hooks, and subagents are the easiest to misread from docs. We checked those against the running tools rather than relying only on product language.
Capability matrix
Every candidate clears the bar.
| Capability | Claude Code | OpenCode | Codex CLI | DeepAgents | Goose |
|---|---|---|---|---|---|
| MCP | Native | Native | Native | Native | Native |
| Skills | Native | Native | Native | Native | Native |
| Hooks | Native | Native | Native | Native | Native |
| Subagents | Native | Native | Native | Native | Native |
| Code execution | Native | Native | Native | Native | Native |
| Shell | Native | Native | Native | Native | Native |
| Web | Native | Native | Native | Native | Extension |
The Goose web note matters, but it is not a disqualifier. It means web access is enabled through an extension rather than assumed as a built-in default.
The bigger conclusion is that capability is table stakes. If your worker needs the capabilities above, all five harnesses can be made to do the job. The differences show up in how much default context they carry, how easy the capability is to remove, and how portable your project remains if you change harnesses later.
Verification against running tools
Our first pass recorded Goose as missing hooks. That was wrong.
Goose has a granular hook system with events around shell execution, file edits, and session lifecycle. It is configured differently from the other harnesses, which made it easy to miss if you only scan a feature table.
That is the lesson: if one capability decides your choice, verify it by running the harness. A public doc page can lag the tool, use different words, or hide an important detail in a configuration section.
For a real selection process, make the capability check executable:
| Check | Passing evidence |
|---|---|
| MCP | The agent can call a real MCP tool in a clean project. |
| Skills | A small skill changes behavior without editing the base prompt. |
| Hooks | A hook fires on the lifecycle event you need. |
| Subagents | A delegated task runs in a separate agent context. |
| Code and shell | The agent can run a command and use the result in a later turn. |
| Web | The agent can fetch or search a current external source when the task requires it. |
Portability
One encouraging pattern showed up while checking capability: a shared project layout is starting to emerge.
Goose, Codex CLI, and DeepAgents can read skills and hooks from a similar file layout. That does not make them identical, but it does reduce the cost of moving an agent project between harnesses. If your team expects to support more than one harness, prefer the layout that keeps instructions, tools, hooks, and skills in project files instead of in a proprietary control plane.
Portability is not free. Tool names, event names, and runtime assumptions still need testing. But a project-native layout is a meaningful advantage because it keeps the agent's working contract close to the code and docs the team already owns.
Implications for selection
Do not eliminate one of these harnesses because it cannot do the basic job. All five can.
Instead, use capability parity as the starting line:
- Confirm the harness clears your specific capability bar.
- Measure how much context the harness carries to provide those capabilities.
- Check whether unused tools can be removed or loaded only when needed.
- Measure memory footprint and per-task cost under your own workload.
Capability fit answers "can it work?" The rest of the series answers "what does it cost to work this way?"