- Permissions and sandbox limits. Many agents don’t run on a dev’s laptop with admin access They run in the cloud or in locked down sandboxes: no sudo, restricted filesystem, restricted network egress. So “just install it” is sometimes not allowed or not even possible.
- It is a token and time sink and easy to go down the wrong path. Dependency errors are noisy: missing system libs, wrong versions, build toolchain issues, platform quirks. Agents can spend a lot of iterations trying fixes that don’t apply, or that create new mismatches.
Repo ready environments don’t replace agents installing deps. They just reduce how often they have to guess.
I think a lot of teams realize “agent sandboxing” isn’t just isolation, it’s about making long-running agent work actually converge.
In practice, agents don’t fail only because the model is wrong. They fail because the environment is flaky: missing deps, slow setup, weird state, unclear feedback loops. If you give an agent an isolated, secure environment that’s already set up for the repo, you remove a ton of friction and iterations become much more reliable.
The other piece is “authority” / standards. You can write guidelines, but what keeps agents (and humans) aligned is the feedback: tests, linters, CI rules, repo checks. Centralizing those standards and giving the agent a clean place to run them makes compliance much more deterministic.
We built this internally for our own agent workflows and we’re debating whether it’s worth offering the sandbox part as a standalone service (https://envs.umans.ai), because it feels like the part everyone ends up rebuilding.