The bounded workspace pattern gives an agent a fenced sandbox — a directory, a branch, a namespace — where it has full freedom and outside of which it has none. Autonomy scales with containment.

The counter-intuitive truth from running coding agents in production: agents with unlimitedaccess are slower and less reliable than agents with generous but explicit boundaries. An unbounded agent spends context negotiating scope ("should I touch this file?") and its errors have unbounded blast radius. A bounded agent spends context on the work itself, because the fence answers scope questions mechanically before they are asked.

The fence has physical and logical layers. Physically: a container, an ephemeral VM, or a dedicated working directory whose writes never touch the host. Logically: allow-lists for executable commands, deny-lists for credential paths, a dedicated Git branch, and network egress restricted to documented endpoints. The strongest implementations deny by default — anything not explicitly granted is refused — because allow-lists fail safe while deny-lists fail open.

Properties of a Good Fence

• Resettable: the workspace is disposable infrastructure; a failed run tears down to a known-good snapshot via its baseline anchor.
• Observable: every read and write inside the fence is logged, so review means reading a diff, not auditing a hunch.
• Promotable: work exits only through an explicit gate — a passing test suite, a reviewed pull request — never by leaking across the boundary.
• Sized honestly: boundaries too tight starve the agent into retry loops; too loose and they are theater. Expand grants based on demonstrated behavior, not optimism.

This pattern composes with everything else in the stack: plan-and-execute gives the workspace a contract, event sourcing gives it a journal, and maker-checker gives its exits a reviewer. It is the quiet prerequisite that makes the loud patterns safe.