Cloud agents are becoming an operating layer
The latest generation of coding agents does not sit in your editor waiting for input. It runs in the cloud, unattended, often for long stretches: reconstructing a full development environment, installing dependencies, running tests, retrying on failure, and coordinating changes across more than one repository. The vendors building these systems describe the requirements accurately — durable execution, environment reconstruction, network and secret access, and verification access so the agent can check its own work.
Those are real engineering problems, and solving them is what turns a chat assistant into infrastructure. But notice what the list is about: it is about keeping the agent running reliably. None of it is about keeping the system the agent changes coherent.
Durable execution answers “did the agent finish its run?” It does not answer “was the architecture still intact when it did?”
The environment is now a governance surface
One claim from the cloud-agent vendors is worth taking seriously: output quality depends on the full development environment — network access, secrets, dependencies, and the ability to verify. That is true, and it has a consequence they tend not to draw out. If the environment determines what the agent can do, then the environment is a governance surface. What an agent is allowed to reach, change, and rely on is a set of decisions, and those decisions need to be enforced, not just configured.
This generalizes a pattern we have written about repeatedly: as agents act on more of the system, governance has to follow them to the surfaces where they act. The cloud environment is simply the newest and largest such surface.
Once agents run unattended, the missing layer is governance
The defining property of a cloud agent is that no human is watching the individual steps. It can spawn subagents, touch multiple repositories, and decide for itself how to approach the work. Each of those capabilities is exactly the condition under which architectural drift enters a system: local optimization, inconsistent enforcement, and decisions that fragment across handoffs.
A repository rule can govern code that an agent commits through Git. It cannot automatically govern every action the agent takes through a CLI, an API, an integration, or its own runtime. When the agent runs unattended across repositories, the question “what architectural decisions are allowed to survive this execution?” has to be answered by the system, because no reviewer is there to answer it in real time.
| Capability | Durable execution | Architectural governance |
|---|---|---|
| Keeps the agent running | Yes | — |
| Rebuilds the environment | Yes | — |
| Retries through failure | Yes | — |
| Checks the change against decisions | No | Yes |
| Keeps multi-repo architecture coherent | No | Yes |
Governance as executable infrastructure
The deeper shift the cloud-agent moment reveals is that governance is no longer an organizational process — a meeting, a review, a document. It is becoming executable infrastructure: execution runtimes, agent orchestration systems, verification layers, repository-native policy enforcement, and explainable enforcement traces, all running alongside the agents themselves.
In that stack, durable execution and architectural governance are adjacent layers, not competitors. One makes the agent reliable; the other makes its output trustworthy. A cloud agent with perfect durability and no governance is a system that will run forever and drift continuously.
Cloud agents make durable execution table stakes. The differentiator becomes the layer above it: governance that decides which architectural decisions survive the run.