Most agent infrastructure collapses orchestration, state, and execution into a single VM per agent. That works for coding agents that need persistent shells. It breaks for fleets of data agents, monitoring agents, and always-on business workers that spend most of their time idle.
GluonDB runs a large fleet of persistent agents on a small infrastructure footprint by splitting the problem into three independent layers: orchestration, filesystem, and sandboxed execution. The sandbox is pooled and temporary. The filesystem is durable. The control plane is persistent. The VM is not the agent.
This separation creates clean security boundaries, reduces attack surface, and prevents infrastructure costs from scaling linearly with agent count.
The Problem with VM-per-Agent
The default pattern treats the VM as the unit of identity. Each agent gets a Firecracker microVM or container. The orchestration loop, working files, and execution environment live together. When the agent is idle, the VM idles. When you need 10,000 agents, you provision 10,000 VMs.
This creates three problems:
- Cost scales linearly. Each agent burns CPU and memory even when waiting for the next scheduled task or external trigger.
- Security boundaries blur. The orchestration code that decides what to run lives in the same environment where untrusted model output executes arbitrary commands.
- State management is fragile. If the VM dies, you lose the agent’s working state unless you build separate persistence on top.
For coding agents that need live shells, this trade-off makes sense. For fleets of business agents that wake up on schedules, read from APIs, write reports, and occasionally run a script, it does not.
GluonDB’s Three-Layer Split
GluonDB separates concerns that are usually bundled:
- Orchestration layer: Persistent control plane that manages agent identity, schedules, tool calls, and state transitions. Lives outside the sandbox.
- Filesystem layer: Durable storage for each agent’s working files, memory, and artifacts. Mounted into sandboxes on demand.
- Execution layer: Pooled, ephemeral sandboxes that spin up when the agent needs to run untrusted code, then disappear.
The orchestration layer decides what to run. The filesystem holds what the agent remembers. The sandbox executes what the model requested. None of these layers depend on the others staying alive.
Authentication and Identity
Each agent has an identity in the orchestration layer, not in a VM. Authentication happens at the control plane boundary. The agent’s credentials never touch the sandbox.
When an agent needs to execute code:
- The orchestration layer validates the request.
- A sandbox spins up from a pool.
- The agent’s filesystem mounts read-only or read-write depending on the operation.
- The sandbox runs the code, writes output to the filesystem, and terminates.
- The orchestration layer reads the result and decides the next step.
The sandbox never authenticates. It never sees the agent’s API keys or database credentials. It cannot call the orchestration API directly.
Connection Pooling and Multiplexing
Because sandboxes are ephemeral, GluonDB can pool them aggressively. A fleet of 10,000 agents might only need 50 live sandboxes at any moment. Most agents are waiting for a schedule, an external event, or a human approval.
The orchestration layer multiplexes agent activity across the pool:
- Agents share sandbox capacity, not sandbox instances.
- Each sandbox is single-tenant during execution, then wiped.
- The filesystem layer handles concurrent reads and serializes writes per agent.
This reduces infrastructure cost by two orders of magnitude compared to VM-per-agent.
Security Boundaries
The split creates hard boundaries:
| Layer | Trust Level | Attack Surface | Failure Mode |
|---|---|---|---|
| Orchestration | Trusted | API authentication, rate limits, authorization logic | Agent identity compromise, privilege escalation |
| Filesystem | Semi-trusted | Path traversal, quota enforcement, encryption at rest | Data exfiltration, cross-agent reads |
| Sandbox | Untrusted | Arbitrary code execution, network egress, resource limits | Sandbox escape, DoS via resource exhaustion |
If a compromised agent tries to exfiltrate data, it can only access its own filesystem mount. It cannot reach the orchestration API or other agents’ data. If it tries to DoS the system, resource limits kill the sandbox and the orchestration layer rate-limits future requests from that agent identity.
Monitoring and Rate Limiting
Each agent has different behavior patterns. A monitoring agent might wake up every minute. A reporting agent might run once a day. A data pipeline agent might execute hundreds of tool calls in a burst.
GluonDB tracks per-agent metrics at the orchestration layer:
- Tool call frequency and types
- Sandbox spin-up count and duration
- Filesystem read/write volume
- API request patterns to external services
Rate limits apply per agent identity, not per sandbox. If an agent starts making unusual requests (sudden spike in sandbox usage, unexpected API calls, filesystem writes outside normal patterns), the orchestration layer can throttle or pause it without affecting other agents.
Observability lives outside the sandbox. The agent cannot tamper with its own logs or metrics.
Code Execution Flow
Here is what happens when an agent needs to run untrusted code:
# Orchestration layer (trusted environment)
def execute_agent_code(agent_id: str, code: str, context: dict):
# Validate agent identity and rate limits
if not check_rate_limit(agent_id):
raise RateLimitExceeded(agent_id)
# Allocate ephemeral sandbox from pool
sandbox = sandbox_pool.acquire(timeout=30)
try:
# Mount agent's filesystem (read-only or read-write)
sandbox.mount_filesystem(agent_id, mode="rw")
# Inject minimal context (no credentials)
sandbox.set_env(context)
# Execute code with resource limits
result = sandbox.run(
code,
timeout=300,
max_memory="512M",
network_policy="egress_only"
)
# Collect output from filesystem
output = sandbox.read_output(agent_id)
return result, output
finally:
# Wipe sandbox and return to pool
sandbox.reset()
sandbox_pool.release(sandbox)The orchestration layer never runs untrusted code. The sandbox never sees agent credentials. The filesystem is the only shared state, and it is scoped per agent.
Threat Model and Failure Modes
Compromised Agent Identity
If an attacker steals an agent’s authentication token:
- They can trigger tool calls and code execution for that agent.
- They can read and write that agent’s filesystem.
- They cannot access other agents’ data or escalate to the orchestration layer.
- Rate limits and anomaly detection can throttle the attack.
Mitigation: Short-lived tokens, per-agent API key rotation, behavioral monitoring.
Sandbox Escape
If an attacker escapes the sandbox:
- They land in an ephemeral VM with no persistent state.
- They cannot reach the orchestration API (network policy blocks it).
- They can only access the mounted filesystem for one agent.
- The sandbox terminates after the timeout, wiping any persistence.
Mitigation: Firecracker microVMs, seccomp filters, read-only mounts for sensitive operations.
Resource Exhaustion
If a compromised or buggy agent tries to DoS the system:
- Sandbox resource limits (CPU, memory, disk I/O) kill runaway processes.
- Per-agent rate limits prevent infinite sandbox spin-up.
- The orchestration layer can pause or disable the agent without affecting others.
Mitigation: Per-agent quotas, circuit breakers, automatic backoff.
Data Exfiltration
If an agent tries to exfiltrate data:
- It can only access its own filesystem mount.
- Network egress policies limit outbound connections.
- The orchestration layer logs all external API calls and can block suspicious patterns.
Mitigation: Filesystem isolation, network policies, egress monitoring.
When to Use This Architecture
This split makes sense when:
- You have a large fleet of agents with different activity patterns.
- Most agents are idle most of the time (scheduled tasks, event-driven workflows).
- You need durable state but not persistent execution environments.
- Security boundaries between agents matter (multi-tenant, customer-specific agents).
- Infrastructure cost needs to scale sublinearly with agent count.
It does not make sense when:
- Every agent needs a live shell or persistent REPL (coding agents, interactive debugging).
- Agents need to maintain long-running processes (web servers, database connections).
- Sandbox spin-up latency is unacceptable (sub-second response requirements).
- You have a small number of agents with high resource needs (better to provision dedicated VMs).
Technical Verdict
GluonDB’s three-layer split (orchestration, filesystem, execution) solves the fleet-scale security and cost problem by refusing to treat the VM as the agent. The orchestration layer is persistent and trusted. The filesystem is durable and scoped per agent. The sandbox is ephemeral and untrusted.
This creates clean security boundaries, reduces attack surface, and allows infrastructure to scale sublinearly with agent count. A fleet of 10,000 agents can run on 50 pooled sandboxes if most agents are idle most of the time.
The trade-off is latency. Spinning up a sandbox, mounting a filesystem, and tearing it down adds overhead compared to a persistent VM. If your agents need sub-second response times or long-running processes, this architecture is the wrong fit.
For fleets of business agents, data agents, and monitoring agents that wake up on schedules and execute occasional tool calls, it is the right default. The VM should not be the unit of identity. The sandbox should not be the agent.