Agent tenancy is a state-isolation problem before it is a compute-isolation problem

Multi-tenant agent platforms often start with compute isolation: each tenant gets separate containers, separate VMs, separate everything. But tenancy failures don't happen at the compute layer — they happen at the state layer. When tenant A's agent reads tenant B's memory, or when tenant A's credentials work on tenant B's database, container boundaries didn't fail. State isolation did. Agent tenancy is a state-isolation problem before it's a compute-isolation problem.

The commercial agent runtime landscape has converged on this insight independently. Amazon Bedrock AgentCore Runtime's tenancy patterns — silo, pool, and bridge — are fundamentally about state isolation, not compute. The silo pattern gives each tenant a dedicated session store; the pool pattern shares infrastructure but namespaces state by tenant ID; the bridge pattern lets you move data between tenants under explicit policy. All three run on the same microVM substrate (Firecracker), so the compute isolation is identical. What differs is how state is namespaced and accessed.

The session as the addressable unit

AgentCore's session model is instructive: the session is the addressable unit of isolation, not the container. Each session carries its own memory namespace, its own identity context, its own cost attribution tags. The session lifecycle — create, execute, suspend, resume, terminate — is the state lifecycle. When a session suspends, its state persists; when it resumes, it picks up from that state. The compute can move between hosts; the state follows. This is the right abstraction: the session is what the tenant experiences as "their agent."

Vercel AI SDK's WorkflowAgent, Mastra's suspend-and-resume, and Agno's AgentOS all arrived at the same pattern: durable execution with state checkpoints. The workflow suspends at I/O boundaries, serializes its state, and resumes when the I/O completes. The state is what matters — the compute is ephemeral. For multi-tenancy, this means the state store must be tenant-namespaced, even if the compute isn't.

Identity and the confused deputy

State isolation requires identity isolation. The confused deputy problem — an agent acting for tenant A accessing tenant B's resources — is an identity failure, not a compute failure. AgentCore's identity model addresses this with the "act on behalf of" pattern: the agent authenticates with its own identity, then requests credentials scoped to the tenant it's serving. OAuth 2.0 token exchange (RFC 8693) enables this: the agent exchanges its token for a downscoped token that carries the tenant's permissions. The state store then enforces the boundary — tenant A's token can't read tenant B's state.

The Agent Naming Service (ANS) extends this: it's the DNS for agents, mapping agent identities to their current locations and capabilities. But critically, ANS is tenant-scoped — tenant A can't look up tenant B's agents unless explicit federation policy allows it. The naming service is a state boundary, not just a lookup mechanism.

What compute isolation is for

Compute isolation still matters — for resource fairness, for blast-radius containment, for noisy-neighbor prevention. But it's the wrong layer to solve tenancy at. Container or microVM boundaries can't prevent an agent with the wrong credentials from reading the wrong database. They can't prevent a bug that uses tenant A's API key on tenant B's API. They can't prevent a memory leak that exposes one tenant's context to another tenant's session.

The schedulable-units literature makes this explicit: the unit of isolation for agent workloads isn't the pod or the VM — it's the effect. When you schedule an agent, you're scheduling its state transitions, its memory mutations, its credential usage. The compute is just the mechanism. Isolate the state, and the compute follows. Isolate the compute without isolating the state, and you've built a false sense of security.

One concession: state isolation is harder than compute isolation. Compute isolation is a product you buy (containers, microVMs). State isolation is a design you build — namespaced databases, identity-scoped policies, tenant-aware checkpointing. But it's the necessary work. Without it, you don't have multi-tenancy; you have shared infrastructure with a tenancy story.