Next Sunday morning, a company you've probably never used is going to delete a chunk of its customers' data on purpose, and the reason has nothing to do with a hack, a bug, or anyone doing anything wrong.

Manus, the AI agent company, told its users on August 11 that it's going back to operating independently. Meta bought it in December of last year for something around two billion dollars. In April, China's National Development and Reform Commission blocked the deal through its foreign investment security review office and required the parties to unwind a transaction that had already closed. That's rare. That basically doesn't happen. And now the cleanup is happening in public.

Part of that cleanup is this: data generated by affected users on or after December 29, 2025, which is the exact date the acquisition closed, gets deleted between 8:00 in the morning Singapore time on August 23 and sometime on August 24. Users can back up until 7:59 that morning and restore starting the 25th. Manus was clear that this isn't a security incident and that pre acquisition data isn't affected. They're waiving charges during the backup window and promising some kind of bonus afterward. As corporate breakups go, they're handling it about as decently as the situation allows.

Now here's why I'm writing about it, because I know most of you don't use Manus.

Nobody who had work sitting in that account did anything wrong. They didn't pick a sketchy vendor. They picked a company that got acquired by Meta, which is roughly the most establishment outcome available to a startup. And then two governments had an argument about it, and the calendar delivered a deletion date.

You cannot underwrite that risk. You cannot research your way around it. There is no due diligence process on earth that would have flagged "Beijing will block this and force an unwind" as a data retention risk when you signed up.

Which means the only defense is structural. You assume every platform you use might hand you a two week notice someday, for reasons that will make sense to somebody in a boardroom and none to you. And you build accordingly.

So today we're building the exit. Not because you're leaving anything. Because the exit being built is what lets you stay calm when the email arrives.

First, find what only exists in one place

Grab a page. You're making a list of every system that holds business data, and next to each one you're writing where else that same data lives.

Most entries will have an answer. Your invoices live in your accounting software and also in your email and also in your bank's records. Fine. Redundant by accident, which still counts.

The dangerous entries are the ones where the answer is "nowhere else." Those are your single points of failure, and every business has more of them than the owner expects.

Here's where they usually hide.

Your automation platform holds the logic of how your business runs. Not the data, the logic. If your scenarios vanished tomorrow, could you rebuild them from memory? Probably not the fiddly ones, and the fiddly ones took the longest to get right.

Your CRM holds relationship history. Names and emails export easily. The notes about who prefers a phone call, who went dark in March and came back in June, which deal died over a payment term, that's the part that took three years to accumulate and the part that's hardest to reconstruct.

Your email service provider holds your subscriber list, but more importantly it holds engagement history and the deliverability reputation attached to your sending domain. The list exports. The reputation doesn't.

Your meeting recorder holds transcripts of every conversation you've had. Your project tool holds decision history buried in comment threads. Your design tool holds source files. Your scheduling tool holds nothing worth saving, which is a nice thing to be able to say about something.

Circle the ones with no second home. That's your build list.

The automation, concretely

I run this in Make, and it's a straightforward pattern that you'll repeat once per platform. Here's the shape of one.

The trigger is a schedule. Monthly on the first, early enough that nothing else is running. Not weekly. Weekly generates so much noise that you stop looking, and the whole thing quietly rots.

Step one calls the platform's export endpoint, or if the platform doesn't offer one, pulls the records through its regular API with pagination. This is the step where you find out which of your vendors respect you. A tool with a clean bulk export is telling you something about how it thinks about your relationship. A tool where the only way out is clicking through a settings page and waiting for an email is also telling you something.

Step two writes the result to storage with a dated path. I use a folder structure like year, then month, then platform name. Boring and searchable, which is the correct combination. Google Drive works fine for this. So does anything else, as long as it isn't the platform you're backing up.

Step three is the one people skip and the one that makes the whole thing worth building. Check the size of what you just wrote and compare it to last month. If the file is smaller than eighty percent of the previous run, something is wrong. An API changed, a token expired, a pagination loop quit early. Send yourself a message. Otherwise stay silent.

That's the rule that keeps this alive. Silence on success, noise on anomaly. If your backup automation emails you every month saying everything is fine, you'll archive those emails without reading them within six weeks, and then it'll fail silently for a year.

Step four, once a quarter, writes a line into a simple log. Date, platform, record count, file size. That log is what you'll actually look at when you're wondering whether this thing has been working.

Build one. Get it running. Then clone it for the next platform, which takes about fifteen minutes because the shape is identical and only the first step changes.

What to actually pull from each

Some specifics, because "export your data" is useless advice without them.

