External state

A loop that runs on a schedule has a problem a chat session does not: nothing survives between runs. The model starts each time knowing nothing about the last. Whatever must persist has to be written down somewhere outside the conversation.

That external store is the spine of the whole system, and deciding what belongs in it is most of the design work.

• What has already been done, so the next run does not redo it. This is the one people forget, and it produces duplicate pull requests and repeated messages.
• What was decided and why, so a later run does not relitigate a settled question.
• What is in progress and since when, so stuck work becomes visible instead of silently abandoned.
• What was escalated to a human and is still waiting.

The store does not need to be sophisticated. A markdown file in the repository, a project board, a small table — all work, and the plain ones have a real advantage: a person can read the state and correct it. State a human cannot inspect is state you cannot debug.

Idempotency follows directly. If a run is interrupted halfway, the next one must be able to tell what completed. The usual answer is to write the record of an action before performing it, so a crash leaves a claim you can reconcile rather than an invisible gap.