An automation that asks an AI for every next action keeps rebuilding the same sequence. In Northstar I separated the loop executing a stored procedure from situations that need a fresh decision. This article follows the actual code that decides which iteration counts as verified and when the next one must stop.
Separate the established procedure from current material
When a task changes its inputs and target but keeps the same kind of procedure, the sequence need not be invented again. A stored Recipe carries the step meanings and expected results, while this request supplies parameters. The runner checks the definition, code hash and selected files before using the established path. The reusable unit is a verifiable execution definition, not an old model answer.
That distinction also identifies where fresh judgment belongs. A changed site, missing target or different task needs investigation. During a normal iteration, however, the next action should not require another invention by the model. I left the repetition responsibility in code.
What repeatProgram actually checks
RepeatOptions validates integer bounds for the repetition count and interval. Each iteration awaits run and requires its returned verified flag. An unverified result raises PROGRAM_ITERATION_NOT_VERIFIED before another iteration is called. The interval applies between iterations, not before the first one.
Verified iterations contribute their steps, evidence counts and outputs with an iteration number. Reported model calls are aggregated as execution data. A missing field cannot be interpreted as proof that the surrounding conversation had no cost. Internal model use on a normal stored path differs from the external agent work needed to select or revise that program.
A new iteration cannot choose an arbitrary target
Each iteration remains subject to host checks for the bound project, profile and definition. ProgramRunner creates an execution ID and connection credentials and compares keys and input fingerprints within the same run. That distinguishes a duplicate call inside a run from an intended new iteration. Another arrival of the same call is not a reason to dispatch the mutation again.
For a multi-tab procedure, roles and the original destination must remain in the definition. Using whatever tab a person now sees would make later iterations touch unrelated material. Performing the requested count and preserving the task's scope have to be verified together.
Leaving a loop does not establish operational success
A Python process returning exit code zero is still unverified if no execution result exists. ProgramRunner combines the SDK result with materialized outputs, host completion and journal records. A failed output save can leave a needs-review state rather than success. A computational loop and an operationally completed task cannot be reduced to the same return statement.
Failure in a later iteration also does not erase earlier external effects. The runner's recorded iteration and step state must be inspected to determine what was verified. I do not claim that repeatProgram's return value automatically preserves every failure history. The loop and the durable run record have separate responsibilities that need an explicit connection.
An intentional repeat is different from a retry
Repetition performs the several iterations requested by the person. Retry policy decides how to deal with a failure or an uncertain outcome. An unverified publication must not be sent again under the name of a new iteration. Unknown results and stops should prevent the next iteration until the original run is reconciled.
The shared local-wait module deliberately has no start operation. That does not make repetition itself undesirable. It separates an executor responsible for starting a justified new iteration from a reader responsible only for following an existing one. Even a long workflow should make the locations capable of creating a new submission easy to identify.
Keep the evidence within its actual scope
I compared the current repeat and runner code with the notebook workflow records. I did not perform another live batch publication in the original browser. This loop explanation is therefore not a success-rate claim for every site or a zero-cost claim for all AI use. It explains the structure in which a normal repeat does not ask a model to decide each click.
For another company's repeated work, I would first record iteration inputs, success criteria, stop conditions and completion evidence. The person can simply request a count, but the implementation must know what changes per iteration and what remains bound. Those criteria help the next agent find grounds for reusing an existing program.