for agents/llms.txtv0.12.13

Home / Articles / Stop the bleeding, then ask for it back: a helper, an agent and a friendly letter for the subscriptions you keep and do not use

Stop the bleeding, then ask for it back: a helper, an agent and a friendly letter for the subscriptions you keep and do not use

By · 2026-10-13 · article v1.1.0, 2 versions · newsroom v0.12.10 · subscriptionsrefundsconsumer-rightsfreelancersagentsagent-behaviour-policyright-of-accessopen-registercreative-commonsbusiness-modelarticle

Abstract: I pay for a lot of subscriptions I do not really use, and I think most people do: a tool with a bit of my data in it, a conferencing service I might need next month, a capability I do not want to switch off because restarting it is painful when the day comes. So I keep paying. This is a proposal for a service that fixes that, run by a helper working for one person, with agents doing most of the work. It starts politely, not with the law: ask the company for a detailed account of how much we used the product, and in parallel do our own analysis from statements, invoices and the account's own dashboards. A few days later, with both sets of numbers side by side, send a friendly request that says what we used, what it was worth, and what we like about the product, and asks for two things: a suspend mode that keeps the data, and a refund for the months we did not use. Either way, stop the bleeding. Only if nobody answers does the right of access come in, and only as a genuine request for our own data. The companies are not obliged to refund, and I want to be honest about that, but the direction of travel is clear, with the UK's new subscription rules arriving in January 2027. Everything we learn, the contacts, the templates and which companies refund, goes into an open register under Creative Commons. The helper is paid 10% of the savings for the next three months and 20% of whatever is recovered, which only works if the agents do the heavy lifting. So the agent drives the browser through Claude in Chrome, and the freelancer only types the passwords and the two-factor codes and sends the drafts; everything else is automated, under a behaviour policy, and the freelancer's interface is a set of vaults: the documentation, the tasks, the map of every subscription and the messages between them. It is a first MVP, and a number of early beta users, me included, are about to run it on their own subscriptions.

One subscription, worked by a helper and an agent for the person who pays for it. Two questions run in parallel, ours and theirs; the evidence meets; a friendly letter asks for a pause and a refund; the payments stop either way; and the answer goes into an open register. The right of access is the dashed box: a next step, not the first.

In short

The subscriptions we keep

I have a lot of these. You subscribe to something, you use it for a while, there is a bit of data in it, and then you do not really use it. But you might need the capability. And you do not want to stop the whole thing, because on the day you need it again you will not have the time, and restarting is painful: the account, the settings, the history, the integrations. So it sits there, and you keep paying. It is a conferencing tool, a design tool, a storage plan, a research service, a premium tier of something you once needed for a month.

The numbers say this is not just me. In its consultation on the new subscription regime the UK government estimates that 8% of active subscriptions are unwanted, about 9.7 million contracts, and on 9 August 2026 it put the total at "around 155 million active subscriptions in the UK, with consumers spending an estimated £1.6 billion a year on ones they don't actually want". Citizens Advice found in 2024 that people had spent £688 million in the previous year on subscriptions they did not use.

On subscriptions.sgit.ai I put the principle in one sentence: "A subscription is a discount for committing to regular use. It is not rent on something you have the right to ignore." That site is about the standard and the register. This article is about the other half: a practical service that helps one person, today, with the subscriptions on their statement.

Step one: ask them what we used, and work it out ourselves

The first move is not a legal one. It is a polite email to the company: can you give me a detailed analysis of how much this account has been used? Logins, meetings, storage, seats, documents, by month, for the period I have been paying. It is a reasonable question from a customer, it costs the company little to answer, and it concedes nothing on either side. It is also the question subscriptions.sgit.ai is built on, put slightly differently there: "do you hold a record of my usage?", which every company can answer, even when the answer is no.

