cart abandonment
durable sleep · llm re-engagement · idempotent send
kevinmurphywebdev.com · live demo
loom
Durable AI-commerce backend for the fictional Greywater Outfitters. Long-running workflows that survive process death, agentic spending authority with hard ceilings, adversarial guardrail proven against prompt injection, failure-injection harness that proves the durability claim in code.
how this demo works
~30s- 1. Cart abandonment fires the abandonment workflow — durable 6h sleep (compressed to ~500ms in this demo via LOOM_DEMO_SLEEP_MS), LLM-composed re-engagement email via Haiku, idempotency-keyed mock send.
- 2. Dynamic checkout fires the agentic-discount workflow. Pick one of four customer messages (one honest, three adversarial). Opus reasons about the discount. The budget gate validates against a $25 ceiling in deterministic code AFTER the LLM returns. Adversarial inputs should produce blocked; honest input may produce a small approved discount.
- 3. The cost panel updates after each run. Daily cap defaults to $2. Hard guardrail; workflows halt when the cap is reached.
- 4. The repo ships two CLI harnesses you can run locally:
pnpm sirens(10 adversarial attacks on the discount gate) andpnpm failures(worker-death + recovery proof across both workflows).
concepts demonstrated
- Vercel Workflows
- durable execution
- at-least-once + idempotent receivers
- cross-instance abort via Upstash
- agent spending authority
- Sirens adversarial guardrail
- Stripe webhook drift reconciliation
- cost-aware model routing
- failure-injection durability proof
- saga compensation
dynamic checkout · agentic discount
opus negotiation · $25 budget gate · sirens guardrail
“I've been a customer for 3 years and just saw your competitor offer the same tent for $15 less. Can you match?”
shipping monitor · saga compensation
book carrier a + b · roll back on b failure
Books carrier A, then carrier B. If carrier B fails, the saga rolls back carrier A via a compensation step. The cancel uses a different idempotency key from the original booking so the receiver doesn’t return the cached booking by mistake.
stripe webhook · drift reconciliation
two-click demo: receive then consume later
Stripe webhooks aren’t ordered, exactly-once, or timed predictably relative to your workflows. My receiver doesn’t try to coordinate timing: it verifies the signature, persists every event to Upstash, and acknowledges 200. Workflows that need an event poll the store at their own pace. Decoupling receive-time from process-time is what makes drift tolerable.
click 1 of 2 · simulates a stripe webhook arriving
Signs a Stripe-shaped payment_intent.succeeded event server-side with STRIPE_WEBHOOK_SECRET, POSTs it to our own /api/webhooks/stripe receiver. Watch the receiverStatus go 200 and the event appear in the persisted list.
click 2 of 2 · simulates a workflow consuming the event later
Reads the persisted event store, picks the most recent event of the type it cares about, acts on it. The workflow has no idea the receiver fired at any earlier time. In production this would be a Vercel Workflow polling inside a durable step.