Selecting an agent harness: workload-based recommendation
Turn startup tokens, capability requirements, tool loading, memory, and task cost into a workload-specific base harness choice.
After four measurements, it is tempting to ask for a single winner.
That is usually the wrong shape of answer. Teams are not choosing a harness in the abstract. They are choosing a base harness for a worker: a tax analyst, a code-review specialist, a marketing expert, a support operator, or another domain agent that will need tools, skills, hooks, and production controls.
A coding-oriented harness can be a good default for a repo-heavy review worker and a bad default for a narrow support worker. A minimal harness can be efficient until the workload needs shell access, hooks, code execution, subagents, or a large integration catalog. A harness with low token overhead can still be the wrong choice if it uses too much memory for your concurrency target or takes more turns to finish the task.
Part 5 turns the measurements into a workload-based selection process. It uses the same dimensions from the earlier posts: startup token cost, capability requirements, tool loading, memory footprint, and total per-task cost.
Selecting the right harness
A five-part series comparing candidates for teams building worker agents on top of a harness.
Startup tokens
Fixed prompt and tool-schema tokens before work starts
Capability requirements
Tools, skills, hooks, subagents, shell, web, and code execution
Tool loading behavior
Config-time composition versus runtime loading for large catalogs
Memory and task cost
Memory footprint, task turns, and total per-task token use
Workload recommendation
A workload-specific recommendation and measurement plan
In this post
Start from the worker you are building, not from a single ranking.
At equal capability, the harnesses are closer than their defaults suggest. The decision is usually about workload fit: repo-heavy versus domain-specific, fixed tools versus large catalogs, low concurrency versus high concurrency, short tasks versus long tasks.
Measure the smallest capable profile for your workload before standardizing on one harness.
Measurement summary
All five harnesses can support the basic production bar we tested. That does not make them equivalent.
They differ in four ways that matter for harness engineering:
- How much context they carry by default.
- How much of that default surface area can be removed.
- Whether tools can load only when needed.
- How much memory and total token cost they consume under the real workload.
The practical lesson from the series:
Do not compare the largest default profile of one harness against the smallest default profile of another. Compare the smallest profile that can still do your job.
Workload categories
| If you are building... | Start with... | Why |
|---|---|---|
| A repo-heavy code-review worker | Claude Code, Codex CLI, or DeepAgents | The coding toolkit is not waste if the worker inspects diffs, runs commands, investigates repos, and uses shell frequently. |
| A tax, marketing, support, operations, research, or product worker | Goose, OpenCode, or Claude Code with built-ins disabled | These workers often need a narrow tool set. The win is removing coding tools they will not call. |
| A worker with many integrations, most idle on a normal turn | Goose, or Claude through the API or SDK | Runtime loading helps when a large catalog would otherwise become fixed overhead. |
| A high-concurrency worker product | Goose or Codex CLI as early candidates, then measure | Default memory footprint ranged from about 90 MB to about 516 MB in our measurement, and density matters at scale. |
| A long-running multi-step worker | Run a per-task benchmark before choosing | Turn count and context management can dominate startup token cost. |
This table is a starting point, not a universal ranking. A harness can be the wrong default and still be the right choice for a specific worker.
Cost controls
Whatever harness you choose, the same levers set the cost.
| Lever | Who controls it | What to do |
|---|---|---|
| Tool set size | You | Load only the tools the worker needs. |
| Built-in defaults | Harness and configuration | Prefer profiles that let you remove unused surface area. |
| Runtime tool loading | Harness | Use it when the catalog is large and mostly idle. |
| Context management | Harness and task design | Watch how history, logs, files, and tool outputs accumulate. |
| Workload profile | You | Separate tax, code-review, marketing, support, research, and operations workers instead of forcing one default profile. |
Capability is table stakes. Model choice is separate. The harness decides how the model is put to work, and much of that decision is the tool surface you hand it.
Selection process
Use a small but real benchmark before you commit.
- Pick three representative tasks: one short, one multi-step, and one failure-prone.
- Configure each harness to the smallest profile that can complete those tasks.
- Confirm the capability bar from Part 2.
- Measure startup token cost, memory footprint, turns to completion, and total tokens.
- Check what happens when you add the next likely integration.
That last step matters. Many harnesses look fine with one or two tools. The decision changes when each customer, team, or workflow mounts a different catalog.
Recommendation
For repo-heavy review workers, start with a coding-oriented harness. The extra default surface area may be part of the job.
For tax, marketing, support, research, operations, and product workers, start with the harness profile you can make smallest while keeping the required skills, tools, MCP connections, and hooks. Carrying a full coding toolkit on every turn is usually the wrong default unless the worker uses it.
For high-concurrency products, measure memory early. A harness that is efficient on tokens can still be expensive to host.
For long-running workers, measure total per-task cost. A low startup token cost does not help if the harness takes more turns or carries too much context forward.
The right answer is workload-specific. Karta supports harness-native agent projects because teams will not all make the same choice. The platform layer should let each worker use the harness that fits its job, then provide the production controls around it: identity, releases, isolation, budgets, observability, and rollback.