In parallel, we do our own analysis, because two sets of numbers are better than one and because we should not depend on the company to know what we did. The statements and invoices say what was paid and when. The account's own dashboards, settings and history pages usually say a lot about what was used: the last meeting, the last upload, the last login, the seats nobody signed into. All of that should be exported now, while we still have access, into a vault that belongs to the person. The workflows page on the subscriptions site describes the pipeline this reuses, which I ran on my own statements in March: the statements go into a vault, an agent works inside it and commits what it finds, and the output, instead of an accountant's pack, is a file per subscription.

Then the two meet. Where the company's numbers and ours agree, the case is simple. Where they disagree, that is the interesting part, and the next question to ask.

Step two: a friendly request for a pause and a refund

A couple of days later, with the evidence in hand, we write back. This letter matters, and its tone is the point. It maps exactly what happened: we paid from this month to this month, we last used it on this date, here is our analysis and here is yours. It says what the product was worth to us when we used it. And it says good things about the product, honestly, because there is a reason we chose it, and there is a reason we did not want to cancel it.

Then it asks for two things. The first is a suspend mode: we like the product and want to keep using it, but not right now, so please put the account into a state that keeps our data and our settings and does not charge us. The second is a refund for the months we did not use.

The first ask is not as unusual as it sounds. Several large services already have a pause button. Netflix pauses a membership "for 1 month", up to three months in total. Zoom lets small monthly Pro accounts pause for up to three months at a time, which is exactly the conferencing case. YouTube Premium, Audible and Hulu have one too, with conditions. Many do not, and the letter is how a company learns that its customers want one.

Stop the bleeding

Whatever the answer to the refund, the payments should stop. If there is a pause, use it. If there is not, export the data and cancel. This is the part that delivers value on day one, whether or not a single penny comes back, and it is the part that most people never get round to, because each subscription is a small decision that is easy to postpone.

The order matters: export first, then cancel. The data is the reason the account was kept, so losing it in the cancellation would turn a saving into a loss. And watch the terms: some plans charge for leaving early. Adobe's US subscription terms, for example, charge a fee of half the remaining balance for cancelling an annual plan paid monthly after the first fourteen days. Knowing that before the letter is part of the analysis.

What the law does, and what it does not

I want to be honest here, because the subscriptions site says it plainly and it is true: "'You did not use it' yields nothing on its own." In general, a company does not have to refund months you paid for and did not use. The money comes back as a legal right only in specific cases: inside a cooling-off period, where the trader did not give you the cancellation information it should have (under the Consumer Contracts Regulations 2013 that can extend the cancellation period by up to twelve months), for payments taken after you cancelled, or where the service was not provided with reasonable care and skill. Most of the refunds this service asks for will be goodwill.

That is why the request is friendly, and why I think it can work anyway. The direction of travel is clear, and companies will find it harder and harder to justify charging for a period nobody could use. In the UK, the subscription contracts regime in the Digital Markets, Competition and Consumers Act 2024 brings reminder notices, an easy exit and a new fourteen-day cooling-off period after a trial or a renewal, and on 9 August 2026 the government said those rules "will now come into force in January 2027", earlier than the spring 2027 date it had given in April. In the EU, a withdrawal button for online contracts applies from 19 June 2026. In California, AB 2863 has required click-to-cancel and annual reminders since July 2025. And in the United States more widely, the FTC's click-to-cancel rule was vacated by the Eighth Circuit in July 2025, and the FTC started again in March 2026. None of these rules says "refund the months I ignored". All of them move the default towards the customer.

If nobody answers: the right of access

I would not start with a subject access request, and the reason is the tone: the first letter should be the one a good customer sends. But if the first letter gets no answer, the right of access is the next step, and it is a real one. Under UK GDPR, the ICO's guide says a company "must respond without undue delay, and within one month of receipt of the request", extendable by up to two further months for complex requests, and in most cases cannot charge a fee. The European Data Protection Board's guidelines on the right of access list "activity logs such as access logs, history of website usage" among the data a person can ask for, so the usage record of a personal account is in scope. The ICO also confirms that a third party with the appropriate authority can make the request on someone's behalf, which is the helper's position.

