Sandbox Loom

Sandbox Loom gives autonomous software-development workflows a controlled place to work. Agents receive a defined workspace and clearly bounded authority, while people retain visibility and approval over consequential actions.

The first supported use case is autonomous software development. The same approach can support other workflows that need controlled automation, verification, and human oversight.

What it provides

• A clear definition of what an agent may do
• Disposable workspaces separated from the host
• Controlled access to Git and other external systems
• Verification, checkpoints, and acceptance evidence
• Pause, recovery, and human approval for higher-risk actions

Start here

1. Run the quick start to see the smallest working flow.
2. Browse the examples to compare simple and advanced workflows.
3. Review the security model to understand the safeguards.
4. Read the architecture and decisions when evaluating adoption.

Review an adoption path

Use the documentation as an evaluation and handoff path rather than as a feature list:

1. Start with the operating model and current boundaries in Architecture.
2. Inspect the security model and architecture decisions to understand authority, isolation, and deliberate tradeoffs.
3. Run the quick start, then validate and preview a workflow with the commands in Workflows.
4. Compare the examples with the workflow you want to adopt, including its approval and evidence requirements.
5. Finish with Operations, the local operations runbook, and Local Dogfooding before enabling isolation or external integrations.

This path lets decision-makers evaluate the model first and gives contributors an executable route from an objective to bounded work, verification, evidence, and human review.

Project status

The initial MVP is implemented in Ruby and is intended for local evaluation and controlled adoption. Youki is preferred when available, with automatic runc fallback. Hosted multi-tenant operation is outside the current scope.

Documentation map