Agent Sandboxes Don't Solve the Problem That Actually Matters

Previous in this series: Where Does an Agent Actually Live, If Not Inside Its Sandbox?

Next in this series: Giving Everyone ChatGPT Isn't the Same as Owning an Agent

It's a Wild West Out There, and Everyone Knows It

It's a wild west out there, and everyone knows it.

Walk into almost any company right now and ask who's building agents, and the answer is: everyone, individually, in whatever tool they happen to be using. A personal skill in Claude Code gets called an agent. A script that automates one person's Tuesday gets called an agent. It works, which is exactly why nobody questions it yet. Even OpenAI's push into hosted sandboxes is really a symptom of the same underlying question the rest of the industry is circling: how do you take something built on one person's laptop and make it survive contact with production? A sandbox answers part of that. It answers the execution problem. It has nothing to say about who's allowed to run the thing, who approved it, or what happens when the person who built it stops showing up.

Agents Are Applications Now, Whether Anyone Treats Them That Way

Agents are applications now, whether anyone treats them that way or not.

The application-server era had this figured out decades ago: a team builds software, a team maintains it, and the software outlives any single person's involvement in it. Agents collapsed the "build" part down to almost nothing — you describe what you want, and it exists — but collapsing the build time didn't collapse the obligations that come after. Something still has to be operated. Something still has to evolve from version one to version ten without breaking. Organizations just haven't caught up to the fact that the fast, disposable-feeling thing they let someone spin up on a Tuesday afternoon is already carrying all the same weight a real application always has.

An organization owns an agent. It isn't a personal project that quietly disappears the week its owner goes on vacation.

Building One and Being Trusted With One Are Different Problems

Building one and being trusted with one are different problems.

Anyone can build an agent today — that part of the wild west is already settled, and settled in favor of speed. What's missing is everything that comes after the build: a review cycle where someone other than the builder actually looks at what the thing does before it goes live, and a real way to version it when it inevitably needs to change. Without both, the risk isn't abstract. It's someone going on PTO, or leaving the company outright, and taking the only working knowledge of how their agent functions with them — leaving a team staring at something they can't safely touch, let alone improve.

Multiply that across every team solving the same problem its own separate way, and what you get isn't innovation. It's duplicated effort with no shared visibility into any of it.

The Sandbox Was Never Going to Be the Whole Answer

The sandbox was never going to be the whole answer.

Isolation keeps one agent's bad day from becoming everyone else's problem, and that matters — but it was always solving the smaller piece. The harder question sits one layer up: once an organization decides it's actually willing to stand behind an agent, what does it need to see before it trusts the thing enough to authorize it? Not a demo. Not a vibe. Something closer to evidence.

That's the question worth asking next.