Building and Operating Agentic AI Coding Products at Scale with Temporal

cursor · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Cloud coding agents

Cursor needed cloud coding agents that could run independently, in parallel, and reliably enough for production coding work, while preserving agent progress across VM lifecycle events and workflow deploys.

Constraints:

Local agents compete for developer machine resources.
Dedicated cloud VMs are expensive to keep running while idle.
Agent workflows must survive failures without replaying expensive token histories.
Temporal workflow upgrades can introduce nondeterminism if histories no longer match.

Architecture

Cursor built Cloud Agents with dedicated cloud environments and Temporal Cloud workflows. A server creates agent records, starts Temporal workflows through queues and workers, provisions VMs as needed, runs agent-loop turns, supports follow-ups and background reviews through child workflows, stores production histories for CI replay, and uses Kubernetes/Temporal deployment tooling for worker upgrades.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  user[User] --> cursor-servers[Cursor Servers]
  cursor-servers --> temporal-cloud[Temporal Cloud]
  temporal-cloud --> workflow-workers[Workflow Workers]
  workflow-workers --> dedicated-vm[Dedicated VM]
  workflow-workers --> agent-loop[Agent Loop]
  agent-loop --> proof-artifacts[Proof Artifacts]
  proof-artifacts --> user[User]
  temporal-cloud --> workflow-history-ci[Workflow History CI]
  workflow-history-ci --> workflow-workers[Workflow Workers]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`User`	Starts cloud agents and reviews diffs, screenshots, videos, and logs.	`Cursor Servers`
`Cursor Servers`	Create agent database entries and start Temporal workflows.	`Temporal Cloud`, `Dedicated VM`, `User`
`Temporal Cloud`	Durable workflow engine for cloud-agent loops and follow-ups.	`Workflow Workers`, `Cursor Servers`
`Workflow Workers`	Pick up Temporal activities and execute agent workflow turns.	`Temporal Cloud`, `Dedicated VM`, `Agent Loop`
`Dedicated VM`	Per-agent coding environment with isolated resources.	`Workflow Workers`, `Proof Artifacts`
`Agent Loop`	Runs LLM coding actions, tests, and follow-up turns.	`Workflow Workers`, `Proof Artifacts`
`Proof Artifacts`	Screenshots, videos, and logs that show the agent's work.	`Agent Loop`, `User`
`Workflow History CI`	Replays production histories to catch Temporal nondeterminism before deploy.	`Temporal Cloud`, `Workflow Workers`

Data flow

A user starts a cloud agent, Cursor servers create a database entry and Temporal workflow, workers check or provision a dedicated VM, the agent loop runs to produce code plus proof artifacts, idle VMs are torn down, and future prompts resume by checking out the branch and continuing the workflow.

“when the user starts an agent, Cursor servers launch a dedicated coding environment just for that agent somewhere in the cloud. So this is bringing up a VM that only that agent um can access, and it can use the complete resources of that VM. Um and then the”transcript, stated

“then, of course, it talks to Temporal to kick off a new workflow for that agent. And we use Temporal Cloud. We think that's a great solution. It's really, you know, allowed us to bring this product up a lot faster than we could”transcript, stated

Why this architecture

Cursor moved agent loops to Temporal because the homegrown workflow system had roughly 90% success and was effectively a weaker Temporal. Dedicated VMs support parallel independent agents and proof artifacts, while Temporal makes expensive agent progress durable across failures and follow-ups.

“should. I mean, we basically built a bad version of Temporal, right? Temporal at home. Um, and I'm sure this is the experience a lot of people in this room has had.”transcript, stated

“using something like Temporal to give us that reliability without having to repeat the tokens to get to that point”transcript, stated

Models used: Cursor Cloud Agents · Temporal Cloud · BugBot

Scale

Cursor reports about 50 million Temporal actions per day.
“popular, we think. And this is about 50 million Temporal actions per day and growing over about 7 million plus unique workflows every day. Um our activity success rate is over 99%”transcript, stated
The system handles over 7 million unique workflows daily.
“over about 7 million plus unique workflows every day. Um our activity success rate is over 99% and getting better with time. Uh for contrast, back when we tried to build this ourselves, we had about a 90% uh”transcript, stated
Activity success is over 99%, compared with about 90% in the homegrown system.
“our activity success rate is over 99% and getting better with time. Uh for contrast, back when we tried to build this ourselves, we had about a 90%”transcript, stated
Cloud agents crossed one-third of Cursor's internal merged PRs.
“ago, we crossed uh 1/3 of our internal merged PRs come from cloud agents. And that's definitely growing uh growing uh every day. So, very quickly, I want to talk about other ways we use Temporal. It's not”transcript, stated

Alternatives considered (roads not taken)

Local agents on the developer's machine.

Rejected because: Cloud agents can run in parallel without competing for local resources or the same files.

“allow you to have as many agents as you want in parallel without them interfering with each other, competing for resources, or all fighting for the to edit the same file at the same time.”transcript, stated

