Agent Workspaces Need Explicit State Boundaries

Summary

Running agents in parallel or across repeated sessions raises a practical question: which state belongs to each task, and what should survive its execution environment? Two announcements from Supabase and Vercel address different parts of that question. Their limited common pattern is making workspace state an explicit infrastructure decision.

Key Updates

Supabase: separate local project state. In its October 14 announcement, Supabase describes a local project per git worktree, giving parallel coding agents separate databases and services to reset, migrate and test. Multi-project support and the native runtime ship in CLI v2.119.0 behind an experimental flag. The post recommends native mode as one project per sandbox; Docker remains the better fit for several projects on one laptop because its containers provide separate networks and filesystems.

Vercel: files with an independent lifetime. Vercel’s October 15 announcement makes Drives generally available for Sandbox on all plans. Mounted files can survive a sandbox and be reused in another environment. Agents can share read-only copies or create independent writable forks. Those forks do not merge back into the original drive, so preserving a workspace does not settle how results are reconciled.

Why It Matters

A separate code branch does not, by itself, establish ownership of every database or file an agent touches. Likewise, stopping a compute environment is an insufficient cleanup policy when some files are deliberately persistent. These are the operating assumptions under pressure.

For local databases, the operational questions concern reset scope, connection configuration and whether another task can change the state a test depends on. For persistent files, they concern which version a later run receives, who may change it, how long it remains and how a fork’s output becomes accepted work.

The two products expose different mechanisms. They do not establish a shared stack or automatic coordination between agents. Supabase’s experimental status constrains readiness claims; Vercel’s no-merge fork behavior leaves an explicit integration decision for the team. Neither announcement proves that an agent’s output is correct or that every access boundary is secure.

Builder Takeaway

Before expanding parallel or resumable agent work, make a small inventory of state: code, databases, files, caches and credentials. For each, name an owner, its permitted writers, its lifetime and the review needed before promoting changes.

Then test the boundaries with disposable data:

• Reset one task’s database while another runs, and check that the second task’s expected records remain intact.
• Replace the execution environment and verify which files persist and which are discarded.
• Change a fork and confirm the parent is unchanged; require an explicit review and transfer step for accepted results.
• Check how stale workspaces, stored credentials and retained artifacts are identified and cleaned up.

Treat these as acceptance checks for your configuration. Passing them does not establish complete isolation or validate the agent’s reasoning. Keep experimental capabilities within a bounded evaluation until their behavior fits the workflow’s requirements.