Define a stopping rule before giving an agent a loop

Write an observable definition of done

Thanks to Omnisend for sponsoring this video.

The recording distinguishes prompts, goals and loops, using a thermostat analogy. An instruction to keep trying needs a check that can actually establish success.

1. Choose a small task and write the expected output.
2. Specify how the agent can test that output.
3. Define what to do if the needed access or input is missing.
4. Set a budget or iteration limit alongside the completion condition.

Match the mechanism to the task

The July examples use /go with until conditions and /loop for repeated work. These are commands shown in the recording, not a claim that every current client supports the same interface.

1. Inspect the recorded goal examples, such as a checked game or generated sequence.
2. Distinguish a task that finishes once from a timed check of changing state.
3. Read the current client’s own instructions before using an exact command.
4. Start with a small read-only or reversible experiment.

Review repeated actions and cost

The video also discusses PR watching and branch pruning. A repeated trigger should not silently acquire permission to make consequential changes.

1. Keep external actions and deletion behind their required review boundary.
2. Inspect the first result before enabling repetition.
3. Make failures, unresolved conditions and token use visible.
4. Stop or revise a loop that cannot establish progress instead of letting repeated attempts stand in for evidence.

The takeaway

A loop is useful when its inputs, limits and success check are clear. This guide does not create a schedule or grant permission for unattended repository changes.