🔄 Topic

Letting multiple agents work at the same time without trampling each other: a task graph to order the work, and git worktrees so every agent gets its own isolated copy of the repository.

🎯 Goal

Get real parallelism from the agent stack while keeping one property absolute: no agent can corrupt another agent’s work in progress, and nothing merges without review.

🛠 What I Did

I built the isolation layer before allowing the concurrency.

Main areas covered:

  • modeled work as a task graph with dependencies, so the scheduler knows what can run in parallel and what must wait
  • gave each agent task its own git worktree — a separate working directory sharing one repository history
  • kept the main working tree reserved for me, so autonomous work never touches the branch I am sitting on
  • made worktree cleanup part of task completion, so finished tasks do not leave stray copies with stale state
  • ran the parallel scheduler against real tasks and watched independent branches land without conflicts
  • kept merges gated: an agent’s worktree branch only joins main after verification passes

🔗 Key Cybersecurity Connections

This is compartmentalization, applied to automation. Each worktree is a blast-radius boundary: a confused agent can ruin its own copy and nothing else. The merge gate is the trust boundary — isolation is only useful if crossing back into shared state requires evidence.

The same logic runs through sandboxing, per-tenant isolation, and least-privilege workspaces: give each actor the smallest world it needs, and inspect everything that leaves it.

🔍 Investigation Questions

  • Can two concurrent tasks ever write to the same working directory?
  • What happens to a worktree when its task crashes mid-write?
  • Can an agent’s branch reach main without passing verification?
  • Are abandoned worktrees detected and cleaned?
  • Does the task graph actually prevent dependent tasks from racing?

🚨 Detection Opportunities

Checks for a multi-agent repository:

  • two tasks bound to one worktree path
  • commits appearing on main without a gated merge
  • worktrees surviving after their task closed
  • dependent tasks starting before their prerequisite finished
  • a worktree diverging far from its task’s declared scope

Example:

project=multi-agent-worktrees
signal=commit_on_main_without_gated_merge
risk_area=isolation_bypass
triage=identify_source_worktree_and_verification_record

🧭 MITRE ATT&CK Techniques

No direct mapping claimed. This is isolation and change-control design for concurrent automation.

🗺 Visual Investigation Diagram

Task graph
    ↓
Independent tasks → parallel
    ↓
One worktree per task
    ↓
Agent works in isolation
    ↓
Verification gate
    ↓
Merge to main (or discard)

⚠ Challenges

The discipline cost is real: worktrees multiply disk state, and cleanup has to be as reliable as creation. An isolation mechanism that leaks copies eventually becomes its own inventory problem — last week’s sprawl lesson, again, at a smaller scale.

📚 What I Learned

I learned that parallelism is earned by isolation, not by optimism. The scheduler got faster only because every path where tasks could collide was closed first.

➡ Next Steps

  • Add a sweep for orphaned worktrees to routine maintenance
  • Record task-to-worktree mapping in the provenance log
  • Stress-test the graph with deliberately conflicting tasks
  • Keep the merge gate identical for human and agent branches

🧠 Reflection

Watching three agents work simultaneously without a single conflict felt like the payoff for a month of boring discipline: contracts, verification, and now compartments.

🧩 Lessons Learned

What worked

One worktree per task, with merges gated on verification.

What broke

Early runs left orphaned worktrees behind after crashes.

Why it broke

Cleanup was written as a happy-path step, not a guaranteed one.

Fix / takeaway

Isolation needs lifecycle: create, bound, verify, merge, destroy — every time.

📈 Skill Progression Context

This supports my cybersecurity progression because compartmentalization, controlled promotion across trust boundaries, and cleanup discipline are the same mechanics behind sandboxes, DMZs, and change control.

😄 TL;DR

Every agent gets its own sandbox copy of the repo; nothing rejoins main without proof.