When Cursor first launched cloud agents a year ago, the team thought they were simply porting local agents to run on servers. After a year of production experience, they’ve learned the work is far more complex. As Josh Ma detailed in a recent engineering blog, building reliable cloud agents means reconstructing the entire world an agent needs to operate in—not just running the same code remotely.
The Development Environment Is the Product
The single biggest factor in cloud agent output quality, Cursor found, is ensuring the agent has a complete development environment. This is trivial for local agents because they inherit your laptop’s shell, packages, and environment variables. In the cloud, everything must be rebuilt from scratch.
The insidious part is that an incomplete environment rarely causes crashes or errors. Instead, it produces a subtle degradation in output quality that can easily be mistaken for a model limitation. Cursor traced this pattern repeatedly: the agent lacked the environment to execute or verify its work. A year ago, models were less capable of using their environment anyway, so setup mattered less. As models have grown smarter, environment completeness has become the bottleneck for unlocking their full potential.
To achieve “full environment” today, Cursor had to rebuild substantial infrastructure:
- Better user tools for building agent environments
- Methods to efficiently hibernate and resume agent VMs between messages
- Pipelines to checkpoint, restore, and fork VM images
- Tight harness and client integrations so agents and humans can interpret and interact with the environment
As cloud agents take on more work—creating PRs, pulling dependencies, doing research—they need controlled network access. Over time, Cursor built what is essentially enterprise IT for agents, complete with secret redaction, network policies, and credential management.
Long-Running Agents Need Durable Execution
Cloud agents present a different reliability challenge than local agents. Instead of competing for local resources, they run in isolated VMs, making it easy to run many in parallel and delegate tasks spanning hours. But VMs introduce new failure modes: inference provider outages, pod replacements, EC2 node failures.
Cursor initially used a work-stealing architecture where worker nodes picked up agents and ran them to completion. That fragile setup, transplanted from local agents, often operated at only one 9 of reliability in early beta.
As cloud agents matured, Cursor realized they were reinventing durable execution primitives that Temporal already solves: retries, scheduling across machines, durability across node failures. They migrated to Temporal. Now the agent loop can survive inference blips, pod hibernation and resumption, and runs lasting days or weeks. That migration alone pushed reliability past two 9s. Today, Temporal handles more than 50 million actions per day across more than 7 million unique workflows. Internally, over 40% of Cursor’s PRs now come from cloud agents, and the share is growing.
Cursor also refined their Temporal workflow architecture. They moved from “eternal” agent workflows to multiple shorter ones that exit after a single task, making version upgrades easier. They split activities to better capture timeouts and retries, as async tool calls, subagents, and inference provider outages changed underlying assumptions.
Decoupling Agents, Machines, and Conversation State
A cloud agent is no longer one loop on one machine. An agent may run on one machine, spawn async subagents across several, or start locally then delegate to the cloud. A subagent might outlive its parent or run on a different kind of pod.
To make this work, Cursor keeps three components decoupled: the agent loop, machine state, and conversation state. The agent loop lives in Temporal, not on the VM, so pod lifecycles can be managed independently. Agents can run across different pod types, including readonly VMs or prewarmed VMs.
For conversation state, Cursor separated the storage and streaming layer from the core agent workflow. They built an efficient append-only storage mechanism that streams updates to web and desktop clients. This layer handles retries: if a step fails after streaming partial output and retries, the client detects it, rewinds the stream, and shows new data instead of old.
Knowing When to Get Out of the Way
Building a cloud agent harness means constantly reevaluating how much behavior is deterministic and how much gets handed to the agent. Early on, Cursor didn’t trust the agent much, so the harness double-checked work after every task, forced commits, and pushed. As models got smarter, logic moved out of the harness into tools the agent controls.
A year ago, multi-repo setups required hardcoded harness behavior. Now, they give the agent the repo layout, expose tools for branches and PRs, and let it decide how to work. CI Autofix followed a similar path: earlier harness versions contained logic for grabbing job failure logs and writing them to the VM. Today, they just give the agent GitHub CLI access and automatically write large outputs to searchable files. The notification to the agent got much simpler.
The harness isn’t disappearing; what it contains is changing. Computer use is a current example. Cursor’s cloud agent harness has a dedicated subagent type for computer use with custom model routing, prompting, and screen recording. VNC and Chrome belong to the environment, shared between parent and subagent. This scaffolding exists because models aren’t ready to handle computer use alone, but the agent still controls when to invoke it.
Cloud agents also need different prompts than local agents. They’re encouraged to be more autonomous because blocking is costly. Locally, you know when an agent has stopped. In the cloud, it could sit for hours before you check.
Toward Self-Healing Agent Environments
Looking forward, Cursor wants to move past the binary choice between hand-holding and full autonomy. A better pattern is giving the agent tools to understand its system. The goal is for cloud agents to report missing secrets, blocked network access, or environment issues preventing progress—and then act in a self-healing way. In a recent research blog, Cursor discussed “autoinstall” as one path toward this.
Key Takeaways for Builders
Cursor’s experience offers several lessons for anyone building AI agents:
- Environment trumps model sophistication. The biggest quality gains come from ensuring complete, reproducible environments—not from swapping models.
- Use durable execution frameworks early. Work-stealing is fragile; adopting Temporal or similar systems avoids reinventing retries, scheduling, and fault tolerance.
- Decouple components. Separate agent logic, machine resources, and conversation state to allow independent scaling and lifecycle management.
- Evolve your harness as models improve. Move deterministic logic into agent-controlled tools, and design prompts for autonomous behavior, especially in cloud settings where blocking is invisible.
- Build self-healing capabilities. Equip agents to diagnose and fix environment issues rather than failing silently.
Cloud agents have improved immensely in just the last few months, and Cursor expects the rate of change to accelerate. Their cloud agents let teams take advantage of this expanding capability surface without having to build and maintain the underlying infrastructure. For product builders, the most important lesson might be this: when you treat an agent as a team member, you realize it doesn’t need a smarter brain—it needs a world it can actually work in.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.