Cursor Just Shipped Multi-Repo Cloud Agent Environments. Here's What It Still Can't Do That My Cloudflare Stack Already Does.

On May 13, Cursor shipped multi-repo cloud agent environments. The same week, Cursor disclosed that 35% of its own internally merged pull requests are now created by autonomous agents.

What Cursor actually shipped on May 13

The headline feature is multi-repo cloud agent environments. Agents can now operate across multiple repositories inside a single configured environment, building on the multi-root workspaces Cursor shipped on April 24. The environment is reusable across sessions, which is the practical part – you stop reconfiguring the same dev box every time an agent kicks off.

The configuration surface is a Dockerfile. Build secrets are scoped to the build step and are not passed to the running agent, which closes the most common foot-gun in agent infra: an API key baked into a build accidentally ending up in an agent's working memory. Cursor can also auto-configure the Dockerfile by inspecting your repos for tools and dependencies, though that's in private beta and rolling out to Enterprise customers over the coming weeks.

Layer caching got the biggest performance bump. Cache-hit builds now run 70% faster because only the changed Dockerfile layers rebuild. For agents that spin up dozens of times a day across a team, that's the difference between waiting and working.

The operational surface is the part competitors keep underselling. Every environment has a version history with rollback. Rollback is admin-restricted. Every environment change writes to an audit log. Egress allowlists and secret scopes are per-environment, so a secret available to environment A is not reachable from environment B. This is the boring infrastructure you need before you let an agent open PRs against production code.

The proof point Cursor put in the announcement is Amplitude. Their Cursor Automations watch public Slack channels, investigate reported issues, figure out which repos are affected, and open PRs across the right repos. That's a multi-repo agent doing first-line triage at a real company at real scale. It is not a demo.

The 35% number is why this matters more than the SERP is saying

Cursor disclosed that 35% of its own internally merged pull requests now come from autonomous agents running in cloud sandboxes. Not 35% of PRs opened. 35% of PRs merged. That's the conversion rate that tells you the loop closes – review, fix, ship – without a human pushing every commit.

The top five results on this story all read it the same way: "managed cloud agents are the future, here's how to set them up." The Cursor changelog is 408 words of pure what. The DevOps.com piece is 1,820 words and the strongest in the SERP, but it stops at the DevOps framing and never compares Cursor to a durable platform. A Medium "quiet revolution" piece celebrates without taking a position. None of them frame the May 13 release as a platform choice against alternative runtimes.

The hidden frame in every "cloud agents are the future" post is managed-versus-DIY. That frame is wrong. The real choice is session-scoped versus durable. Cursor's environments are session-scoped – the disk and configuration persist, the agent's reasoning context does not. Durable runtimes flip that. Which one you want depends on whether your agents finish their work inside a single run, or pick it back up tomorrow.

What my Cloudflare Workers and Agents SDK stack already does

I run six production agents on Cloudflare. The runtime is Workers; state lives in Durable Objects with per-instance SQLite; long-running orchestration runs on Cloudflare Workflows. Solo build, single account, decoded in detail here. The full stack – Workers, DOs, D1, R2, Vectorize, AI gateway pass-through – runs $10 to $30 per month. Cursor Enterprise pricing for cloud agent environments isn't public, but per-environment isolation only pushes per-team cost in one direction.

Three things this stack does that Cursor's May 13 release does not.

Multi-repo, by default. Workers can fetch arbitrary source over HTTP at any time. The Browser Rendering API handles cross-site context pulls when an agent needs to read something that isn't in a git repo. The equivalent of Cursor's "multi-repo environment" is simple: fetch what you need, when you need it. Not better, not worse – different. You write the fetch logic; you don't configure an environment.

Durable cross-session state. A Durable Object holds an agent's reasoning context across days or weeks. The agent process resumes, not just the repo state. If yesterday's agent was halfway through a refactor and the Worker tier restarted, today's agent picks up the plan where it left off because the plan lives in the DO's SQLite, not in the runtime. Cursor environments persist disk and configuration; what dies with the session is the agent's working memory.

