Skip to content
← Back to Articles

The Agent Infrastructure Layer Is Here

· 10 min read
Agentic Development GitHub Copilot Platform Engineering Security Opinion
The Agent Infrastructure Layer Is Here

The Laptop in the Same Room

My laptop is in the same room. It’s open. It’s charged. I haven’t touched it in three hours.

I’m walking laps around my kitchen with my phone, dispatching agents over Telegram into GitHub Copilot CLI sessions. One is reviewing a pull request on the htek.dev Astro 5 site. Two are running content-illustrator jobs against gpt-image-2. Four are on cron schedules I set up weeks ago. Right now, somewhere on my hardware, ~40 domain agents are alive — most idle, several working, one of them writing this paragraph.

I am extremely more productive this way. Some of my best work this year happened in the gym, in the car, or pacing the living room while Hector Jr. and the twins napped. The laptop is across the room. I rarely sit at it.

That’s the moment I realized: the medium of sitting at a keyboard is the bottleneck, not the agent. And in Q2 2026, the industry caught up. GitHub’s cloud and local sandboxes for Copilot entered public preview on June 2, 2026 — running Copilot CLI sessions inside isolated ephemeral Linux environments hosted by GitHub, with copilot --cloud and /sandbox enable flipping the runtime layer for everyone. That, plus the broader agent-native Copilot desktop direction, turned persistent agent compute from a personal hack into a product layer. The agent infrastructure layer is here.

This article is a perspective piece, not a tutorial. It picks up where my prior essay on workflows as the new asset left off — and extends that thesis into the persistent-compute era.

The New Shape of Compute

The new shape of compute is agents as your interface, not your IDE. Persistent compute decouples the agent from the developer’s keyboard, so voice and chat replace code .. The laptop becomes a heavyweight tool reserved for focused work — not the daily driver. For me, it has become a side computer, and the Telegram bridge into Copilot CLI is the front door.

Six months ago I would have called that a hack — “ooh, look, I can SSH from my phone.” It isn’t. SSH from a phone is unusable for real engineering. What changed is the agent. With a competent agent on the other side of the wire, the phone stops being a remote terminal and becomes a dispatch console.

Once you taste that, you cannot go back. I have trouble walking toward my desk now. The keyboard is slower than my voice. The keyboard is slower than my walking. The keyboard pigeonholes you into one task at a time, in one window, in one room.

A lot of developers won’t even feel this yet. They’ll insist the laptop is the most productive medium they’ve ever had — and they’ll be right, for the workflow they’re running. The point isn’t that laptops are bad. The point is that agents are so much faster than typing that the medium has to change to keep up with them.

Architecture flow diagram: developer dispatches over voice or chat into a persistent compute host running sandboxed agents, with a continuous governance loop feeding back into the runtime. The new shape of agentic development — keyboard input becomes optional, persistent compute hosts long-running agents inside dynamic sandboxes, and a governance loop runs continuously alongside them.

The Asset vs the Workflow — the Workflow Is the Winner

The asset versus the workflow — the workflow is the winner. That single sentence is what made persistent compute inevitable. Once the workflow is the asset, the workflow is what scales — and a laptop is the wrong substrate to scale a workflow on. The result is a category shift: compute follows the asset, and the asset moved up the stack.

In my prior essay I argued that code stopped being the asset around the time agents got good enough to write it. The asset moved up the stack: into context engineering, agent design, and the harness around the model. That essay was about what won. This one is about what wins demand.

Workflows demand somewhere persistent to live. A laptop can host one or two agents comfortably. Run ten and the OS starts swapping. Run forty and the laptop becomes a single point of failure for your entire process — close the lid and your work stops, sleep mode kills sessions, a Windows Update reboot wipes a day of running cron jobs. I’ve watched it happen.

Persistent agent compute solves the structural problem the workflow created. It is the natural next step: if the workflow is the asset, the workflow needs infrastructure. Not “more RAM on my MacBook” infrastructure — real infrastructure, with uptime, isolation, and compute that doesn’t care whether your laptop is plugged in.

That’s why the persistent agent compute category shipped real product in Q2 2026 instead of staying hypothetical. GitHub put cloud sandboxes into public preview. Microsoft published guidance on building long-running AI agents on Azure App Service with the Microsoft Agent Framework. The Microsoft and GitHub ecosystem hit the same wall at roughly the same time — laptops can’t host real workflows — and reached for the same answer: move the agent off the developer’s machine.

Trust Is the Gate

The only thing standing between us and fully autonomous agents is trust, and sandboxing is the trust unlock. Long-running agents accumulate blast radius the longer they run, so isolation has to live at the runtime layer — not in policy documents. GitHub’s cloud sandbox model and OpenShell-class policy runtimes are both expressions of this same principle: lock the runtime, not the developer.

Persistent compute amplifies the problem. An agent that runs for five minutes can only break so much; an agent that runs for five days can break a lot.

I contributed to GitHub Copilot CLI specifically to integrate with NVIDIA OpenShell because I genuinely believe sandboxing is the last layer we need to ship fully autonomous agents into production. Everything else — hookflows, governed extensions, memory — is necessary. Sandboxing is sufficient.

