Multi-agent systems are often described as prompt graphs: a supervisor delegates to a planner, a coder, a reviewer, and a tester. That framing is useful, but it omits the infrastructure problem that appears when those agents are full coding agents rather than lightweight function calls. A deep agent can open shells, edit files, install dependencies, cache credentials, spawn subprocesses, and maintain an interactive session for hours. If several of those agents run against the same project, ordinary in-process orchestration is not enough.
An agent hypervisor treats each agent as an isolated runtime unit. Instead of placing every specialist inside one conversation or one process, the orchestrator provisions a container, workspace, identity, credentials, and lifecycle state for each agent. The agents can run concurrently, attach to interactive terminals, message each other, and work on separate branches or worktrees without trampling each other’s files. The orchestration layer resembles a lightweight control plane for virtual machines or containers, but the managed workload is an LLM harness.
Google Cloud Platform’s Scion project is a concrete example of this pattern. It describes itself as a testbed for running deep agents such as command-line coding agents in isolated containers across local machines, remote VMs, and Kubernetes clusters. The transferable idea is broader than Scion: when agents have real operating-system authority, safety and productivity come from external runtime boundaries, scoped identities, and observable lifecycle management, not only from instructions embedded in the model context.
In an agent-hypervisor design, the unit of scheduling is not a tool call. It is an agent process running inside a harness such as a coding CLI, research agent, or auditing agent. The harness owns the model loop and tool interface, while the hypervisor owns provisioning, termination, workspace isolation, logs, credentials, and operator access. This separation allows the same orchestration substrate to support different agent harnesses.
A project-level namespace, sometimes called a grove or group, defines which agents belong to the same work context. Inside that namespace, each agent still needs its own identity and filesystem boundary. Local systems can use git worktrees with dedicated branches. Hosted systems can clone or fetch the repository into per-agent workspaces. In both modes, sibling agents should not read each other’s private state, task prompts, or credentials unless the orchestration policy explicitly permits it.
A runtime broker is a machine or cluster that offers execution capacity to the control plane. Profiles bind a task to an execution environment: local Docker for quick experimentation, rootless Podman for developer workstations, a macOS virtualization backend for local isolation, or Kubernetes for remote parallelism. Profiles let the same agent template run in different places without rewriting the task definition.
When an agent needs broad operational freedom, do not rely only on telling it what not to do. Put the freedom inside a bounded container, workspace, identity, network policy, and credential scope. The model can act autonomously inside that boundary, while the hypervisor limits blast radius outside the boundary.
Starting an agent requires more than launching a model. The orchestrator resolves the agent template, selects a runtime profile, creates a workspace, projects allowed credentials, starts the harness, and records lifecycle state. For coding agents, the workspace step is critical because concurrent edits must remain separable until a human or merge agent reviews them.
type AgentSpec = {
name: string;
template: "coder" | "reviewer" | "security-auditor";
task: string;
runtimeProfile: "local-docker" | "remote-kubernetes";
repoUrl: string;
baseBranch: string;
credentialScope: string[];
};
async function startAgent(spec: AgentSpec) {
const identity = await createScopedIdentity(spec.name, spec.credentialScope);
const workspace = await provisionWorkspace({
repoUrl: spec.repoUrl,
baseBranch: spec.baseBranch,
branch: `agent/${spec.name}`,
});
const container = await runtime(spec.runtimeProfile).start({
image: imageForTemplate(spec.template),
mounts: [{ hostPath: workspace.path, containerPath: "/workspace" }],
env: projectCredentials(identity),
networkPolicy: policyForTemplate(spec.template),
command: harnessCommand(spec.template, spec.task),
});
await recordAgentState(spec.name, {
phase: "running",
activity: "thinking",
containerId: container.id,
workspace: workspace.branch,
identity: identity.id,
});
}The code is intentionally framed as a control-plane sketch. A production implementation would add admission control, cleanup jobs, logs, heartbeats, retry policy, image provenance checks, and approval gates before projecting sensitive credentials.
Infrastructure state and agent activity are different. A container can be healthy while the agent is blocked waiting for a child task, and a stopped container may still preserve resumable work. Split the state model into phase, activity, and detail. The phase records infrastructure progress such as provisioning, starting, running, stopping, or error. The activity records what the agent is doing while alive: idle, thinking, executing, waiting for input, blocked, completed, limits exceeded, or offline.
Deep agents often need human interaction. The runtime should let an operator attach to the agent’s terminal, detach without killing the task, send a message later, inspect logs, and resume a stopped session. This gives the system a practical human-in-the-loop path without collapsing every interaction back into a single chat transcript.
A team can launch one agent to implement a feature, another to write tests, and a third to audit the result. Each agent receives its own branch and container, so the agents can make progress concurrently. The final integration step compares branches, resolves conflicts, and accepts only the work that passes tests and review.
Auditing agents need different authority from implementation agents. A security agent may need read-only source access, dependency scanners, and issue trackers, but no write token for production infrastructure. Hypervisor orchestration makes that distinction concrete by binding different templates to different identities and runtime profiles.
Some agent tasks need more CPU, network locality, or cluster access than a laptop can provide. Runtime brokers let a control plane dispatch agents to remote VMs or Kubernetes clusters while preserving the same lifecycle, messaging, and logging interface. This is useful for long-running codebase analysis, data research, integration tests, and platform automation.
Local orchestration can create a git worktree per agent, mounted into the container as the writable workspace. Hosted orchestration can use clone/fetch provisioning with a dedicated branch per agent. The important invariant is that each agent has an independent working directory and a clear merge path back to the main branch.
async function provisionWorkspace(input) {
if (input.mode === "local") {
await exec("git", [
"worktree",
"add",
`../.agent_worktrees/${input.agentName}`,
"-b",
input.branch,
input.baseBranch,
]);
return { path: `../.agent_worktrees/${input.agentName}`, branch: input.branch };
}
await exec("git", ["init", input.path]);
await exec("git", ["-C", input.path, "fetch", input.repoUrl, input.baseBranch]);
await exec("git", ["-C", input.path, "checkout", "-b", input.branch, "FETCH_HEAD"]);
return { path: input.path, branch: input.branch };
}Avoid ambient host credentials. A container should receive only the tokens and config files required for its assigned role. Sensitive credentials can be mounted read-only, injected through a broker, or replaced with short-lived scoped tokens. Child agents should receive equal or narrower privilege than their parent unless a policy engine authorizes escalation.
A template describes the agent role: prompt, harness, allowed tools, and optional home-directory content. A profile describes where and how it runs. Keeping these separate lets you run the same reviewer locally for a small patch or on Kubernetes for a large repository without duplicating role configuration.