Transport retries are solved. Agent retries are not.

When an AI agent times out on a write and retries as a new tool call, provider SDKs often mint a fresh idempotency key. The first call may already have succeeded. The second creates a duplicate side effect. That gap sits above the tool — and it is showing up in primary sources.

The claim

Action integrity for agents requires three things most stacks do not ship together:

Business-operation identity — stable across model replans and framework re-invocations, not only HTTP retries.
Observe-before-retry — check the system of record when the outcome is unknown.
An agent-ready next step — continue, retry, repair, or escalate — instead of letting the model guess.

Three identities, one collapse

Teams treat “idempotency key” as one concept. In practice there are three layers. Only the first is usually handled well.

Transport

Network retry of the same HTTP request. Stripe SDKs and similar clients largely cover this.

Mostly solved

Agent tool-call

Framework or model re-invokes the tool after timeout, crash, or replan — often with a new session key.

Often broken

Business operation

Canonical intent: refund this order once, open one ticket for this incident. Rarely productized.

Underserved

Primary evidence

stripe/ai#402 — Agent-level retry creates duplicate charges; SDK keys reset on a new tool invocation. Fix belongs above the tool.
langgraph#7417 — Long tool calls on LangGraph Cloud can be silently re-dispatched from checkpoint while still running.
crewAI#5802 — Task retry re-runs tool side effects with no guard that the tool already completed.
claude-code#36149 — MCP tools double-dispatched with different tool_use IDs → duplicate creates.
AWS Agentic AI Lens BP04 — Retries without deterministic keys produce duplicate side effects; check for an existing result before executing.
Temporal Activity docs — At-least-once activities can charge twice if the worker dies after success before reporting.

What exists — and what still feels too hard

Too light

Claim/SKIP ledgers and transport keys stop some duplicates, but they do not reconcile an unknown timeout against live provider state.

Too heavy

Durable workflow rewrites (Temporal and peers) solve long-running orchestration. Most agent teams hitting this bug have 2–3 dangerous tools — not a platform migration.

Homework-heavy

Protect-style SDKs ask customers to write observe logic. That destination knowledge is the hard part agent builders do not want to reinvent.

Wrong layer

MCP security gateways focus on auth, allow/deny, and approvals. They decide if a call is allowed — not whether it already happened.

What we are building

Afterstate is the outcome layer for dangerous agent tools: business operation identity, destination observers, and next-step receipts at the tool/MCP boundary — without forcing a durable-workflow rewrite.

Prebuilt observers first for Stripe (and Slack for demos).
Agent-native receipts: applied · not_applied · ambiguous.
Explicit next step: continue · retry · repair · escalate.
Exception desk when observe is impossible.

We are not claiming the category is empty. We are claiming the default for agent builders is still missing.

Building agents that write to the real world?

If you have seen a duplicate charge, ticket, or message after a timeout, we want to hear the story.

Request early access