An AI Coworker in an LXC Container

There’s a container on my Proxmox host — Ubuntu 25.04, 4 vCPUs, 8 GB — whose only job is to run a coding agent with access to this site’s repository. It has written posts, redesigned pages, fixed SEO bugs, and shipped the search feature you can use right now. Not as a copilot in my editor: as a coworker with its own machine.

The problem this post answers is the one I actually lost sleep over: how do you give an autonomous agent commit access and still sleep at night? I didn’t know when I started — that uncertainty is exactly why the lab got to host the experiment. The answer turned out to be the same answer as for any junior engineer: constrain the blast radius and make review cheap.

Why the agent gets its own container

The first decision was isolation. The agent runs in an LXC container rather than on my workstation, which buys exactly what containers buy: a filesystem boundary, a resource cgroup, and a snapshot story. If an agent-driven npm install goes sideways, the damage is confined to a ZFS dataset I can roll back in one command. It also makes the agent’s environment reproducible — the same reason we put CI in containers, as I covered in the container internals post.

Sizing turned out to be trivial: the model runs in a datacenter, not here, so the container is doing text processing and site builds. 4 vCPUs and 8 GB never break a sweat; the full Astro build with 90 posts and OG image generation takes about a minute. (If you want to know why local inference wasn’t an option, the memory-bandwidth math answers it — a GPU-less container with an 8 GB ceiling isn’t in that conversation, and frontier-model quality wasn’t negotiable for prose.)

API traffic doesn’t go straight to providers either. It routes through an LLM proxy on an Oracle free-tier VM, so keys live off my LAN and I get one choke point for logging and rate limits.

The pipeline is the guardrail

The agent inherits the same publishing pipeline the whole site runs on, and that pipeline is doing quiet security work:

• Everything is a git commit. There is no path to production that skips version control. Every change the agent makes is diffable, attributable (commits are co-signed with the agent’s name), and revertible.
• CI is the reviewer that never trusts. Type-check plus full build on every push. The content schema is strict — an invalid frontmatter field or a broken internal link pattern fails the build before deploy.
• draft: true is a staging area. Posts can land in the repo without going live, so “write it” and “publish it” are separate decisions.
• AGENTS.md is the onboarding doc. The repo carries its own instructions — voice, conventions, schema, do-nots. The agent reads it the way a new hire reads a runbook, and it works for the same reason runbooks work: the knowledge lives next to the system, not in someone’s head.

Notice what’s not in the list: trust in the model. The loop is designed so that a bad change is cheap to catch and cheap to undo — the same philosophy as the agent-loop architecture itself, where the model proposes and the harness disposes.

What it’s actually like

The honest report: the agent is excellent at the work that has a verifier. “Make the sitemap emit lastmod and prove it in the build output” comes back done, with the grep to show it. It’s weaker where taste is the spec — I still edit for voice, and the MCP integrations that let it check its own output (build logs, link checkers, search indexes) matter more than raw model quality.

The surprise was workflow, not capability: an agent with its own machine and a queue beats an agent in your editor, because it turns “help me type” into “here’s a task, ping me with the diff.” That’s a delegation model, and delegation needs exactly the guardrails above — which is why the pipeline came first.

Takeaways

• Give an autonomous agent the same thing you’d give a new hire: an isolated machine, a documented repo, and a review process — not raw trust.
• LXC + ZFS snapshots make the blast radius a rollback, not an incident.
• Route agent API traffic through a proxy you control: keys off the LAN, one place to log and limit.
• Make CI strict enough that “the build passed” means something; then let the agent iterate against it.
• The productivity unlock is delegation with verification — the model proposes, git and CI dispose.