The short version

Isolated agents, reviewable branches, and 28 automated lifecycle tests.

Key decision

Give each task its own worktree. Check shell commands against a fail-closed policy the agent cannot edit.

Verification

Lifecycle tests, durable job records, incident-derived controls, and revocable autonomy levels.

agent grid · one worktree per task
lanes build tests review docs tools guardian armed kill switch: ready
agent-01wt/implementation
› reviewing task changes
› pytest tests/test_lifecycle.py 28 passed
› git commit -m "verify dedup against response ids"
harvest → branch ready for review▍
agent-02wt/catalog-sync
› nightly catalog → embeddings sync
› catalog indexed, sync complete
guardian blocked: raw mail API call → use gate
› rerouting through integration gate▍
agent-03wt/rls-audit
› cross-tenant test matrix: 18 tables
› proposing column-level write boundary
waiting for human · autonomy: suggest
› evidence log: awaiting review
supervisorjobs · events
14:02 dispatch task-0142 → worktree created
14:02 spawn agent-01 (tmux)
14:19 turn agent-01 in-progress → done
14:19 harvest task-0142 → branch, nothing destroyed
Rendering of the desktop app. Real lanes and behaviors, names removed. Screenshots on request.

Problem

Running several coding agents at once fails in predictable ways. They collide in the same working tree. They run a destructive command because nothing stopped them. They are trusted up front instead of after a track record. I wanted parallelism with real isolation, a policy layer the agents cannot edit, records I could audit later, and an autonomy model with evidence behind every step up. The safety layer was in the repo on day one, not retrofitted.

Orchestration

  1. File-driven dispatchDispatch writes a task file. A supervisor watches for it. No sockets, no RPC, nothing that cannot be inspected with ls and cat.
  2. One git worktree per taskEach agent gets its own worktree, so parallel agents never share a working tree and cannot overwrite each other.
  3. Spawn and turn detectionThe supervisor spawns the agent inside tmux and detects turn completion by output activity, distinguishing in-progress from waiting-for-human.
  4. Harvest to branchFinished work is harvested onto a reviewable branch. Nothing is merged silently and nothing is silently destroyed.
  5. Durable job recordsEvery delegated job has a durable record with a full event timeline, so any outcome can be traced back to who asked for what and when.

Lane topology enforces boundaries: the coordinator never edits a lane's repository directly, and each lane is isolated from the others.

Desktop app

An Electron application presenting a resizable grid of live agents, each in its own worktree-backed terminal on the same terminal stack VS Code uses (xterm.js and node-pty). Lane sidebar, one-click agent launch into an auto-created worktree, auto-tiling, live status indicators, a finish action that keeps the branch or merges it, a kill action, and an integrated file browser and editor. Packaged as a macOS build.

Safety layer

guardian hook · every shell command
Agentissues a shell command
Guardian hookPreToolUse · fail-closed · self-protecting
Allow → execute → logautonomy level + reversibility
Block → log → incident?force-push · rm -rf · raw API · creds
Kill switchevery domain → observe-only
Incident learning looproot cause → control → handoff warning

Architecture model. Scroll horizontally on smaller screens →

Fail-closed: anything the policy does not recognize is blocked. The hook protects its own configuration from the agents it governs, and incidents feed back into it.
  • Guardian hook. A PreToolUse interceptor on every shell command an agent runs. It blocks forbidden patterns (raw calls to high-consequence APIs, credential reads, force pushes, recursive deletes, destructive SQL) under a domain-aware fail-closed policy. It protects itself: agents cannot modify the hook, its configuration, or the autonomy rules without explicit human approval.
  • Integration gates. The only sanctioned paths to high-consequence third-party APIs such as marketing automation and helpdesk systems. Raw access is blocked at the hook layer.
  • Kill switch. One command locks every domain to observe-only.
  • Preflight validator. Checks paths, state freshness, autonomy consistency, integrations, and approaching deadlines before any significant work begins.
  • Context handoff generator. Produces per-task hard constraints and an orientation document for each delegated job, carrying relevant past incidents forward as warnings.
  • Incident learning loop. Structured records with root cause, impact, what would have prevented it, and mitigations. Each record feeds back into hooks, gates, and handoffs. Three production incidents have been converted into permanent, enforced controls this way.

Evidence-gated autonomy

autonomy ladder
observe read and report suggest propose; human applies act-and-report reversible changes, reported autonomous inside guardian policy graduation requires evidence: accepted suggestions, zero corrections over 30 days, confirmed reversibility · kill switch returns any domain to observe
Every action is logged with its autonomy level and reversibility. Trust goes up on evidence and comes down instantly.
  • observeRead and report. No changes.
  • suggestPropose changes for a human to apply. Suggestions and corrections are logged.
  • act-and-reportApply reversible changes and report each one. Earned by an accepted-suggestion record with no corrections.
  • autonomousAct without a per-action report, inside the guardian's policy, for a domain with a proven record. Revocable by the kill switch at any time.

Numbers

Platform code~6,400 lines Python
Desktop app~1,600 lines Electron
Automated tests on the agent lifecycle28
Autonomy levels4
Production incidents converted into controls3
All figures appear on my resume.

This is the platform I build the other systems on this site with. Its output is not a demo. It is the code, tests, and reports behind the ads engine, the sales engine, and the attribution platform.

Explore the portfolio

Selected workFour systems and their outcomesAds optimization engineClassification, evaluation, verified mutationsAI sales engineRetrieval, claim validation, human approvalAttribution platformTenant isolation and client economicsAgent orchestration platformIsolated worktrees, guardian policy, durable jobsWebsite re-platformMigration, visual verification, rollbackHow I workBackground and engineering principlesStart a conversationandreasengelbertson@gmail.com
↑↓ navigate ↵ openSearch stays in your browser