Cursor puts its coding agents in the browser, and that changes the workflow

Cursor has launched a web app for managing its background coding agents, extending them beyond the IDE and Slack into a browser control plane. You can assign a task in natural language, watch the agent work, inspect the diff, and merge the result into your repo without opening the desktop editor.

That changes where AI coding work happens.

Cursor is moving the agent out of the editor sidebar and into the broader engineering workflow. The IDE still matters, but it no longer has to be the place where work starts, gets reviewed, or gets approved. For teams already using Cursor, that removes an obvious point of friction. If an agent can fix a bug or wire up a feature in the background, there's no reason the whole loop should depend on somebody sitting in a local editor session.

What shipped

The new web app gives Cursor users a browser interface for its background agents, which first arrived in May and later got a Slack interface in June. From the browser, teams can:

• hand an agent a task in plain English
• track progress live
• share links to running agent jobs
• review generated changes
• merge the result through a built-in pull request flow

Cursor says customers wanted the product in more places. That fits how engineering work actually shows up inside companies. A bug report lands in Slack. A Jira ticket gets triaged on the web. Support files a request. Someone spots a production issue from their phone while away from a laptop.

If the agent can start from any of those places, the desktop app stops holding up the workflow.

Why the browser matters

For years, AI coding tools have mostly lived in the editor sidebar. Useful, sometimes very good, but still framed as something that sits next to the developer while the human drives every step.

Cursor is leaning into a different model. The agent works asynchronously, with enough context and permission to modify a codebase, run checks, and open a PR on its own. Putting that in a browser makes it easier to treat the agent like a managed system instead of a fancy autocomplete box.

That matters at the team level.

A browser hub is easier to share and easier to approve from. Tech leads can inspect diffs on a phone. Staff engineers can queue work without spinning up a local environment. Managers and TPMs can at least see what's happening without installing an IDE plugin they'll barely touch.

It also shifts the conversation. Once agents are doing real repo work in the background, the questions are about job state, logs, permissions, failure rates, and merge controls.

The interesting part is the orchestration

The browser UI is the visible piece. The harder part is the system behind it.

Cursor's setup, as described, looks like a fairly standard agent pipeline, just executed well if the product holds up:

1. A natural-language task comes in.
2. The platform parses intent and provisions an isolated agent environment.
3. The agent generates code changes against the repo context.
4. It runs tests and validation in a sandbox.
5. It submits the output as a pull request for review and merge.

That flow sounds simple until you start listing the failure points.

The agent needs repository context, conversation history, file state, and test feedback. Cursor says that context carries across Slack, browser, and IDE, presumably through a centralized store that keeps task history and code snapshots available wherever the user picks things back up. That's important. Losing context between interfaces is one of the fastest ways to make agent workflows feel unreliable.

Provisioning matters too. Cursor describes containerized agents with auto-scaling and near-instant startup. If that holds up in practice, it's a real product advantage. Nobody wants to wait 90 seconds for an agent to spin up just to fix a unit test or clean up a helper. Fast cold starts make asynchronous work feel usable.

Then there's validation. Cursor says agents run tests like npm test or pytest, scan for syntax and security issues, and check style compliance before handing work back. That's baseline if you want enterprises to trust this. An agent that writes code but can't get through a basic CI path is still a demo.

Trust is the hard part

This launch matters because Cursor seems to understand where the friction has moved.

The problem for many teams isn't whether a model can write code. Often it can, at least for bounded tasks. The problem is trust and control. Can the system preserve context across tools? Can it run safely against private code? Can it show its work clearly enough that a reviewer isn't stuck untangling a messy patch?

That's why the merge workflow matters. Same for shareable links and live progress.

These aren't flashy features. They answer the questions teams ask once AI use moves past casual experimentation and into real engineering workflow. If agents are going to handle bug fixes, refactors, and feature scaffolding, you need observability and review mechanics. Otherwise you've got a black box with repo access, and security teams are right to hate that.

Cursor says agent containers use least-privilege file mounts and ephemeral credentials, with OAuth2 for repo access. Good start. Enterprise buyers will still want answers to a few obvious questions:

• Can this run inside a private network or VPC?
• How are secrets handled during test runs?
• What gets retained in memory, logs, or vector storage?
• What audit trail exists for every generated change and merge action?

A browser front end doesn't create those problems, but it does expand the number of places where people can trigger sensitive actions. Governance matters more as access gets easier.

Cursor is selling workflow

The business context helps explain why Anysphere moved quickly here. Cursor says it's at over $500 million in ARR and used by half of the Fortune 500, including Nvidia, Uber, and Adobe. At that scale, enterprise demand drives the roadmap.

Enterprises usually don't want isolated AI tricks. They want systems that fit existing process.

The web app fits that. Slack support fits that. Pull request integration fits that. The pattern is obvious: put the agent where work already starts.

GitHub Copilot, Tabnine, and Cognition's Devin point to a broader split in the market. One group focuses on assistance inside the coding surface. Another is trying to own the full software task loop: intake, execution, validation, review, merge. Cursor is moving deeper into the second group.

That's the harder product to build.

A decent autocomplete model can look good in a benchmark clip. A background agent that reliably changes real repos, survives test suites, and produces reviewable PRs faces a much tougher test.

What teams should watch

If you're evaluating this seriously, the useful question is whether your current workflow is ready for it.

Review quality

If the agent opens a PR, can your reviewers evaluate AI-generated changes quickly? That requires clear commit structure, solid test evidence, and enough traceability to explain why the agent touched what it touched.

Cost control

Cursor's background agents on the Pro tier cost $200 per month plus usage fees. That can get expensive fast if teams start treating agents like unlimited labor. Usage limits, repo scopes, and task templates will matter.

Failure modes

Agent systems fail in familiar ways: partial refactors, stale context, overconfident fixes, and tests that pass locally while missing the real bug. The browser UI may hide some of that behind a clean job panel. It doesn't solve reliability by itself.

Security posture

Least-privilege credentials and sandboxed containers are good baseline controls. They're not a substitute for standard code review, SAST/DAST, and branch protection. If anything, agent-driven workflows make those controls more important.

Where this is going

There's a clear reason these products keep moving beyond the editor. The IDE is where code gets polished. It isn't always where software work starts, and it doesn't need to be where every routine task gets supervised.

Cursor's web app reflects that shift pretty plainly. The company wants its coding agents to act like queued workers attached to the engineering process. For teams already comfortable with AI-generated PRs, that will probably be useful.

The usual catch still applies. This only works if the agent produces changes that are easy to trust. If review stays lightweight and failures stay manageable, a browser hub is a real upgrade. If not, it's a cleaner dashboard for flaky automation.

That's the standard now. Reliability.

What to watch

The caveat is that agent-style workflows still depend on permission design, evaluation, fallback paths, and human review. A demo can look autonomous while the production version still needs tight boundaries, logging, and clear ownership when the system gets something wrong.