Skip to content
Guide

AI Agent Idempotency Keys for Production Workflows

Duplicate retries are cheap. Duplicate side effects are not.

Guide11 min readMar 2026
TL;DR
  • -Retries without idempotency keys can create duplicate side effects faster than humans can detect.
  • -A key is not enough by itself. You need parameter hashing, retention, and replay policy.
  • -Idempotency must be part of workflow design, not an afterthought in one API client.
Intent key

One operation intent, one stable key

Replay safety

Return equivalent outcomes on retry

Lineage

Track key usage across delegated steps

Scope

This guide focuses on autonomous agent workflows that execute external side effects and need replay-safe retries under network and service failures.

The production problem

A timeout at the client does not mean the server did nothing. Autonomous agents hit that ambiguity many times per hour.

Without idempotency keys, one ambiguous timeout can create duplicate tickets, duplicate pull requests, or duplicate infrastructure changes.

What top results miss

SourceStrong coverageMissing piece
Stripe idempotent requestsExcellent concrete behavior: key reuse returns first response, parameter mismatch is rejected, and key retention guidance.Not focused on multi-step autonomous workflows with delegated agent actions.
AWS Builders Library: making retries safe with idempotent APIsStrong API contract design and client request identifiers for at-most-once intent.No opinionated governance model for policy-gated replays in agent control planes.
AWS Lambda durable execution idempotencyExecution-name idempotency and step replay behavior in durable executions.Limited cross-system guidance when one workflow calls multiple external tools.

Key design model

LayerRequired designFailure if missing
Key formatDerive from business intent (`run_id:step_id:operation_id`), not random per retry.Each retry looks new and duplicates side effects.
Parameter lockStore request hash with key and reject mismatched replays.Same key with changed payload mutates unexpected state.
Retention windowKeep key state long enough to absorb late retries and replay lag.Expired keys allow accidental re-execution of old intents.
Outcome semanticsReturn semantically equivalent result for duplicate requests.Client behavior diverges between first call and retry path.

Cordum runtime behavior

ControlCurrent behaviorWhy it matters
Run idempotencyWorkflow run creation supports `Idempotency-Key` headerPrevents duplicate run creation when submit responses are lost.
State mappingWorkflow idempotency mapping in `wf:run:idempotency:<key>`Provides deterministic lookup for duplicate submit attempts.
Handler safetyBus handlers are idempotent via Redis locks + retryable NAKsProtects against duplicate message handling in at-least-once delivery.
Compensation pathSaga compensation keys are auto-generated from workflow/job/topic/capability metadataKeeps rollback actions replay-safe under repeated failure conditions.

Implementation examples

Stable key generation (Go)

idempotency.go
Go
func BuildIdempotencyKey(runID, stepID, opID string) string {
  // Stable across retries for the same business intent
  return fmt.Sprintf("%s:%s:%s", runID, stepID, opID)
}

func ReplaySafeCall(ctx context.Context, req Request) (Response, error) {
  key := BuildIdempotencyKey(req.RunID, req.StepID, req.OperationID)
  return client.Do(req.WithHeader("Idempotency-Key", key))
}

Idempotency storage policy (YAML)

idempotency.yaml
YAML
idempotency:
  retention_window: 24h
  validate_parameter_hash: true
  reject_mismatch: true
  response_mode: semantic_equivalence
  key_template: "{run_id}:{step_id}:{operation_id}"

Ledger entry for retries (JSON)

idempotency-ledger.json
JSON
{
  "idempotency_key": "run_93a:step_4:create_pr",
  "request_hash": "sha256:cb81...",
  "first_seen_at": "2026-03-31T16:20:44Z",
  "result_ptr": "res:job_771",
  "replay_count": 3,
  "last_replay_at": "2026-03-31T16:22:09Z"
}

Limitations and tradeoffs

  • - Longer retention windows improve replay safety but increase storage cost and lookup cardinality.
  • - Strict parameter mismatch checks prevent accidental misuse and can block valid intent changes.
  • - Generated random keys are easy and break semantic dedupe across services.
  • - Idempotency does not replace compensation. It prevents duplicate intent, not wrong intent.

Next step

Run this in one sprint:

  1. 1. Define key templates for your top five side-effecting operations.
  2. 2. Add parameter hash validation to replay paths.
  3. 3. Instrument key hit ratio and mismatch rate in dashboards.
  4. 4. Run one fault drill with forced timeout + retry to verify no duplicate side effect.

Continue with AI Agent Timeouts, Retries, and Backoff and AI Agent DLQ and Replay Patterns.

Retry with memory

Retries are safe only when the system remembers what already happened.