Cursor Engineering Lead: How to Give AI Agents Their Own Cloud Computers

Model capability is no longer the bottleneck—engineering agents is

When model capability is no longer the bottleneck, what are AI agents really missing? In a technical talk, the Cursor engineering lead gave their answer: give agents a cloud computer.

The talk opened with a key judgment: for a growing number of tasks, the bottleneck is no longer model intelligence itself, but whether humans are willing to hand tools, context, and bolder goals to the model. The Cursor team's focus is precisely on removing this human-imposed bottleneck—"safely unleashing agents so they can take on bigger tasks."

They break this process into three stages: first, give agents tools and context so autonomy becomes possible; then, learn to work well with stronger models and adjust their own working patterns; finally, enter the stage of "building systems of systems"—shifting from hand-holding agents task by task to building an automation foundation that covers everything from A to Z.

Following the human onboarding process: give agents the treatment of a new hire

Cursor's approach is straightforward: look back at what human developers go through when they onboard. A new hire gets a computer, is told how to set up the development environment, and receives extensive documentation explaining the various operations of daily work. In the past, the "onboarding training" given to models was, plainly put, throwing the model into a codebase and letting it rapidly skim through thousands of lines of code—no environment, no ability to test, only blind reading. The speaker admitted that if they themselves worked this way, they would find it equally frustrating.

To address this, they built a cloud onboarding agent: anyone can visit cursor.com/onboard, configure their repository, and the agent begins exploring the codebase—not to modify code, but to figure out how to get the project running. It identifies which services need to be started, handles environment variables, confirms required permissions, and works interactively with the developer, ultimately delivering a runnable demo.

Making agents as convenient as local development

Agent onboarding is just the starting point. When many developers are running numerous cloud agents in parallel every day, any small issue gets multiplied. Cloud agents need to set up their environment from scratch on every run, whereas in local development people typically keep services running continuously—this difference introduces significant waiting time.

Cursor built the AnyDev CLI tool for this: it starts services, waits for them to be ready, checks status, and like a Swiss Army knife covers miscellaneous chores such as creating test accounts and logging into third-party services. In addition, they created simplified versions of the documentation intended for human developers, for agents to consult when they encounter edge cases.

The effect creates a positive feedback loop: the better the development environment works, the more developers are willing to run more cloud agents, and output increases accordingly. This process distilled into several core principles—

• Give agents eyes: Whatever a human can see, the agent should be able to see. The application the agent is running must be visible, and if a human manually changes state, the agent must be able to perceive it; when debugging conversations, the agent also needs to see other agents' conversation logs.
• Give agents tools: Under reasonable safety constraints, agents should be able to do what you can do, especially running applications and using services.
• High-quality input yields high-quality output: Agents are autoregressive—the quality of the codebase, instructions, and context directly determines the quality of output.

Computer use: the agent's next major battleground

The team believes that the foundational primitive of human autonomy is computer use. Coding is the first domain agents have mastered, and computer use is the next critical area: raw pixel input, mouse and keyboard output. The speaker pointed out that the difficulty is not in clicking the right spot, but that GUI navigation is more like a video game than chess—you can only see a small field of view, there are one-way doors and game-over states, so it demands higher-level metacognition, fallback capabilities, and general intelligence, which is exactly where the Claude series of models excels.

They demonstrated how the agent performed after receiving the task "build a private marketplace feature": the agent implemented each widget on its own, handled URL input and CSP configuration, and recorded a demo for self-testing. For developers, this is a high-bandwidth way to review—seeing the agent demonstrate its work before reading the code. When multiple agents are running in parallel, this capability becomes especially critical.

Computer use refers to AI agents operating computer interfaces the way humans do—receiving screen pixels as input and controlling applications through low-level actions such as mouse clicks and keyboard input, rather than relying on APIs or command lines. This concept was brought into the mainstream by Anthropic when it introduced the Computer Use capability in Claude 3.5 Sonnet in 2024, and was subsequently followed by products such as OpenAI's Operator.

Unlike coding agents that can directly manipulate the environment by reading and writing files and running scripts, computer-use agents must handle visual recognition and interaction with arbitrary GUI applications, facing challenges such as limited resolution, dynamically changing interfaces, and irreversible operations (such as accidentally deleting files). This field therefore places extremely high demands on models' visual understanding, spatial reasoning, and long-horizon planning, and is regarded as a key step in the evolution of agents from specialized tools to general-purpose assistants.

Learning to assign bigger tasks to agents

Once autonomous agents complete onboarding, the next step is learning to assign more and larger tasks. The talk mentioned two modes: one is to throw the small tasks and bugs accumulated in notes and to-do lists directly into the prompt box to kick off, letting more agents run in parallel and replacing line-by-line code review with demos; the other is larger-scale projects, handing bigger units of work to agents and letting them work continuously for longer periods.

