From a turn to a loop
The lifecycle plugins in cursor/plugins answer a harder question than “what should the agent do?” They answer “what should happen after an event, and what state proves that it is safe to continue?” This chapter follows a recurring task from trigger to persisted state, follow-up, delegation, verification, and stop. The goal is to recognize a bounded agent loop rather than confuse repeated activity with progress.
A single turn is easy to understand. The user asks for work, the agent responds, and the host ends the turn. A loop changes the ownership model. A hook may continue the task after the visible response. A worker may return evidence later. A reviewer may be required before completion. Once that happens, the plugin needs a record of where it is, a rule for what happens next, and a condition that ends the process.
The loop begins with an event
Ralph Loop shows the smallest useful lifecycle. Its response hook looks for a completion promise in the agent’s output. Its stop hook runs when the turn ends. If the configured promise has not been fulfilled and the iteration limit has not been reached, the hook feeds the original prompt back as a follow-up. The same request returns to the agent, but the working tree and conversation now contain the previous attempt.
The trigger and the work are separate. The response hook does not solve the task. It records whether the agent’s output contains the configured completion signal. The stop hook does not decide whether the implementation is correct. It decides whether the loop should receive another turn under the configured state. This separation is what lets the loop stop for a meaningful reason instead of continuing whenever a response happens to arrive.
Continual Learning uses a more selective trigger. A completed turn increments a counter, but the hook also checks elapsed time and whether the transcript has advanced since the previous run. Trial mode can use shorter thresholds for a limited window. A duplicate generation is ignored. Only when the conditions align does the hook emit a follow-up asking for the memory update. The event is necessary, but it is not sufficient.
Advisor uses several event types because “unfinished work” can be observed in different ways. A file edit marks that changes exist since the last consultation. A completed advisor subagent call records the consultation and clears the pending marker. A stop event can emit a nudge when edits remain unreviewed. If the agent ended its turn by asking the user a question, the nudge stays quiet. The lifecycle therefore includes a judgment about when a reminder would help and when it would interrupt a necessary pause.
The general pattern is:
- An event arrives.
- The hook checks whether the event qualifies.
- The hook reads persisted state.
- The hook updates state and may emit a follow-up.
- The next turn or delegated task produces evidence.
- The workflow verifies, completes, or returns to the loop.
The order matters.