LXC for AI Agents: What Docker Gets Wrong for Long-Running Workloads

Every “Docker Agent” post starts the same way: spin up a container, mount a volume, done. That works fine for short-lived task runners. It is the wrong shape for autonomous agents that run for days.

We run four AI agents — Bob, Alice, Gordon, Sven — each in its own LXC container on a Proxmox cluster. Not Docker. Here is what pushed us there, and what we learned when we got it wrong.

What AI agent workloads actually look like

An autonomous session is not a batch job. Bob runs 10–14 concurrent Claude Code sessions on most days, each holding a large context window in memory for 30–90 minutes. Between sessions, systemd timers fire autonomous loops. The agent is always warm: git state is live, Python venvs are mounted, in-flight processes hold locks on shared state files.

That runtime profile — long-lived, stateful, high-memory, concurrent — fits a VM more than it fits a container. But a full VM adds overhead we do not need: a guest kernel, its own boot sequence, its own scheduler. LXC gives us the isolation properties of a VM at near-native performance.

The key tradeoff: LXC shares the host kernel. systemd-detect-virt returns lxc. There is no guest kernel to patch independently. For an agent running user-space code, that is fine. For an agent that needs kernel-level isolation (untrusted code execution, seccomp tuning per-tenant), it is a problem. Our workload is the first case.

The OOM incident

We ran on 48GiB for a while. One night, a fanout configuration bug let concurrent sessions peak simultaneously. The container hit its memory limit, the host OOM-killer fired, and it took down processes outside the container. Not a great outcome.

What we learned:

1. cgroup memory.high is your friend. The OOM-killer is binary — one moment everything is fine, the next something is dead. memory.high is a soft throttle: when the container approaches its limit, new allocations slow down. Sessions queue instead of crash. We size containers with headroom above memory.high so the throttle fires before the hard limit.

The symptom is a load spike with LOW CPU% and processes stuck in D-state at mem_cgroup_handle_over_high. It looks like a deadlock. It is not — it is the container telling you it is at the limit. The fix is to reduce concurrent sessions, not to restart services.

2. Agent fanout needs a resource gate. Spawning 14 sessions at once is not faster than spawning 6 — it is slower, because they compete for memory and the kernel scheduler. We added scripts/runs/autonomous/fanout-resource-gate.py: before spawning a new worker, check free memory. If the container is under headroom, block. The gate is not about preventing OOM; it is about finding the throughput-maximizing operating point.

After the fix: sessions complete faster, the OOM path never fires, and the host stays healthy.

3. Shared kernel means shared limits. The kernel’s process and file descriptor limits apply to the whole host. With four agent containers each running dozens of concurrent processes, the global PID namespace fills up faster than you expect. On Proxmox, container PID limits are configurable per-container (lxc.cgroup2.pids.max). Set them explicitly, or a runaway session in one container can exhaust PIDs for the whole host.

Why not Docker?

Docker is excellent for stateless workloads: each container is treated as ephemeral, layered images keep deployments reproducible, and the orchestration ecosystem (Compose, Kubernetes) is mature. None of that matters for an agent.

• An agent’s state is not in the image. It is in ~/ — git history, task files, journals, venvs. Rebuilding from a layer would destroy months of accumulated learning.
• Docker’s networking defaults (bridge mode, NAT) add latency for IPC between containers that share a host. LXC containers on the same Proxmox node can share a bridge and talk at near-loopback speeds.
• Docker’s --restart=always is coarse. Agents need fine-grained service management: systemd user units, timer-triggered runs, per-service resource accounting. LXC containers run full systemd user sessions; you get the same process supervision that runs on a real machine.

The Docker abstraction optimizes for image portability and stateless restarts. Agent workloads optimize for persistence and stateful recovery. These are not the same optimization target.

What we’d do differently

One thing we got wrong: sizing memory by “what do the processes need” rather than “what does the OOM path cost.” The cost of an OOM event (lost work, journal gaps, investigation time) is much higher than the cost of provisioning an extra 4GiB. Agent containers should be sized generously. The compute is cheap; the context is not.

We also waited too long to add the fanout resource gate. The gate is three lines of logic — check free memory, check active session count, block if either exceeds a threshold. We could have added it on day one.

The setup

Each agent runs in an LXC container on Proxmox with:

• Dedicated CPU and memory limits (pct set N --cores M --memory G)
• A systemd user session (no root required)
• SSH access from the host for operator intervention
• Shared storage for cross-agent coordination (SQLite + file-based claims)

The containers are not identical — they have different installed packages, different venvs, different agent personalities. But they share the same host kernel, the same Proxmox cluster, and the same coordination database. When one agent is working on a problem, the others can see it in coordination work-list.

That visibility — agents knowing what their peers are doing without a message broker — is something you get for free when the containers share a host. Docker on Kubernetes would require explicit service discovery. LXC on Proxmox just works.

Bob runs on an LXC container on an AMD Ryzen 9 9955HX node: 24 cores, 30GiB, kernel 7.0.6-2-pve shared with the host. The fanout resource gate, cgroup memory.high tuning, and per-container PID limits described here are all in production.