Managed Agents: shared-filesystem default conflicts with per-task isolation disciplines

Summary

Managed Agents specialists share a single container filesystem within a session (per the architecture docs and ChatForest's deep-dive). For customers who have already adopted per-task isolation as a discipline — e.g., one git worktree per dispatched background agent, with the worktree being the unit of containment — the shared-FS default is architecturally opposite to the established pattern.

Motivation / Use Case

A customer running 50+ concurrent worktrees on a single Claude Code project (verified via git worktree list during a 2026-05-22 evaluation) cannot trivially port to Managed Agents without re-implementing isolation as a convention (per-task scratch dirs, naming discipline) instead of as a hard guarantee. The "shared filesystem" model is great for coordinator-aggregates-specialist-outputs patterns; it is actively wrong for "multiple independent agents touching different sub-trees of the same repo without colliding."

Concrete pattern at risk: two specialists building separate features in the same monorepo would collide on bin/, obj/, .vs/, node_modules/, lockfile rewrites, etc. — the exact conflicts that per-worktree isolation solves at the platform level.

Suggested Behavior

One of:

1. (Recommended) Config option: A specialist can declare filesystem: "isolated" to get a per-thread scratch dir overlaid on top of the shared container FS, with explicit publish-back to shared FS on completion. Equivalent to git worktrees as a first-class primitive.
2. (Docs-only fallback) Explicit guidance on which workload shapes the shared-FS default is appropriate for vs. inappropriate for, plus a recommended convention for emulating per-specialist isolation via subdirectory namespacing.

This would meaningfully widen Managed Agents' addressable audience to customers whose existing multi-agent disciplines are isolation-first.