From Copilot to Delegate: Why Autonomous Agents Need a Sandbox

AI coding assistants are becoming good at more than completing the next line of code. Given a well-scoped task, they can investigate a bug, trace it across repositories, write a fix, run tests, and prepare a pull request.

But there is a large operational gap between an agent that helps an engineer in a terminal and one that can be trusted to continue working after the engineer walks away.

That gap is the agent sandbox.

Uber describes a similar industry shift in its Software Factory: more software-development sessions are being initiated by managed agents that handle bounded workflows, with humans reviewing outcomes or stepping in for genuine decisions. The important change is not simply a more capable model. It is moving execution into an environment where the surrounding system can control context, access, workflow, and cost.

An agent sandbox is one practical way to make that change.

View full-size diagram ↗

The sandbox as a delegation boundary

We built a reference implementation around a simple contract: an engineer delegates an outcome, the sandbox performs the work asynchronously, and the agent returns a reviewable artifact.

The engineer can ask for a bug fix, a coverage improvement, a security remediation, a code review, or a small enhancement. Before dispatch, the local assistant gathers the information the job must have: affected repositories, environment, acceptance criteria, reproduction details, and requester identity.

The long-running work then moves to a remote sandbox. Each job receives a fresh Git worktree and branch created from the latest configured mainline. Shared repository clones make startup fast, while per-job workspaces prevent concurrent agents from interfering with one another. A bounded worker pool limits concurrency, and a durable job store tracks state such as queued, running, waiting for input, succeeded, failed, or cancelled.

This makes autonomy an infrastructure property, not just a prompt instruction.

Give the agent context, not unlimited access

Autonomous execution works best when an agent can find the right information quickly. In the sandbox, repositories are indexed as code graphs so the agent can ask questions about symbols, callers, and cross-file paths instead of repeatedly searching the entire codebase. Workflow-specific skills provide the operating procedure for tasks such as fixing a bug or improving coverage. Test commands, scanners, logs, and reports are available as tools inside the environment.

This reflects another lesson from Uber’s Software Factory: grounded context reduces the turns an agent spends looking for information—and reduces the chance that it confidently follows the wrong path.

At the same time, context should not mean unrestricted authority. The sandbox constrains capabilities at the systems layer:

• database access is read-only and environment-scoped;
• source-control credentials can create branches and pull requests but cannot administer the project;
• protected branches require human review and prevent direct delivery to production code;
• secrets are injected at runtime rather than copied into prompts or repositories;
• the service has no direct inbound network exposure; and
• jobs, actions, logs, and requester identity are recorded for traceability.

The core principle is simple: give the agent enough access to diagnose, implement, and verify—while ensuring that its final act is a proposal, not an irreversible production change.

Autonomy still needs an escalation path

Some tasks are ambiguous in ways that code cannot resolve. If two plausible interpretations would produce materially different behavior, the agent should not guess silently.

The sandbox therefore supports pause-and-ask. A running job can enter a waiting state, surface one consolidated question to the engineer, and resume in the same workspace when an answer arrives. If nobody responds within a defined window, the agent can proceed with a clearly stated assumption and flag it in the pull request.

This creates a useful middle ground between constant supervision and unchecked autonomy. Humans stay out of routine execution but remain available for decisions that carry product or architectural intent.

Design for failure, not just the happy path

Long-running agent jobs will occasionally hit a tool failure, a turn limit, or an unexpected repository condition. A production-minded sandbox should make those failures visible and recoverable.

In this implementation, output streams to a job log, work is checkpointed through commits and pull requests, and partial tracked changes can be salvaged before a failed workspace is cleaned up. Cancellation is explicit. Concurrency is capped. Idle infrastructure can stop when no jobs or users are active. The result is closer to a small workload platform than a remote shell with an AI process inside it.

That distinction matters. A remote shell gives an agent somewhere to run. A sandbox gives the organization a way to operate agents.

A practical path to managed agents

The broader Software Factory vision can sound like it requires a large centralized platform. It does not have to start that way. A useful first version can be assembled from familiar engineering building blocks:

1. a typed interface that turns conversations into bounded job requests;
2. an asynchronous queue and durable lifecycle;
3. isolated workspaces created from known source revisions;
4. task-specific skills and graph-grounded code context;
5. least-privilege access to diagnostics and delivery systems;
6. verification through tests and scanners;
7. human escalation for genuine ambiguity; and
8. pull requests, reports, logs, and audit events as the outputs.

The model remains important, but it is only one component. Reliable delegation comes from the system around it: the sandbox defines what the agent can see, what it can do, how long it can run, when it must ask, and what counts as a completed result.

That is the step from using an AI assistant to operating an autonomous engineering capability.

---

Further reading: Running a Software Factory Efficiently at Uber Scale. This post uses the managed-agent concept as a point of departure; the architecture and conclusions above come from our own agent-sandbox implementation.