Herm

The deciding trait is the silence. Because the agent runs inside a container that can only see the directory you started in, it does not stop every ninety seconds to ask whether it may read a file, and you stop being a rubber stamp. Anyone who has approved forty prompts in a row without looking will recognise what that fixes.

The cost is that Docker has to be there and working, which on some machines is its own afternoon. Pick it when the interruptions are what you actually hate about agents. Pick a host-based agent when your laptop and containers have an unhappy history.

The boundary is editable by the thing it bounds. When the agent needs a tool it does not have, it writes a Dockerfile and rebuilds, which is elegant and puts the definition of the enclosure in the same hands as the code inside it. The row scopes those files per project and says nothing about what they may contain.

A mount, a network flag or a privileged directive is one line, and nothing documented reviews these files before they are built. What it does right is scoping them per project, so the blast radius of a bad one is a single working directory rather than a machine.

1. Treating model choice as a property of the task rather than of the session is the correct decomposition. Exploration is cheap and repetitive, synthesis is expensive and rare, and vision is a separate capability entirely; paying one price for all three has always been an accident of interface design rather than a decision.

2. What is not described is how the roles hand off: what an exploration model returns to the main agent, and in what form, determines whether the split saves cost or loses information.

3. No evaluation accompanies the arrangement, so the saving is asserted. The design will survive model changes, which is its strongest property.

The engineering here is better than the numbers, which is a common and expensive combination. Careful isolation work and per-role routing take months and attract no users on their own, and there is no entity, no revenue and no funding to buy the distribution that would fix that.

Moat: none, though the isolation work is genuinely harder to copy than a wrapper. Likely path: the ideas end up in a funded competitor and the author is thanked in a changelog. Position: use it, and expect to be the one who reports the bugs.

The prerequisite is the project. Containers by default means a working container runtime on every developer machine, licensed and supported, which on this fleet is a piece of work with its own budget line. Where that already exists, the isolation is a straight win and the security conversation gets shorter.

Distribution is a tap or an install script, so version pinning is ours to arrange. No single sign-on, no directory sync, no audit export, and nothing that runs unattended. Sixty seats cost nothing beyond the provider keys. Approved with conditions: only on machines where the container runtime is already managed by us.

Open system prompts is the line that separates a tool I use from a tool I own. When it behaves stupidly I open the prompt and fix it, rather than filing an issue and waiting two releases, and the skills and tools are the same: files, not a plugin API with a blessed surface.

Nine providers with Ollama among them means my own weights are a first-class option rather than a footnote, and MIT keeps the fork viable. The one gap is protocol support, so the servers I run stay outside. Grudging respect, and this is the closest thing to ownership on the shelf.