That’s why I got excited when GitHub started rolling out cloud and local sandboxes for Copilot. They are doing the right thing: redesigning the Copilot compute layer to align to the agent era, starting with sandboxing. That is exactly the right place to put it. My whole platform philosophy is let the right thing to do be the easy thing to do — and with sandboxing built into the compute layer, the right thing to do is the only thing you can do. There is no “skip the sandbox” path. That is a structural win for the ecosystem.

I’ll be honest: I’m not running a sandbox today. I’m running a strict governance process — hookflows that block raw git, governed extensions instead of fat tools, and continuous review of agent behavior. It works. It also has potential holes. Everyone should be doing sandboxing in some way or another. Sandboxing is the layer that closes the cracks your governance leaves open — the strongest assurance available that nothing slips through. It is the last layer of protection, not the only one.

Concentric trust-layering diagram with the agent at the core, surrounded by an inner harness ring, a dynamic sandbox ring, and an outer continuous-governance ring. Defense in depth for long-running agents — the harness governs the agent’s tools, the sandbox isolates the runtime, and a continuous governance loop closes the cracks the static layers leave behind.

What’s Still Missing: Absurd Granularity

What’s still missing across the category is dynamic granularity. A static sandbox — defined once, locked down, reviewed quarterly — becomes another IT layer of governance, and agents route around IT layers the same way developers always have. The fix is per-binary, hot-reloadable policy that the agent itself can extend at run time, gated by deterministic and non-deterministic review.

Agents move faster than quarterly review cycles. The sandbox has to move with them.

NVIDIA OpenShell is the benchmark here. OpenShell exposes per-binary network policies in a hot-reloadable policy file. That means an agent can declare this binary needs to talk to this endpoint, and the policy adjusts in real time, gated by deterministic and non-deterministic review. That is the level of malleability the rest of the category has to match.

I’m hoping the Copilot sandbox surface evolves in this direction — that it lets the agent declare what individual endpoints it needs, with absurd granularity, and the policy engine adapts. Early signals from the Copilot cloud agent docs suggest GitHub is thinking about this seriously. If sandboxes stay rigid, they become the next bureaucratic layer everyone routes around. If they go dynamic, they become the foundation for fully autonomous agents.

This is a constructive push, not a critique. GitHub is in the best position in the industry to ship dynamic sandboxing because the Copilot CLI already understands the agent’s intent at the tool-call level. The pieces are there. The question is whether the policy layer evolves fast enough to keep pace with the agents running inside it.

My Copilot CLI extensions approach is a version of dynamic granularity — but at the tool-governance layer, not the runtime layer. It is the second line of defense. Sandboxing is the first. Both should exist.

Governance Has to Move at Agent Speed

Persistent agents change the governance calculus completely. Continuous governance is non-negotiable, because long-running agents accumulate risk continuously, and the governance loop itself has to be a workflow — not a policy document. It is not about what governance you have enabled. It is about what workflows are enabling governance. The same DevOps discipline DORA has measured for a decade — small batches, automated checks, fast feedback — applies, but at agent speed.

A static “we have a security review” model breaks the moment an agent runs for 72 hours and touches twelve repos. The governance loop has to be another agent, finding holes, patching them, tightening permissions, then doing it again the next hour. This is the harness primitive set I rely on:

That last one is the part most teams skip. The governance strategy itself must be a workflow, not a document. The 2024 Accelerate State of DevOps Report is direct about this: high performers win on disciplined process, not raw speed — and that pattern carries into agentic development. Persistent compute makes it practical: a governance-auditor agent can run on a cron, every hour, forever, with no laptop required. Two months ago I would have said that’s overkill. Today it is the only model that keeps up.

If you want a deeper walkthrough of the harness primitives behind this, the agent harness post and governance stack cover the architecture in detail. Persistent compute does not change what those primitives are — it changes how often they have to run.

Leave the Keyboard

The agent infrastructure layer is here, and the shape is finally clear. Compute is moving off the laptop into Copilot’s cloud sandboxes and Azure-hosted long-running agents. Sandboxing is moving into the compute layer by default. Governance is moving from a document to a workflow that runs at agent speed. The category is real, the tools are shipping in Copilot CLI releases, and the laptop is no longer where development happens.

The change you can make this week is smaller and more personal: try a different medium for one day. Set up a Telegram bridge to your CLI. Dispatch one agent over voice while you walk the dog. Notice how much the keyboard was constraining you. The first day feels weird. The second day, the laptop starts to feel like a desktop tower from 2008 — useful for the heavy stuff, irrelevant for everything else.

Once you have done that, the rest of the stack follows naturally. You’ll want persistent compute, because closing your laptop will start to feel like a limit. You’ll want sandboxing, because long-running agents will start touching things you care about. You’ll want continuous governance, because static rules will start to feel slow. The infrastructure layer is here precisely because thousands of developers are about to want all three.

The right thing to do is becoming the easy thing to do. The only thing left is to stop staring at the keyboard.

Resources

External sources:

Prior articles in this thread:

← All Articles