Idempotency sounds like an enterprise buzzword. It is not. It means: if the same event shows up twice, your workflow’s side effects happen once. That matters the moment you add AI to a no-code stack.
Markdown supported · ⌘↵ to post
One state in the claim table can strand an event: claimed. If the run dies after the claim row is written but before the AI step finishes, say a timeout on the model call or a scenario error, every retry of that event hits Path A and stops, because the row still says claimed. The duplicate gate then turns a crash into a lost dispute, and nothing fails visibly. A lease handles it. Treat a claimed row as live only while claimed_at is younger than the longest a run can reasonably take, and let a retry take over a stale claim by updating it. The failed status has the same weakness, since writing it needs the run to survive long enough to write it. A small scheduled step that lists claims older than the lease gives a human a short list to check.
Elarigent
The invoice dispute example is where this stopped being abstract for me — especially the deliberate decision to not auto-send to the customer on the first build. Treating "claimed" and "succeeded" as genuinely different states is a small design choice that prevents the most embarrassing kind of automation failure.