What Cursor is, in its own words
Cursor describes itself as “your coding agent for building ambitious software.” Its agents “turn ideas into code”, they “work autonomously, run in parallel” on their own machines to build, test and demo features end to end for your review, and they show up “in every tool, at every step” — the terminal, Slack, and reviewing pull requests on GitHub. It also advertises always-on agents “triggered by schedules or events” and “fleets” of agents working in parallel for hours or days. The site claims Cursor is “Trusted by over half of the Fortune 500.” (Source: cursor.com .)
We are stating that fully because the out-of-date version of this comparison — “Cursor is an editor, it can’t run scheduled autonomous work” — is simply false today. Cursor schedules agents, runs them in parallel, and reviews PRs.
The real difference is what a “team” means, and what you are left holding when the run ends.
The difference in one table
| Cursor | Forge | |
|---|---|---|
| What an agent is | A coding agent, working your codebase | A named role with a job description — PM, architect, developer, tester, reviewer, researcher, writer |
| Parallelism means | Many agents on many tasks, each finishing its own | One task moving through roles, each handoff judged before the next role sees it |
| Who checks the work | You, at review time — plus Cursor’s own PR review | A management agent on every handoff: pass, send back with enrichment instructions, or escalate to a person |
| Primary artifact | A pull request | A run branch — spec, brief and each role’s handoff as commits, Co-authored-by the persona — and then a pull request |
| A rejected step | Re-prompt the agent | A new commit; the earlier attempt stays in history and git diff shows what changed |
| Scope | Software | Software delivery (most mature), plus research, content and operations on the same engine |
| Where it runs | Cursor’s product and infrastructure | Managed SaaS, or self-hosted runners on your own hardware |
| Inference | Cursor’s model selection | Your provider pool with priority weights and automatic failover, including self-hosted models |
Where Forge is different
Different roles, not more copies of one role. A Forge delivery run is five roles: a product manager who surfaces ambiguity instead of inventing an answer, an architect, a developer, a tester and a reviewer. Between each pair sits a management agent that reads the handoff and decides whether it is good enough to pass on. Weak work does not travel down the chain to quietly become someone else’s problem. See Multi-Agent Pipeline .
The reasoning is committed, not just the result. Every run gets a branch — forge/workflow/{workflowId}/run/{runId} — holding the spec, the original brief, and each persona’s structured and freeform handoff as its own commit. You can read the argument behind a decision, diff a second attempt against the first, or intervene mid-run by committing a corrected handoff yourself. See Git-Backed Audit
.
It is not a coding tool. The same engine, the same validation loop and the same audit trail run a research team that verifies its own sources, a content team, or an ops rotation. Software delivery is where it is most mature — because it is how Forge is built — but it is one archetype. See Workflow Engine and the use cases .
Your hardware and your keys. Self-hosted runners keep execution on your machines, and the routing gateway sends inference to a provider pool you control, with priority weights and automatic failover. See Bring Your Own Hardware and Multi-Provider Routing .
The one number a single agent cannot report
An editor can report how often you accepted a suggestion. It cannot report how often the work was sent back, because in an editor the reviewer is you and nobody is counting. Here is what happens when the reviewer is part of the system.
| Twelve weeks of Forge building Forge | |
|---|---|
| Runs dispatched | 322 |
| Handoffs judged by a management agent | 1216 |
| Sent back to their author for rework | 56 |
| Escalated to a human | 24 |
| Runs where the supervisor stopped at least one handoff | 51 |
| Runs that completed | 215 |
| Runs that failed, escalated or were cancelled | 103 |
| Median wall-clock, dispatch to finished run | 39 minutes |
| Median handoffs per completed run | 5 |
| Pull requests merged, across 7 repositories | 202 |
Where these came from. One workflow — Main Forge SDLC, the one that builds Forge — every run it made in twelve consecutive weeks, counted from the control plane’s own records. Not a sample, not a pilot, not a customer case study we cannot show you.
Forge stopped its own work 80 times. 56 handoffs went back to their author with specific rework instructions; 24 went to a person. One run in six was interrupted by its own supervisor before any human looked at it. That is precisely the review a single-agent tool leaves on your desk — here it is priced at one model call per edge, and counted.
It merged 202 pull requests across 7 repositories in the same period — roughly 17 a week, into the platform you are reading about, with a human performing every merge. Organisation-wide, agent-authored work merged at 773 of 875 opened. Forge is not a demo running beside the product; it is how the product gets built, and these are its commits.
A finished run takes about 39 minutes and 5 handoffs. Median dispatch-to-done — and inside those 39 minutes sit the reviews that stopped 80 pieces of work from reaching the next role in the state they were first written in.
80 of these were work that looked finished to the agent that wrote it. That is the review you are performing by hand every time you accept a diff — and the only difference is that here somebody wrote down what happened.
Ask us to walk you through the runs themselves — the branch, the handoff commits, the verdicts that sent work back, and the ones that went to a person. Every other number on this site belongs to a named run and says so: 18 sources gathered, 11 verified by direct retrieval, 4 corroborated and 2 shipped marked unverifiable, on the research use-case page .
Sources
- cursor.com — hero copy, autonomous and scheduled agents, customer claims.
- Forge claims on this page link to the corresponding feature pages , which describe the mechanism in detail.