Parallel Agents Multiply Artifacts Too — Designing Lifespans and Cleanup for Intermediate Outputs

Worktrees, screenshots, temp branches — parallel agents leave debris at parallel speed. A design for defining artifact lifespans and automating cleanup without ever destroying uncommitted work.

antigravity⁴⁰⁹ parallel-agents² operations²⁰ disk-management git¹⁰

✦ Premium Article

A while after I started running multiple Antigravity 2.0 agents in parallel, a low-disk warning woke me up. The culprit was neither the app nor model caches. It was the debris my agents had left behind: eleven verification worktrees, thousands of browser screenshots and recordings, more than eighty merged-but-undeleted temp branches.

Parallelism speeds up task completion — and it speeds up debris accumulation by exactly the same factor. The deferred tidying that never mattered with one agent becomes an operational problem the moment you raise the degree of parallelism. That was my lesson.

Deleting is scary; hoarding is unsustainable. What follows is the design I settled on to walk that line: defined lifespans per artifact type, and automated cleanup wrapped in paranoid guards. Run logs are a different animal with different retention needs, covered separately in Keeping Unattended Agent Run Logs Long Enough to Debug — Without Filling the Disk. This article is about everything else — the by-products of work.

Start with an inventory, not a delete script

Cleanup design goes faster when you begin by cataloguing, not coding. In my environment, parallel agents produce six artifact types:

Artifact	Produced by	Lifespan	Deletion condition
Verification worktrees	Isolated parallel task execution	7 days	Branch merged and no uncommitted changes
Temp branches	Agent trial and error	14 days	Merged, or 14 days since last commit and unreferenced
Screenshots and recordings	Browser verification, visual regression	3 days	Associated run finished successfully
Build outputs	Verification builds	2 days	Unconditional (regenerable)
Downloaded reference material	Research tasks	30 days	30 days since last access
Residue of failed runs	Abnormally terminated tasks	14 days	Postmortem record closed

What matters in that table is not the specific numbers but the fact that only two axes ever appear in the deletion column: can it be regenerated, and is anything still referencing it. Regenerable artifacts get short lives; anything entangled with human judgment gets conditions. Tune the numbers to your own environment freely.

Safety guards — make "safe to delete" a suspicious question

Lose work to automated deletion once and the cleanup system itself loses trust — you will be back to manual tidying forever. So the guards should feel excessive. I run three.

First, never touch a worktree with uncommitted changes:

is_dirty() {
  local wt="$1"
  # dirty if any uncommitted changes, untracked files, or stashes exist
  [ -n "$(git -C "$wt" status --porcelain 2>/dev/null)" ] && return 0
  [ -n "$(git -C "$wt" stash list 2>/dev/null)" ] && return 0
  return 1
}

Second, exclude directories in use by a running agent. Each run writes its working path to a lock file at start and removes it on exit; the cleaner only checks lock existence:

is_in_use() {
  local path="$1"
  grep -qsF "$path" "$HOME/.agent-runs/active/"*.lock 2>/dev/null
}

Third, deletion is always two-phase. Phase one moves the target into a quarantine directory; the real deletion happens on the next run, seven days later. It is insurance against "deleted yesterday, needed today" — and it has paid out twice for me.

quarantine() {
  local target="$1"
  local dest="$HOME/.agent-trash/$(date +%Y-%m-%d)"
  mkdir -p "$dest"
  mv "$target" "$dest/" && echo "quarantined: $target"
}
# hard-delete only quarantine folders older than 7 days
find "$HOME/.agent-trash" -maxdepth 1 -type d -mtime +7 -exec rm -rf {} +

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦An inventory of six artifact types with assigned lifespans and deletion conditions

✦Three safety guards that make it impossible to delete uncommitted work or in-use worktrees

✦Roughly 41GB reclaimed on first run, followed by three months of zero deletion accidents

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

The cleaner itself — worktrees and branches

Git artifacts demand the most care. Worktree cleanup runs in this order:

#!/usr/bin/env bash
# cleanup-worktrees.sh — quarantine or remove only provably safe worktrees
git worktree list --porcelain | awk '/^worktree /{print $2}' |
while read -r wt; do
  [ "$wt" = "$(git rev-parse --show-toplevel)" ] && continue  # skip main checkout
  is_in_use "$wt" && { echo "skip (in use): $wt"; continue; }
  is_dirty "$wt"  && { echo "skip (dirty): $wt";  continue; }
 
  branch="$(git -C "$wt" branch --show-current)"
  # confirmed merged into main?
  if git merge-base --is-ancestor "$branch" main 2>/dev/null; then
    git worktree remove "$wt" && echo "removed: $wt"
    git branch -d "$branch" 2>/dev/null
  else
    # unmerged: quarantine only after lifespan expiry (7 days)
    last=$(git -C "$wt" log -1 --format=%ct 2>/dev/null || echo 0)
    age_days=$(( ($(date +%s) - last) / 86400 ))
    [ "$age_days" -gt 7 ] && quarantine "$wt"
  fi
done
git worktree prune

The asymmetry is deliberate: merged means immediate removal, unmerged means quarantine only after expiry. An unmerged branch may contain decisions nobody has made yet, so it never skips the quarantine stage.

Regenerable artifacts like screenshots and build outputs need nothing this defensive — find -mtime plus the deletion condition covers them.

Operating the cleaner — weekly dry-runs, then real deletions

When I turned cleanup into a scheduled task, the first month was dry-run only. Every week it reported "here is what I would delete" without deleting anything. Only after the reports stopped listing things I cared about did I flip it to live mode.

The other operational point is mutual exclusion with agent runs. The cleaner is scheduled into a low-activity window and additionally protected by the lock-file mechanism above. Relying on time separation alone eventually collides with a retried run that drifted off its slot.

Measured results

In my own setup — an indie developer running content sites and several apps on unattended automation — the first live run reclaimed about 41GB: roughly 24GB of build outputs, 13GB of screenshots and recordings, and 4GB of worktree and branch residue. Over the following three months, weekly cleanup kept usage within a ±5GB band, with zero deletion accidents and two rescues from quarantine.

Better than the disk numbers: git branch -a and the worktree list now show only living work. When I ask an agent to describe the current state of a repository, the noise is gone — and context token consumption dropped visibly as a side effect.

The next step

Start by measuring, not deleting. One pass of du -sh over your artifact locations, grouped by type, tells you the accumulation rate of your own environment. Lifespan design can wait until you have seen those numbers.

It is unglamorous scaffolding, but it is what lets the benefits of parallelism last. I hope it serves your setup as well as it has served mine at Dolice Labs.

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.