Summary: A Cursor engineering post says building cloud agents required rebuilding environments, reliability, and orchestration rather than merely moving local agents to servers. Complete development environments most affected output quality, while adopting Temporal raised reliability beyond two nines. The company now separates agent logic, machine state, and conversation state, and is moving toward agents that diagnose and repair their own environment issues.
A year ago, shipping cloud agents looked to Cursor like a straightforward move: take the local agent, run it on a server. Twelve months of production reality said otherwise. In a recent engineering blog post, Josh Ma explains that the real job turned out to be rebuilding every condition an agent depends on—not relocating the same code to different hardware.
A Complete Environment Beats a Stronger Model
Ask Cursor what moves the needle most on cloud agent output quality and the answer isn’t model choice—it’s whether the agent has a complete development environment. Locally this comes free: the agent inherits your laptop’s shell, packages, and environment variables. In the cloud, everything starts from nothing.
The nasty part: a half-built environment almost never throws errors or crashes—it quietly degrades output quality, and the blame usually lands on the model. Every time Cursor chased this pattern down the finding was identical: the agent lacked the environment to execute or verify its work. A year ago that hardly mattered, because models barely used their surroundings; now that models are sharper, environment completeness gates how much capability you unlock.
Reaching that “full environment” took a major infrastructure build:
- Sharper tools for assembling agent environments
- Efficient hibernation and resumption of agent VMs between messages
- Pipelines for checkpointing, restoring, and forking VM images
- Harness and client integrations letting agents and humans interpret and operate the environment
The workload kept growing—PRs created, dependencies pulled, research carried out—and with it the need for controlled network access. Piece by piece, Cursor assembled what amounts to enterprise IT for agents: secret redaction, network policies, and credential management.
Reliability for Agents That Run for Days
Reliability means something different once agents leave your laptop. Rather than competing for local resources, cloud agents live in isolated VMs—run many in parallel and hand them jobs that stretch over hours. Isolation brings fresh failure modes: an inference provider goes dark, a pod gets replaced, an EC2 node goes down.
Cursor’s first answer was a work-stealing architecture: worker nodes picked up agents and ran each to completion. Transplanted straight from the local world, the setup proved fragile—early-beta cloud agents often sat at a single 9 of reliability.
Maturity brought a realization: Cursor was rebuilding by hand the durable execution primitives Temporal already handles—retries, scheduling across machines, surviving node failures. So they moved onto Temporal. The agent loop now rides out inference blips, pod hibernation and resumption, and runs lasting days or weeks. That migration alone lifted reliability past two 9s. As of the post, Temporal processes more than 50 million actions per day across more than 7 million unique workflows, and over 40% of PRs inside Cursor come from cloud agents—a share still climbing.
The Temporal workflow design got its own rework: one “eternal” agent workflow became many shorter ones that finish a single task and exit, making version upgrades far less painful. Activities were split finer, so timeouts and retries get captured more accurately—async tool calls, subagents, and inference provider outages had broken the original design assumptions.
Three Separate Concerns: Agent, Machine, Conversation
The era of one loop on one machine is over. Today a cloud agent might run on a single machine while async subagents fan out across several others, or begin locally and hand work off to the cloud. A subagent can outlast its parent and sit on an entirely different pod type.
Making that possible meant holding three things apart: agent loop, machine state, and conversation state. Because the loop lives in Temporal rather than on the VM, pod lifecycles can be managed independently, and agents can land on any pod type—readonly VMs and prewarmed VMs among them.
Conversation state gets the same treatment: storage and streaming were pulled out of the core agent workflow into an efficient append-only store that streams updates to web and desktop clients. Retries live here too—when a step fails after part of its output has streamed and then retries, the client notices, rewinds the stream, and shows the new data in place of the old.
Deciding What the Harness Owns—and What the Agent Does
Every harness decision circles one question: how much behavior stays deterministic, and how much belongs to the agent? Early on Cursor trusted the model little, so the harness re-inspected work after every task and forced a commit, then a push. As models improved, that logic moved out of the harness into tools the agent operates itself.
Multi-repo setups once required hardcoded harness behavior; now the team describes the repo layout, hands over branch and PR tooling, and leaves the approach to the agent. CI Autofix traced the same arc: earlier versions carried logic that grabbed job failure logs and wrote them to the VM, whereas the agent today simply gets GitHub CLI access and large outputs land automatically in searchable files. The notification to the agent shrank accordingly.
None of this means the harness is disappearing—what sits inside it keeps changing. Computer use is a live example: the cloud agent harness includes a dedicated computer-use subagent type with its own model routing, prompting, and screen recording. VNC and Chrome belong to the environment, shared between parent and subagent. The scaffolding exists because models aren’t yet ready to handle computer use on their own; the agent, though, still controls when to invoke it.
Prompting shifts too: cloud agents are pushed toward autonomy because blocking is so costly. Locally, you see the moment an agent stops; in the cloud, it may sit for hours before anyone checks.
The Next Step: Agents That Diagnose Their Own Environment
Cursor’s roadmap aims to dissolve the either-or between hand-holding and full autonomy. The better pattern gives the agent tools for understanding its system: cloud agents should report missing secrets, blocked network access, or whatever environment issue is stopping progress, then repair it themselves. A recent research blog describes “autoinstall” as one route toward that goal.
What Builders Should Carry Away
Cursor’s experience leaves several lessons for anyone building AI agents:
- A complete environment beats a smarter model. The biggest quality gains come from complete, reproducible environments—not from swapping models.
- Adopt durable execution early. Work-stealing is fragile; Temporal or something similar spares you from reinventing retries, scheduling, and fault tolerance.
- Keep the components separate. Splitting agent logic, machine resources, and conversation state allows independent scaling and lifecycle management.
- Let the harness evolve as models improve. Move deterministic logic into agent-controlled tools, and write prompts that assume autonomy—especially in the cloud, where a block goes unseen.
- Build in self-healing. Equip agents to diagnose and fix environment issues rather than failing silently.
Cloud agents have come a long way in just the past few months, and Cursor expects the pace of change to keep accelerating. Their cloud agents let teams ride this expanding capability surface without building and maintaining the infrastructure underneath. For product builders, the takeaway may come down to one line: treat an agent as a teammate, and you realize it doesn’t need a smarter brain—it needs a world it can genuinely work in.