How to Build an Agent That Handles Subscription Cancellations

Design each tool as a typed function with a fixed output schema. The language model's only job is to choose the tool and fill its arguments; the tool returns facts.

1. Contract reader. Input: contract ID or document. Output: cancellation notice period, early termination fee (if any), cooling-off clause with its own start date, refund basis (full, pro rata, none), and the clause IDs where each was found. Never let the agent paraphrase a clause without the source span.

2. Billing lookup. Input: customer ID. Output: plan start date and time in the customer's time zone, list of charges (date, amount, currency, status), last successful payment, payment method token reference, and current subscription status.

3. Jurisdiction rules. Input: customer country and region, contract type, purchase channel. Output: statutory withdrawal right (yes or no), length in calendar or business days, and whether the right was correctly disclosed at purchase. Keep this table versioned and reviewed by counsel, not by the model.

4. Refund router. Input: a case record with an idempotency key. Output: refund ID, amount, status, and provider timestamp. It refuses to run without a policy decision ID.

A small helper schema keeps the handoff honest:

{
  "case_id": "CXL-10482",
  "customer_id": "cust_8821",
  "contract_id": "ctr_2024_A",
  "cancellation_requested_at": "2025-03-10T18:22:00Z",
  "cooling_off_ends_at": "2025-03-13T23:59:59-05:00",
  "refundable_amount": 49.00,
  "currency": "USD",
  "reason_code": "WITHIN_WITHDRAWAL_WINDOW",
  "policy_decision_id": "pol_7781",
  "idempotency_key": "refund_CXL-10482_v1"
}

Most practitioners assume a general three day right to cancel. There isn't one. The FTC's Cooling-Off Rule gives three days to cancel certain sales made at the buyer's home, workplace or a temporary seller location, and it explicitly does not cover sales made entirely online, by mail or by telephone (FTC, Cornell LII). The clock runs to midnight of the third business day, with Saturday counted and Sundays and federal holidays excluded (FTC).

State and sector rules add their own windows. Ohio, for example, gives five days for business opportunity plans, seven days for telemarketing sales and thirty days for hearing aids, generally measured in business days (Ohio Attorney General).

The practical lesson: the agent must treat cooling-off as a property of the specific contract and purchase channel, not a global constant. If disclosure was defective, the window may stay open. Ohio notes that a cancellation right does not start until the consumer receives written notice, so a health club that never gave notice leaves the right open (Ohio AG).

A customer on a monthly plan at $49 calls on Monday, March 10, at 6:22 p.m. Eastern and asks to cancel. The plan started Friday, March 7. The jurisdiction is Ohio, the purchase was in person at a temporary location, and the amount was above $130 for that channel.

1. Contract reader returns a 3 business day cooling-off clause, no early termination fee, full refund basis, clause 7.2.
2. Billing lookup shows one charge of $49 on March 7, status settled, and no usage credits.
3. Jurisdiction rules confirm the FTC 3 business day window applies and was disclosed. Counting business days from Friday: Saturday counts, Sunday does not, Monday does not count as a holiday. The customer has until midnight on Wednesday, March 12 (FTC).
4. Policy engine sees "within window, amount $49, first charge, no fee clause" and auto-approves a full refund of $49 with reason code WITHIN_WITHDRAWAL_WINDOW.
5. Refund router issues the refund with idempotency key refund_CXL-10482_v1 and returns a refund ID.

Total exposure: $49. Compare that with the same request arriving Thursday, March 13. The window has closed, the clause still permits cancellation with 30 days notice, and the refund basis is pro rata for unused days. The policy engine now routes the case to a human for approval because the amount is not determinable from a statutory rule alone. One day of difference in arrival changes the decision path, which is exactly why the deadline must be computed, not guessed.

Statutory rules are written in terms your database does not naturally hold. For a sense of how detailed they can get, read the FTC's rules on how a valid cancellation is delivered, such as postmark timing (FTC). Your agent should capture the customer's stated channel and timestamp, then let the rules table decide whether that channel is valid.

Your own terms may create refund obligations that are stricter than statute, or exits that are more expensive than the customer expects. A vendor lock-in analysis of SaaS contracts points to narrow cancellation windows, sometimes 30 days before renewal, missing data export obligations and vague termination language as the most common ways customers get trapped (toslawyer). Each of those becomes an edge case the cancellation agent will meet.