Keep Cursor's homegrown orchestration.

Rejected because: Temporal added another reliability nine and replaced a weak in-house workflow system.

“Temporal, um we rewrote it to have Temporal, and that just added another 9 to our reliability just by making that switch. Um it also helped us break out of some bad software habits, which which I'll talk about later. So, you know, in”transcript, stated

Keep dedicated VMs running indefinitely.

Rejected because: Dedicated VMs are expensive, so Cursor tears them down and resumes with branch checkout.

“about here is that this dedicated VM is kind of expensive to keep running. So, we don't want to run it forever, but we do want to give the user the impression that their agent lives forever. So, um,”transcript, stated

Infinitely running workflows.

Rejected because: Version bouncing during deploys caused problematic workflow behavior.

“if we had an infinitely running workflow that basically never completed. And when it wasn't working, it would just wait there for follow-ups to be sent via signals, and then wake back up. Um this is kind of one of the promises of Temporal.”transcript, stated

Patterns

`durable-execution` (agent runtime)

Temporal workflows preserve agent progress and run agent loops through failures, follow-ups, and deploys.

“Temporal fits into this picture. Um, first is that it allows us to outsource the reliability of these agents”transcript, stated

`multi-agent-orchestration` (parallel coding)

Users can run many cloud agents in parallel, each with a dedicated environment.

“these are agents that you can run in parallel as many as you want and they run somewhere in the cloud”transcript, stated

`safety-policy-enforcement` (execution isolation)

Each agent gets a dedicated coding environment, avoiding interference with other agents or local work.

“each agent gets their own dedicated environment.”transcript, stated

`eval-driven-development` (workflow deploys)

Cursor saves production workflow histories and replays them in CI to catch nondeterminism.

“fetching and storing those histories, and then saving those to a lockdown S3 bucket”transcript, stated

`observability-tracing` (proof artifacts)

Agents produce screenshots, videos, and logs that prove changes worked.

“able to produce screenshots or videos or log files that prove to you that their”transcript, stated

Tradeoffs

Execution environment

Chose Dedicated cloud VMs over Local developer machine execution.

Rationale: Dedicated environments allow parallel agents and proof artifacts without resource interference.

“each agent gets their own dedicated environment.”transcript, stated

Workflow engine

Chose Temporal Cloud over Homegrown orchestration.

Rationale: Temporal improved reliability from roughly 90% to over 99% activity success.

“back when we tried to build this ourselves, we had about a 90% uh success rate with cloud agents.”transcript, stated

Workflow lifecycle

Chose Smaller turns and auto-upgrade over One infinitely running workflow.

Rationale: Smaller workflows were easier to reason about and safer during deploys.

“we broke up the workflow into smaller uh, smaller turns basically, what are called turns.”transcript, stated

Gotchas (what bit them)

Homegrown workflow orchestration hit reliability limits.

Root cause: The agent loop needed durable replay and failure handling that Cursor had partially rebuilt itself.

Resolution: Move cloud-agent orchestration to Temporal Cloud.

“we basically built a bad version of Temporal, right? Temporal at home.”transcript, stated

Dedicated VMs are expensive when idle.

Root cause: Cloud agents need full environments, but async work can wait on follow-ups or reviews.

Resolution: Tear down idle VMs and recreate them later by checking out the branch.

“we actually take down that dedicated VM. And if another respon- another prompt comes in from the user in the future”transcript, stated

Temporal workflow upgrades can fail via nondeterministic replay.

Root cause: New workflow code may not match old workflow history.

Resolution: Store production histories and replay them in CI before deploy.

“the history that it's trying to replay does not match the workflow history”transcript, stated

Infinitely running workflows bounced across versions.

Root cause: Long-lived workflows could move between old and new code during traffic and deploys.

Resolution: Break workflows into smaller turns with auto-upgrade behavior and Kubernetes deployment integration.

“workflows could bounce back and forth between versions of workflow, which is obviously really bad”transcript, stated

Evaluation

Cursor measures Temporal actions, workflow counts, activity success rate, internal merged PR share, and workflow-upgrade safety by replaying saved production histories in CI.

Metrics: Temporal actions per day · Unique workflows per day · Activity success rate · Cloud-agent merged PR share · Nondeterminism errors in CI

“our activity success rate is over 99% and getting better with time.”transcript, stated

“new workflow code doesn't hit any non-determinism errors and we can fail”transcript, stated

Outcomes

Cursor moved cloud-agent orchestration to Temporal.
The system reached over 99% activity success and about 50 million Temporal actions per day.
Cloud agents crossed one-third of Cursor's internal merged PRs.

The source reports about 50 million Temporal actions/day, more than 7 million workflows/day, over 99% activity success, and one-third of internal merged PRs from cloud agents.

“this is about 50 million Temporal actions per day and growing over about 7 million plus unique workflows every day.”transcript, stated

“we crossed uh 1/3 of our internal merged PRs come from cloud agents.”transcript, stated