What surprised the team was that "the stronger the agents, the more imaginative the work developers do" materialized far beyond expectations. They particularly emphasized the "safety through freedom" that security enables: while agents act autonomously in the cloud, developers are freed from resource management and context switching, and don't need to worry about agents messing with environment variables.

"Safety through freedom" refers to a design philosophy: rather than constraining agents through layers of approvals and sandbox restrictions, give agents ample autonomy in a controlled cloud environment while freeing human developers from tedious supervision. When agents run on isolated cloud machines, even if they accidentally modify environment variables or execute wrong commands, it won't affect the developer's local environment or production systems—risk is confined to a recoverable range.

This concept appears to contradict the traditional "principle of least privilege" but is actually complementary: safety boundaries are guaranteed at the infrastructure level (cloud isolation, snapshot rollback, permission auditing), and within those boundaries, agents are granted operational freedom close to that of humans, enabling them to complete more complex long-horizon tasks. Cursor's practice shows that this model actually builds trust and boosts output better than frequently interrupting agents to ask for confirmation.

When something fails, fix the system—don't work around it

When an agent fails, it's worth taking the time to investigate the root cause and implement a fix—because such fixes get multiplied across the entire team and company. If failure modes persist over time, they compound and spread across the whole company, and people become increasingly reluctant to use agents; conversely, after investing in improvements, everyone becomes more willing to use them, trust builds gradually, and people dare to hand off bigger tasks in one go.

Let agents improve themselves: Agent Experience

When the team realized that "teaching agents to work better" itself feels like writing code, they naturally thought of having agents do it themselves. They call this direction Agent Experience (AX), sitting alongside developer experience and perhaps deserving even more attention.

Mechanically, agents are asked to report issues as they work—when they encounter something annoying, broken, or confusing, they report it rather than toughing it out. All reports flow into a logging system, where a "manager" role (shared by humans and agents) reviews, categorizes, deduplicates, and then buckets them: technical issues, permission issues (the agent lacks access), and ignorance issues (the agent doesn't know the right approach and needs human guidance). Finally, agents and humans fix them together, with the goal that over time human involvement decreases until agents can solve things end-to-end and are highly trustworthy.

The most representative skill is called WCF—Work on the Factory. Every cloud agent loads this skill, and the prompt is nearly identical to the process described above. The speaker mentioned that earlier models couldn't do this well, but today's models "get annoyed," notice when things are broken, recognize when they're confused, and proactively report.

The fixing phase also has its nuances: agent experience issues are often sporadic and flaky, and having an agent just wing it doesn't work well. They teach the cloud agent responsible for fixing to spin up another batch of agents to validate the entire evaluation suite after changes, ensuring the solution is robust enough. This way, the PR that comes back to humans carries the credibility of "thoroughly validated."

Agent Experience (AX) is a concept proposed by analogy to Developer Experience (DX). DX focuses on how smooth it is for human developers to use tools, APIs, and documentation, while AX focuses on the quality of the agent's experience when calling tools, reading documentation, and executing tasks—including whether instructions are clear, whether error messages are understandable, and whether tool interfaces are model-friendly.

As agents become one of the primary "users" of software systems, AX is growing in importance: an interface that is human-friendly but full of ambiguous prompts and hidden state will cause agents to frequently make mistakes and waste large amounts of tokens and runtime. Optimizing AX means re-examining documentation structure, error code design, tool granularity, and even repository organization so that agents can complete tasks at lower cost. Cursor placing AX alongside or even above DX reflects a shift in product perspective: "agents are users too."

These patterns will extend beyond coding

The speaker likened these skills to background garbage collection or cleanup processes in an operating system. Although currently clearly applied to cloud coding scenarios, they believe these patterns will extend beyond coding—after all, the cloud development experience itself is not purely a coding problem; there are many variables involved, and only a minority are truly about coding.

If you'd also like your agents to "onboard" and get running, you can visit cursor.com/onboard to try it out.

One-line Summary

Cursor believes the bottleneck is no longer model intelligence, but how to engineer the release of agent autonomy.

Paragraph Summary

According to the Cursor engineering lead, the bottleneck for AI agents has shifted from model capability to engineering: whether humans are willing to hand tools, context, and bigger goals to models. Cursor replicated the human onboarding process for agents, building a cloud onboarding agent that explores the codebase, configures the environment, and generates a runnable demo, then used tools like AnyDev CLI to make the cloud development experience nearly as smooth as local. The team proposed three principles—give agents eyes, give agents tools, and trade high-quality input for high-quality output—and identified computer use as the next critical domain after coding. In addition, they introduced Agent Experience (AX), letting agents proactively report issues and fix them end-to-end through the WCF skill, backed by batch evaluation validation, ultimately pushing these patterns beyond coding.