Harness as a Service sells you the box. The harness is the verifier.

The pricing page has three tiers and a diagram. The diagram is a set of concentric rings with “agent loop” written in the middle, and the rings say things like execution, memory, observability, governance. The tiers are priced per sandbox-hour, with a cold start measured in milliseconds and a maximum session length in the fine print. Somewhere on the page, usually above the fold, is the sentence: your agent needs a harness. Then the buy button, which sells you a virtual machine.

I want to separate two things that this page runs together. One is the observation that an agent in production is more than a model call, which is correct and overdue. The other is the implication that the missing piece is isolated compute you should be paying for by the hour, which is a sales motion wearing an architecture diagram. The harness is a real thing. The box is a small part of it, and not the part that makes your agent work.

The catalogue gets the decomposition right

Hermosa’s Harness-as-a-Service survey is the best map of this market I have read, and I want to credit it before I argue with the framing it has been pulled into. It walks 44 harness-layer products out of a broader catalogue and refuses to treat them as one category. There are hosted runtimes, where a vendor operates the loop and the state. There are SDKs, where you own orchestration and therefore own scaling and recovery. There are sandboxes, isolated compute for running code. And there are browser services. Two things both called “agent platform” can leave you with completely different responsibilities, and the survey is good at saying which.

That sentence is the one to keep. The state architecture shapes the application more than the model does, which is another way of saying the harness is where your agent’s behaviour actually lives. The survey also makes two smaller points that deserve wider circulation: MCP reduces tool coupling but not platform coupling, because state, execution, identity and observability still bind you to a runtime; and the pricing units across these products (credits, tokens, invocations, compute time, browser hours) are not comparable without a defined workload including idle time and retries. If you are choosing a vendor, read it.

What I want to push on is what happened to the word once the catalogue existed. A survey of four markets became a category, and the category acquired a shape: the harness is the stuff around the loop, the stuff around the loop is mostly infrastructure, and infrastructure is what you buy. Each step is a small slide. The sum is a definition of harness that leaves out the only part I have ever seen decide whether an agent shipped something good.

The sandbox is a real need and a sales motion

Let me be fair to the box first. There is a use case for a VM around agent code and I have seen it: you are running experimental agent output, code the model wrote a minute ago, and you need to show somebody, a security team or a customer, that whatever it does cannot reach anything that matters. A microVM with a filesystem policy and a network policy is a clean answer to that question. Hermosa lists the isolation technologies honestly, Firecracker microVMs, gVisor, pre-warmed pools, plain machines, and notes that runtime, startup, session length, filesystem policy and network policy matter more than any single winner. Fine. All true.

Now look at what is being sold. The pitch is not “here is a seatbelt for experimental code.” The pitch is that isolated compute is the harness, that every agent needs one, and that the natural unit of purchase is a sandbox-hour with a per-seat multiplier. The economics are obvious from the vendor side: a VM is meterable, a verification strategy is not. So the meterable thing gets the diagram, the concentric rings, and the word.

The claim that you need a hosted box collapses on contact with your own laptop. Claude Code’s sandboxed Bash tool uses macOS’s built-in Seatbelt framework, with nothing to install, to enforce filesystem and network boundaries on every command and its child processes. On Linux it uses bubblewrap and socat. Apple ships container, which runs Linux containers as lightweight virtual machines on Apple silicon under macOS 26. A tiny sandbox that lives on your Mac, starts in a blink, and costs nothing per hour is not a research problem. It is a package you already have.

The honest caveat: a Seatbelt profile shares your kernel and admits whatever your policy admits, so it is a boundary you configure rather than a wall you were handed. That is the right trade for code you are iterating on and reading. It is the wrong trade for code you distrust, which is exactly the case where isolation itself is the deliverable and renting the box is correct. Rent it then. Use the one on your machine for everything else, which is nearly everything. And in neither case have you built a harness yet. You have built a place to run one.

The loop is a process, and the harness is whatever wraps it

The second misconception is quieter. Even people who are not selling VMs tend to describe the harness as the layer that collects metrics: traces, evals, a dashboard with token counts. Instrumentation is part of it. It is not the definition. The harness is the architecture around a stateless model call, and it has a recognisable set of parts: memory and data, inference and a router that picks which model gets which request, the loop itself, and the output surface that decides what the result looks like to whoever is waiting for it. I wrote the long version of that elsewhere; the short version is that the harness is the part you own.

None of those parts is fixed. The same components morph into a single-agent loop, a planner with workers, a chain of handlers, a pair of agents arguing, and the harness is the name for whatever configuration you end up with. Which is why I have stopped saying “agentic loop” and started saying process. You can object that this is a rename, and I would agree if a loop were an accurate description. It is not. “Loop” says something repeats: a while, a for, a tool call followed by a model call followed by a tool call. That is a cartoon of what runs. What runs has preconditions that must hold before a step is allowed, guardrails that can veto a step mid-flight, state that is written and read without ever appearing in a transcript, budgets that end it early, and side effects that outlive it. Those components are invisible in the word loop and central to the word process.

The rename changes what you build because it changes what you are forced to name. A process has an entry condition, a resource envelope, an owner, a list of things it may touch, and a defined end. Draw the harness around a loop and you draw a while and a max_iterations. Draw it around a process and you have to write down the guards, the ledger, the budget and the stop condition, which is the actual work. And once you have drawn it that way, one more component appears in every harness I have seen that had to produce something real. It grew a second system whose only job is to check the first one.

The pattern everyone meets: verification

Give an agent a task and a loop and it will finish. It will finish confidently, with a summary of what it did, and the summary will be consistent with its own assumptions, because the summary was generated by the same process that made the assumptions. Nothing inside the loop can tell you the assumptions were wrong. So you build something outside it: another agentic system that verifies the result, or tests the boundaries, or attacks the interface, or walks through the thing the way a human user would and reports whether it arrived where the requirements said it should. That second system is the harness’s verifier, and it is the component that turns an agent that produces output into an agent that produces outcomes.

It can be a unit test. It should not only be a unit test. A unit test checks that a function does what the agent that wrote it, and the agent that wrote the test, jointly assumed it does. Both of them share the same blind spots because both of them sat inside the same context window. Delta verification is one way to break that: measure the environment before and after and diff. But the starting point I reach for is the integration test, because integration is where the assumptions meet things the agent could not have known.

Take a backend endpoint. The agent adds POST /invoices/{id}/refund, writes a handler, writes a migration, writes a unit test that mocks the payment client, and reports done. An integration-shaped verifier does something different. It starts the service, runs the migration against a real schema, hits the endpoint with a real request, checks that the row changed, checks that the downstream call to the payment provider went out with the right idempotency key, and checks that the health endpoint still answers afterwards. Every one of those steps is a place where the agent’s assumption could have been silently wrong: the migration that references a column renamed last month, the client that needs a header the mock never required, the deploy that fails on an environment variable the agent never saw. The unit test passes through all of them. The integration run stops at the first one.

Agents are bad at integration tests. That is your design problem.

The strongest objection I get is that agents are terrible at running integration tests, and it is true. Hand an agent a test that needs a running database, three downstream credentials and a deploy target, and it will spend forty turns fighting Docker, then quietly switch to a mock and call it green. But I would turn that around. It is your job to design a system where integration tests are easy to describe and easy to execute, and that job existed before agents. Teams that had a one-command staging environment before 2024 have agents that verify. Teams that needed a wiki page and a VPN ticket to run one integration test have agents that mock.

The shape that works is what I would call an agent environment: a tiny replica of the production setup that the agent can stand up by itself. Not a copy of production with real credentials, which is the thing everyone rightly refuses to give a model. A hybrid. The service runs locally against a local database that already holds every row the tests need, seeded and disposable. Alongside it sits an integration database that mirrors the real schema, where the agent has read access to the structure and can push and read test data, but cannot alter the schema without asking a human. The downstream services are either real sandbox tenants or faithful local implementations with the same contract. Everything the agent needs to prove the trajectory is inside the fence, and nothing it could damage is.

