Slack vs. Teams Is the Wrong Question for the AI Era

I was thinking about whether Slack or Teams is better positioned for the age of AI agents. Neither is. Here's why.

The Bus vs. The Control Plane

Slack treats a workspace like a bus architecture. Channels are composable surfaces. Agents are just another peripheral that plugs in. An agent's output lands in the same stream as a human's. No context switch, low ceremony, great DX.

Teams is the lobby of the Microsoft building. Worse as a standalone messaging tool, but it's the session layer for Copilot across the entire M365 graph: files, meetings, email, calendar, Planner, Loop. The AI play here isn't "agents in chat." It's agents orchestrating across every surface you already live in. Teams isn't the bus. It's the control plane.

So the question resolves to: are AI agents primarily conversational participants (Slack's bet) or workflow orchestrators (Microsoft's bet)?

Both bets are probably right. And that's the problem, because neither tool is built for either model cleanly.

Three Problems Hiding Behind One UI

The transport layer is fine. Messages, channels, threads, presence. This is plumbing. Agents don't need a new pipe. They need a better API contract. The issue isn't that these tools can't carry agent messages. It's that they have no semantic distinction between "human said a thing" and "agent performed an action." Everything gets flattened into chat bubbles. It's routing both data and control signals over the same wire with no header to tell them apart.

The interaction model is wrong. Chat is a serial interface. Agents operate in parallel, asynchronously, and often silently. Forcing agent output into a chronological message stream is printing database query results into a group text. You need a dual-pane model: conversation stream for humans, structured action/state pane for agents. Notion is closer to this than either Slack or Teams. Accidentally.

The coordination primitive doesn't exist. Neither tool has a native concept of agent handoff, agent workspace, or shared agent context. When three agents need to collaborate on a task today, they do it through human-readable messages in a channel. That's two databases synchronizing by emailing each other CSVs.

The Sharpest Way to See It

I wrote about CQRS (Command Query Responsibility Segregation) in a previous post — the idea that systems which change state (commands) and systems which read state (queries) have different requirements and should be separated. It makes this problem precise.

Slack and Teams violate this completely. The command path (agent takes action, modifies state) and the query path (human reads what happened, decides next steps) have different consistency, latency, and representation needs. Both get smashed into a single mutable chat stream.

The consequences are concrete:

• No draft-commit separation. An agent writes directly to the shared human-readable stream. There's no review gate. No staging area. No undo.
• No projection layer. A human and an agent supervisor should see different views of the same event. Right now, they see the same chat bubble.
• No trust boundary. If you take CQRS seriously as a trust framework, separating who can write from who can read, separating intent from execution, the current model is dangerous at enterprise scale.

The analogy: a relational database doing both OLTP and OLAP on the same tables isn't "broken." It needs a read replica and a different query surface. The storage engine is fine. Same thing here.

Fork, Don't Re-Architect

The tempting conclusion is that Slack and Teams need to be re-architected for AI. They don't. They need to be forked.

Re-architecting a tool with 300 million users is performing heart surgery on a marathon runner mid-race. The install base is the product. Break the human UX to serve agents, you lose the humans.

Instead: build an agent-native layer that sits alongside the chat product, not inside it. Think of the difference between the Excel UI and the Excel calculation engine. Same data model, completely different interaction surface. The chat product becomes one view into a shared workspace, not the workspace itself.

The Missing Piece

The real gap isn't Slack. It isn't Teams. It's not even the command side; some platforms are already building structured stores for agent decisions and context. The gap is the projection layer: the set of distinct read surfaces that let different consumers (humans, auditors, dashboards, other agents) see and act on the same agent action in different ways.

Most agent-enabled products today still project into a single surface. The agent's action, the human's notification, the approval mechanism, and the audit trail all collapse into one chat message or one card. That's every microservice writing directly to the frontend database. It works for single-agent demos. It breaks when you need multi-user approval, multi-surface delivery, or agent-to-agent handoff.

The projection layer between agent decision stores and human surfaces (Slack, Teams, email, Notion, dashboards, other agents) is the product to build. Those surfaces are all just views. Different materializations of the same stream of agent actions and human decisions.

Whoever builds that layer owns the value. Slack and Teams become interchangeable front-ends. Which is exactly what neither Salesforce nor Microsoft wants to hear.

This Is Already Starting to Happen

How far along are agent platforms on this? Further than you'd expect in some areas, behind in others. The best agent-enabled products already have structured backends for agent memory, decision history, and context. Audit trails are landing in event stores. Tracing and debugging views are being built. The command side is emerging.

But the projection layer is lagging. In most systems, the agent's recommendation and the human's approval still live on the same surface: a chat message, an Adaptive Card, a notification with a button. The approval concept and the notification are the same object.

This works for a single user receiving a single recommendation. It breaks when:

• Multiple users need to weigh in on the same recommendation
• The same recommendation needs to be approvable from chat, a dashboard, a mobile notification, or by another agent
• The agent lives in a shared channel where many users can talk to it conversationally

Approval is a command. Notification is a query. They're on the same surface today. That's the CQRS violation in miniature, and it's the one that matters as agents go from single-user demos to multi-user, multi-surface coordination.

The Bottom Line

Slack vs. Teams is a consumer preference question masquerading as a platform strategy question. The AI era doesn't need a better chat tool. It needs the projection layer behind all chat tools: infrastructure that treats human communication as one view into a stream of agent decisions, not the system of record.

The command side is being built. The read surfaces are still stuck in single-projection mode. That's where the architecture breaks, and where the opportunity is.