Harness-compute separation makes model runtimes replaceable

I think harness-compute separation is what makes model runtimes genuinely replaceable. The decisive move is not adding another provider interface after the agent has already been built. It is dividing the system before that point: the harness owns the reasoning loop, tool dispatch, and memory, while compute owns the environment where commands execute. Once those responsibilities stop sharing an environment and an implementation, an execution runtime becomes a dependency behind a contract rather than part of the agent’s identity.

That boundary changes what the agent is allowed to assume. The harness can run on trusted infrastructure—a CI runner, Kubernetes cluster, or laptop—while commands run inside an isolated sandbox reached through JSON-RPC or a provider API. The reasoning loop no longer needs to know which machine, container, or managed service performed the work. I can preserve the agent’s control logic while replacing the place where its effects happen.

A declarative workspace manifest makes this more than an appealing diagram. It describes what a fresh session requires through provider-agnostic entries: inline files, empty directories, host files or directories, Git repositories, cloud-storage mounts, environment variables, and operating-system users and groups. That description is serializable and belongs to no single sandbox provider. The portability test is unusually sharp—switch the sandbox client class and leave the manifest unchanged.

I see the relative-path rule as the small constraint carrying most of that promise. Manifest paths must be relative rather than absolute, so the workspace contract does not leak one machine’s root layout into every future runtime. An absolute path would couple the supposedly portable definition to a provider’s filesystem conventions. Replaceability is often won this way—not by a grand interface, but by refusing to admit one implementation detail into the shared contract.

The range of compute clients shows why the seam matters. Local Unix execution and Docker sit beside managed or specialized environments for burst workloads, edge execution, previews, and full development environments. A stable harness can choose among those runtime characteristics without rewriting its reasoning loop. The provider may change; the contract describing work does not.

Security makes the same separation valuable for a second reason. Primary API keys and database credentials stay with the trusted harness; the sandbox receives only scoped, time-limited tokens. In a CLI bridge, for example, the model-provider key can remain in the harness process rather than the prompt-injectable execution session. The goal is structural—a malicious injected command inside compute should not be able to reach the central control plane or steal its primary credentials. A replaceable runtime is easier to distrust because authority does not have to travel with it.

Durability completes the argument. If a sandbox crashes or expires, the harness can restore state into a fresh container from a snapshot rather than restart the whole run. Initial state can resolve in a fixed order: reuse a live session, resume durable run state, use explicit serialized session state, or finally materialize a fresh manifest. A durable-workflow integration can extend that mechanism to cross-provider forking—a session can be paused, snapshotted, and moved between runtime types without losing its conversation context.

I concede one precise limit: a provider-neutral manifest does not make every runtime operationally equivalent. Different environments fit different workloads, and the one-line client swap depends on keeping provider-specific filesystem assumptions out of the manifest. Separation makes replacement architecturally possible; it does not erase the need to choose compute whose execution characteristics fit the job.

That distinction is why I would judge an agent platform by what survives a runtime change. The reasoning loop, tool dispatch, memory, workspace declaration, credentials, and recoverable session state should remain on the harness side of the seam. The sandbox should be something the system can select, discard, lose, recreate, or replace. As the harness remains the product, compute can disappear without taking the agent’s identity, authority, or accumulated state with it.