Isolation is not a prompt
Running one agent framework for several users, I hit session and memory leaking between instances. The fix was not a better system prompt. It was operating-system isolation and a small control plane.
Agents are stateful in a way chatbots are not. They keep sessions, memory, files, credentials and tool connections. When you run one agent framework for many users, all of that state has to stay separate. In my experiments with multi-tenant agent hosting, it did not. The framework I was using had known bugs where session and memory state could leak across instances.
The tempting fix is in the prompt: “Only use information from this user’s session.” That is not isolation. It is a polite request to a probabilistic system, and the data is still sitting in the same process.
Figure 1. Left: one runtime, many tenants, and leaks in the gaps. Right: a container per tenant behind a small control plane. The kernel enforces the walls.
The design I landed on
| Concern | Shared runtime | Per-tenant workspace |
|---|---|---|
| Session and memory | Same process, separated by code paths | Separate container, separate filesystem |
| Credentials | In one process, separated by lookups | Held by the control plane, injected per tenant |
| Blast radius of a bug | Every tenant | One tenant |
| Who enforces the boundary | The application, and hopefully the prompt | The operating system kernel |
| Cost | Lowest | Higher: one container per active tenant |
| Operations | One thing to run | A control plane plus lifecycle management |
The control plane does three jobs: authentication, routing each request to the right tenant’s workspace, and keeping credentials out of the agent containers until they are needed. The design calls for it in Go: small, fast to start and easy to reason about.
The same idea became Hermes Studio: a browser IDE for agents where every workspace is kernel-isolated. Process isolation, not isolation by prompt.
Why this matters inside a company
Every enterprise agent platform will face the same question, just with higher stakes: the HR agent and the engineering agent should not share memory, and an agent acting for one employee must not carry another employee’s context. When you evaluate an agent runtime, ask one question before any other: what enforces the boundary between two users’ agents? If the answer involves the words “instructions” or “system prompt”, keep looking.