Your agent has spent the week fixing failing tests on your laptop, inside a rootless container you started once and stopped thinking about. Now it has to run in continuous integration, on hardware shared with other people’s jobs, and the review says the thing executing model-written code needs a kernel of its own. You open the orchestrator expecting a bad afternoon: how it picks work, the branch it commits to, the pipeline that checks the result before anything merges. What changes is the line that builds the sandbox. Nothing else in the agent ever knew which sandbox it had.

A channel doesn’t care what is patched in

Every channel on a recording console has an insert point: a break in the signal path, a send and a return, wired to a standard connector. A compressor goes across it tonight. Tomorrow it is a different one borrowed from downstairs, or a plug-in doing the same job in software, or a short cable that returns the signal untouched. The channel was built to the fitting, not to the box. Nobody rewires the console when the box changes.

An isolation provider is that insert point. The orchestrator is handed one object that knows how to make an environment, and behind it sits a bind-mounted directory, a rootless container, a microVM, or something written in-house. The agent works inside whatever it was given, puts its commits on a branch, and the verified result gets integrated the same way regardless. Locally that is Podman; in the pipeline it is a remote microVM; the agent code and the review path are untouched because only the factory behind the interface changed.

There is one thing you can patch in that you will regret. A provider that does no isolation at all makes the interface complete and the API tidy, and it belongs nowhere near an environment with real risk. Left in as a default, it is the bypass cable somebody meant to remove: the signal path looks the same and the host filesystem is now in it.

Limits belong to the take, not the evening

The other half is what the sandbox is allowed to consume, and the habit is to set that once, on the container, for the whole run. That is one limiter on the master output with its threshold chosen for the loudest moment of the night. You either hold the worst case open all evening, wasting capacity that nobody else can borrow, or you set it tight and clip when the burst finally arrives.

Tool-call-aligned resource control moves the setting down to the individual call. The agent declares the intent of a call, or the intent can be inferred, and a controller maps that phase onto a cgroup hierarchy the kernel enforces — the scheduler, the memory cgroup. A compile needs a brief spike of memory. A search call does not. The controller opens headroom for the compile under a tight cap and takes it back the moment the call ends, so a shared tenant is not carrying a permanent worst-case reservation that starves every other agent on the machine.

This is worth the trouble because of where the time and the ceiling actually are. In a coding agent much of the latency sits in operating system execution rather than in the model, and memory usually decides how many runs fit side by side. Size it from the average and the tool-driven peaks kill you; freeze it as a static quota and you have put a fixed number on a workload that is neither deterministic nor stateless. The failure is quiet, too. A run killed for exceeding memory comes back looking like an agent that gave up halfway, and gets debugged as a reasoning problem for a week.

The isolation is a capability, not a fixture

Attaching limits to the call is what makes the box underneath replaceable. The policy — how much this kind of work may consume, how far it may reach, when the grant is revoked — now lives above the provider, written where you can read it, instead of being implied by whichever runtime somebody picked. Any provider that can honour it will do, and the ones that cannot are visibly disqualified rather than quietly trusted.

That puts isolation where it belongs: a capability of the harness, adjustable without touching orchestration or tools, and not a property of the framework or the model vendor you happen to be on. It is the same seam as the one between the model and your software, drawn one layer lower.

Decide what a single call may consume. Then the machine enforcing it is a choice you can change on a Tuesday.