The agent should extract and surface, in plain language:

• Notice period before the next renewal date.
• Whether cancellation is effective at renewal or immediately.
• Early termination fee formula and any cap.
• What data the customer gets back, in what format, and for how long after termination.
• Whether a separate refund policy exists and which one wins in a conflict.

That last point matters when a refund is promised by promise but constrained by the contract. The agent should never resolve the conflict itself; it should raise a flag with both clause IDs attached.

If you rely on a merchant of record, check what refund and chargeback terms it imposes. MoR providers typically manage refunds and disputes on the seller's behalf and carry the legal seller role, while payment facilitators process payments and leave tax, compliance and most customer liability with you (Paddle, Gapp Group). The agent's refund router has to speak to whichever model you chose, and its ceilings should be set by that contract.

The decision rule is simple: an action needs human approval when it is irreversible, costly, regulated or affects many records. Issuing a refund is the textbook case, and refund initiation is commonly paired with dual approval from finance and a manager, with the invoice and validation evidence attached (StackAI). Approval workflows also need to route to the right approver role, supply an evidence pack that can be reviewed in 10 to 30 seconds, and support "approve with edits" so a reviewer does not restart the whole case (StackAI).

A workable gate matrix for cancellations:

Two implementation details cause most incidents. First, idempotency: every refund call carries a key derived from the case and attempt number so a retry cannot double-pay. Second, evidence packs: the tool outputs and the policy decision, assembled before the approval screen loads, so the reviewer is confirming a decision rather than hunting for facts (StackAI).

A step limit is also worth setting. If the agent loops more than twice on the same tool call, stop and hand off. Loops usually mean missing data, and missing data is a reason to ask a human, not to retry.

If your customer paid with a stored card credential, the refund usually goes back to the original payment method. That only works if you can still resolve the token. Processor tokens usually work only inside that processor's environment; the token string is meaningless elsewhere because the mapping to the underlying card stays behind the provider's API (Payment Therapist). Network tokens are issued and managed by the card networks and can update automatically when a card is reissued, but coverage varies by region and issuer, so a PAN fallback is still needed in some cases (Very Good Security).

For the cancellation agent, this means one extra check before the refund router runs: can this payment method be refunded, and by whom? Tokenization documentation makes the same point, that only the original tokenization system can swap the token back to the primary account number for authorization (Payabli). When a merchant moves processors, the agent may find a valid charge and a token it cannot resolve. The right output is a reason code like REFUND_CHANNEL_UNAVAILABLE and a manual task, not a promise of a refund.

Log every step, not just the outcome. A workable event schema for the case:

• request_received with channel, timestamp in UTC, and computed customer-local time.
• tool_call for each of the four tools, with input hash, output, latency and the tool version.
• field_extracted for each contract field, with source clause ID and confidence.
• deadline_computed with the rules version and the exact business-day arithmetic.
• policy_decision with the decision ID, rule fired and threshold values.
• approval_requested and approval_granted with approver role, timestamp and any edits.
• refund_submitted with idempotency key and provider response.
• customer_notified with the message template ID.

Store the events append-only and make the case replayable from the log alone. When an auditor asks who did what, when and why, the answer should be one query, not an archaeology project (StackAI). Keep the rules table version in the log too: if the deadline calculation changes after a review, you need to prove which version produced which case decision.

Two habits pay off. First, separate the model's reasoning from the tools' facts in the log so a model upgrade cannot be blamed for a wrong refund. Second, sample-approve recorded cases weekly against the rules table to catch drift before a customer does.

When multiple models sit behind these tools (a small model for extraction, a larger one for ambiguous contract language), routing them through one API with a single key keeps cost tracking and failover simple. Quanta Inference (https://quantaintelligence.ai/inference) exposes text and embedding models through an OpenAI-compatible endpoint, which is enough to prototype the reader and the classifier before you commit to a policy engine. For teams that want the approval workflow and audit trail built by someone who has shipped it, a Quanta consulting call (https://quantaintelligence.ai/calendar) covers scope and architecture in half an hour.