Opening four Cursor Agent windows does not automatically create a development team. It creates four parallel conversations. The difference becomes obvious when one Agent changes an interface, another tests the previous version, a third checks a startup path that no longer exists, and every window still reports “done.”
The coordination problem is not solved by giving each Agent a stronger persona. It is solved by separating responsibility and making the work products inspectable outside the chat.
The full operating guide is here: Running an AI Development Team in Cursor: From Requirement to Testable Delivery.
Start with an acceptance card, not a vague feature request
Before delegating, the PM role should turn the request into a compact contract containing:
- the user outcome;
- what is in and out of scope;
- acceptance criteria;
- required evidence; and
- known risk boundaries.
“Add CSV export” names a feature. “Export the current filtered failures, preserve Chinese text and special characters, pass the list regression suite, and avoid unrelated refactors” creates something another role can independently judge.
If an Agent cannot tell when to stop from the card, the task is not ready to assign.
Roles should own different decisions
For a cross-module feature, I have found this split more useful than sending the same prompt to several Agents:
PM — requirement, task boundaries, dependencies, acceptance and rework
DEV — implementation, targeted tests, diff and change report
OPS — install, build, startup, configuration and runtime evidence
QA — acceptance criteria and regression testing from the requirement
EVAL — independent quality and risk observation
Human — final release and risk decision
The important part is what each role must not substitute for. DEV should not accept its own completion claim. OPS should not redefine functional correctness. QA should not merely paraphrase DEV’s test report. EVAL should not silently mutate lifecycle state.
The same person or model may serve several roles in separate sessions, but the artifacts and decisions should remain distinct.
Keep evidence outside the conversation
Cursor gives Agents code search, file editing, terminal access, diff review and checkpoints. Those tools are useful, but the durable result should still be recoverable from the repository and project workspace.
A minimal DEV report might contain:
# REPORT: TASK-001
- Change: added exportFailuresCsv and a list-page action
- Target tests: pnpm test export-csv — 12 passed
- Regression: pnpm test failures-list — 28 passed
- Sample: artifacts/failures-special-chars.csv
- Not verified: Safari iOS download behavior
- Diff: 3 files, no unrelated refactor
The report is not proof by itself. It is an index into inspectable evidence: changed files, commands, outputs, artifacts and unresolved risks.
This matters during long-running work. If only the conversation remembers what was verified, a restart turns recovery into another round of guessing. A durable task and report can name the commit SHA, exact tests, preserved invariants and the next safe resume point.
QA should verify the requirement, not the worker’s story
Suppose DEV reports the CSV feature complete. QA should start from the acceptance card and independently test zero records, one record, large output, special characters, filtering, failure behavior and unrelated diff changes.
If Chinese text is still garbled in Excel, the correct next action is not “try again” in chat. The failed criterion, reproduction evidence and affected artifact should become a traceable rework task. That makes it possible to distinguish an implementation error from a specification omission.
A completion claim is not an accepted delivery
The workflow I want is:
requirement
→ role-owned tasks
→ implementation and runtime evidence
→ independent QA
→ acceptance or traceable rework
→ human release decision
Cursor supplies the development surfaces. A file-backed coordination layer such as FCoP can keep TASK, REPORT, ISSUE and REVIEW artifacts visible across sessions. CodeFlowMu-open shows one way to allocate PM, DEV, OPS, QA and EVAL responsibilities around those artifacts. The UI may index the state, but it should not become the only source of truth.
I would keep this proportional to risk. A one-file fix may need one Agent and a diff review. A cross-module change benefits from PM and QA separation. Deployment, security and data changes justify OPS evidence, independent evaluation and an explicit human gate.
The unresolved implementation question is recovery: when a long-running Cursor Agent restarts mid-handoff, what durable evidence does your workflow use to reconstruct the active owner, verified state and next authorized action without trusting the last chat message?
Other language: 中文版本