Is Cursor Becoming the iOS for Agents?
On September 2, 2026, Cursor released Self-Hosted Machines. At first glance, this looks like an enterprise deployment feature: Cloud Agents can perform file edits, terminal commands, browser actions, local MCP calls, and other tool execution on machines managed by the enterprise itself. But the more important change may not be that Cursor has added another execution environment. It is that enterprise-owned machines are beginning to become execution resources that Cursor Agents can schedule and use.
Cursor is explicit about the architectural boundary. With My Machines and Self-Hosted Pools, the agent loop still runs in Cursor’s cloud, while file edits, terminal work, browser operations, and access to internal networks happen on enterprise-owned machines or workers. At the pool level, enterprises can also manage worker fleets, dedicated hardware, Kubernetes, autoscaling, and network environments. (cursor.com)
Taken alone, this can still be described as “cloud agent + enterprise execution machine.” But when we connect it with Cursor’s recent product evolution, a direction much larger than Self-Hosted Machines starts to emerge: Cursor is turning the agent from a one-off intelligence call into an execution entity that can persist, wait for external events, wake up again, retain a goal, and continue working over time.
That is why “AI IDE” increasingly feels too small a label for what Cursor is building. A more interesting question is:
Is Cursor moving toward becoming an iOS for agents?
Of course, “iOS” here is not meant literally. It refers to a platform position.
1. Why Cursor Is Starting to Look Like an iOS for Agents
The most important thing about iOS is not simply that an app can run on a certain chip. What iOS really created is a unified application runtime world: how apps get permissions, access devices, maintain lifecycle, use notifications, identity, networking, and hardware capabilities. Developers do not have to reinvent these foundations for every application.
In other words, iOS does not merely control one app. It defines how apps exist, how they obtain capabilities, and how they interact with people and devices.
Seen from that perspective, Cursor’s recent evolution is strikingly similar. Models are selectable. Agents can maintain long-running goals, be reawakened by events, load Skills, MCP servers, and tools. Cloud Agents have isolated execution environments, subagents can run in separate virtual machines, and enterprises can connect agents to their own automation and infrastructure through APIs, service accounts, and worker pools.
Cursor’s August 19 update is especially important. The company explicitly described a goal of having always-on agents “operate as a system.” Agents can subscribe to events such as PRs, Slack threads, and scheduled tasks, wake up when something changes, and keep a long-running /goal instead of disappearing after one prompt. PRs created by Cloud Agents can continue to be watched so that new CI results or automated feedback can trigger further work. (cursor.com)
The Cloud Agents API pushes this abstraction further by separating the agent from any single execution. Its newer v1 model uses durable agents + per-prompt runs: the agent persists, while each new piece of work becomes a run. (prod.cursor.com)
Put together, these capabilities make Cursor look less like “an AI that can code” and more like this:
Give work to the platform, and the platform keeps an agent alive, gives it intelligence, grants it tools, finds an execution environment, and brings it back when work needs to continue.
Cursor remains centered on software development, so “Software Agent Platform” or “an emerging iOS for software agents” is still the more careful description. Whether it expands into a general-purpose enterprise Agent OS remains uncertain.
But the direction is already important.
2. One of Cursor’s Most Important Advantages: Taking the Long Agent Lifecycle Seriously
This deserves explicit credit.
A great deal of agent development has focused on one-shot execution: how much better the model reasons, how many tool-use steps it can complete, or how much a benchmark improves. But real work is difficult for a different reason: work rarely ends in a single run.
A real software task may last for hours or days. It may wait for CI, a teammate’s response, code review, or an external system to change. Machines may sleep, networks may fail, humans may change the requirement halfway through, and an agent may need to understand several hours later why it stopped in the first place.
Cursor’s recent product design suggests that it is no longer satisfied with simply making agents run for more steps. It is treating waiting, recovery, reactivation, and long-running goals as normal parts of the agent lifecycle.
Subscriptions, scheduled tasks, persistent /goal, automatic PR follow-up, isolated VM subagents, durable agents, Self-Hosted workers, and pool routing are not individually impossible to reproduce. The value comes from turning them into a coherent product experience that ordinary developers can actually use. (cursor.com)
In software-development agents, I think Cursor is currently very far ahead on productization, and the product direction is unusually coherent.
That does not mean Google is ignoring long-lived agents. Quite the opposite: Google Cloud’s 2026 Agent Executor explicitly targets agents that can run for hours or even days, with durable execution, event logs, snapshots, resume, connection recovery, and distributed session consistency built into the runtime. Google’s thinking at the infrastructure layer is deep. (cloud.google.com)
The difference today feels more like this: Google is building powerful agent infrastructure, while Cursor has been faster at turning long-lifecycle behavior into something developers directly experience in the product.
That is one of the most important things to learn from Cursor. It is not only asking “What can an agent do?” It is seriously asking a harder question:
How does an agent keep working over time?
Figure 1: A persistent agent identity and goal span multiple runs. Based on the Cursor update and Cloud Agents API.
3. Self-Hosted Machines Changes More Than the “Cloud vs. Local” Question
Once we see the long-lifecycle direction, the significance of Self-Hosted Machines becomes clearer.
We are used to classifying agent products as either cloud or local. Cursor shows a third architecture: the enterprise can own the execution environment while the Agent Platform retains the control loop.
The code checkout can remain on enterprise machines. Internal build tools, package registries, secrets, and intranet services can stay behind the enterprise boundary. The enterprise can operate dedicated GPUs, high-memory machines, or Kubernetes worker fleets. Yet the agent loop itself still runs in Cursor’s cloud. (cursor.com)
So Self-Hosted Machines should not be understood as Cursor retreating from the cloud toward traditional private deployment.
In one sense, the opposite is true:
Cursor is showing that an Agent Platform does not need to own the enterprise’s machines in order to extend its control plane into the enterprise.
The machines belong to the enterprise. The network belongs to the enterprise. Much of the business software belongs to the enterprise. But decisions such as which agent receives the work, when that agent should continue, and what tool should be called next can still be organized by the Agent Platform.
That is a much more important distinction than “local or cloud.”
Figure 2: Self-hosted tool execution and the cloud-based agent loop. Source: Cursor runtime documentation.
4. An Agent iOS Does Not Need to Become Every SaaS Product
This is why I no longer think the most useful question is whether Cursor will become another enterprise SaaS company.
If it truly moves toward becoming an iOS for agents, becoming a CRM, ERP, email system, project-management suite, or finance product would actually undersell its strategic position. iOS does not need to become a bank, a map service, a ride-hailing app, an e-commerce marketplace, or a social network.
What an Agent Platform needs to control is how agents obtain and use the capabilities of those systems.
Long-lived agents, event triggers, schedules, MCP, service accounts, computer use, resource scheduling, identity, and permissions are not inherently coding-specific. As these capabilities become more general, an Agent Platform can sit above large parts of the existing software stack.
So the more interesting question is not:
“Will Cursor replace Salesforce?”
It is:
When a person needs to get work done, will they still need to enter Salesforce first?
Those are very different questions.
5. What May Change Is Not SaaS Itself, but the Habit of Humans Operating Software Directly
Email is the simplest example.
Traditionally, if I want to manage email, I open Gmail or Outlook, enter the inbox, find messages, read them, inspect prior conversations, judge importance, and then decide whether to reply, forward, or archive.
Now, if an agent has authorized access to email, I can simply state the work requirement: check whether there are important messages I need to handle today, summarize the important ones, and prepare replies where appropriate.
The agent can read mail, understand context, search history, and classify items. With further authorization, it can archive, label, forward, or send.
Email has not disappeared.
The mail server has not disappeared.
The Gmail web interface has not disappeared.
But something important has changed:
I may no longer need to enter that interface myself.
The same shift can happen across Calendar, CRM, ERP, GitHub, file systems, project-management platforms, and internal enterprise applications. The old pattern was “I need to open an application to do a task.” The emerging pattern may be “I need to complete a task; let the agent decide which applications to use.”
This is not merely SaaS replacement. It may represent a more fundamental shift in computing:
from application-centric computing toward task-centric computing.
In the old model, computers first present applications to humans. In the emerging model, agents may first receive work from humans and then organize applications behind the scenes.
Figure 3: Software continues to provide business capabilities while the first entry point may shift to agents. Based on sections 4–7.
6. GUI Will Not Disappear, but It May Stop Being the First Door to Work
This does not mean Windows, macOS, browsers, or software interfaces will vanish. GUI remains extremely valuable for exploration, visual design, reviewing complex outputs, exception handling, and high-impact decisions.
What may change is whether GUI must remain the required first interface for every piece of digital work.
A knowledge worker today may open email, Slack, browsers, CRM, ERP, Word, Excel, project-management tools, and many internal applications every day. Much of what we call “knowing how to use software” is really memorizing where a function is, which menu contains an action, which system owns a state, and where information must be copied next.
If an agent can understand the goal and then choose API, MCP, terminal, browser, or computer use by itself, much of that operational knowledge can move from the human to the agent.
Humans ask less often:
“Where is the button?”
and increasingly express:
“What result do I want?”
Computer use is particularly interesting here because enterprises have decades of software with no modern API, no MCP, and often no clean automation interface. Where APIs or MCP exist, agents can use them. Where they do not, browser or GUI interaction can become a fallback under appropriate authorization and safety controls.
That means old software does not need to be completely rebuilt as “AI-native” before agents can operate within the enterprise.
Windows and macOS may therefore gain a new role. They will not only be environments for humans to run software; they may also become execution environments through which agents use existing enterprise digital assets.
GUI may increasingly function as an Agent Compatibility Layer—an interface between agents and the entire legacy software world.
7. What the Agent iOS Is Really Competing For Is the First Entry Point to Work
Seen this way, the position that an Agent Platform can compete for is much larger than any single SaaS market.
Traditionally, when someone wants to complete digital work, they first open Windows, a browser, or a specific SaaS product and then find the right function. In the future, they may first tell an agent: “Check which customers need follow-up today,” “Finish this release,” “Find out why the project has not shipped,” or “Handle today’s procurement exceptions.”
Whether that requires email or CRM, shell or MCP, ERP or browser interaction may then be decided by the agent.
Traditional software will not disappear. ERP will still hold orders, CRM will still hold customer facts, GitHub will still hold code, and banking systems will still hold real accounts. Many systems of record may become even more important as agents operate more frequently on top of them.
What changes is that they may increasingly shift from “places humans work in every day” toward:
business capabilities and systems of record that agents can call.
So what an Agent iOS is really competing for is:
When a human wants to get work done, who do they go to first?
That is a much larger position than “the next SaaS category.”
8. But Inside an Enterprise, “Can Do” Is Far From Enough
At this point, Agent Platform and digital employee begin to diverge.
An agent that can write code is not automatically a software engineer. An agent that can read email is not automatically a sales assistant. An agent that can operate ERP is not automatically authorized to make procurement decisions.
Enterprises have never defined an employee solely by which tools they can use. Once a person joins an enterprise, they also need a role, responsibilities, reporting lines, work rules, permission boundaries, delivery standards, and exception-handling procedures.
Digital employees are no different.
So between the generic agent and the digital employee sits an important layer of enterprise semantics:
the job role.
Agent capability answers:
“Can it do this?”
The enterprise role answers:
“Why should this be done, how should it be done, and what counts as complete?”
As Agent OS infrastructure matures, the “can it do this?” layer may become increasingly standardized. What remains specific to each enterprise becomes concentrated in the second question.
9. Agent Platform Governance Is Not the Same as Enterprise Work Governance
This distinction should not be made by pretending Cursor lacks governance. If Cursor truly intends to become an Agent Platform, it will naturally continue to strengthen platform governance: what models an agent can use, which tools it can access, which networks it can reach, which service account initiated the run, which worker executed the task, and what platform events occurred.
Google is also building centralized governance and Agent Runtime capabilities in a similar direction. (cloud.google.com)
But the enterprise still has another kind of authority it cannot outsource:
the authority to define its own work.
A successful agent run does not necessarily mean an enterprise task is complete. A platform log proving that an action occurred does not necessarily prove that the action was authorized under company policy. A complete session history does not automatically become an official business record.
So I prefer to distinguish two layers:
Agent Platform Governance governs how agents run safely and reliably; Enterprise Work Governance governs why the enterprise allows the work to happen and what result ultimately counts as valid.
Every enterprise needs the second kind of governance authority, but that does not mean every company needs to buy another Governance SaaS product. A small team may solve the problem with Cursor, GitHub, existing approvals, and human review. A large enterprise may need more formal governance across multiple agents, departments, and business systems.
The implementation can vary. What cannot be lost is:
the enterprise’s final authority to interpret its own work.
That is work sovereignty.
Figure 4: The platform governs execution; the enterprise defines work and acceptance. Based on the distinction in sections 8–12.
10. Why a Digital Employee May Actually Be a Team
This leads to another interesting question.
We often imagine:
one agent = one employee.
But real jobs are not single-function roles.
A mature human employee simultaneously understands tasks, plans work, executes professionally, checks results, handles exceptions, reports progress, and decides when to escalate. These functions are hidden inside one human mind, so we do not usually separate them explicitly.
In an agent system, giving all of these responsibilities to one agent produces a familiar structure: it understands its own task, plans its own work, executes it, reviews it, and then announces that it is complete.
Technically this can work. But as the work becomes more consequential, this structure is not always desirable.
So the significance of multi-agent systems may not primarily be “more models.” It may instead be Multi-Role.
Different agents can represent different functions. A manager role can interpret goals and coordinate work. A professional worker role can execute. QA can perform independent checking. OPS can handle environment, runtime, and recovery. Where needed, a separate evaluation role can observe and assess the execution team.
All of those roles could use the same underlying model, or the same Agent Platform. What matters is that they have different responsibilities, contexts, permissions, and formal work relationships.
Conversely, running five models that merely talk to one another does not create an enterprise organization.
So one useful hypothesis is:
A digital employee does not have to be one all-purpose agent. It may be a minimal work team organized around distinct functions.
That is not because “multi-agent” sounds more advanced. It is because real jobs already contain multiple functions.
11. From Generic Agents to “Localized Digital Employees”
There is another important qualifier.
What enterprises ultimately need is not an abstract “digital employee,” but a localized digital employee.
“Localized” here does not simply mean that the model runs locally, nor does it imply fully offline deployment. Its deeper meaning is that the digital employee genuinely enters the environment and work system of a specific enterprise.
It uses that enterprise’s machines, files, and internal systems. It takes on roles defined by that enterprise. It follows that enterprise’s procedures and policies. It acts inside that enterprise’s permission boundaries. And it produces formal work facts that the enterprise itself can retain, inspect, and interpret.
The same generic agent entering two different companies should not become the same “employee,” because the two companies have different roles, policies, permission structures, work objects, and lines of responsibility.
So Agent Platforms provide generic capabilities, while localization answers:
How do those generic capabilities become “this company’s employee”?
That may become one of the defining questions once agents enter real enterprises.
12. This Leads to the “Localized Digital Employee Workstation” We Are Researching
The idea becomes easier to see if we reduce the scenario to an ordinary enterprise Windows PC.
Suppose Cursor eventually becomes a very mature Agent OS: it provides the model, harness, MCP, browser, computer use, agent lifecycle, and long-running execution. Windows continues to provide the physical machine, files, Office, browser, Git, enterprise applications, and decades of legacy software.
The enterprise still needs another layer: what job does this digital employee hold on that machine, what work is assigned today, which functional roles exist inside it, what enterprise rules it follows, which actions require authorization, who reviews the result, and where exceptions are escalated.
CodeFlowMu, which we are currently researching and developing, is an attempt to explore this class of problem.
One working interpretation is to treat it as a Localized Digital Employee Workstation. It is not another Windows, and it is not another Cursor. It is an attempt to take generic capabilities from Cursor, Codex, or other Agent Platforms and organize them into digital employees that work according to one enterprise’s own roles, rules, responsibilities, and tasks.
If this direction proves valid, a single enterprise machine can be understood as several layers: Windows provides the digital work environment; Cursor, Codex, and other Agent Platforms provide intelligence and execution capability; and the localized digital employee workstation organizes those capabilities into the enterprise’s own jobs and work teams.
It is important to be clear that “Localized Digital Employee Workstation” is still a product concept under research and development, not a market-validated industry category.
The central question we still need to test is:
Once agents become increasingly capable of using software, what else does an enterprise need before that capability becomes a real digital employee with a role, responsibilities, rules, collaboration relationships, and delivery obligations?
13. In CodeFlowMu, Multi-Agent Is Increasingly About Multi-Role
CodeFlowMu is a research project for a digital-employee runtime that is still under development. One idea that has become increasingly clear is that the important part of “Multi-Agent” is not how many models are running, but whether different work functions inside a digital employee can be represented explicitly.
For example, a development-oriented digital employee may use PM as the role that interprets ADMIN requirements, organizes tasks, and drives outcomes; DEV for professional software work; QA for independent verification; OPS for runtime, environment, and recovery; and, where needed, an independent EVAL role for observing and assessing the work of the execution team.
These roles can use different models, or they can all use the same model. What makes them different roles is not the model name but their responsibilities, permissions, contexts, and formal work relationships.
So when we say “one digital employee can be a team,” we do not mean squeezing multiple separate employees into one machine.
A better description is:
A digital employee can make explicit the planning, execution, checking, operational support, and evaluation functions that were previously hidden inside a human worker’s mind.
In this sense, Multi-Agent is fundamentally Multi-Role.
14. FCoP Studies How Those Roles Collaborate Formally
Alongside CodeFlowMu, we are also researching FCoP.
FCoP is not intended to define how Cursor schedules workers, how Codex reasons, or which model, harness, or UI an agent must use.
It focuses on more durable work facts: TASK, REPORT, ISSUE, REVIEW, relationships between work objects, authorization references, persistent idempotency, and how formal work continues to be identified and interpreted after concurrency, retries, or recovery.
These belong to the work itself, not to any particular Agent Platform.
Today the execution layer may use Cursor. Tomorrow it may use Codex. Different roles may even use completely different models. Execution may move from a Windows workstation to a cloud worker. But an enterprise TASK should not collapse back into a chat transcript simply because the Host changed. A REPORT should not disappear because the model changed. An authorization should not lose its basis because the runtime changed.
So the working division we are exploring is:
Agent Platforms provide general intelligence and execution capability; CodeFlowMu studies how to localize those capabilities into one enterprise’s own digital employees; FCoP studies how the roles inside those digital employees form formal, durable, and recoverable work relationships.
This remains a development and research direction, not an industry architecture we claim has already been proven.
Figure 5: PM, DEV, QA, OPS, independent EVAL, and the formal work facts studied by FCoP. Based on the research proposal in sections 10–14.
15. The More Successful Cursor Becomes, the More Important This Question Gets
From this perspective, Cursor becoming more capable does not make the localized digital employee problem disappear.
Quite the opposite.
If Cursor, Codex, and future Agent Platforms make models, harnesses, MCP, browser use, computer use, worker infrastructure, long-running agents, events, and schedules increasingly mature, enterprise digital-employee systems have less reason to rebuild all of that generic infrastructure themselves.
What remains becomes increasingly enterprise-specific:
What is the job? Which internal roles are needed? Which policies govern the task? Who has authorization? Who verifies the result? What counts as delivery? How should recovery happen after an exception?
A generic Agent Platform cannot define those things once for every enterprise because enterprises are inherently different.
So Cursor’s rapid progress actually helps separate two questions more clearly:
Cursor is increasingly answering: “How can an agent become better at working?”
The different question we are researching is:
“Once the agent is already very capable, how do we make it work according to one specific enterprise’s way of working?”
The second question does not exist because Cursor is insufficient.
It exists because Agent Platforms are becoming good enough that it can finally become a separate problem.
16. An iOS for Agents May Be Emerging, While Digital Employees Are Just Beginning
Seen in retrospect, the significance of Self-Hosted Machines is no longer simply that Cursor Cloud Agents can use enterprise-owned machines. Combined with long-running Goals, Subscriptions, durable agents, worker pools, MCP, and computer use, it starts to reveal a different computing model.
In the past, humans operated software. In the future, humans may increasingly assign work while agents organize software.
In the past, Windows, browsers, and SaaS interfaces were the main entry points to digital work. In the future, they may increasingly become execution environments, tools, and systems of record used by agents.
In the past, software organized human operating procedures. In the future, Agent Platforms may increasingly organize software around human work goals.
If that transition continues, Agent Platforms will not merely compete for a software category. They may compete to become the first entry point above all digital work.
Cursor deserves significant credit for how aggressively it is pushing in this direction. In particular, its productization of the long agent lifecycle is notable: it no longer treats the agent as a single model call, but as a software execution entity that can wait, be reawakened by events, preserve long-running goals, use different execution environments, and continue moving work forward. (cursor.com)
But once agents truly enter enterprises, the next question begins.
Enterprises will not ultimately need one universal, all-powerful agent. They will need development digital employees, sales digital employees, research digital employees, operations digital employees, and finance digital employees. They will hold different roles, follow different rules, and carry different responsibilities. A complex digital employee may itself contain multiple functional roles.
So the future software stack may gradually separate into three layers:
Software continues to provide real digital capabilities and business facts; Agent OS platforms organize and call those capabilities; enterprises then localize generic agent capabilities into digital employees that belong to their own roles, policies, and responsibilities.
Cursor is actively exploring the second layer.
We are only beginning to research how the third layer should work.
An iOS for agents may be emerging. Digital employees that truly belong to each enterprise are only beginning to clock in.