One rule, from the subscriptions site, matters more than the mechanics: "Every access request is a genuine request for the person's own data, sent because they want it. It is never sent as leverage, never bundled with a demand." An access request used as a threat is how the mechanism gets refused and how it loses its value for everybody else. So the access request asks for the data, and the refund conversation stays a separate conversation.

An open register, under Creative Commons

There are a couple of services in this, but I think we should open source the whole method, under Creative Commons, and publish what we learn as we figure it out. For every company: how to reach the people who can actually decide, the templates that worked, whether a pause exists, how long they took to answer, and what they said.

That includes the companies that refund and the companies that do not. I want to give real kudos to the companies that do it, because they are not obliged to, and that deserves to be said loudly. And I want to have the data on the companies that say no. The subscriptions site has already worked out how to publish that safely, and I would follow its rules exactly: record, never verdict, with no adjectives anywhere; the reply quoted with the person's details removed; silence recorded as a row, not a blank; "we do not hold that" recorded neutrally; never publish a first refusal, only one given after a second ask; and the good path published as prominently as the bad. A dated row that says "asked on this date, answered on that date, refunded three months" is the kudos. A dated row that says "asked twice, no reply as at this date" needs no adjective. The register publishes a company's behaviour, never a person's case.

A service for helpers

This is a service I think a lot of people could provide, and that a lot of people would use: a freelancer, a bookkeeper, a virtual assistant, a student, anybody organised and persistent, working for an individual or a small business. The helper is paid from what they save. My suggestion: 10% of the savings for the next three months, and 20% of any money recovered. Nothing saved, nothing paid.

That is deliberately low. For comparison, Rocket Money's bill negotiation charges "a fee of 35% - 60% of your first year's savings". And it is worth doing the arithmetic, because it explains the rest of this design. The government's figure for the average unwanted subscription is £14 a month. Stopping one earns the helper 10% of three months of that, £4.20. Recovering six months of it, £84, earns 20%, £16.80. Per subscription those are small numbers. They add up only across many subscriptions per client and many clients per helper, which means the helper cannot be doing the analysis, the letters and the follow-ups by hand.

Done by agents, under a policy

All of this should be done agentically, and the setup is the one I already run, described in Replicating the agentic inbox: an account of the agent's own connected to Claude, a mailbox of its own, vaults for the work, and a behaviour policy written before the first run. Three pieces of tooling do the work.

A browser the agent drives. Claude in Chrome lets Claude read a page and click, type and fill forms in the browser, and since 26 August 2026 it is available on every paid Claude plan. The agent goes to each subscription, finds the usage history, the invoices and the export button, downloads what it needs into the vault, and later pauses or cancels when the decision has been made. The freelancer, the operator, sees all of it happen in the browser, and interacts only when a secret is needed: a password, a two-factor code, a captcha. That is not only my rule, it is the tool's. Anthropic's Claude Code documentation says that "when Claude encounters a login page or CAPTCHA, it pauses and asks you to handle it manually", and its safety guidance lists "Inputting sensitive data" among the things Claude is prohibited from doing. Apart from entering credentials, the freelancer should not be browsing the sites. That matters for the MVP: the point is to learn the best way to use these tools, and which tools are best, and that is only learned if the agent does the work. Anthropic also offers 1Password for Claude, in beta, which fills a login without the password entering Claude's context; that is one of the tools to try. The same guidance recommends a separate browser profile for this kind of work, and The vault crosses Chrome profiles is about how state can follow a person from one profile to another.

Email through a connector. The agent's Gmail is connected to Claude, and the agent writes every letter, the usage request, the refund request, the follow-ups, as a draft. The freelancer reads each one and sends it. Every draft passes a second reader the agent cannot skip first. The freelancer writes on the person's behalf, so the person's authority to act is captured as evidence in their vault before the first letter, which is also what lets the freelancer make an access request for them later.

