Most of the agent workflows this site has covered so far share one property: something asks the agent to do something, the agent does it, and a person checks the result before the next thing happens. That loop is the basis of PDAID's Build and Test & Correct phases, and it's why the site's agentic coding piece puts so much weight on defining "done" before the work starts.
Cursor's announcement of a feature called Projects describes something with a different shape. According to Cursor's changelog, a Project runs a "coordinator agent" that doesn't write code itself but plans work, delegates it to other agents, and brings finished work back for a human to check. Cursor says the coordinator can be told to "watch a Slack channel, run on a schedule, or follow all your PRs," and that it then "takes action based on signals it detects, without waiting for your prompt." Cursor also describes a Project as maintaining "a set of files that sync across every cloud and local machine its agents use," accumulating research, learned facts about the codebase and preferences about how work should be done, over months and across what Cursor describes as potentially thousands of subagents.
Everything in that paragraph is Cursor's own description of a feature it is rolling out in beta. None of it is something this site has tested or verified. But the shape of the workflow raises real questions for anyone applying PDAID discipline, independent of whether this particular product works as described.
The trigger moves outside the conversation
In a normal session, a person opens the request, and that request is the natural place to put Purpose, Behaviour, Clarifications, Context and Constraints. When a coordinator instead reacts to a Slack message, a scheduled time, or a PR appearing, there is no equivalent moment where a person sits down and states what should happen and why.
That doesn't mean the PDAID phases stop applying — it means they have to be written down in advance, attached to the trigger rather than to a conversation. If a coordinator is subscribed to "every bug report in this channel," the Behaviour and Constraints for how it should respond to a bug report need to already exist somewhere the coordinator reads them, because nobody will be typing them in at the moment it fires. Without that, the coordinator is left inferring what a reasonable response looks like each time, which is exactly the kind of unsupervised decision-making the decisions article argues should not be left to the model.
A backlog of autonomous changes needs its own review cadence
A single-session agent produces one thing to check. A coordinator that fires on schedule or on every PR can produce a queue of finished work arriving at whatever pace the triggers set, not the pace a reviewer chooses. If it runs unattended for weeks, "check the result before moving on" — the basic discipline behind Commit & Maintain — turns into a backlog, and backlogs get skimmed rather than checked.
The practical implication is that unattended triggers need a review cadence decided in advance, not left to whenever someone gets to it. That might mean capping how much work the coordinator can queue before it stops and waits, or it might mean every autonomously-triggered change is held at a fixed checkpoint until reviewed, rather than being layered on top of the last unreviewed one. Either way, the number of changes waiting for review is now a thing to watch, in the same way the site's baseline article argues you need to know which point in history is actually known to work.
Cursor describes the coordinator as bringing finished work back "for you to check" — but a description of the intended handoff isn't evidence about what happens when several days' worth of autonomously-triggered work arrives at once. That's a genuinely open question for anyone using a tool like this, not something the vendor's description settles.
Shared context that grows for months is also a place drift can hide
The site's context-management article makes the case for writing down what a project needs so it survives between sessions. Cursor's description of Project files goes further: the shared context accumulates automatically, with agents adding "research and artifacts" and "what they learn about the codebase and how you prefer work to be done," synced across every machine involved.
That's useful in exactly the way the earlier context article describes — nobody has to re-explain the project every time. But a file that many agents write to over months, without a human curating it, is also a plausible place for an early wrong inference to get treated as established fact and quietly relied on by every agent afterwards. Nothing in Cursor's description says how — or whether — a human reviews what's been added to that shared context, or how to tell a hard-won fact from a plausible-sounding guess one agent recorded and the next one trusted. Until that's known, treating the shared context file itself as something to periodically audit — the same way you'd audit any other accepted Context in PDAID's Context & Constraints phase — seems like the safer default than assuming it self-corrects.
Three more ways the boundary moves
Projects moves the trigger away from a fresh prompt. Cursor's changelog now describes three other mechanisms that move different boundaries: when an agent wakes up, who decides whether a tool call may proceed, and what an unattended agent can carry from one run to the next.
/loop makes the stopping condition part of the specification
Cursor says its /loop skill can repeat a prompt on a local schedule, continue until a specified outcome is reached, or run until you stop it. If you do not give a fixed interval, Cursor says the agent can decide when or what event should wake it. One example in the changelog is asking it to work on a feature until the tests pass.
That makes the stopping condition part of the work you need to define. "Tests pass" may be a useful mechanical stop, but it does not tell you whether those tests cover the behaviour you actually care about. Before starting a loop, decide the accepted behaviour, the boundaries the agent must not cross and what evidence you will check at the end. The loop can decide when to wake; it should not get to decide what counts as acceptable.
Auto-review moves some approval decisions to a classifier
Cursor describes Auto-review as a run mode for Shell, MCP and Fetch tool calls. Allowlisted calls run immediately, calls that can be sandboxed run in the sandbox, and other agent actions go to a classifier subagent that can allow the call, try a different approach or ask for your approval. Cursor also says you can steer that classifier with custom instructions.
That is a permission-control mechanism, not a verification mechanism. A classifier can decide that a tool call is allowed without establishing that the resulting software satisfies the behaviour you agreed. Fewer approval prompts therefore make the end-of-run checkpoint more important, not less: inspect the resulting change, run the agreed checks and compare the result with the behaviour and constraints set before the run.
Automations widen the trigger surface and add memory between runs
Cursor's Automations can run on schedules or on events from Slack, Linear, GitHub, PagerDuty and webhooks. Cursor says each invocation starts a cloud sandbox and follows the configured instructions using the MCPs and models you have selected. It also describes a memory tool that lets automations learn from past runs and improve with repetition.
A later changelog entry adds more Slack and GitHub triggers, including an emoji reaction on a Slack message, issue and pull-request events, review-thread changes and completed GitHub Actions runs. It also says cloud agents started by automations can use their own computers to produce demos or artefacts, and that memory files can be deleted in the UI or by prompting the automation to delete outdated memories when it runs.
The practical difference is that unattended work can now start because something happened in another system, and later runs can be influenced by information retained from earlier ones. That gives you two additional things to review explicitly: the trigger rules that decide when work begins, and the memory that can shape later runs. A demo or artefact is evidence that the agent produced something; it is not evidence that the result matches the behaviour you agreed.
What this doesn't change
None of this is an argument against unattended, signal-triggered or classifier-mediated agents. It is an argument that removing the human from the moment of triggering or from individual approval prompts does not remove the decisions a human still has to make: what counts as done, what must not change, and whether a piece of work is safe to keep. Those decisions have to move earlier, into the trigger rules, stopping conditions, standing constraints and review checkpoints.
If you're evaluating a tool like this, the questions worth asking before turning it on are the same ones PDAID asks before any increment: what is this allowed to do, what evidence will show that it did the right thing, what evidence would show that it did the wrong thing, and how much work are you prepared to let accumulate before a person checks it.