By the time a customer clicks cancel, the decision was made weeks ago. The card that failed three times, the plan that got downgraded, the seats that stopped logging in, the support ticket that never quite got resolved: those are the real cancellation events. The cancel button is just the receipt. Most teams find out too late because nobody is watching the signals between renewals.
A churn-prevention agent watches those signals continuously and acts before the receipt prints. It reads your Stripe subscriptions and usage, weighs the risk signals together, and triggers the right retention play: route a failed payment into dunning, draft a save offer for a human to approve, alert the customer success manager, or tag the account as at-risk. It is a detector and an orchestrator, not a discounter. It never issues a refund, credit, or discount on its own.
What this agent does
On a fixed cadence and on every relevant Stripe webhook, the agent runs a short sequence: pull the subscription state, gather the risk signals, score the account, decide whether a play is warranted, and route the action. Each step is logged, so when you ask why an account got flagged, there is a clear answer instead of a vibe.
It is a layer above involuntary recovery, not a replacement for it. Failed and expired cards are involuntary churn, and that has its own playbook covered in failed payment recovery. This agent decides which signals warrant which play, then hands the involuntary cases down to dunning while it handles the voluntary ones. For where these boundaries come from, see what an AI agent can actually do and how to limit agent actions.
Detector and orchestrator, not discounter
This is the line that keeps the agent safe to run. It detects risk and orchestrates a response, but it never moves money or makes a binding promise. It does not apply a coupon, issue a credit, or refund an invoice. When the right answer is a save offer, the agent drafts the offer and the reasoning, then waits. A human approves the words and the value before anything reaches the customer.
Connections and permissions
Stripe exposes everything the agent needs through its API and webhook events, including subscriptions, invoices, charges, and customer records, per the Stripe Billing documentation. The agent reads those, listens for change events, and writes only the narrow metadata needed to tag an account.
- Read from Stripe. Subscription status, invoice and charge history, upcoming renewals, payment method expiry, and customer metadata.
- Listen to webhooks.
invoice.payment_failed,customer.subscription.updated, and related events flag risk the moment it appears. - Write a tag only. Add an at-risk tag or metadata field to the customer. No write access to balances, coupons, or refunds.
- Notify and draft. Alert the CSM in Slack or email and draft a save message. Sending waits for approval.
Least privilege matters because a billing key is the most sensitive credential you will hand an agent. Scope a restricted key to read plus the single tag-write it needs, and keep refund, payout, and coupon permissions off entirely, as the Stripe API reference permits per-resource. The same hygiene applies as in limiting agent actions. In our experience, the fastest way to lose trust in a billing agent is to give it refund rights "just in case." Keep that capability human-only and the agent stays welcome.
The churn-risk signals it watches
Stripe Billing surfaces both involuntary signals, like failed and expiring cards, and behavioral ones you layer on top, like downgrades and declining usage, per the Stripe revenue recovery docs. The agent reads them together, because no single signal is reliable on its own. A downgrade from a thriving account means something different than a downgrade from one that has gone quiet.
Involuntary signals
- Repeated failed payments. One decline is noise; three in a row on the same card is a pattern that needs dunning.
- Cards expiring soon. A card that lapses in the next billing cycle is a cancellation waiting to happen unless it is refreshed first.
Voluntary signals
- Plan downgrades. A step down in tier or seat count is often the first move before a full cancel.
- Declining usage. Seats that stop logging in, or events that fall off, say more than any survey ever will.
- Support friction. A cluster of tickets, especially unresolved ones, raises the risk score.
- Cancellation intent. Visiting the cancel flow, or a ticket asking how to cancel, is the loudest signal of all.
The single most underrated signal is silence. An account that simply stops using the product rarely complains; it just disappears at renewal. A usage-decline trigger catches that quiet churn weeks earlier than any billing event would. If you also score accounts in your CRM, the agent can hand a clean risk read to a step like HubSpot lead scoring rather than reinventing the math.
How retention plays are triggered
Each combination of signals maps to one play, and the mapping is explicit rather than improvised, so every action is traceable. Stripe Billing recommends pairing automated recovery with human outreach for high-value accounts, per its revenue recovery guidance. The agent follows that split: machines handle the routine, humans approve anything that touches a relationship or a balance.
The four plays
- Hand to dunning. A failed or expiring card is involuntary, so the agent routes it straight into failed payment recovery with Smart Retries and update prompts. No human needed for the routine retry.
- Draft a save offer. When usage drops or a downgrade lands on a high-value account, the agent drafts a win-back or save message with the reasoning attached. A human approves the offer and the value before it sends.
- Alert the CSM. A multi-signal account, say declining usage plus support friction, pings the assigned customer success manager with the full context so they can reach out personally.
- Tag the account. Every flagged account gets an at-risk tag in Stripe and your CRM, so reporting and renewal reviews see it coming.
When we drafted save offers for human approval instead of auto-sending them, the approvals took seconds and the messages got noticeably better, because the CSM tightened the wording for the specific account. If a save play involves an email sequence, the agent can hand the segment to a tool like Mailchimp segmentation rather than blasting everyone. And every flagged account flows into your numbers through Stripe revenue reporting, so churn risk shows up next to MRR, not buried in a separate tool.
Common mistakes
- Letting the agent discount. The fastest way to train customers to threaten cancellation is an agent that hands out coupons. Keep offers human-approved.
- Reacting to one signal. A single failed card or a single quiet week is noise. Weigh signals together before triggering a play.
- Conflating voluntary and involuntary churn. A dunning flow will not save an account that is bored; a save offer will not fix an expired card. Route each to its own play.
- Auto-sending win-back messages. A generic, machine-sent save email can read as desperate. Draft, let a human sharpen it, then send.
- Silent flagging. If the CSM only learns an account was at-risk after it churns, the tag was worthless. Notify with context, in time to act.
The discipline here is the same one behind tightly scoped automations everywhere: detect broadly, act narrowly, and keep a human on anything irreversible, as laid out in how to limit agent actions.
Frequently asked questions
What is the difference between this agent and a Stripe dunning agent?
A dunning agent recovers involuntary churn: failed cards, expired cards, retries. This churn-prevention agent sits one layer up. It watches voluntary and involuntary signals together, decides which retention play each account needs, and hands failed payments down to dunning. Involuntary recovery has its own dedicated post.
Can the agent issue a discount or refund to save an account?
No. The agent never issues refunds, credits, or discounts on its own. It is a detector and orchestrator, not a discounter. When a save offer makes sense, it drafts the offer with the reasoning attached and routes it to a human for approval before anything touches the customer or your Stripe balance.
Which churn-risk signals does the agent watch on Stripe?
It watches repeated failed payments, plan downgrades, declining usage, cards expiring soon, support friction, and cancellation intent. No single signal triggers a play on its own. The agent weighs them together, so a downgrade plus declining usage reads differently than a downgrade from an otherwise healthy, active account.
Does the agent contact customers automatically?
Not without approval. The agent can alert your CSM, tag the at-risk account, and draft a win-back or save message, but any outbound that reaches the customer waits for a human nod. Safe defaults are detect, draft, tag, and notify. You approve the words before they leave under your brand.
What Stripe access does the churn-prevention agent need?
Read access to subscriptions, invoices, charges, and customer records, plus webhook events for payment and subscription changes. It does not need write access to balances or the ability to issue credits. Scope the key to read plus the narrow write needed to add a tag or metadata, nothing more.
Three takeaways before you close this tab
- The cancel button is a receipt. Watch the signals weeks earlier, not the cancellation itself.
- Detect broadly, discount never. Save offers are drafted, then human-approved, always.
- Dunning is one play, not the whole job. Failed cards route to dunning; this agent decides the rest.
Sources
- Stripe, "Stripe Billing documentation", retrieved 2026-06-05, stripe.com/docs/billing
- Stripe, "Recover failed payments and revenue", retrieved 2026-06-05, stripe.com/docs/billing/revenue-recovery
- Stripe, "Stripe API reference", retrieved 2026-06-05, stripe.com/docs/api
- Aryan Agarwal, "Gravity churn-prevention agent guardrails", internal v1, May 2026, About