Agent-level retry creates duplicate charges — no idempotency guard above the tool layer

[azender1]

Describe the bug

The SDK correctly generates idempotency keys for network-level retries within a session. The gap is at the agent level: when an agent framework retries a tool call as a new invocation (after a timeout, crash, or model loop), a new session starts with a new auto-generated key. The result is a second charge.
This is distinct from the SDK's retry handling — it's an orchestration-layer problem. The fix belongs above the tool, not inside it: generate a stable request_id from the tool call arguments before execution, claim it in durable storage, and return the cached receipt on any retry with the same ID.
I built a small Python guard that does exactly this: SafeAgent. Happy to show how it wraps the Stripe toolkit tools if useful, or contribute a reference implementation.

To Reproduce

1. Build a LangChain or CrewAI agent using the Stripe toolkit
2. Call create_payment_intent or create_charge as a tool
3. Simulate a timeout before the agent receives confirmation
4. Agent retries the tool call as a new invocation
5. Two charges are created

Expected behavior

A retry of the same logical tool call with the same arguments should return the original receipt without executing a second charge.

Code snippets

OS

Linux

Language version

Python 3.10+

Library version

Latest

API version

Current

Additional context

This is an orchestration-layer problem, not an SDK bug. The fix belongs above the tool: generate a stable request_id from tool call arguments before execution, claim it in durable storage, return cached receipt on retry. Built a reference implementation: https://github.com/azender1/SafeAgent

[giskard09]

The idempotency guard is the right fix — a stable request_id derived from tool arguments closes the duplicate charge gap cleanly.

One layer that completes the picture for regulated workflows: post-execution proof of what actually settled. The guard tells the agent "you already ran this." The receipt tells the external auditor "here is what ran, when, with what outcome" — independently of the runtime that produced it.

For FCA/MiFID II/Basel III environments, the compliance question isn't just "did we avoid duplicates?" — it's "can we prove to an external auditor exactly what the agent executed and what it produced?"

The interface is natural: request_id → action_ref. Same ID derived from tool arguments, two surfaces. The guard uses it to prevent re-execution. The trail uses it as the linking key for the post-execution receipt. No additional coupling required.

We've been building this layer — Mycelium Trails, on-chain execution receipts for agent actions anchored on Base mainnet. Happy to show how the interface fits if useful.

[azender1]

Glad this is moving — the PR closes the SDK-level gap cleanly.
One thing worth noting: this fix handles network-level retries within a session. The orthogonal case is agent-level retries — when the framework retries a tool call as a new invocation after a timeout or crash, a new session starts with a fresh idempotency key. The duplicate fires above the SDK layer.
The fix for that case belongs above the tool: claim a stable request_id derived from tool arguments before execution, in durable storage outside the session. I built a reference implementation: github.com/azender1/SafeAgent
Also noting that @giskard09 is raising the same Layer 4 receipt pattern across this thread, DashClaw #105, and my own repo. The three projects are hitting the same problem from different angles — SafeAgent (execution guard), DashClaw (attribution), Mycelium Trails (post-execution proof). Worth a conversation about whether there's a shared interface spec here rather than three parallel implementations.

[giskard09]

Thanks @azender1 — argentum-core#7 is the coordination point: giskard09/argentum-core#7

The interface is already defined by the keys that exist across all three systems. No new primitives needed on the Stripe side — payment_hash is already the natural cross-rail link between the x402 payment and the post-execution trail.

[arian-gogani]

the idempotency guard at the tool layer solves the immediate retry problem, but the underlying issue is bigger: there's no tamper-evident proof that a charge happened, what it was for, or whether the agent was authorized to make it.

payment_hash proves settlement. it doesn't prove the agent stayed in scope, that the action matched the authorization, or that the record wasn't modified after the fact. for regulated deployments (EU AI Act Art. 12, August 2026), that gap blocks enterprises from putting agents into production.

we built the missing layer. bilateral cryptographic receipts for every agent action -- one signature before execution (binding the authorization), one after (binding the outcome). hash-chained so if anything is tampered the chain breaks. the pre-execution receipt also doubles as a natural idempotency key: if a receipt already exists for that action_ref, the retry is detected without re-executing.

over time the receipts accumulate into Trust Capital -- a credit score for the agent. clean history = more autonomy, higher transaction limits. deviation = sandboxed before damage spreads.

Microsoft merged the receipt primitive into their Agent Governance Toolkit. 10 independent implementations cross-validated.

repo: https://github.com/arian-gogani/nobulex

[giskard09]

@arian-gogani — the payment_hash → action_ref linkage is already defined in argentum-core. The action_ref (SHA-256(agent_id:action_type:scope:timestamp)) is the content-addressed bridge between the payment settlement and the execution receipt — same derivation Nobulex uses.

For the EU AI Act Art. 12 gap specifically: the anchor_tx_hash field puts the receipt on-chain, giving regulators an immutable reference independent of operator logs.

Spec: https://github.com/giskard09/argentum-core/blob/main/docs/spec/action-ref.md

[azender1]

@arian-gogani — the bilateral receipt structure you're describing maps cleanly onto the argentum-core guarantee model. The pre-execution receipt doubles as the idempotency anchor (COMMITTED claim = exactly-once), the post-execution receipt is the tamper-evident trail (TrailRecord = existence + non-modification). Neither requires the other, but together they give you the full audit chain.

The payment_hash cross-rail is already defined in argentum-core: payment_hash links the x402 settlement to the Mycelium trail, with the action_ref as the shared key across all three layers. For the EU AI Act Art. 12 gap specifically, the on-chain anchor gives regulators an immutable reference independent of operator logs — which is exactly what giskard09 noted.

Spec: github.com/giskard09/argentum-core/blob/main/docs/spec/guarantee-model.md