This is analogous to the staging environment people have always used for testing, with one difference that matters: it is built to be described in a paragraph and started with one command, because the thing starting it is not a person who can improvise. The definition has to be precise. Which database, which seed, which ports, which downstream twin, which command proves health. Write that down once and the integration verifier stops being the thing your agent avoids and becomes the thing it runs on every turn.

Who verifies the verifier

The second objection is sharper. A verifier built from the same spec, by the same model family, shares the spec’s mistakes. The refund verifier checks that the idempotency key went out because the spec said so, and never checks that a refund over a threshold needs a second approver, because nobody wrote that down. Moving verification one layer out moves the assumption problem one layer out with it.

Partly true, and the answer has two halves. The first is that the verifier does not have to be as clever as the agent it checks. Build the much simpler version first, or even just describe it: the service starts, the migration applies, the endpoint answers, the row changed, the downstream call went out. A simple verifier has fewer places to be wrong than the implementation, and an integration run catches an entire class of failure, the environment disagreeing with the agent, that has nothing to do with the spec. That class is most of what breaks in practice.

The second half is that the residue is a human problem and should be. When the verifier’s requirements are themselves controversial, when the spec is silent or two clauses pull against each other, no automated system can reconcile that. The human in the loop is not there to rerun the checks. They are there to settle what the checks should be. You can ask an agent to inspect the verifier’s spec for gaps and it will find some, but the final word on a controversial requirement belongs to the person accountable for the product. That is a smaller, better-defined job than “review all the code,” and it is the job worth keeping.

Measuring the implementation trajectory

That reframing is the whole idea. The harness is not there to prove that the output is correct in the abstract. It is there to measure the implementation trajectory: the path from the spec to the point where a user gets what they asked for, and whether the work is actually moving along it. Each verification point is a fix on that path. A unit test is a fix taken very close to the agent, where its assumptions still hold by construction. An integration run is a fix further out. A deploy health check, further still. The further out the fix, the more of the world it has had to agree with, and the more it is worth.

The interesting problem is the end of the path. In many cases the true final point cannot be measured by the harness at all, because it is a human customer noticing that the interface makes sense, that the payment cleared, that the product does the thing. No verifier inside your process has access to that. What the harness can do is place its last validation point as close to that boundary as it can get: not “the function returns the right value” but “a scripted user, starting from a cold browser, completed every step the requirements describe and the money moved in the test ledger.”

What is the baseline for that claim? A scripted user in a cold browser is not a production customer, and I am not pretending otherwise. The baseline is a human developer. It is what you would have done by hand before calling the feature done: open it, click through it, pay with the test card, look at the ledger. The near-boundary check automates exactly that walk, no more. If the trajectory has been measured to that point and every fix along it held, you are not certain the customer will be happy. But you are about as sure as the developer who tested it themselves would have been that the customer can complete the steps you promised, which is a different claim from “tests pass” and a far more useful one.

This is also where the human belongs, and it is not where the sales page puts them. The human looks at the trajectory itself and asks whether it is the right one. Is this path optimised, or is the agent taking a detour through three abstractions it invented? Is it simple enough that the next agent can follow it? Should we abandon this track for another one entirely? Those are judgement calls about direction. The harness handles the measurement of position; the human handles the choice of destination.

What you are actually buying

So when the page says your agent needs a harness, agree with it, and then check what the buy button does. If it provisions a microVM, you have bought a floor for the process to stand on. Useful, occasionally necessary, and available for free on the machine in front of you for the vast majority of what you will run. If it wires up traces and a dashboard, you have bought instrumentation, which tells you what the process did but not whether it should have. Neither of those is the thing that decides whether the work is good.

The harness that matters is the one you build around your own boundaries: the agent environment that stands up in one command, and the verifier that starts the service, runs the migration, calls the endpoint, checks the downstream call and the deploy, and walks as far toward the customer as an automated system can walk. It is specific to your system, which is exactly why nobody can meter it. An agent without one produces confident output. An agent with one produces a measured trajectory, and the gap between those two is the entire difference between a demo and a product.

Build the verifier. Rent the box if you must. Do not confuse the receipt for the harness.