Here's what Daniel wrote to us. It's a long one, so bear with me. "We talked earlier today about how to deploy a better solution for email routing than using Google Groups, which is a workaround I and probably countless other people rely upon. As you pointed out, Groups was always intended to be something like a modern take on the listserv. The fact that people use it for email delivery routing is simply because Google has never bothered to revisit it."
He goes on. "I mentioned I've been using Google Workspace literally since I was nineteen or twenty, so it's the only way I know of using things in the cloud like Drive, Calendar, and Contacts. It's not so much that I love Google, but that whenever I've looked into alternatives to Workspace, I've come up against a wall. You have projects like Nextcloud that are self-hostable, but both feel dated compared to Google Workspace. The impediment, for me at least, is cost. If a license is eight or ten euros per month, I've been using Google for so long that I think it's a reasonable price for all the essential tools it offers."
"But when you run into friction points like routing and you see that Cloudflare does it a lot better, you begin to wonder: does this make sense? I was looking today for contact storage because I'm setting up SIP and migrating my traditional telephony over to it. My instinct, and this wasn't because I was trying to de-Google, was to have somebody make an API service for managing an address book so that it can be synced across devices regardless of what's actually backing it. The answer, surprisingly, was mostly no, which I think is probably a reflection of the fact that, like me, most people are tied into monolith bundles. The amount of people that want to break out doesn't create a very compelling business case."
Then he gets to the thesis. "The reason I'm sending this prompt and the reason I think that Google and Microsoft's mode could finally actually be under threat is because of agentic AI. The thought of creating your own documents portal might have seemed ridiculous a few years ago. Who is going to have time to divert a dev team to creating a replica of Google Docs, reinventing the wheel? But I feel like with a few well-oiled primitives for contact books, documents, and calendar, we could get there."
"When you think about what Google Workspace offers to most organizations, it's actually less compelling than it is convenient to have this bundle. As soon as you start wanting to do more programmatic things with document access, you begin running into API challenges. Enterprises often scale off Google and Microsoft. All this leads us to ask: what do you think are some of the viable paths away from these big cloud titans? I love the convenience of cloud computing, and as a Linux user, having a cloud workspace eliminated all these Libre Office Microsoft Word friction points of yesteryear. Cloud is, in my view, still the answer. But I think the traditional monoliths of Google and Microsoft have had probably undeserved supremacy for too long, and that the time has come for many organizations, or might be ready, to migrate to a more tailored and fitting alternative."
So let's unpack this. Is the monolith actually under threat, or is this just wishful thinking from a long-time power user?
The thing that jumps out at me first is the nineteen years of muscle memory. When you've been inside an ecosystem since you were basically a teenager, the cost of leaving isn't the eight euros a month. It's the thousand tiny things you don't even know you'd have to re-learn. That's the real moat.
And Daniel's not pretending otherwise. He literally says it's not that he loves Google. He's just never found the exit door that didn't look like a downgrade.
Right. And that's the core tension here. Google Workspace isn't loved, it's just convenient. Convenience has this compounding cost that only surfaces at the edges. Nobody wakes up and thinks, I need a better email routing architecture. You only hit that wall when you're doing something slightly unusual, like setting up SIP telephony and needing a syncable address book.
So let's trace the three friction points he actually hit. Email routing via Google Groups. Contact storage with no API alternative. And document access that gets awkward the moment you want to do anything programmatic. Those are the cracks in the bundle.
And the question underneath all of them is the same. Is the bundle actually delivering value, or is it just the path of least resistance? We'll work through the mechanisms of the friction first, then get to the agentic AI thesis, and then what you can actually do about it this week.
Let's start with the concrete friction points. The places where the bundle actually breaks down.
Google Groups as email routing. I need to say this clearly because a lot of people don't realize they're doing it. Google Groups was designed as a modern take on the listserv. That's what it is. A mailing list with a web interface, membership management, moderation tools. It was never built to be a mail routing engine.
But people use it for exactly that. Why?
Because Google never gave them another option inside Workspace. If you want multiple people to receive mail at info at your domain dot com, you can't just set up a simple forward. You either pay for a full user license for that address, or you create a Group and add people to it. The Group becomes your routing layer by default.
And what's wrong with that?
It's a mailbox pretending to be a router. When mail hits a Google Group, it lands in a mailbox first. Then the group software decides what to do with it. That means delivery delays, bounce handling that doesn't work the way you expect, and this whole layer of group settings that have nothing to do with routing. You're configuring spam moderation and reply-to behavior for something that should just be a dumb pipe.
So the tool is doing a job it was never designed for, and the friction shows up in the seams.
Now compare that to Cloudflare Email Routing. It operates at the DNS level. There's no mailbox. There's no storage. Mail arrives, Cloudflare looks at the recipient address, and forwards it to wherever you've told it to go. That's it.
So it's structurally different. Not just a better version of the same thing.
Completely different architecture. With Cloudflare, you point your MX records at them, and then you set up rules. Catch-all routing, per-address forwarding, the whole thing. It's free. No per-user licensing. And because there's no mailbox, there's nothing to fill up, nothing to archive, nothing to manage.
And Daniel's been paying for Workspace licenses partly to solve a problem that Cloudflare solves for free at the DNS layer.
That's the thing. He's not alone. I'd guess tens of thousands of small organizations are doing the exact same thing. They don't know there's an alternative because the alternative isn't inside the Google admin console. You have to know DNS exists, know to look outside the bundle, and then actually make the switch.
The bundle's power is that it keeps your attention inside the bundle. You don't go looking for solutions elsewhere because you assume the solution should be in here somewhere.
And Google has zero incentive to fix this. If they built proper DNS-level routing into Workspace, they'd cannibalize their own Group usage and possibly some license revenue. The workaround is the product.
Let's talk about the contact storage gap. Daniel went looking for an API-first address book service and came up empty. That surprised me less than it seemed to surprise him.
It shouldn't surprise anyone, honestly. The market for standalone contact APIs is nearly nonexistent. And that's not an accident. It's not because nobody wants it. It's because the data is the moat.
Say more about that.
Think about what happens to your contacts inside Google Workspace. They're not just names and phone numbers sitting in a silo. They're connected to your email, your calendar, your documents. Google knows who you email most often, who you schedule meetings with, who appears in your shared documents. That cross-product data graph is the real product. Contacts are the nodes in that graph.
So if you extract contacts into a standalone service, you break the graph. And Google has no reason to make that easy.
None. And here's the chicken-and-egg problem. The reason nobody has built a great contact API service is that the people who would want it are already locked into Google or Microsoft. The addressable market is tiny because the monoliths have already absorbed it. Daniel's own words: "the amount of people that want to break out doesn't create a very compelling business case." He's right.
But he's also the proof that the demand exists. He's setting up SIP, migrating traditional telephony, and he needs a syncable address book across devices. That's not an exotic use case. That's... making phone calls.
CardDAV. It's an open standard from, what, two thousand eleven? Every major operating system supports it natively. iOS, Android, desktop clients, they all speak CardDAV. You can self-host a CardDAV server with something like Radicale, which is lightweight, or Nextcloud's contacts app. Your devices will sync to it just fine.
But Daniel didn't find a service. He found a protocol and a do-it-yourself option.
Right. And that's the gap. The protocol exists, the self-hosted software exists, but the managed API service that says "give us your contacts and we'll sync them everywhere" doesn't really exist as a standalone product. Because the business case is suppressed by the monolith.
The third friction point he mentioned was API access to documents. What's actually happening there?
This one's subtle. Google's APIs exist. The Docs API, the Drive API, they're documented and they work. But the developer experience is clearly an afterthought. You hit rate limits that are tuned for human clicking, not machine automation. The OAuth scope model is this sprawling mess where you have to request permissions that look terrifying to end users just to do basic things. And the APIs don't always expose what you'd expect.
Give me an example.
Say you want to programmatically generate a document from a template and then export it as a PDF. That should be three API calls. Instead, you're dealing with the Drive API for file management, the Docs API for content manipulation, and then you discover that certain formatting operations don't have API endpoints at all. You end up doing this hybrid thing where you use the API for what it can do and then... hope the rest works.
So the bundle is optimized for humans clicking, not for machines automating. And as soon as you want to build something on top of it, you feel the friction.
And that's the tell. Daniel mentioned that enterprises often scale off Google and Microsoft. They build custom layers on top. But they have dev teams. A small business or an individual power user hits the same API wall and has no team to throw at it.
Which brings us to the cost math. Eight to ten euros a month. He's been paying it so long it feels reasonable. Is it?
It's reasonable if you use everything in the bundle and it all works the way you need. But Daniel's own experience undermines that. He's using Google Groups as a routing workaround. He can't find a contact API that works for his SIP migration. He's hitting API friction when he tries to do programmatic things. So what's he actually paying for?
He's paying for the parts that work. Email delivery that doesn't require him to think about MX records. Drive storage that's just there. Calendar that syncs.
Right. But when you add up what you actually use versus what you're paying for, the value proposition gets murkier. Cloudflare Email Routing is free. A CardDAV server on a five-dollar VPS handles contacts. The only thing left in the bundle that's genuinely hard to replace is the integrated experience. The fact that your contacts inform your calendar, your calendar informs your docs, your docs inform your search.
That cross-product data graph you mentioned.
That's the thing. And that's what makes leaving hard. Not the individual apps. The glue between them.
So we've seen the cracks. Now the big question. Does agentic AI actually change the calculus?
This is where Daniel's thesis gets interesting. He's not just complaining about the monolith. He's arguing that the thing that made the monolith necessary is about to become cheap.
Walk me through that.
The reason Google Workspace exists as a bundle is that integration is hard. Making your contacts talk to your calendar, making your documents aware of your meetings, making search work across all of it. That integration layer is expensive to build and maintain. Google spent two decades and billions of dollars on it.
And Daniel's argument is that AI agents can now do that integration work.
Not can. Will be able to. And soon. Here's the shift. Previously, if you wanted a modular workspace, you'd need a dev team to build the integration layer. Your contact book needs to talk to your calendar, your calendar needs to talk to your document store, your document store needs to be searchable. Each of those connections is custom code. That's expensive.
So the bundle won because integration was the hard part, and bundling solved it by owning everything.
But if AI agents can handle the integration, the economics flip. Suddenly you can have a contact book from one provider, a document store from another, a calendar from a third, and agents that make them feel like a single product. The agents become the glue.
This sounds like the "primitives" concept he mentioned. Contact books, documents, calendar. Each as a well-defined API service, not a bundled app.
And that's the vision. You don't need a Google Docs clone. You need a document primitive. Something that stores documents, versions them, exposes an API. The agent handles the interface. You say "draft a proposal based on last week's meeting notes" and the agent pulls from your notes primitive, your calendar primitive, and your document primitive, and assembles the result.
So the agent is the UI. The primitives are just data stores with APIs.
That's the idea. And it's plausible now in a way it wasn't even two years ago. The cost of building your own document portal used to be a dev team. With agents, the integration layer becomes cheap. Not free. But cheap enough that the economics of the bundle start to look shaky.
Let's steelman the other side. What's Google's counterargument?
The data graph. Google's advantage isn't just the apps. It's that your contacts, calendar, documents, and search are all part of the same system. The system knows things implicitly that a modular setup would have to reconstruct explicitly. When you type someone's name in a Google Doc, it suggests their email because it knows you've emailed them. When you create a calendar event, it suggests the document you were just working on. That's not magic, it's the data graph, but it feels like magic.
And a modular setup with agents has to rebuild that from scratch.
Has to rebuild it, and has to do it well enough that users don't feel the seams. That's hard. The agents need to understand the relationships between your data across different services. They need to maintain context. They need to be fast. Google's had two decades to optimize this. A modular setup is starting from zero.
So the agentic AI thesis is plausible but not inevitable. The data graph moat is real.
It's real, but it's also... I think it's narrower than it looks. Most users don't actually use the deep integration. They use email, they use docs, they use calendar. The cross-product intelligence is nice but not load-bearing for most workflows. If agents can deliver the basics, the advanced integration becomes a feature people are willing to trade away for control.
Especially if they're hitting friction points like the ones Daniel described.
Right. The bundle's value proposition weakens every time you hit a wall. And Daniel's hit three walls just in the course of setting up SIP telephony. That's not a power user doing exotic things. That's someone trying to make phone calls and realizing the monolith doesn't play well with others.
What does a realistic path look like? He's not going to de-Google overnight.
He shouldn't. The realistic path is hybrid. Keep Workspace for the human-facing UI where it's good. Move the friction points to better tools. Use agents to bridge the gaps.
So what does that actually mean? Give me the concrete steps.
Email routing is the easiest win. If you're using Google Groups for routing, migrate to Cloudflare Email Routing. It's free, it operates at the DNS level, and it gives you proper control. The migration is maybe thirty minutes. Change your MX records, set up your forwarding rules, and you're done. You keep Gmail as your actual mailbox, but the routing layer is now outside the bundle.
And contacts?
Don't wait for an API service to appear. It's not coming. Self-host a CardDAV server. Radicale is lightweight, it's a single Python file essentially, you can run it on a Raspberry Pi. Nextcloud is fuller-featured if you want the whole suite. Your devices already support CardDAV natively. Set it up once, sync everywhere, and you've solved the contact problem without Google.
That solves the SIP migration issue too. His phone system can pull contacts from the same CardDAV server.
And that's the pattern. Identify the friction point, find the best-of-breed tool for that specific thing, and move just that piece. Don't try to replace the whole bundle at once. That's how migration projects die.
What about documents? That's the hard one.
Documents are the hardest to extract because the collaborative editing is good and hard to replicate. But here's where the hybrid model shines. Keep Google Docs for collaborative editing. But for programmatic document work, use something else. Markdown files in a git repository. A headless document store with an API. Let agents handle the conversion and synchronization.
You're not replacing Google Docs. You're adding a parallel document path for programmatic use, and letting agents keep them in sync.
That's the vision. And it's not science fiction. The pieces exist. The agents are what make it practical to glue them together.
Let's talk about Nextcloud for a second. Daniel mentioned it feels dated compared to Google Workspace. Is that fair?
It's completely fair. Nextcloud has the features. File storage, calendar, contacts, document editing with Collabora. It's a full suite. But the user experience feels like it's from five years ago. The gap isn't features. It's the intelligence layer.
That's where agents could close the gap.
Potentially. Imagine Nextcloud as the primitive store. Files, contacts, calendar, all self-hosted, all with APIs. And then an agent layer on top that provides the smart search, the contextual suggestions, the cross-app intelligence. The agent doesn't replace Nextcloud. It makes Nextcloud feel modern.
Has anyone actually built this yet?
Not as a polished product. There are pieces. People are experimenting with connecting AI agents to self-hosted infrastructure. But the integrated experience that makes Google Workspace feel cohesive doesn't exist yet in the open-source world. That's the gap Daniel's thesis is pointing at.
The question is whether that gap gets filled before Google and Microsoft absorb agents into their own bundles.
That's the race. Google's already adding AI features to Workspace. Microsoft has Copilot deep in three sixty-five. If they make their agents good enough, the bundle gets stickier, not less sticky. The window for a modular alternative might be narrower than we think.
But Daniel's point is that enterprises already scale off these platforms. Spotify, Airbnb, they run on Google Cloud but build their own productivity layers. The tools exist for large orgs. The question is whether agentic AI makes those same tools accessible to small orgs and individuals.
I think the answer is yes, with a caveat. The tools become accessible, but the integration work doesn't disappear. It shifts from writing code to configuring agents. That's easier, but it's not zero. You still need to know what you're doing.
The modular future isn't for everyone. It's for people like Daniel who are willing to do the configuration work in exchange for control.
At least for now. The holy grail would be a turnkey modular workspace where the agents handle everything and you just use it. Nobody's built that yet. But the primitives are there. The protocols are there. CardDAV, CalDAV, WebDAV, IMAP. These are mature, open standards. The missing piece is the agent that makes them feel like a single product.
That missing piece is what Daniel's betting on.
He's betting that the cost of building that integration layer is about to collapse. And I think he's right about the direction. The only question is timing.
Okay, so if the modular future is plausible, what do you actually do about it this week?
Three things. First, if you're using Google Groups for email routing, stop. Migrate to Cloudflare Email Routing. It's free, it's DNS-level, it's structurally better. The migration takes thirty minutes. You change your MX records, set up forwarding rules, and you're done. You keep Gmail as your mailbox. This is the lowest-hanging fruit and it solves a real problem immediately.
Second?
For contact storage, don't wait for the market to produce an API service. Self-host a CardDAV server. Radicale if you want minimal. Nextcloud if you want the full suite. Your devices already speak CardDAV. Set it up once and you've got syncable contacts across everything. This directly solves Daniel's SIP migration problem.
And third?
Start treating your workspace as modular even if you stay on Google. Identify the friction points. Move the ones with better alternatives. Keep the bundle where it delivers value. The mindset shift is the important part. Stop evaluating the bundle as a whole. Evaluate each component on its own merits.
The monolith's power is inertia, not excellence.
Once you start seeing it that way, the exit doors become visible. They were always there. You just weren't looking for them because the bundle trained you not to.
That's the practical path. But there's a bigger question lurking here.
Whether agentic AI actually delivers on the modular workspace promise, or whether Google and Microsoft just absorb agents into their bundles and the moat gets deeper.
Right. And I don't think we know the answer yet. The technology is moving fast enough that either outcome is plausible.
The thing that gives me hope for the modular side is the open protocols. CardDAV, CalDAV, IMAP, WebDAV. These aren't new. They're battle-tested. They work. The only thing that made the bundle win was the integration layer being expensive to build. If agents make that layer cheap, the protocols are already there waiting.
The thing that gives me pause is that most people don't want a modular workspace. They want their email and calendar and documents to just work. The bundle delivers that. The question is whether agents can deliver it without the bundle.
I think they can, but it'll take longer than the enthusiasts expect. Daniel's been in Workspace for nineteen years. The muscle memory is deep. A modular alternative has to be not just as good, but noticeably better, to make people switch. Being cheaper isn't enough. Being more private isn't enough for most people. It has to be better.
And "better" means the integration has to feel invisible. The moment a user sees the seams between their contact book and their calendar, they're back in the bundle.
That's the bar. Invisible integration across services that don't share a vendor. That's a hard problem. Agents make it possible. They don't make it easy.
But if it works, the implications go beyond productivity software. Data portability becomes real. Privacy becomes a choice rather than a tradeoff. The economics of cloud infrastructure shift from monoliths to ecosystems.
That's the deeper thing Daniel's getting at. He loves cloud computing. He's not trying to go back to local files and manual sync. He wants the cloud without the cage. The convenience without the lock-in. That's not an unreasonable thing to want.
It's what the cloud was supposed to be before the monoliths won.
Before the monoliths won. And if agentic AI does what Daniel thinks it will, we might get a second chance at that. A cloud that's modular by default, where you pick the best tool for each job and agents make them work together.
That's a future worth building toward. And in the meantime, move your email routing to Cloudflare and set up a CardDAV server.
Start small. The monolith didn't win in a day. It won't lose in a day either.
We want to hear from listeners who are experimenting with this. If you're building a modular workspace, if you've migrated off Google Groups for routing, if you're using agents to glue your own stack together, send us the details. The weird prompts are what drive this show.
Thanks to our producer Hilbert Flumingtop for keeping us on the rails.
This has been My Weird Prompts. Find us at my weird prompts dot com. Send your own prompts to show at my weird prompts dot com.
We'll be back soon.
