Daniel sent us this one — and it's basically the Slack paradox. Slack was supposed to kill email. That was the pitch. Instead, we got two inboxes to check, the same bad communication habits just migrated wholesale, and now we're all more anxious and less clear. But here's the twist he's pointing at — while Slack faceplanted as an email replacement, it's quietly thriving as something nobody planned. The notification backbone for AI agents. The same platform that couldn't fix how humans talk to each other is accidentally perfect for how machines talk to humans. And that raises a real question about whether the notification layer we've all been hunting for was hiding in a chat app this whole time.
It's one of those ironies that's almost too neat, you know? The tool fails at its stated mission and then succeeds at a mission nobody had articulated yet. Slack launched in twenty thirteen, Salesforce bought it for twenty-seven point seven billion dollars in twenty twenty-one — this was supposed to be the thing that liberated knowledge workers from email hell. And it did not do that. A twenty twenty-three McKinsey report found knowledge workers spend sixty percent of their time on communication and coordination, and chat tools were contributing to the load, not reducing it. AI agent builders are treating Slack and Telegram and Discord as their front end. Not because anyone designed them for it. Because the channel-based architecture they already have happens to be exactly what machine-to-human notification needs.
The thing that made Slack bad for people made it good for bots. That's the core of it.
And I think unpacking why that's true tells us something bigger about the difference between human communication and machine communication. Human communication is messy, bidirectional, full of subtext and context and social anxiety. Machine-to-human notification is structured, unidirectional, scoped to a topic. Slack's architecture — channels, subscriptions, bots, APIs — is a terrible fit for the first thing and a beautiful fit for the second.
Like adopting a feral cat and discovering it's actually a very disciplined raccoon.
I don't know if that metaphor holds up under scrutiny, but I appreciate the energy.
It holds up fine. The point is, Daniel's question has two layers. Layer one — why did Slack fail at what it was sold to do? Layer two — why is it suddenly winning at something else? And the second layer only makes sense once you've really sat with the first.
And I think most of the conversation about Slack over the past decade has been stuck in layer one. It's either "Slack is great, you're using it wrong" or "Slack is a nightmare, delete it." Neither of those captures what's actually interesting now, which is that the architecture has found its real use case and it's not the one on the box.
Which means we should probably start with how it failed, because that failure is what reveals the architecture. And then we can get to why that same architecture is suddenly the darling of people building AI agents.
There's a specific comparison Daniel's pointing at that I want to get to — the purpose-built notification platforms like PagerDuty and Opsgenie. They were actually designed for alerting and incident response. But they're narrow. They handle incidents, not the full range of what an AI agent might need to tell a human. Slack's generality — the fact that it can handle "deployment complete" and "anomaly detected" and "approval needed" all in the same interface — that's the accidental superpower.
The single pane of glass everyone's been chasing, but for notifications instead of dashboards. Daniel's phrase, not mine. But he's right.
And I think the story of how we got here — from "Slack will replace email" to "Slack is the notification bus for AI" — is genuinely worth tracing. Because it's not just about one product. It's about what happens when you build a tool for one kind of communication and it turns out to be much better suited to a different kind entirely.
Let's trace it. Where do you want to start — the failure or the architecture?
Because the failure isn't just "people didn't use it right." The failure is structural. There are specific mechanisms that made Slack worse for human communication, and those mechanisms are exactly what make it good for machine communication. They're two sides of the same coin.
Walk me through it. What's the first thing that broke?
The first thing that broke is the most obvious one, and it's baked into the original pitch. Slack was sold as a replacement for email. "Kill email," "the end of the inbox," all of that. But in practice, it didn't replace anything. It just added another place you had to check. RescueTime did a study in twenty twenty-two — knowledge workers were toggling between email and Slack an average of sixteen times a day, and each switch cost about twenty-three minutes to fully refocus. That's not liberation. That's just more tabs open.
The promise was "one inbox" and the reality was "congratulations, you now have two inboxes and they both demand attention.
And the cognitive cost of that is measurable. It's not just annoying — it's a real productivity drain. The same twenty twenty-three McKinsey report we mentioned found that sixty percent of knowledge worker time goes to communication and coordination. Chat tools were supposed to shrink that number. They didn't. They grew it.
Which is almost impressive in a perverse way. The tool designed to reduce communication overhead somehow increased it.
That's the surface level of the failure. But I think the deeper thing — and this is what we'll dig into more — is that the same problems that made email miserable just migrated over. The CC culture became at-channel spam. The reply-all nightmare became fragmented threads across three different DMs. The anxiety of an unread inbox became the anxiety of a red badge with a number in it, except now people can see when you're typing.
The pathologies survived the transplant. The organ wasn't rejected — it just brought all its diseases with it.
That's a grim way to put it, but yes. And that's the setup for the interesting question. If all of that is true — and I think the evidence is pretty solid that it is — then why are AI agent builders now looking at Slack and Telegram and Discord and saying "this is exactly what we need"?
Because the things that make it bad for humans are irrelevant to machines. A bot doesn't care about typing indicators. It doesn't get anxious about read receipts. It just needs to deliver a structured message to the right channel at the right time. And Slack's architecture — channels, topics, subscriptions, bot APIs — that's basically a notification bus with a chat history attached.
That's the pivot. And it's worth noting this isn't theoretical. Telegram launched its Bot API in twenty fifteen — inline queries, custom keyboards, deep linking. It became the default platform for crypto trading bots, then for all kinds of automated notification systems. Discord followed the same path. Slack's been building out its bot and API surface for years. None of them set out to be the notification layer for AI agents. But they built the plumbing, and now the agents are moving in.
The failure narrative and the success narrative are the same story. Slack couldn't fix human communication because human communication is messy and social and full of subtext. But machine-to-human communication is none of those things. It's structured, scoped, and one-directional. And it turns out the channel model is basically purpose-built for that, even if nobody realized it at the time.
That's the frame I want to carry through the rest of this. The failure isn't just a cautionary tale. It's the thing that reveals why the architecture actually works — just not for the thing it was sold to do.
Let's get into the failure mechanisms. Because you said they're structural, not just cultural. Walk me through what actually broke.
The first structural failure is the one we just touched on — the "more places to check" problem. But I want to put numbers on it because the scale of the damage matters. RescueTime's twenty twenty-two data showed sixteen context switches a day between email and Slack. Each switch costs roughly twenty-three minutes to get back to full cognitive focus. That's about six hours of lost deep work per day. And Slack wasn't replacing anything — it was layering on top.
So the tool that was supposed to give you more time for actual work was eating most of the workday just in switching costs.
That's just the toggle cost. The second mechanism is what I think of as the mirroring problem. Every bad email behavior found its Slack equivalent, and in some cases the Slack version was worse. Email had the CC spiral — Slack gave us at-channel and at-here, which is the same impulse but with the added force of real-time interruption. Email had reply-all disasters — Slack gave us threads that splinter across channels and DMs so you're having the same conversation in three places and nobody knows which one is authoritative.
Covering the covers.
And email had the anxiety of the unread count. Slack added typing indicators. The green dot. So now you're not just anxious about what's waiting for you — you're anxious in real time, watching someone type a response and then stop typing, and your brain fills in the gap with the worst possible interpretation.
The "someone is typing and then they aren't" as a new category of workplace dread. That's not a feature, that's a psychological experiment nobody consented to.
The research backs this up. A twenty twenty-four study in the Journal of Organizational Behavior found Slack users reported twenty-three percent higher stress levels than email-only users, controlling for workload. That's not a small effect. That's a significant, measurable increase in human misery directly attributable to the platform's design choices.
It's not just that Slack failed to reduce communication overhead. It actively increased stress while doing it. The cure was worse than the disease.
Which brings me to the third mechanism, and I think this is the deepest one. Email, for all its flaws, had an implicit asynchronous norm. You sent an email, you expected a response in hours or days. Slack's entire interface is built around real-time presence. Notifications, online status, typing indicators — all of it signals "I am here, you are here, respond now." It eroded the psychological safety of asynchronous communication without anyone making a formal policy change. The design itself was the policy.
The architecture trained people to expect immediacy, and then the culture formed around that expectation. It's not like anyone sat down and said "from now on, all responses must be within ninety seconds." The tool just made that feel like the norm.
And this is where I think the Jason Fried critique from twenty sixteen is worth revisiting. He wrote that internal memo at Basecamp, declared Slack "the new email," and banned internal chat at the company. People thought he was being dramatic. But his argument was that Slack optimized for speed and visibility at the expense of attention and depth. It was built to deliver messages, not to help people digest them. And a decade later, that diagnosis holds up.
The failure isn't that Slack is a bad product. It's a very good product for a specific thing. The failure is that the specific thing it's good at — fast, visible, real-time message delivery — turns out to be actively harmful for how humans actually think and work.
That's the structural diagnosis. Slack optimized for the sender. Every feature — notifications, channels, threads, reactions — is designed to make it easier to get a message out and harder to ignore one. The receiver's cognitive experience was never the design target. And that's not a bug in the implementation. It's a property of the architecture.
Which is why "better Slack discipline" never actually fixes it. More channels, better naming conventions, stricter moderation — those are bandaids on a design that fundamentally privileges the sender over the receiver.
And I think that's the cleanest way to frame the failure. Slack is sender-optimized. Human cognition needs receiver-optimized tools. Those two things are in direct tension, and Slack picked one side.
Here's where the story flips. That sender-optimized architecture — the thing that made Slack a nightmare for human conversation — is exactly what makes it work for machine-to-human notification. Because when the sender is an AI agent, you want sender optimization. You want reliable delivery, channel-based routing, structured messages, subscription management. The things that felt oppressive when they came from your coworker are just good engineering when they come from a bot.
The same design choices that punished the receiver when the sender was another human become neutral infrastructure when the sender is a machine. The bot doesn't have ego. It's not going to get passive-aggressive if you mute its channel.
And AI agent builders figured this out fast. You've got agents doing code review, monitoring deployments, flagging anomalies, requesting approvals. Each of those needs to reach a specific human or team at a specific moment. Building a custom notification UI for every agent is insane. But Slack channels already solve the routing problem — an agent posts to the deployment channel, the security channel, the approvals channel, and the right people are already subscribed.
What Daniel's really pointing at is that Slack accidentally built the notification bus everyone's been looking for, and nobody noticed because they were too busy complaining about at-channel spam.
The Telegram story makes this even clearer. Telegram launched its Bot API in twenty fifteen — inline queries, custom keyboards, deep linking. It wasn't built for AI agents. It was built because Pavel Durov wanted a platform where bots could do useful things. But that API turned out to be so well-designed for automated messaging that crypto trading bots colonized it first, then AI agent notifications followed. By the time anyone was seriously building autonomous agents, Telegram already had a decade of bot infrastructure ready to go.
Which means the first-mover advantage in the agent notification space didn't go to the company that planned for it. It went to the messaging app that happened to build a good bot API for completely unrelated reasons.
Discord followed the same path. Their bot ecosystem grew out of gaming communities wanting moderation tools and music bots. But the architecture — servers, channels, role-based permissions, webhooks — maps almost perfectly onto what you'd want for routing agent notifications to the right human teams. It's an accident of design, but it's a very productive accident.
What does this actually look like in practice? If I'm building an AI agent today and I want to use Slack as my notification layer, what's the pattern?
The simplest version is the "human in the loop" pattern. An agent is doing something that requires human judgment at a decision point — say it's reviewing expense reports and it finds one that's ambiguous. It posts to the finance approvals channel with a structured message: amount, category, what's ambiguous, what it recommends, and two buttons — approve or reject. A human sees it, clicks one, the agent continues. No custom UI. No new tool to log into. It's just a Slack message with interactive components.
That works because Slack already has the subscription model. The right people are already in the finance approvals channel. They already have notifications configured. The agent doesn't need to know who they are or how to reach them — it just posts to the channel and the platform handles delivery.
And that's the thing that purpose-built notification platforms like PagerDuty and Opsgenie don't do as well. They're excellent at what they're designed for — incident alerting with escalation policies, on-call schedules, deduplication. If your server goes down at three in the morning, PagerDuty is the right tool. But an AI agent doesn't just produce incidents. It produces status updates, approval requests, anomaly flags, summary reports, suggested actions. PagerDuty's model is narrow — it's built around the concept of "something is broken and someone needs to fix it.
PagerDuty handles the "everything is on fire" use case beautifully, but an AI agent's output is mostly "here's something you might want to look at" and "can you confirm this before I proceed." Different category entirely.
PagerDuty knows this. They announced AI-native alerting features in early twenty twenty-five, which is basically them saying "we see the same trend and we want in." But their architecture is still incident-centric. Escalation policies, on-call rotations, acknowledged versus resolved states — all of that assumes the notification is about something broken. An agent saying "deployment complete, all tests passed" doesn't need escalation. It just needs to land in the right channel.
Slack's weakness — the fact that it handles everything from "lunch order" to "production outage" in the same interface — becomes its strength when you're routing diverse agent notifications. PagerDuty is a specialized tool for a narrow problem. Slack is a general-purpose notification surface that's already where the humans are.
That last part is the killer feature. The humans are already there. You don't have to onboard anyone to a new platform. You don't have to convince teams to install another app or check another dashboard. The agent just shows up in Slack where everyone already lives, and the notification is just another message in a channel they already watch.
Which brings us to the "single pane of glass" irony Daniel mentioned. Enterprises spent years and millions of dollars trying to build unified dashboards for all their metrics and alerts. And the answer wasn't a dashboard at all. It was a chat app with a bot API.
The dashboard dream was always a little misguided, honestly. Dashboards are pull-based — you have to go look at them. Notifications are push-based — they come to you. And for the range of things an AI agent needs to communicate, push is the right model. You don't want to have to remember to check whether your agent found an anomaly. You want it to tell you.
The architecture that failed for human conversation — channels, notifications, real-time delivery, sender optimization — turns out to be basically ideal for the notification layer between autonomous agents and the humans who oversee them. The same thing that made your coworker's at-channel ping feel like an intrusion makes your agent's anomaly alert feel like good engineering.
I think that's the deepest point here. We spent a decade judging Slack by whether it fixed human communication. It didn't. But we may have been judging it by the wrong standard. The thing it actually built — a channel-based, API-accessible, subscription-driven notification fabric — is turning out to be far more valuable than "better email" ever would have been.
What do we actually do with this? I think there are three things worth pulling out that change how you should think about your tools tomorrow.
All right, give me the first one.
If you're building an AI agent today, do not build a custom notification UI. Just don't. Slack, Telegram, Discord — they already solved the routing problem, the subscription problem, the delivery problem. You bolt a custom dashboard onto your agent and now you've got two problems: you're maintaining a UI instead of improving your agent logic, and you're asking users to check yet another place. Put your agent's output in the channels where people already live.
The engineering advice is basically: stop building notification infrastructure and start using the notification infrastructure that accidentally already exists.
Focus your effort on the agent's reasoning, its decision quality, its ability to know when to escalate. The delivery layer is a solved problem. Don't rebuild it.
What's the second one?
This one's for everyone drowning in Slack noise. Recognize that the platform is optimized for senders, not for you as a receiver. It will not fix itself. You have to architect your own attention. Schedule do-not-disturb blocks. Turn off typing indicators if the platform lets you. Treat notifications as something you control, not something that controls you.
The tool won't protect your focus. You have to build the fence yourself.
The fence works. The people I know who've actually tamed Slack didn't do it with better channel naming conventions. They did it by treating every notification as an opt-in decision. If a channel doesn't earn its place in your attention budget, mute it. The sender's urgency is not automatically your emergency.
The third takeaway?
The single pane of glass everyone's been chasing for notifications already exists. It's your chat app. Stop shopping for another dashboard. Route every agent, every monitor, every automated alert through one channel-based platform. The integration surface is already there, and more importantly, the humans are already there. You're not going to get adoption on yet another tool. You'll get adoption on the tool everyone already has open.
Which means the broader point is: pay attention to what your tools are accidentally good at. Slack's creators set out to replace email. They failed at that. But they accidentally built a notification fabric that AI agents are now moving into. The most interesting use case was never on the roadmap.
Which leaves us with the open question, though. Does this model actually scale? Right now, an agent posts to a channel and a human reads it. That works when you've got three agents and five channels. What happens when you've got fifty agents, each producing dozens of notifications a day, all routed through the same chat interface?
Then you've just rebuilt email, but with bots. Congratulations, you've come full circle.
That's the risk. The chat-based notification model works precisely because agent traffic is still relatively low-volume. As agents become more autonomous and more numerous, the same overload dynamics that broke human-to-human Slack could break machine-to-human Slack too. A hundred agents all posting "task complete" to your general channel is just a new flavor of the same problem.
The next evolution might not be a better chat app at all. It might be something that separates notification from conversation entirely. A protocol layer — agents write to a bus, humans subscribe to topics on the bus, and the delivery mechanism is independent of any specific platform.
A notification bus. Not Slack, not Telegram, not Discord — a protocol that any platform can implement and any agent can write to. The agent doesn't know or care whether you're reading its messages in a chat app, an email client, or a dedicated notification surface. It just publishes to a topic, and your subscription preferences handle the rest.
Which is basically what email protocols did for human communication forty years ago, except purpose-built for machine-to-human notification. SMTP for agents.
Nobody's built it yet. Which is the interesting thing. We're in this moment where the accidental solution — Slack and Telegram and Discord — is working well enough that nobody's feeling the pressure to build the intentional one. But the pressure's coming.
The final thought is really that the tools we build for ourselves often end up serving machines better. Slack's second life as an agent notification platform is a reminder that the most interesting use cases are the ones nobody planned for. And the next interesting use case is probably something nobody's planning for right now either.
Now: Hilbert's daily fun fact.
Hilbert: The term "tidal bore" shares a linguistic root with the Old Norse word "bára," meaning wave — but in South Sudan's Sudd wetlands, Cold War era hydrologists mapping the White Nile's seasonal pulses noted that the local Nuer term for the river's surge translates more precisely to "the water that walks backward.
The water that walks backward. That's actually quite good.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you want to send us your own questions — or tell us we're wrong about Slack — email the show at show at my weird prompts dot com. We'll be back with another one soon.
