Someone Has to Run the Agents: The New Platform Layer Nobody Budgeted For

For two years the story of AI coding has been a story about the editor: the autocomplete that finished your line, the chat panel that explained a stack trace, the inline diff you accepted or rejected. That framing is now out of date. The most telling product news of the past month isn’t a new model or a smarter completion — it’s the quiet arrival of infrastructure whose entire job is to run other agents safely, in bulk.

Look at three releases side by side. Dropbox shipped Nova, an internal platform for orchestrating coding agents against its monorepo and CI. LinkedIn’s platform team described treating AI enablement as a shared foundation rather than a per-team scramble. GitHub turned Copilot into a standalone desktop app — a control center for managing many parallel agent sessions at once. Different companies, different scales, same shape. The agent stopped being a feature inside your IDE and became a workload that needs scheduling, isolation, identity, and observability.

That’s not an AI problem. That’s a platform-engineering problem, recreated one level up.

The fleet, not the assistant

A single copilot in your editor has a natural governor: you. You read its suggestion, you run the tests, you hit commit. The human is the orchestration layer, the sandbox, and the audit log all at once.

That model breaks the moment you have a hundred agents running. GitHub’s Copilot app makes the shift literal with its “My Work” view — a dashboard of concurrent sessions, each chewing on a different issue or PR. The interesting engineering decision underneath is humble: every session gets its own git worktree.

# one checkout, many isolated working trees — no branch juggling
git worktree add ../agent-deflake-1 -b agent/deflake-test-A
git worktree add ../agent-migrate-2 -b agent/bump-grpc-1.62
git worktree add ../agent-review-3  -b agent/security-pass

It’s a twenty-year-old Git feature, and it’s load-bearing. When agents work in parallel, “which branch am I on” becomes a concurrency bug, and the fix is mechanical isolation, not a cleverer prompt. That tells you where the hard problems actually live.

Sandboxing is the whole ballgame

If you want one signal that this is platform work and not model work, it’s how much effort is going into containment. OpenAI wrote up its Windows sandbox for Codex, and the story is a tour through the unglamorous middle of operating systems: dedicated local accounts like CodexSandboxOffline, write-restricted tokens scoped to specific directories, ACLs protecting .git metadata, firewall rules drawing the network boundary. They tried the off-the-shelf Windows Sandbox first; it couldn’t hold both ends — strong isolation and deep enough tool access to be useful.

That tension is the entire design space. An agent you trust completely needs no sandbox and is too dangerous to deploy. An agent locked down so hard it can’t touch the repo is safe and useless. Everyone is converging on the same answer: ephemeral, identity-scoped environments. GitHub offers local sandboxes (restricted filesystem and network) and cloud sandboxes (throwaway Linux boxes with centralized policy). LinkedIn’s orchestrator “spins up isolated sandboxes with defined identities and permissions.” Dropbox runs agents in isolated cloud sessions wired to infrastructure but deliberately separates code publication from execution so everything stays auditable.

Give an agent an identity and a permission set, run it in a disposable box, write down what it did. That’s not prompt engineering. That’s the same checklist you’d write for an untrusted CI runner or a third-party microservice — because functionally, that’s what an autonomous agent is.

Intent, plan, validate: the contract that replaces vibes

The other recurring pattern is the refusal to accept loose natural language as an interface. LinkedIn frames AI as a five-stage execution model — intent, plan, execution, validation, output — and insists that intent be structured: explicit scope, out-of-scope boundaries, ordered steps, allowed tools, acceptance criteria. Not “fix the flaky tests,” but a spec a machine can be held to.

You can see why in Dropbox’s most successful Nova deployments, which are tellingly boring. “Deflaker” remediates flaky tests. Dependency migrations get bumped across the monorepo. These work because they’re gradeable — there’s a deterministic validation loop (“propose, validate, iterate”) that can tell a good change from a plausible-looking wrong one. The model proposes; hermetic tests dispose.

# the shape of a task an agent platform can actually run safely
intent: "Migrate callers of LegacyAuth.verify() to AuthV2.check()"
out_of_scope: ["changing auth semantics", "touching prod config"]
allowed_tools: [code_search, edit, run_tests]
acceptance:
  - "all existing tests pass"
  - "no new calls to LegacyAuth remain"

The validation loop isn’t a nicety bolted on for safety. It’s the thing that makes the whole exercise economically real. Without it you’ve automated the production of changes you can’t trust — which brings us to the part nobody has solved.

The bill comes due as a feedback gap

Simon Willison recently drew a sharp line between AI enthusiasts and skeptics: enthusiasts are racing against time, terrified that competitors who move first will bury them; skeptics are racing against entropy, watching code ship faster than anyone can review it, institutional knowledge evaporate, and products drift into incoherence. His point is that both are right, and the real failure is the absence of a feedback loop connecting them.

That is precisely the gap the platform layer exists to close. A validation loop is a feedback loop. An audit trail that separates what an agent proposed from what actually ran is a feedback loop. Copilot’s “Canvas” — a live surface where an agent’s plan, terminal state, and deploy status are visible and steerable instead of buried in a chat scroll — is an attempt to make agent work legible enough that a skeptic can actually inspect it. The enthusiasts’ speed and the skeptics’ reliability concerns don’t get reconciled by a better model. They get reconciled by infrastructure that makes a hundred autonomous changes observable, reversible, and gradeable.

Plan for the platform you didn’t budget for

GitHub now ships a Copilot SDK in six languages so teams can build on the same agentic runtime, which is a quiet admission that the runtime — not the assistant — is the product. The lesson for everyone else is uncomfortable but clear: if your engineers are running agents, you already have an agent platform. The only question is whether anyone owns it, or whether it’s a hundred improvised shell scripts and --dangerously-skip-permissions flags accreting into your next incident.

The glamorous version of this story is the model getting smarter. The real version is that someone has to run the agents — and that someone is building orchestration, sandboxing, identity, and validation that looks an awful lot like the platform engineering we already knew how to do. We just have to do it again, at a new altitude, before the fleet outruns the guardrails.