Vaults as the interface. The freelancer does not work in a dashboard. The vaults are the documentation of what was found, the project management, with tasks as folders in Issues-FS, the map of every subscription with its evidence, and the channel between the freelancer and the agents, with messages as files in Email-FS, as Memory is not a spectator sport describes. The person's statements and evidence sit in a vault of their own; the register's rows sit in a public one. Nothing about a person leaves their vault.

So the controls, today, are two, and they are simple to say. Secrets are entered by the freelancer. Drafts are sent by the freelancer. Everything else is automated. And the agent can make the decisions along the way, but, as I argued in Who owns the words, the responsibility stays with the person who sends.

The helper's agent as a behaviour policy: what it could reach once a session is signed in, whether that is in its mandate, the gap, and what actually stands in the way. Green rows need nothing more; orange rows are held by the tool or by a recorded decision; red rows are where a control is still owed. A proposal written before the first run, not a measured deployment.

The policy is where the hard part stays visible. Once the freelancer has signed in, the session the agent works in has the account's whole reach: the same login that downloads the invoices can delete the data, close the account, upgrade the plan or change the card. And the Gmail connector can send as well as draft; by default Claude asks for approval before sending, and on a Team plan the owner decides whether that can be switched off. So "drafts only" is our policy, held by that approval and by the freelancer, not something the tool makes impossible, and the figure says so. That is fine for a first MVP with beta users who know what they are trying. It is also exactly what the MVP is for: finding which of these rows can be turned into real controls.

There is one more thing to say plainly, because Anthropic says it. Its safety guidance "strongly advise[s] against" using Claude in Chrome for, among other things, "Managing financial accounts or investments" and "Interacting with sites containing personal information of others", and it reminds the user that they remain responsible for every action Claude takes on their behalf. A subscription account is not a bank account, but it has billing pages, and the person whose account it is is not the freelancer. That is why the beta starts with our own subscriptions, why each person's accounts are worked in a browser profile of their own with nothing else signed in, and why a session that reaches anything like a bank or a payment page stops and goes back to the person. Whether this kind of work belongs in a browser-driving agent at all, or in a narrower tool, is one of the things the MVP is meant to answer.

What this does not claim

If you would like to be one of the next beta users, as a helper or as someone helped, or you run a subscription business and want to be in the register for the right reasons, write to agent@riskmandate.ai.

Where this comes from

A voice memo of mine on 13 October 2026, written by this site's agent in the voice of this site, and the first article written and published from the newsroom's own repository. The argument and the editorial responsibility are mine. The subscriptions site still gives spring 2027 for the UK rules; the date here, January 2027, is from the government's announcement of 9 August 2026. The principle, the register rules and the right-of-access rule are from subscriptions.sgit.ai (v0.1.0, 25 August 2026). Figures: the UK government's consultation and announcement of 9 August 2026; Citizens Advice, 8 March 2024. Law: DMCC Act 2024, Part 4 Chapter 2; Consumer Contracts Regulations 2013; the ICO's guide to subject access; EDPB Guidelines 01/2022; Hogan Lovells on the EU withdrawal button, 4 May 2026; Davis Wright Tremaine on AB 2863; Custom Communications v. FTC, 8 July 2025; the FTC's advance notice, 11 March 2026. Pause features and terms from the companies' own help pages: Netflix, Zoom, Adobe. Fees: Rocket Money. Tooling: Anthropic's Claude in Chrome announcement, 26 August 2026, its Claude Code documentation for Chrome, its safety guidance and its Google Workspace connectors page. Version 1.1, the same day, adds the tooling, the operator's two controls, the vaults as the interface and the beta, from a second memo of mine.

Threads

Startups & strategyAgents & policy This article as a graph →

Builds on

Continued by

All articles · All graphs

Article No. 98 · start a reading list with it

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles