- A speaker from Cursor explains how, with models this good, the bottleneck is no longer model intelligence but the tools, context, and ambitious tasks humans give agents — so Cursor's job is to set agents free safely.
- Cursor went through three stages: giving agents the tools and context to be autonomous, learning to take advantage of more capable models, and then "building the system that builds the system."
- They built a Claude onboarding agent (cursor.com/onboard), a dev CLI, and computer use so agents can see and run apps, derived principles of autonomy, and created self-improving loops where agents report and fix their own development-experience issues.
Giving coding agents their own computers: How Cursor built cloud agents
- The bottleneck shifted from model intelligence to humans giving models tools, context, and ambitious objectives; Cursor's framing is to set agents free safely to take on bigger tasks.
- They mirrored human onboarding for agents: a Claude onboarding agent explores a codebase not to change it but to figure out how to run it, handling environment variables and permissions interactively with the developer.
- An "any dev" CLI tool let cloud agents start services, wait for and check statuses, and create test accounts, creating a positive feedback loop where better dev environments led to more agent usage.
- Principles of autonomy: give agents "eyes" (everything you can see, they must see, including other agents' chats for debugging), give them tools to run apps and services under reasonable security constraints, and keep a high-quality codebase because agents are auto-regressive.
- Computer use (raw pixels in, mouse and keyboard out) is the next key domain after coding; the hard part is not clicking precisely but the metacognition and backtracking needed because GUIs are like a video game with one-way doors and game-over states.
- Claude 4.7 is Cursor's computer use model; agents record end-to-end demo videos of features they build, giving developers a high-bandwidth way to review work before reading code, which is invaluable when running many agents at once.
- "Security through freedom": running agents in the cloud frees developers from resource management, context switching, and worry about agents touching environment variables, and surprisingly makes programming more enjoyable.
- Cursor's most important skill is "Work on the Factory" (WCF): every cloud agent reports anything annoying, broken, or confusing; reports accumulate in a system of record, are triaged into technical, permission, and ignorance issues, and are fixed by agents and humans with decreasing human involvement over time.
Cloud agent — A coding agent that runs in the cloud with its own computer and dev environment rather than on a developer's local machine.
Onboarding agent — A Claude agent that explores a codebase to learn how to run it, set up env vars, and demo the app.
Computer use — An agent capability of taking raw pixels in and producing mouse and keyboard actions to operate GUIs.
Auto-regressive — A property of agents where output quality depends heavily on input quality, so a high-quality codebase yields high-quality results.
Security through freedom — The idea that setting agents free in the cloud also frees developers from resource management and environment-safety worries.
Work on the Factory (WCF) — Cursor's core skill instructing every agent to report annoying, broken, or confusing things so tools and workflows improve.
System of record — The store where agent-reported issues accumulate to be triaged, deduped, and fixed.
Agent experience — The agent-facing equivalent of developer experience, which Cursor argues deserves equal or more care.
Hello. So, models are getting really good. And for more and more work, the bottleneck is no longer the model intelligence. The bottleneck is humans giving the models the tools and the context and the increasingly ambitious tasks and objectives to go flex their potential. So at Cursor, we've been working on removing that bottleneck, and I'm going to share a bit about how we've been doing that, and hopefully it's helpful to some of you in your work.
With models this good, we kind of see the job that we have as setting our agents free safely, and having them go off and work on bigger tasks. So we've gone through three stages of the process. The first was giving our agents the tools and the context to be more autonomous. The second is we had to learn how to take advantage of these more capable models. There's actually a lot of work in figuring out how to update your patterns and behaviors. And as you do that, as you're leveraging more agents and getting more work done, you start to see the places where there's stress and strains and where the agents fall over, and you work to improve that. And that brings you to the third stage, which is building the system that builds the system. So instead of spending your day hand-holding agents from task A to D, you take that time to build the system that can solve for A to Z.
So we started thinking about how to make our agents more capable, how to make them work more like we do. We started with looking at what we do with humans to onboard people to Cursor. When a developer joins Cursor, they get a computer. We help them set up their dev environment. We have a ton of documentation, maybe too much, about how to do all the different things that developers need to do in their daily work. So we give them all this context and all this material, and crucially their computer. If you think about what we were doing with the models, the onboarding process was you throw them into a code base, and from the model's perspective, you have thousands of lines of code whizzing by, you don't know what you're doing, you just have some task you have to go solve. And it's kind of incredible that this works as well as it does. If I had to work this way, just site-reading code and I couldn't test the application, I would also probably frustrate and annoy the humans who did have to do the testing for me.
So we decided to build an onboarding agent. We built a Claude onboarding agent. Anybody can go to cursor.com/onboard. You can set up your repo, and the Claude onboarding agent gets to work and starts exploring your code base not to make a change but to figure out how to run it. It's exploring, it's looking around, and depending on how fast this one's playing, you'll see it can start using the app and it'll come back with a demo. And it's not just looking to figure out what to run, what the services are, but there are these complex things it needs to do like figure out the different environment variables, what permissions it needs. So it's this interactive process with the developer to make sure the services are running properly.
Once we have the agents onboarded, we realized there's still quite a bit of work to do because you have all these developers running many Claude agents every day. So any problems are multiplied out across all those runs. Every time the agents run, they have to start their dev environment from scratch. When you're doing local dev, you probably leave things running. Not true for the cloud agents. So we wanted to optimize their dev X. They were spending a lot of time sleeping, waiting for things to start up. They didn't have good ways of waiting for things, so we built an "any dev" CLI tool. They were able to start services, wait for the services to start, check on statuses. They had a Swiss Army knife for things like creating test accounts and signing in for third-party services. So what we saw was as we made the dev environments better, more developers started running more cloud agents and getting more out of it. There's a positive feedback loop that starts to take place. And then of course, we also had to give them all the documentation that we give our human developers. We made simplified versions so they could lean on the materials when they find themselves in edge cases or hard problems.
In doing this process, we derived these basic principles of autonomy. The first is you have to give your agents eyes. Everything that you can see, the agents need to be able to see too. A basic version of this is if the agent's running an app, you should be able to see that app. If you go make changes and use that app yourself and change something in the state, the agent needs to be able to see what you changed. Another interesting one is the agent chats — where you wind up needing to debug what happened in a chat, and you want the agent to be able to see the other agent's chat just like you do. The next thing is giving the agents tools so they can do all the things you can do, with reasonable security constraints. They should be able to run the applications you can run and use the services you can run. Agents are auto-regressive, so it is also very important that you have a high-quality codebase and instructions and everything else so that you get high quality out.
The foundational primitive we believe for human autonomy is computer use. The first domain where agents have really excelled has been coding, and we think computer use is the next really important domain. This is raw pixels in, mouse and keyboard out. And the Claude family of models are really good at this. The hard part is not clicking in the right place. The hard part, better explained, is that if coding is like chess where you can see all the pieces on the board, navigating these GUIs is more like a video game where you can only see a little slice at a time. There are one-way doors. There are game-over states you can get into. So you need this higher-level metacognition and backtracking and the general intelligence skills that the Claude family's really good at. Claude 4.7 is our computer use model.
Here's an example. It was told to go off and build this private marketplace feature. So it goes off and records this demo where it's implemented all the little pieces. We have this URL input and there's CSVs it needs to add. And what's great is that it's not just using that to do its own end-to-end testing to make sure the changes it made work. You as the developer get to have a really high-bandwidth method of reviewing the work of the agent before you get into code. And this becomes really valuable when you are running many of these agents simultaneously in the cloud and bouncing between them.
So once you have these autonomous agents onboarded, you need to learn to give them more work and bigger challenges to tackle. Two basic modes. The first is you have a lot of tasks and bugs and issues and you have to learn when to just stop putting those in your notes or your to-do tracker and just kick off prompts. Put them right into a prompt box and kick them off. When you do, you then have a bunch more of these agents running, and again it's great to have those demos come back instead of having to review lots of code. The second pattern is much bigger projects where you can give a cloud agent much larger units of work and have it work for much longer.
One of the things we were surprised by — we kind of knew that if we made the agents more powerful, developers would do more exciting things, but we were surprised by the extent to which this was true. And one of the really important things was the security that the cloud provided for developers. There's this idea of security through freedom, which sounds like Orwellian propaganda, but in the same way that you're setting your agents free to take things on in the cloud on their own, you also set yourself free as a developer, where you don't have to worry as much about resource management and context switching. You don't have to worry about the agents going and doing things they really should not with your environment variables. And there's a way in which we were all surprised by how much more enjoyable this made programming.
A really important skill we are still learning is, when the agents fail, it's really worth it to take time out to figure out what went wrong, debug it, and implement a fix that's going to be multiplied out across your whole team and company. Failure modes, if they persist, make the agents continually compound failure across the entire company, and people don't want to use the agents as much. But the inverse is also true — when you invest in them and make them work better, everybody wants to use them more. People are building trust with the agents, finding they can one-shot bigger and bigger tasks, and then they want to invest more. So this is a really important change in how you think about your work, where you're kind of programming the system.
So you've onboarded your agents. We gave them the tools to make them powerful. We started learning how to leverage them and scale them up, and we were seeing where they fell over. We started working on this loop of how you teach them to work better. And we realized that it does start to feel like coding again. So of course, we thought, well, the agents should do this. We've got a few ways that we're trying to have the agents do this. The most important one, the one I'm going to talk about today, is agents iteratively improving their own workflows. We call this the agent experience. There's the developer experience, and you have the agent experience, and you need to care just as much if not more about the agent experience.
The way our system works is agents go about their business, and they are told to report issues as they come up. It's really just like what we do for humans, where if you see something wrong, say something, report it, and try to work on a fix. All those reports are accumulated in a system of record, very similar to how human systems work. Managers will go in and review all the issues, categorize them, dedupe them, and bucket them. There are technical problems that can be addressed. There are issues of permission, where the agents just don't have access to something. There are issues of ignorance, where the agents don't still know what to do and need humans to tell them the right way to solve the problem. Then in the last step, these are fixed by both agents and humans, and the goal is over time to have less and less human involvement, so the issues the agents solve are solved end-to-end. We don't really need to review. We can have really high trust in their work, and they have all the context they need.
So I'm going to go through a couple examples. This is our most important skill. It's the WCF skill, which of course stands for Work on the Factory. Every cloud agent gets this skill, and it's almost the exact same prompt I was just showing. Work on the Factory is the idea that when something is annoying, broken, or confusing, you take a moment to report it, so we can improve the tools and workflows rather than just grinding through. Models a while ago would not have been doing a very good job of this, but today they get annoyed, and they find things broken, and they get confused, and they realize that and report it. So we get this system of record where they report all these issues.
Of course, you then have to solve the issues, and this is its own really important challenge if you want this whole system to be self-improving. We were finding with these agent development experience problems, having the agent just go solve them and try to one-shot was not that effective because there's a lot of flake in those problems. Something only happens once in a while. So we taught it to actually have the cloud agent that goes and solves it kick off a bunch more cloud agents with the change in the development experience, and make sure that across that eval set there's a robust solution. So then when the PR comes back to the human's review, there's a high degree of trust that this is a well-validated solution.
I think these are both really good examples of how these skills can work as background garbage collection processes or cleanup processes in the operating system. And we think that while these are clearly applied for the coding domain, in the same way we speed run a lot of AI development in coding, these patterns are going to generalize well outside of coding to other domains. And even if you think about it already, cloud development experience is not really a coding problem. There are a lot of variables in that, and very few of them really are just coding issues.
Okay, so now the thank you slide. If you'd like to talk more about self-improving identity systems, please talk to me. You can find me on X at my name. And if you'd like to set your agents free, you can go to cursor.com/onboard and have Claude onboard to your codebase and maybe ship your next ambitious feature. So, thank you very much.
TL;DR
- A speaker from Cursor explains how, with models this good, the bottleneck is no longer model intelligence but the tools, context, and ambitious tasks humans give agents — so Cursor's job is to set agents free safely.
- Cursor went through three stages: giving agents the tools and context to be autonomous, learning to take advantage of more capable models, and then "building the system that builds the system."
- They built a Claude onboarding agent (cursor.com/onboard), a dev CLI, and computer use so agents can see and run apps, derived principles of autonomy, and created self-improving loops where agents report and fix their own development-experience issues.
Takeaways
- The bottleneck shifted from model intelligence to humans giving models tools, context, and ambitious objectives; Cursor's framing is to set agents free safely to take on bigger tasks.
- They mirrored human onboarding for agents: a Claude onboarding agent explores a codebase not to change it but to figure out how to run it, handling environment variables and permissions interactively with the developer.
- An "any dev" CLI tool let cloud agents start services, wait for and check statuses, and create test accounts, creating a positive feedback loop where better dev environments led to more agent usage.
- Principles of autonomy: give agents "eyes" (everything you can see, they must see, including other agents' chats for debugging), give them tools to run apps and services under reasonable security constraints, and keep a high-quality codebase because agents are auto-regressive.
- Computer use (raw pixels in, mouse and keyboard out) is the next key domain after coding; the hard part is not clicking precisely but the metacognition and backtracking needed because GUIs are like a video game with one-way doors and game-over states.
- Claude 4.7 is Cursor's computer use model; agents record end-to-end demo videos of features they build, giving developers a high-bandwidth way to review work before reading code, which is invaluable when running many agents at once.
- "Security through freedom": running agents in the cloud frees developers from resource management, context switching, and worry about agents touching environment variables, and surprisingly makes programming more enjoyable.
- Cursor's most important skill is "Work on the Factory" (WCF): every cloud agent reports anything annoying, broken, or confusing; reports accumulate in a system of record, are triaged into technical, permission, and ignorance issues, and are fixed by agents and humans with decreasing human involvement over time.
Vocabulary
Cloud agent — A coding agent that runs in the cloud with its own computer and dev environment rather than on a developer's local machine.
Onboarding agent — A Claude agent that explores a codebase to learn how to run it, set up env vars, and demo the app.
Computer use — An agent capability of taking raw pixels in and producing mouse and keyboard actions to operate GUIs.
Auto-regressive — A property of agents where output quality depends heavily on input quality, so a high-quality codebase yields high-quality results.
Security through freedom — The idea that setting agents free in the cloud also frees developers from resource management and environment-safety worries.
Work on the Factory (WCF) — Cursor's core skill instructing every agent to report annoying, broken, or confusing things so tools and workflows improve.
System of record — The store where agent-reported issues accumulate to be triaged, deduped, and fixed.
Agent experience — The agent-facing equivalent of developer experience, which Cursor argues deserves equal or more care.
Transcript
Hello. So, models are getting really good. And for more and more work, the bottleneck is no longer the model intelligence. The bottleneck is humans giving the models the tools and the context and the increasingly ambitious tasks and objectives to go flex their potential. So at Cursor, we've been working on removing that bottleneck, and I'm going to share a bit about how we've been doing that, and hopefully it's helpful to some of you in your work.
With models this good, we kind of see the job that we have as setting our agents free safely, and having them go off and work on bigger tasks. So we've gone through three stages of the process. The first was giving our agents the tools and the context to be more autonomous. The second is we had to learn how to take advantage of these more capable models. There's actually a lot of work in figuring out how to update your patterns and behaviors. And as you do that, as you're leveraging more agents and getting more work done, you start to see the places where there's stress and strains and where the agents fall over, and you work to improve that. And that brings you to the third stage, which is building the system that builds the system. So instead of spending your day hand-holding agents from task A to D, you take that time to build the system that can solve for A to Z.
So we started thinking about how to make our agents more capable, how to make them work more like we do. We started with looking at what we do with humans to onboard people to Cursor. When a developer joins Cursor, they get a computer. We help them set up their dev environment. We have a ton of documentation, maybe too much, about how to do all the different things that developers need to do in their daily work. So we give them all this context and all this material, and crucially their computer. If you think about what we were doing with the models, the onboarding process was you throw them into a code base, and from the model's perspective, you have thousands of lines of code whizzing by, you don't know what you're doing, you just have some task you have to go solve. And it's kind of incredible that this works as well as it does. If I had to work this way, just site-reading code and I couldn't test the application, I would also probably frustrate and annoy the humans who did have to do the testing for me.
So we decided to build an onboarding agent. We built a Claude onboarding agent. Anybody can go to cursor.com/onboard. You can set up your repo, and the Claude onboarding agent gets to work and starts exploring your code base not to make a change but to figure out how to run it. It's exploring, it's looking around, and depending on how fast this one's playing, you'll see it can start using the app and it'll come back with a demo. And it's not just looking to figure out what to run, what the services are, but there are these complex things it needs to do like figure out the different environment variables, what permissions it needs. So it's this interactive process with the developer to make sure the services are running properly.
Once we have the agents onboarded, we realized there's still quite a bit of work to do because you have all these developers running many Claude agents every day. So any problems are multiplied out across all those runs. Every time the agents run, they have to start their dev environment from scratch. When you're doing local dev, you probably leave things running. Not true for the cloud agents. So we wanted to optimize their dev X. They were spending a lot of time sleeping, waiting for things to start up. They didn't have good ways of waiting for things, so we built an "any dev" CLI tool. They were able to start services, wait for the services to start, check on statuses. They had a Swiss Army knife for things like creating test accounts and signing in for third-party services. So what we saw was as we made the dev environments better, more developers started running more cloud agents and getting more out of it. There's a positive feedback loop that starts to take place. And then of course, we also had to give them all the documentation that we give our human developers. We made simplified versions so they could lean on the materials when they find themselves in edge cases or hard problems.
In doing this process, we derived these basic principles of autonomy. The first is you have to give your agents eyes. Everything that you can see, the agents need to be able to see too. A basic version of this is if the agent's running an app, you should be able to see that app. If you go make changes and use that app yourself and change something in the state, the agent needs to be able to see what you changed. Another interesting one is the agent chats — where you wind up needing to debug what happened in a chat, and you want the agent to be able to see the other agent's chat just like you do. The next thing is giving the agents tools so they can do all the things you can do, with reasonable security constraints. They should be able to run the applications you can run and use the services you can run. Agents are auto-regressive, so it is also very important that you have a high-quality codebase and instructions and everything else so that you get high quality out.
The foundational primitive we believe for human autonomy is computer use. The first domain where agents have really excelled has been coding, and we think computer use is the next really important domain. This is raw pixels in, mouse and keyboard out. And the Claude family of models are really good at this. The hard part is not clicking in the right place. The hard part, better explained, is that if coding is like chess where you can see all the pieces on the board, navigating these GUIs is more like a video game where you can only see a little slice at a time. There are one-way doors. There are game-over states you can get into. So you need this higher-level metacognition and backtracking and the general intelligence skills that the Claude family's really good at. Claude 4.7 is our computer use model.
Here's an example. It was told to go off and build this private marketplace feature. So it goes off and records this demo where it's implemented all the little pieces. We have this URL input and there's CSVs it needs to add. And what's great is that it's not just using that to do its own end-to-end testing to make sure the changes it made work. You as the developer get to have a really high-bandwidth method of reviewing the work of the agent before you get into code. And this becomes really valuable when you are running many of these agents simultaneously in the cloud and bouncing between them.
So once you have these autonomous agents onboarded, you need to learn to give them more work and bigger challenges to tackle. Two basic modes. The first is you have a lot of tasks and bugs and issues and you have to learn when to just stop putting those in your notes or your to-do tracker and just kick off prompts. Put them right into a prompt box and kick them off. When you do, you then have a bunch more of these agents running, and again it's great to have those demos come back instead of having to review lots of code. The second pattern is much bigger projects where you can give a cloud agent much larger units of work and have it work for much longer.
One of the things we were surprised by — we kind of knew that if we made the agents more powerful, developers would do more exciting things, but we were surprised by the extent to which this was true. And one of the really important things was the security that the cloud provided for developers. There's this idea of security through freedom, which sounds like Orwellian propaganda, but in the same way that you're setting your agents free to take things on in the cloud on their own, you also set yourself free as a developer, where you don't have to worry as much about resource management and context switching. You don't have to worry about the agents going and doing things they really should not with your environment variables. And there's a way in which we were all surprised by how much more enjoyable this made programming.
A really important skill we are still learning is, when the agents fail, it's really worth it to take time out to figure out what went wrong, debug it, and implement a fix that's going to be multiplied out across your whole team and company. Failure modes, if they persist, make the agents continually compound failure across the entire company, and people don't want to use the agents as much. But the inverse is also true — when you invest in them and make them work better, everybody wants to use them more. People are building trust with the agents, finding they can one-shot bigger and bigger tasks, and then they want to invest more. So this is a really important change in how you think about your work, where you're kind of programming the system.
So you've onboarded your agents. We gave them the tools to make them powerful. We started learning how to leverage them and scale them up, and we were seeing where they fell over. We started working on this loop of how you teach them to work better. And we realized that it does start to feel like coding again. So of course, we thought, well, the agents should do this. We've got a few ways that we're trying to have the agents do this. The most important one, the one I'm going to talk about today, is agents iteratively improving their own workflows. We call this the agent experience. There's the developer experience, and you have the agent experience, and you need to care just as much if not more about the agent experience.
The way our system works is agents go about their business, and they are told to report issues as they come up. It's really just like what we do for humans, where if you see something wrong, say something, report it, and try to work on a fix. All those reports are accumulated in a system of record, very similar to how human systems work. Managers will go in and review all the issues, categorize them, dedupe them, and bucket them. There are technical problems that can be addressed. There are issues of permission, where the agents just don't have access to something. There are issues of ignorance, where the agents don't still know what to do and need humans to tell them the right way to solve the problem. Then in the last step, these are fixed by both agents and humans, and the goal is over time to have less and less human involvement, so the issues the agents solve are solved end-to-end. We don't really need to review. We can have really high trust in their work, and they have all the context they need.
So I'm going to go through a couple examples. This is our most important skill. It's the WCF skill, which of course stands for Work on the Factory. Every cloud agent gets this skill, and it's almost the exact same prompt I was just showing. Work on the Factory is the idea that when something is annoying, broken, or confusing, you take a moment to report it, so we can improve the tools and workflows rather than just grinding through. Models a while ago would not have been doing a very good job of this, but today they get annoyed, and they find things broken, and they get confused, and they realize that and report it. So we get this system of record where they report all these issues.
Of course, you then have to solve the issues, and this is its own really important challenge if you want this whole system to be self-improving. We were finding with these agent development experience problems, having the agent just go solve them and try to one-shot was not that effective because there's a lot of flake in those problems. Something only happens once in a while. So we taught it to actually have the cloud agent that goes and solves it kick off a bunch more cloud agents with the change in the development experience, and make sure that across that eval set there's a robust solution. So then when the PR comes back to the human's review, there's a high degree of trust that this is a well-validated solution.
I think these are both really good examples of how these skills can work as background garbage collection processes or cleanup processes in the operating system. And we think that while these are clearly applied for the coding domain, in the same way we speed run a lot of AI development in coding, these patterns are going to generalize well outside of coding to other domains. And even if you think about it already, cloud development experience is not really a coding problem. There are a lot of variables in that, and very few of them really are just coding issues.
Okay, so now the thank you slide. If you'd like to talk more about self-improving identity systems, please talk to me. You can find me on X at my name. And if you'd like to set your agents free, you can go to cursor.com/onboard and have Claude onboard to your codebase and maybe ship your next ambitious feature. So, thank you very much.