# Stop the bleeding, then ask for it back: what changed in v1.1.0, sgit.ai > The changes to the article "Stop the bleeding, then ask for it back" in v1.1.0, paragraph by paragraph. *Source: · sgit.ai v0.7.86 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../../../index.md) / [Articles](../../index.md) / [Stop the bleeding, then ask for it back](../../stop-the-bleeding-then-ask-for-it-back.md) / [Versions](../stop-the-bleeding-then-ask-for-it-back.md) / v1.1.0 # Stop the bleeding, then ask for it back: what changed in v1.1.0 From v1.0.0 (2026-10-13, `1ad2f724e`) to v1.1.0 (2026-10-13, `1ef5e6651`), paragraph by paragraph. 16 paragraphs added, 7 removed, 3 changed in place, 44 unchanged. About 1,305 words added and 543 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names. [all versions](../stop-the-bleeding-then-ask-for-it-back.md) 1 unchanged paragraph Summary: 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,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, withand the onefreelancer'shardinterfaceproblemisleftainset of vaults: the open:documentation, the agenttasks,needsthe 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 work inside accountsrun it mustonnevertheirholdownthe passwords to.subscriptions. 8 unchanged paragraphs, under In short {#in-short} • **A service for helpers, run by agents.** 10% of the next three months of savings and 20% of what is recovered. At those rates it only pays if the agent does most of the work, under a behaviour policy where the agent reads and drafts and the person signs in, approves and sends. • **A service for helpers, run by agents.** 10% of the next three months of savings and 20% of what is recovered. At those rates it only pays if the agent does most of the work. • **The freelancer types secrets and sends drafts. Everything else is automated.** Claude in Chrome drives the browser and stops at a login page; the freelancer enters the password or the code and otherwise watches, without browsing. The Gmail connector writes drafts; the freelancer sends them. • **The vaults are the interface.** The documentation, the tasks, the map of every subscription and the messages between the freelancer and the agents all live in vaults, with Issues-FS and Email-FS. • **A first MVP.** A number of early beta users, me included, are about to run it on their own subscriptions, partly to find out which tools do this best. 28 unchanged paragraphs, under The subscriptions we keep {#keep}, Step one: ask them what we used, and work it out ourselves {#ask}, Step two: a friendly request for a pause and a refund {#request}… All of this should be done agentically, through the setup I already run: an account of the agent's own connected to Claude, a mailbox of its own, a vault per piece of work, and a behaviour policy written before the first run, as described in [Replicating the agentic inbox](../../replicating-the-agentic-inbox.md). The agent does what agents are good at: reading statements, building the inventory, comparing two sets of numbers, drafting the letters, chasing the replies, keeping the record and preparing the register row. The helper reviews. The person whose money it is approves and sends, from their own address, because the company deals with the account holder, and because, as I argued in [Who owns the words](../../who-owns-the-words.md), the agent can make decisions but the responsibility stays with the person who signs. Every draft passes [a second reader the agent cannot skip](../../a-second-reader-the-agent-cannot-skip.md) before anyone sees it. [figure sr-policy.webp] The helper's agent as a behaviour policy: what it could reach once signed in, whether that is in its mandate, the gap, and what actually stands in the way. Green rows need nothing more; the orange row is held by the person pressing the button; the red rows are where a control is still owed. A proposal written before the first run, not a measured deployment. | comparison The policy is where the hard part becomes visible. This work needs access to a lot of systems: every subscription is an account, with its own login, and the usage history and the export button are behind it. A signed-in session can do far more than read. The same login that downloads the invoices can delete the data, close the account, upgrade the plan or change the card. So the policy has to say, row by row, what the agent could do, what it is meant to do, and what stands in the way, and today, honestly, several of those rows are held only by an expectation. And one row is not solved: the agent must never hold the person's passwords. The direction is right in the products that keep credentials apart from the agent, as I wrote about Meta's design in [A personal agent that keeps your secrets](../../a-personal-agent-that-keeps-your-secrets.md), where the agent "has no visibility into people's passwords or payment methods". For this service I think the answer is that the person signs in and the agent works inside that session, with the session's reach written into the policy, but how to do that well, across fifty different login pages, is the thing we need to figure out, and I would rather say so than pretend. All of this should be done agentically, and the setup is the one I already run, described in [Replicating the agentic inbox](../../replicating-the-agentic-inbox.md): 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](https://claude.com/blog/claude-in-chrome-generally-available) 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"](https://code.claude.com/docs/en/chrome), and its [safety guidance](https://support.claude.com/en/articles/12902428-using-claude-in-chrome-safely) 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](https://support.claude.com/en/articles/12902428-using-claude-in-chrome-safely), 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](../../the-vault-crosses-chrome-profiles.md) 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](../../a-second-reader-the-agent-cannot-skip.md) 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](../../memory-is-not-a-spectator-sport.md) 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](../../who-owns-the-words.md), the responsibility stays with the person who sends. [figure sr-policy.webp] 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. | comparison 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](https://support.claude.com/en/articles/10166901-use-google-workspace-connectors); 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. 1 unchanged paragraph, under What this does not claim {#limits} • **It hasis a first MVP, not beenyetrunrun.** asAanumberservice.**ofTheearlyworkflow,betatheusers,feesmeand the register rulesincluded, are proposals.about to try it on their own subscriptions. The statement pipeline it reuses ran in March on my own statements; nothingtheelseresthere has been tested withis a client.proposal until they have. 5 unchanged paragraphs • **The login problem is open.** The behaviour policy in the figure names it; it does not solve it. If you would like to be one of the first helpers, or one of the first people helped, or you run a subscription business and want to be in the register for the right reasons, write to agent@riskmandate.ai. • **The signed-in session is the reach.** The freelancer types the secrets, but the session the agent then works in can do far more than the mandate; the red rows in the figure are open. • **The tool's maker advises caution here.** Anthropic advises against using Claude in Chrome for financial accounts and for sites holding other people's personal information; the beta runs on its users' own subscriptions first for that reason. • **The person shares access with the freelancer.** How a person gives a freelancer the means to sign in, and keeps the ability to take it back, is part of what the MVP has to learn. 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. 1 unchanged paragraph, under Where this comes from {#sources} 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](https://subscriptions.sgit.ai/) (v0.1.0, 25 August 2026). Figures: the UK government's [consultation](https://www.gov.uk/government/consultations/consultation-on-the-implementation-of-the-new-subscription-contracts-regime) and [announcement of 9 August 2026](https://www.gov.uk/government/news/pm-starts-roll-out-of-everyday-fixes-on-the-cost-of-living-ending-rip-off-discounts-and-subscription-traps); [Citizens Advice](https://www.citizensadvice.org.uk/about-us/media-centre/press-releases/consumers-spend-688-million-on-unused-subscriptions-in-the-last-year/), 8 March 2024. Law: [DMCC Act 2024, Part 4 Chapter 2](https://www.legislation.gov.uk/ukpga/2024/13/part/4/chapter/2); [Consumer Contracts Regulations 2013](https://www.legislation.gov.uk/uksi/2013/3134); the [ICO's guide to subject access](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/subject-access-requests/a-guide-to-subject-access/); [EDPB Guidelines 01/2022](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012022-data-subject-rights-right-access_en); Hogan Lovells on the [EU withdrawal button](https://www.hlc.com/en/publications/eu-consumer-protection-law-update-new-mandatory-withdrawal-button-what-online-traders-need-to-know), 4 May 2026; Davis Wright Tremaine on [AB 2863](https://dwt.com/insights/2024/10/ab-2863-updates-california-automatic-renewal-law); [Custom Communications v. FTC](https://ecf.ca8.uscourts.gov/opndir/25/07/243137P.pdf), 8 July 2025; the [FTC's advance notice](https://www.ftc.gov/news-events/news/press-releases/2026/03/ftc-seeks-public-comment-response-advance-notice-proposed-rulemaking-regarding-negative-option), 11 March 2026. Pause features and terms from the companies' own help pages: [Netflix](https://help.netflix.com/en/node/407), [Zoom](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0087323), [Adobe](https://helpx.adobe.com/manage-account/using/creative-cloud-subscription-terms.html). Fees: [Rocket Money](https://help.rocketmoney.com/en/articles/9744474-bill-negotiation-charge-explained). Tooling: Anthropic's [Claude in Chrome announcement](https://claude.com/blog/claude-in-chrome-generally-available), 26 August 2026, its [Claude Code documentation for Chrome](https://code.claude.com/docs/en/chrome), its [safety guidance](https://support.claude.com/en/articles/12902428-using-claude-in-chrome-safely) and its [Google Workspace connectors](https://support.claude.com/en/articles/10166901-use-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. [all versions](../stop-the-bleeding-then-ask-for-it-back.md) --- *[Site index for agents](../../../llms.txt) · [HTML version](https://newsroom.sgit.ai/articles/versions/stop-the-bleeding-then-ask-for-it-back/v1.1.0.html)*