@Leo Saraivathe thing you already found is most of the answer. The mark and the action can't be made atomic, and that's the limit itself rather than a weakness in your checkpoint file. Once you accept it you stop trying to build exactly-once and start deciding, per side effect, which direction you'd rather fail in. What's actually held up for me in unattended runs: - Persist the plan, then never re-derive it. I'd put this first for agents specifically, and it's the part the long answer above understates. Every idempotency scheme in it assumes the plan is a deterministic function of the inputs. For a cron'd SQL job it is. For an agent it isn't: the planner is a model, so two runs over identical inputs produce different plans, and your operation IDs differ on retry even when you've pinned the input version, because the model's output was never in the key. The fix is exactly steps 3 and 4 up there (read, snapshot, freeze an immutable plan, write the operation rows before executing any of them). The reason it matters more for you than for classical batch never gets said. Retry reads the stored plan. It does not re-plan. If it re-plans, that's a new run and it needs a new run ID. - Related heads-up if you lift that operation_id() function, since it's the most copyable thing in the thread. It hashes input_version into the key, so if the inputs shift between the first run and the retry, the key shifts too and dedupe fails at the exact moment you need it. It's safe only because of the persist-the-plan step, which sits two hundred lines away in the same answer. Take both or neither. Same hazard on deploys: change how you hash the input snapshot and every pending operation ID rotates, which re-fires the backlog. Bill's second rule is the sharpest thing in this thread. Clearing the landing spot before the run does more than tidy up. It turns a question into a precondition. The Codex answer assumes you can ask the destination whether it already holds the effect. Bill's version says make the destination state unambiguous by construction so you never have to ask. When a destination has no idempotency key and no lookup, that's the only move left.

Good eye on good links :))

That is really cool! You know I would love to collaborate :)

@Bas Rosario My heart to you and your family mate! You give so much, allow the universe to give you back some 💙💙💙

@Mira Bradshaw so cool to see your mastering of the process! Your video progressions show it. Magical! And the system you built to complete all this resembles the process I went through with my "team." You and @Danney Tee use of the architecture is inspiring (at least to me as a fellow visual player :)). I do enjoy your humor "I'd say like pulling teeth, but teeth pulling comes with a side of anesthetic, and this definitely didn't." Thanks for letting us into the dentist chair :)

@Mira Bradshaw