The most interesting thing Cursor’s cofounder said about cloud agents wasn’t about speed or scale. It was about silence. When you run an agent locally, it hits an error and surfaces that error to a human, who decides what to do next. The feedback loop is intact. But cloud agents don’t have that. They run unattended, and when something goes wrong, there’s no one in the room to hear it. That’s not a minor implementation detail. That’s the whole problem with deploying AI in production at scale, and Cursor is now the company most visibly wrestling with it.
This is the same tension I keep coming back to in this reading log. The gap between AI that works in a demo and AI that works in a production system is almost entirely a question of what happens when things break. Local models, local agents, human-in-the-loop workflows: these are all partial answers to the same question. The real test is whether you can build infrastructure around a model that fails unpredictably, in a context where no one is watching. Cursor’s cloud agent architecture is one of the first serious attempts to answer that at the product level, not just the research level.
Cursor’s forward deployed engineering work makes this concrete. Pauline Brunet, who leads that team, describes a shift happening in how customers actually use the product. Local agents through the desktop application are largely self-service; people have adopted them fast and the experience is familiar enough that it doesn’t require much hand-holding. Cloud agents are different. Customers are excited about them because of what they promise, but deploying them inside real enterprise workflows, real systems, real codebases, requires the kind of on-site integration work that Cursor is now building a team to do. Brunet’s team is growing tenfold by the end of the year. That’s not a support function. That’s a signal about where the hard work actually lives.
The cofounder Sualeh Asif put the core issue plainly in his conversation about cloud agents: “agents in the cloud don’t have a way to ‘complain.’” That sentence contains a lot. It means the error-handling model you use for local AI doesn’t transfer. It means the mental model of AI as a tool you supervise doesn’t scale to a world where agents run overnight, or in parallel, or across systems you don’t control directly. It means the infrastructure problem is not just compute; it’s observability, error propagation, and the design of workflows that can tolerate model failures without a human in the loop to catch them.
This is why the forward deployed engineering model matters. Brunet’s description of what her team actually does, going on-site, working inside customer systems, deploying applications configured around specific workflows, is a description of the real integration work that never shows up in a benchmark. The customers using Cursor span financial services, telecommunications, semiconductor companies: industries where the cost of an unattended agent silently failing is not an annoyance but a production incident. The FDE team exists because those customers can’t just drop Cursor into their environment and walk away. Someone has to understand both the AI system and the customer’s existing infrastructure well enough to wire them together correctly.
What Cursor is building here, whether they frame it this way or not, is a model for enterprise AI deployment that takes the silence problem seriously. Most AI tooling at this stage either ignores the failure mode entirely or punts it back to the user. Cursor is instead building a team of engineers, all with five or more years of experience shipping production code, to sit inside customer environments and make the thing work. That’s expensive. It’s also the only approach that actually addresses what Brunet describes as the goal: “an AI software factory across their operations,” covering the entire software development lifecycle from planning through deployment and maintenance.
The cloud versus local split is worth dwelling on because it maps onto a deeper question about where AI value actually concentrates. Local agents are fast, private, and controllable; they’re also limited by what a developer can see and manage in real time. Cloud agents can run longer, handle more parallelism, and operate across systems that aren’t open on your laptop. But the tradeoff is exactly the one Asif named. You lose the complaint mechanism. You lose the human in the loop. Whether that’s acceptable depends entirely on how good the surrounding infrastructure is, and right now that infrastructure is mostly being built from scratch, deal by deal, customer by customer, by teams like the one Brunet is scaling.
OpenAI and Anthropic are both pushing in similar directions with their own agent products, but neither has made the forward deployed model this explicit. Cursor’s bet is that the code editor is the right layer to own, because every software team already lives there, and because the path from coding assistant to AI software factory runs through the same workflows engineers use every day. The cloud agent infrastructure is how that path extends into the parts of the organization that aren’t watching the screen.
The silence problem doesn’t get solved by making better models; it gets solved by building systems that know what to do when the model doesn’t know what to do.