Watch & compare
Idempotency
Different ways to see the same idea. Play one cut at a time, then return to the guide to try it yourself.
Why we recommend Retry the intent
Astra makes the crucial distinction easiest to see: the ticket is committed while the agent still does not know the outcome, and retrying the same key and arguments returns that ticket. Its large saved mapping and visible v1/v2 comparison make it the strongest chapter introduction at phone width. Fable is a useful second watch because it first shows a bare retry creating a duplicate, then contrasts a keyed retry; the baseline gives a compact order-API example with parameter-mismatch rejection.
Original · 26 sec
Original explanation
Idempotency lets repeated attempts at one logical operation avoid duplicating its intended effect.
Read the video sequence
- 1–8s: A keyed request creates order 042 once. The reply is lost after the order and request record are committed.
- 10–14s: Retrying the same key and cart returns the recorded order without adding another order.
- 17–25s: Reusing the key with a different cart returns a conflict; the original order remains unchanged.
About this cut
Production: Original prototype; model not recorded.
Recommended · Astra · 30 sec
Retry the intent
Preserve one operation key and its arguments when an agent retries a lost response; reject changed intent rather than silently repeating or changing the effect.
Read the video sequence
- A release agent asks an illustrative ticket tool to create a ticket for release v1 using operation key k7. One database commit saves both ticket #47 and the key-to-ticket record; the count becomes one.
- The reply carrying ticket #47 is lost. The agent does not know the outcome, but the database still contains the ticket. The runner prepares another attempt with the same key and release data.
- The retry looks up k7 and returns the existing ticket #47. No second write occurs, and the agent receives the identifier while the ticket count stays at one.
- The caller changes the release data to v2 while keeping k7. This tool’s contract detects a parameter mismatch and rejects the request; it neither changes ticket #47 nor creates another ticket.
- The unchanged v1 ticket and count of one remain in focus, then the scene fades. This illustrates a service-enforced contract; an agent prompt alone does not supply persistence or permissions.
About this cut
Production: gpt-6-astra.
Illustrative in-house ticket tool: key record and ticket share one database transaction; not a commercial tracker feature claim.
Assumes valid permissions and retained keys; concurrent calls, expiry, and external effects require the guide and service-specific tests.
Audio was analysed for level and synchronization but not physically listened to.
Self-reviewed by gpt-6-astra; no independent comparative ranking or default-cut promotion.
Alternative · Fable · 30 sec
A blind retry acts twice
When an agent's side-effecting tool call times out after the tool already acted, a bare retry creates a second ticket; a stable key for the logical step, stored by the tool with its first result, lets the retry return that result instead.
Read the video sequence
- Normal case. The agent, on step 1, asks the ticket tool to create a ticket. The tool writes ticket #501 into the store and returns #501 to the agent, which shows a green check. The counter reads 1 ticket.
- The agent moves to step 2 and asks for another ticket. The tool writes #502, but the response is lost on the way back: a red cross appears on the wire and it turns red and dashed. A clock spins beside the agent, then a red TIMEOUT badge pops. The store already holds 2 tickets.
- Blind retry. The agent sends the same create request again with nothing to identify it. The tool writes #503 and returns it; the agent shows a green check as if all is well. Then the store jolts with a crash sound: #502 and #503 turn red, the counter reads 3 tickets in red, and a DUPLICATE badge appears. One step produced two tickets.
- Alternate take. Two outlined rewind triangles move left over the fading stage. The picture returns to the start of step 2 with only #501 in the store. This replays the situation with a key; it does not show an operation deleting or rolling back the duplicate tickets.
- An orange "key s2" badge appears beside the agent: the harness names this step with a key. The request chip now reads "create · key s2". The tool stores #502 together with key s2. The response is lost again, the clock spins, and TIMEOUT pops again.
- The key badge glows and the agent retries with the same key. The tool looks the key up: the "#502 key s2" row glows green with a check (a hit sound) and no new row is written. The tool returns #502 to the agent with a chime. The store turns green, the counter stays at 2 tickets, and a SAME TICKET badge appears. The stage fades to black.
About this cut
Production: anthropic/claude-fable-5-1.
Revision: gpt-6-astra comparative review.
Illustrative scenario: the ticket tool is drawn as storing the key with the ticket atomically and checking it before writing. A key attached by a harness has no effect unless the tool or service implements it (as Stripe and EC2 ClientToken do); prompts or harness conventions do not enforce this on their own.
How the key is derived (run and step identity), that it must stay identical across retries and change for a new logical step, and finite key retention are not shown.
Concurrent duplicates (two identical keys in flight) and a reused key with different parameters are not shown; the baseline cut covers the parameter-mismatch conflict.
An editorial rewind separates two hypothetical runs; idempotency does not remove duplicates created by the earlier unkeyed run.
Audio was analysed but not physically listened to. Original self-review evidence is retained; the subsequent hash-bound comparative review is in reviews/comparisons/idempotency.json.
These animations use sound effects rather than narration. The written guide explains the mechanism and its limits. Model names describe how a cut was made, not a quality ranking.
What the review found
- Baseline 4.2–7.7s and Astra 3.8–6.9s both commit before losing the reply. Astra's explicit unknown caller outcome and paired key/ticket records make the distinction between an operation's effect and knowledge of its result clearer.
- Fable 7.46–13.46s uniquely shows an unkeyed retry creating #503 after #502 already exists. Its 24.57–26.07s keyed replay keeps the count at two, making the cost of unsafe retries more concrete than the other two cuts.
- Baseline 17–20.2s and Astra 19–23.3s reject changed arguments under an existing key; Fable does not show that boundary. Astra keeps v1 and v2 available for comparison, whereas baseline relies more on the travelling cart label and mismatch badge.
- Astra 13.6–16.8s has the most readable saved-key-to-ticket mapping at 350px. Baseline 11.7–14.1s is orderly but its result count is small; Fable 24.57–26.07s now has larger ticket rows and count, improving the decisive unchanged-state evidence.
- Fable 15.86–17.16s now displays moving rewind triangles during the fade, clarifying that the reset from three tickets to one introduces an alternate run. It must not be read as idempotency deleting already committed duplicates.
- Baseline 20.2–24.7s, including a 22.1s outcome pulse, and Astra 25–28.7s dwell longer than needed on their resolved outcomes. Fable's 26.07–28.77s close better fits its contrast; Astra's earlier 6.9–9.8s uncertainty hold does useful explanatory work.