Recover failed Stripe payments with Postgres context and Resend

Build me an agent workflow that recovers failed Stripe payments by enriching them with customer context from my Postgres database and sending a personalized recovery email through Resend.

Trigger: a Stripe webhook listening for invoice.payment_failed and charge.failed events.

When the webhook fires, the agent should:

1. Pull the Stripe customer ID, invoice or charge amount, currency, failure reason, and next retry date out of the event payload.

2. Use PostgreSQL Find Row to look up the matching account in my customers table by stripe_customer_id. The lookup should return the customer's name, primary contact email, plan tier, signup date, and last successful payment date.

3. Use PostgreSQL Update Row on that same row to set account_status to 'past_due' and stamp payment_failed_at with the current timestamp. Keep the update idempotent so re-deliveries of the same Stripe event don't churn the row or trigger duplicate emails.

4. If the event includes a subscription ID, optionally call Stripe Retrieve Subscription to get the current period end and next billing date so the email can reference real dates instead of vague language.

5. Compose the dunning email. Tone and personalization is where the agent earns its keep over a static template. Shape the copy by plan tier (self-serve trial gets a light touch, paid customer gets warmth, enterprise gets a more formal note), tenure (a brand-new account vs. a multi-year customer), and the specific failure reason from Stripe (declined card, expired card, insufficient funds, do_not_honor, etc.). The email should acknowledge the failure plainly, explain when Stripe will retry, link to the billing portal so the customer can update their card, and sign off from the billing or success team.

6. Send the email via Resend Send Email to the contact email from the Postgres row, falling back to the email on the Stripe customer object if the database lookup missed.

Edge cases: if the Postgres lookup finds no matching row, still send the recovery email using the Stripe customer name and email, and return the mismatch in the workflow output so we can reconcile later. If the row is already marked past_due with a payment_failed_at within the last 24 hours, skip the email and just log the additional failure so we don't spam the customer through Stripe's retry cycle.

Output: a structured summary with the customer ID, plan tier, failure reason, whether the database lookup hit or missed, whether the email was sent or skipped, and the Resend message ID.