An event-driven agent needs a retained trigger record

Cursor's August 19 release lets cloud agents subscribe to events, including pull-request activity, Slack messages and schedules. A task can wake when something happens, without a person manually starting another session. The release notes describe persistent goals and event subscriptions as part of that workflow.

The feature moves an important piece of evidence outside the agent's own conversation: the thing that woke it.

I would make the trigger record a procurement requirement. A readable agent transcript is useful, but it cannot by itself establish what an external message contained at the moment the agent acted.

The message can move after the action

As an illustration, imagine a Slack comment asks an agent to update a deployment checklist. The agent begins work, then someone edits the comment to narrow the request. The run completes against the original wording.

If I inspect only the current Slack message and the final output, the action may appear inconsistent with the request. If I inspect only the agent's explanation, I am relying on its account of the trigger. Neither view is a dependable substitute for the authorised event that actually entered the run.

I would want the review interface to connect the event identifier and relevant version to the resulting execution. It should also identify the permission configuration used for that execution and the external actions it performed. Those records explain different parts of the event; a single transcript should not be asked to stand in for all of them.

This is a design requirement I would test, not a claim that Cursor's release fails it. The announcement does not establish a complete retention, export or deletion contract. Those details require product documentation and a trial of the intended configuration.

Custody is different from collecting everything

The answer is not to copy every channel into permanent agent memory. A useful trigger record should retain the minimum authorised context needed to explain the action, under the organisation's access and retention rules. The reference back to the original system matters even where only a limited snapshot is appropriate.

There is a tradeoff to decide explicitly. Keeping less can reduce unnecessary data exposure, but it can also leave a later reviewer unable to reconstruct an instruction. Keeping more can aid reconstruction while creating a broader body of sensitive material. The owner of the workflow needs to choose and document that boundary.

I would test custody with an ordinary export exercise. Start a harmless run from a controlled event, change the source message afterwards, and export the records available to an authorised reviewer. Then ask someone who did not watch the run to explain why it started and which request it followed.

If that person must rely on the original operator's memory, the evidence path is incomplete. If the answer requires administrator access to unrelated conversations, the export may be collecting too much. Both findings are actionable before the agent handles consequential work.

Event-driven agents make the distinction particularly visible because the trigger can arrive when nobody is watching. A later review needs a stable connection between the outside event and the inside execution, even when the surrounding conversation has continued.

The purchase question is therefore concrete: can we retrieve an appropriately scoped record of what woke this run, under the permissions and retention policy we agreed? That is a better test than whether the interface has an attractive history panel.

An unattended run should carry a retrievable record of the event that authorised it to begin.