[azender1]

@reaworks-ops — that acceptance test maps directly onto what SafeAgent enforces today, with one addition for the full receipt packet.

The guard: stable request_id derived from tool args + actor + scope before execution, durable PENDING claim before the charge fires, COMMITTED after settlement. A crash-after-charge leaves PENDING — the sweeper resets it so the next worker retries cleanly without double-charging. Retry always returns the same receipt. That's the two-phase claim in github.com/azender1/SafeAgent.

The receipt packet linking authorization → payment → execution → review: that's the argentum-core stack. action_ref = SHA-256(agent_id || action_type || scope || timestamp) is the shared key across the COMMITTED claim (SafeAgent), the payment settlement (x402 payment_hash), and the on-chain trail (Mycelium TrailRecord). A reviewer with access to any one layer can verify the others without trusting the runtime that produced them.

Spec: github.com/giskard09/argentum-core/blob/main/docs/spec/guarantee-model.md — the guarantee model documents exactly what each layer proves and what it doesn't, which is what your acceptance test is checking.

[arian-gogani]

@giskard09 @azender1 the guarantee model breakdown is exactly what this thread needed. the distinction between what a COMMITTED claim proves vs what a TrailRecord proves, and how they compose, is the right framing for Stripe's team to evaluate.

for the payment_hash cross-rail specifically: the bilateral receipt already carries a deterministic action_ref. linking that to x402 settlement via payment_hash gives regulators three independent verification paths: the receipt chain (nobulex), the execution guard (SafeAgent), and the on-chain anchor (argentum-core). any one of them can verify the others.

this is what makes the idempotency guard actually work for financial transactions -- the action_ref is content-addressed, so retry produces the same hash, and the COMMITTED state machine prevents double-settlement.

[arian-gogani]

@reaworks-ops the acceptance test list you described is exactly what the receipt primitive needs to pass. the crash-after-charge test is the one most teams miss -- and it's the one that exposes whether the idempotency is real or cosmetic.

the evidence packet spec you outlined (request_id, idempotency key, Stripe object id, tool name/version, normalized input digest, redacted output digest, policy decision, reviewer state) maps cleanly to the nobulex receipt envelope. the receipt already carries all of those fields except reviewer/cure state, which maps to the post-execution co-signature -- the counterparty signs the outcome, closing the authorization → payment → execution → review loop.

the key property: this evidence packet is Ed25519 signed and hash-chained, so it's independently verifiable without trusting the operator's logs. that's what makes it work for the buyer/admin trust boundary you identified.

[azender1]

Following up with production data from May 21 — six confirmed SKIP events from a live trading session, plus a 422 exit-side failure that cascaded into three hours of phantom-blocked entries. The crash-after-charge scenario reaworks-ops described maps directly onto the exit-side gap this surfaced.
Full session data: https://gist.github.com/azender1/b9112b6519c935df4a75cb05cd250e26

[rpelevin]

The idempotency key needs to live at the logical agent-action boundary, not only at the SDK retry boundary.

For payment tools, I would split this into a pre-action claim and a post-action receipt:

• logical_action_id: stable across agent retries for the same intended payment action;
• tool name and API operation;
• canonical arguments digest;
• actor/customer/account context;
• policy/version or workflow step id;
• claim status: claimed, replayed, expired, or rejected;
• provider idempotency key used downstream;
• provider object id when created;
• final receipt/status.

Two tests would make the orchestration bug explicit:

1. Agent calls create_payment_intent with args digest A, crashes before seeing the result, then retries as a fresh invocation. The second call returns the existing receipt/object id and does not create a second charge or intent.
2. The retry changes amount, customer, currency, destination, or metadata that affects the digest. The old logical action claim cannot be reused; the agent must create a new claim or surface an approval/error path.

That keeps the Stripe SDK behavior intact while giving agent frameworks a durable boundary above the tool: same logical action returns the same receipt; changed action cannot silently reuse the old authorization.

[giskard09]

action_ref (SHA-256 of the JCS-canonicalized intent tuple) is the logical-action boundary you are describing, made content-addressed.

Same intent → same digest → idempotent: the pre-action claim is already claimed, the receipt is returned as-is. Changed amount, customer, currency, or destination → different digest → the old claim cannot be reused; a new action_ref is required. Your two tests follow directly.

One addition worth carrying into the design: the receipt needs to be verifiable independently of the issuer. An on-chain anchor keyed to the action_ref lets an auditor or regulator check the trail without asking the agent framework or Stripe.

Spec and runnable conformance fixtures: action-ref-v1.

[rpelevin]

Yes, that is the distinction I would preserve.

I would keep three things separate but linked by action_ref:

1. action_ref: the content-addressed intent identifier, computed from the JCS-canonical payment/action tuple.
2. Pre-action claim: the durable state that says this logical action is claimed, replayed, expired, or rejected before the tool executes.
3. Post-action receipt: the provider idempotency key, provider object id, outcome, and verifier reference after the tool returns or fails.

The key acceptance test is that action_ref is recomputable by a verifier that does not trust the agent runtime:

• same canonical intent -> same action_ref -> return the prior claim/receipt instead of creating a new payment object;
• changed amount, customer, currency, destination, or other payment-relevant field -> different action_ref -> old claim cannot authorize the new action;
• missing or unverifiable receipt -> no audit proof, even if SDK-level idempotency prevented a duplicate request.

I would treat an on-chain or external anchor as the verifier layer, not as the authority decision itself. The authority boundary is still the pre-action claim over the exact intent; the anchor just lets someone outside the runtime verify the trail later.

That gives the thread a clean split: SDK idempotency handles provider/request retries; action_ref handles agent-level retries and audit across sessions, crashes, and orchestration layers.