Idempotent step-level retry. This is the one most teams underestimate until it bites them. In Workflows, step.do(name, fn) caches each step's result. When a step fails mid-run, the workflow replays from the last cached output. Terminal failures throw NonRetryableError. Workflow IDs are unique per call, so a duplicate dispatch collides instead of double-executing. The difference is concrete: when a cloud build or agent action fails halfway through a side effect, you want the next attempt to skip the parts that already succeeded. Otherwise the agent opens two PRs, sends two emails, or charges the customer twice.

The two gaps Cursor still has not closed

Gap 1: durable cross-session state. Cursor environments persist the box. They don't persist the agent's reasoning. A Durable Object does. This matters most for agents that monitor something over time – incident response, long-running migrations, multi-day customer onboarding flows. The kind of work where "resume tomorrow" beats "start over."

I expect Cursor closes this within two quarters. The v0 already exists in the form of the durable environment artifact; extending that to agent state is a roadmap item, not a research problem.

Gap 2: idempotent retry semantics at the step level. When a Cursor cloud action fails mid-step, Cursor restarts the action. Workflows replay each step from its cached output. That's the difference between "agent ran twice" and "agent shipped two PRs."

This gap is harder to close. It requires platform-level workflow primitives that span the agent runtime, the build system, and external API calls, exposed as a developer surface. Cursor would need to ship workflow semantics as a first-class object – not as a feature buried inside an agent run. That's a multi-quarter project at best.

None of this is a knock on Cursor. It's a statement about category. Cursor is an IDE building a cloud agent runtime. Cloudflare is a platform that already has a durable cloud runtime and is adding agents on top. Both directions converge eventually. The durable side gets there first on the two gaps named above.

What founders and CTOs should do this week

Three profiles, three different moves.

If you're a sub-15-engineer team shipping product features, adopt Cursor cloud agents now. The May 13 environment release removes the last credible "but our build is hard to reproduce" objection. The 35% internal-PR throughput at Cursor is a public proof point you can cite in your own engineering planning doc. Don't overthink it.

If you're already on Cloudflare or Vercel running long-lived background processes, keep building on durable primitives. The agent stack on Workers plus Durable Objects plus Workflows ships features Cursor will not match in 2026. You won't lose by waiting. There's a consumer-side parallel worth reading for how Anthropic is packaging similar primitives for SMBs – the pattern of platform-converging-on-agents is showing up everywhere.

If you're running 50+ agents in an enterprise rollout, wait for Cursor's auto-Dockerfile feature to leave private beta, then test it in parallel against your existing infra before consolidating. The cost question gets real at that scale and per-environment isolation isn't free.

What I'm watching for in 30 days

Two signals.

First, whether Cursor announces persistent agent state – anything that lets reasoning context survive across sessions. If they ship that before July, the durable gap I described above narrows to one issue instead of two.

Second, whether Cursor publishes the 35% number again with a higher figure, or stops talking about it. The first means the loop tightened; the second means it didn't. Either signal is informative.

Does Cursor's May 13 release deprecate the need for self-hosted agent infrastructure?

No. It raises the floor on managed cloud agent environments but doesn't solve durable cross-session state or idempotent retry, which is why self-hosted durable stacks still own long-running agent work.

How fast are Cursor's cached cloud agent builds now?

Cache-hit builds run 70% faster after the May 13 layer caching upgrade. Only the changed Dockerfile layers rebuild on a cache hit.

What does the 35% internal-PR number actually mean?

Cursor reports that 35% of its own merged pull requests are now created by autonomous agents running in cloud sandboxes. It's the strongest single proof point that cloud agent environments have crossed into production use, not because of the percentage itself but because it's measuring merges, not opens.

Are Cursor cloud agents safe for code that touches production secrets?

The May 13 release scopes egress and secrets per environment and isolates build secrets from the running agent. That's the right primitive set. Whether it's safe in your shop depends on your audit and rollback requirements – both of which Cursor now exposes via per-environment version history and audit logs.

Can I run Cloudflare Workers and Cursor cloud agents side by side?

Yes, and that's the most likely setup for teams already on Workers. Cursor handles PR throughput on the codebase; Workers and the Agents SDK handle durable background work. The two surfaces don't overlap.