The question#
Could a durable agent help a publishing workflow recover without repeating an external action? I tested a narrower, inspectable boundary: Stripe accepts a test payment, then the agent crashes before its tool returns.
My contribution#
I chose the question and the real-provider test boundary, and developed the lab with ChatGPT/Codex assistance for implementation, execution orchestration and drafting. The work connects a durable agent session, a separate payment ledger and a provider-side readback.
Approach#
The baseline uses Agents 0.28.1 and Pi Durable 1.3.0, a deterministic faux model and two GBP 1.00 Stripe test-mode PaymentIntents. One run interrupted local Wrangler; the other reset a hosted Cloudflare Durable Object. A separate replay control distinguishes safe and unsafe tool behaviour.
Outcome#
In the two observed recoveries, the unsafe tool was reported as interrupted and its recorded execution count stayed at one. The application rejected duplicate admission of the same operation. No real money moved.
The original hosted runner failed an assertion about a marker written just before the crash. That failed result is retained. Subsequent readback checked the same payment using the replacement instance, transcript and ledger.
Limits#
This is a pinned integration study, not an exactly-once guarantee or a test of production-model behaviour. Webhook delivery converged to one stored payment marker; downstream fulfilment was not tested. The hosted resources were retired. See the case study for full verification boundaries.