Run Scoped Agents Away from the Keyboard Inside Sandboxes

There are two primary modes of agentic work. Human-in-the-loop work keeps the person present while the agent asks questions, proposes decisions, and performs complicated or ambiguous tasks. Away-from-keyboard work assigns a scoped task and lets the agent execute without continuous human interaction.

Away-from-keyboard execution creates major leverage because it lets one person start multiple tasks instead of supervising every permission request and intermediate step. That leverage should be paired with sandboxing so that agent actions are contained within a controlled environment.

A sandbox is an isolated place in which the agent can inspect code, run commands, make changes, and produce commits. The sandbox can run locally through a container system or remotely through a hosted environment. The resulting commits can then be pulled back into the main workspace.

Containment matters because an unsandboxed agent can perform unexpected actions. Examples include deleting files outside the intended project or exposing environment variables to an unsafe destination. The sandbox narrows the execution boundary and makes it practical to grant the agent enough freedom to work without granting unrestricted access to the operator's machine.

Away-from-keyboard agents can also run inside continuous-integration workflows. A pull request can trigger an agent review action that:

1. Checks out the branch.
2. Loads a review prompt or procedure.
3. Inspects the change.
4. Runs checks such as type checking.
5. Records what the agent did.
6. Posts a review result.

Multiple agents can operate in parallel on different tasks. They may run on the local machine if resources allow or in remote sandboxes when local constraints would limit concurrency.

The transition from constant supervision to scoped asynchronous execution changes the productivity model. The human no longer has to remain present for every command. While one agent explores a bug, another can implement a feature, and another can review a pull request.

This is a practical form of parallelization. It does not create additional strategic decision-makers. It creates additional execution workers whose output returns to the human or team for integration and judgment.

Sandboxing makes that parallelism more responsible. It separates the question "Can the agent execute freely inside this task environment?" from the question "Should the agent have unrestricted access to the operator's full system?" The first may be useful; the second is unnecessary for most delegated work.

Use this handoff pattern:

1. Plan interactively. Resolve the mission, constraints, architecture, and acceptance criteria with

the human present.

1. Select an AFK-suitable task. The task should be bounded, testable, and unlikely to require major

new product decisions.

1. Prepare the sandbox. Provide the repository, required tools, and the task environment inside the

sandbox.

1. Define the output. Ask for a branch, commit, pull request, report, or another artifact that can

be inspected later.

1. Run checks automatically. Include the tests, type checks, or review procedure that should execute

before the task is returned.

1. Capture an activity record. Preserve the agent's actions and results so the human can understand

how the output was produced.

1. Review and integrate. Pull the changes back, assess them against the original objective, and

merge only when the result is acceptable.

1. Parallelize separate tasks. Start multiple agents when each task is clearly scoped.

A common division is to use a local interactive agent for planning and selected implementation, then send well-scoped tasks to sandboxed agents triggered through repository actions.

Away-from-keyboard work requires setup. The sandbox, repository access, task format, automated checks, and result-handling path must exist before the workflow becomes smooth.

Sandboxing addresses execution containment, not correctness. An isolated agent can still misunderstand the task, implement the wrong behavior, or produce a change that should not be released. Strategic scoping and review remain necessary.

Not every task should be sent away. Planning, ambiguous work, and complicated decisions benefit from live interaction. The strongest workflow deliberately separates those tasks from mechanical, well-defined implementation.

Use human-in-the-loop sessions for uncertainty and judgment. Send bounded implementation work to sandboxed AFK agents, collect inspectable outputs, and parallelize only where task boundaries are clear.