Orchestrating autonomous coding agents

I built Aergia to answer a simple question: what happens if you let coding agents run unattended, around the clock, with real isolation and real memory? Here are the parts that mattered.

One project, one box

Every project gets its own Docker container. Agents are powerful and occasionally wrong; isolation turns "wrong" into "contained." A blast radius of one repository is the difference between a useful tool and a liability.

The agent loop runs on the host; its file and shell tools don't. SDK PreToolUse hooks intercept them (Read, Write, Edit, Glob, Grep, Bash) and re-execute each call inside the project's container, rewriting paths between host and workspace. To the agent, nothing changes.

// sketch of the idea, not Aergia's source or the SDK's exact hook API
onPreToolUse(["Read", "Write", "Edit", "Glob", "Grep", "Bash"], async (call, project) => {
  const box = await containerFor(project);             // one per project
  return box.exec(call.tool, toWorkspacePaths(call.input, project));
});

The container is locked down: no-new-privileges, a read-only root filesystem, networking disabled, a non-root user, and memory/CPU caps. With no network, nothing inside it can push anywhere. GitHub automation is gated separately by three autonomy levels, and a force-push always needs a human.

Memory that survives the session

A stateless agent re-learns the codebase every run. Scoped, persistent memory that carries across sessions is what turns a sequence of one-shot prompts into something that compounds. Undoing matters as much as remembering: with git checkpoint/restore, a run that went somewhere bad can be rolled back to a checkpoint instead of cleaned up by hand.

Keeping it honest

The failure mode of 24/7 autonomy isn't the dramatic one; it's quiet drift. The guardrails are unglamorous on purpose: token limits enforced mid-stream rather than after the fact, rate-limit-aware model failover, prompt-injection scanning, and secret-scrubbing on agent output. A typed event bus streams each agent's output and state into a live dashboard, so drift shows up while it's happening.

The orchestrator itself runs like any other service (ordered startup recovery, graceful shutdown, container health monitoring with auto-restart), behind strict CI quality gates. It's less "magic" and more "good operations," which is the point.

The project page covers the rest: the 40-command Telegram bot, the 115-event bus, and the 11-package monorepo behind it. If you're putting agents to work unattended and want a second pair of hands, I'm open to select work.