From your CRM, pull contacts with all custom fields, deal or opportunity records with stage history if it's available, and notes. Notes are the thing people forget because they're not in the default export. Go find the notes.

From your email platform, pull the subscriber list with subscribe dates, sources, and tags. Then separately pull your published content as HTML, not as a link. A link to a post on a platform is not a backup of that post. If you publish through beehiiv like I do, the API gives you post content directly, which makes this genuinely easy. Grab the last twelve months and then keep it current monthly.

From your meeting recorder, pull transcripts rather than summaries. The transcript is the primary record and the summary can be regenerated from it. If you use Fathom, the transcripts come out cleanly and they're a lot more useful in a searchable folder than they are locked in a web app you might not have access to next year.

From your automation platform, export your scenario definitions as JSON. Make lets you do this per scenario, and it's the single highest value backup on this list relative to how little time it takes. That JSON is your business logic in a file.

From your relationship tools, and I'm thinking of things like Clay, pull the enriched contact data. You've been accumulating context on people for a long time. Some of that is inferred and some of it you typed in yourself at eleven at night after a good conversation. That second kind doesn't exist anywhere else.

SKIP THE BUILD, TAKE MINE

Every scenario in this piece, exportable and ready to import, plus the folder structure and the anomaly check logic, ships inside the AI Workflow Blueprint. Eleven automations, documented, no assembly required.

The part where you find out it doesn't work

Everything above is the easy half. Here's the half that separates people who have backups from people who have folders.

Once a quarter, pick one platform and actually restore from your export. Not conceptually. Open the file. Try to reconstruct something real from it.

I did this last year with a CRM export I'd been quietly generating for eight months and felt very responsible about. Turned out the export was writing contact records fine and dropping every note, because the notes lived on a separate endpoint I'd never wired up. Eight months of backups, all of them missing the thing I'd have most wanted. I'd have discovered that on the worst possible day if I hadn't tested it on a Tuesday afternoon when it cost me nothing.

That's the whole lesson. An untested backup is a story you tell yourself. The test is cheap and the discovery is expensive, so run the test.

Pick a quarterly date. Put it in the calendar as a recurring block with the platform name rotating. Fifteen minutes each time.

A word about which platforms deserve this

Not everything needs an export pipeline, and building seven of these when you need two is its own kind of waste.

Here's my filter. Build the export if losing the data would cost you more than a day of work to recover, or if the data has legal or financial significance, or if it represents accumulated context rather than something you could regenerate.

That last one is the interesting test. Regenerable data is cheap. If a system holds output that a model could produce again from inputs you still have, don't sweat it. Accumulated data is expensive. Years of customer notes, engagement history, decision logs, the things that got built up one interaction at a time. You cannot regenerate accumulation. That's the stuff.

By that filter, most businesses need three or four of these pipelines, not a dozen. Build the three or four. Ignore the rest with a clear conscience.

The bigger habit underneath all this

I want to name the thing that this is really teaching, because the automation is almost beside the point.

Every tool you adopt is a bet that the company behind it will still be there, still be run the same way, and still be allowed to operate in your jurisdiction, for as long as you need it. That's three separate bets and you're usually only thinking about the first one.

The Manus situation is unusual in its specifics and completely ordinary in its shape. A regulatory body somewhere made a decision, and a deletion date appeared on customers' calendars. Something structurally similar will happen to a tool you use. Maybe an acquisition, maybe a shutdown, maybe a pricing change that makes staying irrational, maybe a compliance requirement in a country you've never visited.

You don't need to predict which one. You need to be the business that shrugs when it happens, exports cleanly, and moves. That's not paranoia. That's just having built the exit before you needed it, which costs you an afternoon now and saves you a very bad month later.

And there's a quieter benefit that I didn't expect when I started doing this. Having clean exports made me a better negotiator with my vendors. When renewal comes and the price goes up thirty percent, the conversation feels different when you genuinely could leave. They can tell. You can hear it in your own voice.

BUILD THE WHOLE STACK WITH ME

The AI Business Accelerator goes six weeks deep on the infrastructure layer most operators never get to. Your actual tools, your actual data, live teardowns, and a stack you own instead of rent.

Your homework is small. Open the list of tools you pay for. Find the one holding data that exists nowhere else. Build that one export this week.

Not all of them. One. The rest will be easier once the first one is running, and one working pipeline beats seven planned ones every single time.

See you tomorrow.

Jordan

The AI Newsroom is written by Jordan Hale. This issue contains affiliate links to tools I actually use. If you sign up through them I may earn a commission at no extra cost to you.