Quick answer
Harness as a service, defined
Harness as a service (HaaS) is cloud infrastructure that runs agent harnesses for you: hosted sessions, sandboxes, streaming, files, and reviewable artifacts behind an API.
An agent is a model plus a harness. The model supplies reasoning; the harness supplies everything that turns reasoning into finished work: the execution loop, tools, context management, permissions, and an isolated place to run. Harnesses such as Codex, Claude Code, and Hermes are where practitioners increasingly look for reliability and cost differences, a shift that 2026's wave of harness engineering writing made mainstream.
HaaS applies the oldest pattern in cloud to this new layer. Just as AWS sells compute you do not rack yourself, a HaaS provider operates the harness infrastructure your product would otherwise have to build and run: session lifecycle, sandbox isolation, streamed progress, file intake, and artifact return.
The term is young. As of mid 2026 it shows up in newsletters and practitioner blogs without a settled definition. Here is ours, from a team operating this layer in production.
Why now
The harness became the story in 2026
Through 2026 a growing body of practitioner writing pushed one argument into the mainstream: as model capabilities draw closer together, the harness around them increasingly decides whether an agent is dependable. Martin Fowler's site published a widely shared treatment of harness engineering, Addy Osmani wrote a practitioner guide to the same discipline, Databricks published a definitional explainer on agent harnesses, and Microsoft made the agent harness an official concept in its agent framework at Build 2026.
The same wave hit Chinese tech media, where coverage went further into economics. A widely shared report from the tech outlet 36Kr found that identical work across three harness frameworks consumed up to 30x more tokens on the most expensive setup than on the cheapest. Sell-side research in China now describes model vendors as racing to build out the harness layer itself.
When major labs are each building their own harness, and measured differences between configurations reach multiples rather than percentages, running and comparing harnesses stops looking like a side task. For products that depend on agent work, it starts looking like infrastructure. That is the demand HaaS answers.
The landscape
Managed agents: the single-vendor form of HaaS
The best-known managed offerings in this space are single-vendor. Anthropic's Claude Managed Agents (public beta, April 2026) hosts Anthropic's own agent loop behind a REST API. Google's managed agents in the Gemini API (public preview since I/O 2026) do the same for the Gemini stack, and Google itself describes the offer as a configurable agent harness. Both are genuine HaaS: a harness someone else operates. But each operates exactly one vendor's harness.
A product that commits to one of them inherits the old problem one level up: its backend couples to a single vendor's sessions, state, and permissions model, and every other harness remains a separate integration.
HaaS does not have to stop at one vendor. A multi-harness HaaS puts one contract over tasks, sessions, streaming, files, and artifacts, with the harness itself as a request parameter. That is the difference between renting one vendor's agent loop and holding a stable interface above several.
Taxonomy
Agent as a service (AaaS) vs harness as a service
Harness as a service overlaps with agent as a service (AaaS), and the relationship is worth stating precisely. In its broad sense, agents as a service means agents delivered through an API on managed infrastructure, and a HaaS is exactly that: send a task, a hosted agent runs it, work comes back. In its business sense, AaaS means finished agents sold as digital workers: a support agent, a research agent, an outcome-priced replacement for a software seat. Analysts use the business sense when framing AaaS as the successor to SaaS.
So a HaaS is agents as a service at the infrastructure level, and it is also the layer that digital-worker products build on instead of operating their own harness stack. One layer serves both readings of the term.
| Capability | SaaS | AaaS | HaaS |
|---|---|---|---|
| What you buy: software features by subscription | Core capability | Not this layer's primary job | Not this layer's primary job |
| Agents that do the work, delivered as a service | Not this layer's primary job | Core capability | Core capability |
| Infrastructure that runs agent harnesses, any vendor's | Not this layer's primary job | Not this layer's primary job | Core capability |
| Primary buyer is a developer or product team | Varies | Varies | Core capability |
If you are building an AaaS product, HaaS exists so that sessions, sandboxes, streaming, and artifact handling do not all have to be built in-house before the actual product ships.
Economics
The build-vs-buy math
The build-versus-buy case is measurable, and the full result table lives on the benchmark page rather than here. Two findings from HarnessRouter's same-task benchmark matter most for this decision. First, six of the eight tested configurations were dominated: another configuration in the same test was both cheaper and faster. Put differently, three out of four setups in that test had a strictly better alternative available, which is poor odds for a default chosen without measurement. Second, the harness is an independent operational lever: with the model held constant, switching only the harness moved cost by 1.5x to 2.1x and end-to-end latency by up to 1.95x.
Independent reporting points the same direction: Chinese tech press has reported up to a 30x token spread between harness frameworks on identical work. Exploiting differences of this size is an operations problem, and absorbing that work is exactly what a managed harness layer is for.
The full result table, methodology, and objective quality evidence are published on the benchmark page, and live usage across reviewed harnesses is on the agent harness rankings.
Buyer checklist
What to evaluate in a harness as a service
Any vendor can publish a definition. If you are comparing HaaS options, these are the questions that separate a managed layer from a thin wrapper.
- Isolation: does every session run in its own sandbox, and what happens to untrusted input?
- Durability: do sessions survive long tasks and dropped connections, and can a run be recovered and continued?
- The streaming contract: can your UI render progress from the event stream, and is the format documented and stable?
- Artifacts: are produced files stored, listable, and retrievable per session, with ownership you can enforce?
- Harness coverage: which harnesses run behind the interface today, and is switching a parameter or a project?
- Comparability: can you send the same task through different configurations and get results you can measure against each other?
- Cost mechanics: is pricing published, and can you attribute spend to tasks instead of reverse-engineering a monthly bill?
- Exit: if you leave, what leaves with you, and how much of your integration was provider-specific?
In practice
HarnessRouter: multi-harness HaaS
HarnessRouter is the world's first unified interface for agent harnesses, operated as a service. In practice that means HarnessRouter owns the operational work: provisioning and warming sandboxes, isolating every session, keeping harness integrations current, streaming progress, storing and returning artifacts, and recovering from failed runs. Your team keeps the product: the tasks you send, the experience around them, and the policies that govern them.
Because HarnessRouter operates Codex, Claude Code, and Hermes behind the same contract, the comparison infrastructure comes with the layer: send one task class through several configurations and route on the measured result.
FAQ
Harness as a service: common questions
What is harness as a service?
HaaS means a provider runs the agent harness infrastructure and you consume it through an API. The provider owns sandboxes, session lifecycle, streaming, and artifact handling; you own the tasks you send and the product around them.
How is HaaS different from Claude Managed Agents or Google's managed agents?
Those offerings each operate one vendor's harness: the single-vendor form of the pattern. The multi-harness form extends it with one contract across harnesses such as Codex, Claude Code, and Hermes, with the harness as a request parameter. HarnessRouter provides that multi-harness layer.
Is HaaS the same as agent as a service (AaaS)?
They overlap. In the broad sense of agents delivered as a service through an API, a HaaS qualifies: hosted agents run your tasks and return work. In the business sense, AaaS means finished agents sold as digital workers, and HaaS is the infrastructure layer those products build on. HarnessRouter serves both readings: it delivers agents as a service and it is the harness layer underneath digital-worker products.
What does HarnessRouter's HaaS include?
HarnessRouter manages the infrastructure side: sandbox provisioning and isolation, session lifecycle, harness integrations and their updates, streaming, artifact storage and return, and the comparison tooling across configurations. You keep the product side: which tasks you send, your user experience, and your policies.
Rent the harness layer, keep the product
Run managed agent harnesses through one API and route each task to the configuration that earns it.
Start building free