Prove an automation survives the second run

What you need

A sandbox workflow, fabricated sample records and a log you can inspect. For the Cirka example, use exported asset records; this exercise does not assume a public Cirka API exists.

See the creative output used in this example

Work through the exercise

1. Choose one small job: route a finished creative to a review queue. Define the input fields as asset_id, version, status and reviewer. Start with fabricated records rather than a live campaign. Name the only allowed output: a review task. Publishing is outside this exercise.
2. Write the state changes on paper: received, validated, queued, reviewed. Decide which system owns each state. A record with no reviewer should go to a visible error queue, not silently disappear. A duplicate should return the existing review task rather than create another one.
3. Run the prompt below to generate a test matrix. Implement duplicate handling in persistent storage using a unique asset_id plus version key and an atomic create-or-return operation. A sentence telling an AI to avoid duplicates cannot enforce that rule when two requests arrive together.
4. Deliver the same sample event twice, then replay it after restarting the workflow. Send a malformed record and simulate a downstream timeout. If the target service succeeded but the response was lost, use the same idempotency key on retry or reconcile by that key before trying again.
5. Record the input key, attempt, state transition, output task ID and error. Confirm that each distinct asset version creates exactly one review task. Capture the evidence and a recovery instruction a teammate can follow. Only consider real connections after these tests pass with sample data.

You can complete this guide by saving the deliverable and review in your own folder. Sharing inside the club is optional and requires membership.

A prompt to adapt

Replace the bracketed inputs with your own approved material. Keep unknown facts marked unknown.

Review this automation contract: [paste input, states, storage and output].
Its only side effect is creating a review task.
Build a test matrix for: success, missing reviewer, duplicate delivery, concurrent duplicate delivery, timeout after target success, retry, process restart and human rejection.
For each give the sample input, expected persisted state, expected side-effect count and recovery action.
Point out where a database constraint, atomic operation or target idempotency key is required. Do not replace enforcement with instructions in a prompt.
Use fabricated assets. Do not call a real publishing service.

Review your result

• Replay and restart do not create another task.
• Concurrent duplicates converge on one output ID.
• Missing inputs appear in a reviewable error queue.
• Recovery can be performed without guessing what already happened.

If it fails

If retries create duplicates, fix the persistent identity and target reconciliation before increasing retry counts. If there is no reliable way to know the result, stop and route to human review.

Try recalling it later

Why does 'check whether a record exists, then insert' still allow duplicates?

Sources and tools

This is an original club exercise. The source-check date identifies this reference edition; it is not a result from running the prompt.

• See the creative output used in this example

Cirka is our founder's app. We use it as an optional creative workspace in these examples. A separate subscription or credits may be required. Check the tools and models actually available in your account; a model mentioned in a guide is not a claim of Cirka integration.

Continue from here

See how this exercise fits into the AI automation and lead generation course, including its full public syllabus.

Browse all free guides for another task, or save your work and return to it later.