Harvey built our pitch deck. They were writing about themselves.

Harvey published a post explaining why they built their own agent runtime. Read it closely and it's a description of the layer we're building.

Harvey is one of the most valuable AI companies in the world. They moved from a chat product to cloud agents — agents that review a data room and produce a first-pass issues list across hundreds of thousands of documents. To run that, they built their own runtime. Managed runtimes exist now, from the frontier labs and from the cloud providers, and Harvey works with all of them. They still run their own.

The post is a precise, unsentimental explanation of why. Three reasons. None of them is about law.

Multi-model isn't a feature. It's the floor.

Harvey's first reason is that they can't be locked to a single model. The obvious version is conflicts — a firm can't route a client's matter through that client's competitor's model. The sharper version is platform risk, and agents make it acute. Commit to one provider's runtime and it isn't just your model that's locked in. It's your whole agent workforce — the agents your team built, tuned, and came to depend on, living inside that provider's formats and orchestration. You can't pick them up and move them.

So Harvey built an abstraction layer that normalizes the harness, the sandbox, and the behavioral differences between providers, so that above it, the choice of model is just a routing decision.

That sentence is the thesis. The model should be a routing decision, not a foundation you pour concrete around. That's how we build, too: model-agnostic by construction, bring your own keys, we never proxy the call. The day a cheaper model clears your quality bar, you move — without re-platforming.

Zero retention is architectural, not a setting

Harvey's second reason is zero data retention. Their point is that it can't be bolted on. Store the data during the run and call a delete endpoint after isn't zero retention — it's retention followed by deletion, and for a privileged matter those are not the same thing.

And agents make this harder than chat ever did, because agents are stateful. A long-running agent accumulates working memory, intermediate files, tool results, recovery checkpoints. A managed runtime earns its keep by persisting all of that for you — in its cloud. That persisted state is your customer's data sitting at rest in someone else's environment. Automatic persistence and zero retention are mutually exclusive.

This is the reason that cuts hardest at anything hosted, including us, and it's worth being straight about. The answer isn't a deletion job. It's the boundary: execution runs on a substrate you control, state scoped to the session and purged, with a self-host path for the buyers who gate on it. The honest framing is a direction we build toward deliberately, not a checkbox — because Harvey is right that you can't toggle it on at the end.

Cost is becoming the whole game

Harvey's third reason, and the one they say matters most, is cost. Serving the most capable models as agents at scale is extraordinarily expensive — a single run can be hundreds of model and tool calls over a large corpus. Route everything to the best frontier model and the per-task cost is not sustainable.

Their insight is that most tasks no longer need the largest model. The work is intelligence-saturated — it sits well within reach of a smaller model, and the frontier model is overspending capability the task doesn't require. Route each task to the cheapest model that clears the quality bar and they see 3-5x cost reductions. They're blunt about why no one renting a runtime can match that: the control isn't exposed to you.

This is the part people misread as a separate product. It isn't. Cost falls out of owning the layer. Own execution and you can attribute every dollar to a tenant and an item, set a budget that pauses a workload instead of surprising you at month-end, and route to the model that's good enough. Cost control is a property of the layer, not a gateway you bolt on the side.

The part the post doesn't say out loud

Harvey's conclusion is: own the runtime. That's correct — for Harvey. But look at what it takes to act on it. A normalization layer across every provider's harness, sandbox, and failure modes. Hosted open models. Retention engineered out of the architecture, not deleted after the fact. That's a dedicated infrastructure org and the runway to staff it for years — the kind of investment that only pencils out when agents are your core product and you're funded to match.

Everyone else running agents in production has the same three requirements and none of that runway. So they assemble the layer out of parts: a queue, a framework, a tracer, an evals notebook, a per-tenant config that nobody owns. Six services in a trench coat. Every layer reports success on the thing it tracks, and the failures live in the seams between them.

The workload layer

That's the layer. The three properties Harvey had to build by hand — multi-model by routing, execution in your boundary, cost attributed per item — delivered as a product instead of a two-year project.

Harvey proved the layer has to exist. The whole post is the proof: the most capable team in their market looked at every managed runtime on the market and decided the only way to meet their requirements was to own this layer themselves.

We think that conclusion is right and the cost of acting on it is wrong. So we're building the workload layer — so that owning it is something you adopt, not something you have to build.