Cursor is the most-deployed agent IDE in current use. It writes code, runs
tests, observes failures, and iterates. The surface looks like MAPE-K. The
question is whether it actually closes the loop, or whether the loop is open
in a way that matters.

## What Cursor does

- A user prompt becomes a multi-step agent run.
- The agent edits files, runs the project's test suite, reads the output, and
  iterates.
- The agent can use tools: `read_file`, `edit_file`, `terminal`, `web_search`.
- The user sees a diff and either accepts or rejects.

## Four practical questions

| Condition | Pass? | Notes |
|---|---|---|
| 1. Closed loop | partial | Cursor observes the test result, but the observation is in-process and not recorded anywhere durable. The "loop" is the agent's scratch state, not a Ledger. |
| 2. Declarative target | yes | The target is the diff. `git diff` after the agent run shows the full intent. The transcript is also available, but the diff is the source of truth. |
| 3. Unattended in the ordinary case | no | Cursor requires a human at every turn. The "yolo mode" (auto-accept) shifts the human to the end, not out of the loop. |
| 4. Ground truth | partial | The agent runs the user's tests, but the user wrote the tests. The eval is whatever the user said it was. There is no separate Verdict plane; the Proposer (the agent) calls the tests and reads the result in the same process. |

## Where the workflow still needs help

**Condition 3 is the loudest failure.** The whole point of an agent IDE is
that the human types a prompt and the IDE does the work. But the human is still
in the loop, approving each change. The system is not unattended in the
ordinary case; it is attended in *every* case.

**Condition 4 is the more interesting failure.** The "ground truth" is the
test suite, but the test suite is not a separate authority. The agent that
proposes the change also runs the eval and reads the result. There is no plane
separation. A change that "passes" the tests passed because the agent's
proposal and the test runner are in the same process. The trust boundary
lives in the user's trust, not in the architecture.

A subtler version of the same problem: Cursor's iteration is bounded by what
fits in the context window and by the user's patience. The "verdict" is the
agent's decision to stop iterating, which is the same agent that decided to
keep iterating. KILL — the case that was passing and now fails — is not a
verdict the agent emits. It is a fact the user discovers when they look at
the diff.

## What would make the workflow stronger

To satisfy condition 3, Cursor would need an unattended mode with a named
exception class. The exception would be "tests do not exist" or "the user is
in the file" or something specific. The current "yolo mode" does not have a
named exception class; it has a duration limit.

To satisfy condition 4, Cursor would need to separate the Proposer from the
Verifier. A change would land in a scratch workspace, an independent Scorer
would run a held-out corpus against the change, and a PromotionToken would
gate the merge. The current architecture has no such plane; the Proposer is
also the Verifier.

## See also

- [closure-test](/reference/closure-test) — the rubric
- [autonomic-software-engineering](/reference/autonomic-software-engineering) — the practice