The interface your users need isn’t a better dashboard. It’s already in their pocket.

For enterprise architects, the challenge has always been building powerful systems that people actually use. The agentic era has brought this delicate balance even more to the forefront as how we work has fundamentally changed: Data entry is increasingly becoming an agentic responsibility. Humans are spending less time entering data and more time making decisions. Agents are doing the tedious work.

What do well-architected systems look like, when the way that people are using them has changed so drastically? Or maybe we should ask the more pointed question: Does the agentic end user need the Lightning Experience?

Not all organizations are fully agentic yet. But as more work shifts to human-agent collaboration, the design patterns you’ve relied on need a second look. Your users’ needs are more collaborative and less data-centric than they were when those patterns were written. The surface they work in needs to reflect that.

Our vision for the future of work is based in conversational, vastly connected systems like Slack. It’s a collaborative view of work with humans at the center. As an organization becomes increasingly agentic, we believe the need to give end users a chat-based experience that simplifies the process of working together and with agents will be critical. Slack does just that.

More than just a digital water cooler, Slack is the main surface for the agentic enterprise. Slack allows you to see your data while having a productive conversation around it. Slackbot sits at the center of that experience, giving users and agents a shared place to act on what they see. Emerging protocols like Model Context Protocol (MCP) and Agent-to-Agent (A2A) extend that further, connecting Slack to systems your agents need to reason across.

Architecting the agentic enterprise: How Slack is becoming the conversational super app

The idea of a super app (a term introduced in 2010 by Mike Lazaridis, the cofounder and then-CEO of BlackBerry) may have started out as a closed ecosystem of many apps that would provide a “seamless, integrated, contextualized, and efficient experience.”  Since then, however, it has evolved into “an application that provides many different application services through one integrated platform interface, eradicating the need for managing and launching multiple applications” (Capgemini’s TechnoVision 2026 report).

The Capgemini report observes that “chat is the new super app,” envisioning AI-augmented chat systems, combined with open protocols like MCP and A2A, transforming the familiar interface into an unexpected but undeniable super app.

For the enterprise architect, the question becomes: which tool is positioned to be that super app for your organization?

Salesforce agentic enterprise architecture

With a clear architectural framework, Salesforce organizes the Salesforce agentic enterprise across four distinct layers:

1. Slack: System of engagement

2. Agentforce: System of agency

3. Customer 360: System of work

4. Data 360: System of context

Underpinning all four layers is a Trust layer spanning every major LLM ecosystem — including OpenAI, Anthropic, Gemini, LLaMA, and open-source models — making the architecture deliberately model-agnostic.

In this agentic enterprise architecture, Slack sits at the top as the primary surface where humans and agents meet, rather than a communication tool existing alongside your enterprise applications. This positions Slack as the chat super app: one simple conversational interface to a network of complex systems.

This means the interface your end users interact with is no longer an application built to display data — it’s a conversation layer built to orchestrate it. Every system below Slack becomes a provider. Every interaction above it becomes an intent. For architects, this shift changes what applications must expose: moving from data and UI surfaces to executable capabilities designed for orchestration, and viewing the intended consumers as not only human end users, but  both humans and software agents.

The goal is removing the cognitive overhead your end users carry today. Context-switching between a CRM, an inbox, a project tracker, and an analytics tool just to make one decision is neither efficient nor effective. The well-architected agentic enterprise collapses that into one surface. And because the architecture is deliberately open, it works with whatever your organization is already running.

Understanding the architecture powering Slack

To understand why Slack can serve as the foundation of the agentic enterprise, it helps to understand what’s happening under the hood. The architectural foundation of Slack is deliberately lean; it is designed for reliability, speed, and horizontal scale.

Decoupling the “thinkers” from the “talkers”

At its core, Slack separates application logic from real-time delivery. This decoupling is what allows it to handle billions of messages without sacrificing performance:

• Web App Servers (The Thinkers): Written in PHP/Hack and running on HHVM, this tier handles the “thinking” — business logic, authentication, database writes, and message validation. It processes HTTP request/response cycles and acts as the authority on what is true.
• Real-Time Messaging Servers (The Talkers): Written in Java, these stateful servers handle the “talking” — managing full-duplex WebSocket connections to fan out messages, typing indicators, and presence updates to connected clients instantly.

This separation means Slack can optimize each layer independently, scaling delivery without touching business logic and vice versa.

Designing for scale: sharding, Vitess, and the thundering herd

Customer data is partitioned using the workspace as the atomic unit of tenancy, mapping workspaces to specific MySQL database shards and search indexes. As organizations scaled to hundreds of thousands of users, Slack evolved its data layer by adopting Vitess on top of MySQL. Vitess encapsulates shard routing logic and allows Slack to flexibly partition data using channel_id as the shard key, minimizing hot spots and supporting automatic failovers.

One of the trickiest real-time messaging challenges is the “thundering herd” problem, when thousands of users reconnect simultaneously after a network drop, overwhelming the back end with requests for workspace state. For Slack, the answer to this problem is Flannel, an application-level edge query engine backed by cache. Deployed globally at edge locations, Flannel enables lazy loading by serving only the essential data clients need at boot time, drastically reducing connect times and protecting core databases from cascading failures.

The architectural takeaway: Slack isn’t a monolith. It’s a carefully decoupled, edge-cached, horizontally scalable system built to stay out of your way, so the intelligence layered on top of it can take center stage.

Understanding the role of Slackbot in the system of engagement

In no other feature does this intelligence layered on top of Slack shine through more than in Slackbot, an agent that is truly native to Slack. With its new AI-powered version announced in October 2025, Slackbot has transitioned from a simple tool that delivered system notifications into the ultimate teammate.

Much more than a novelty layer bolted onto an existing product, Slackbot is architecturally different. It is an agent that is native to the context where work is already happening. Slackbot has the ability to search Slack to gather context and to serve as a conversational interface to Agentforce and other apps and systems across your enterprise, helping coordinate complex, multistep tasks with ease.

Gathering context

Most enterprise AI tools ask users to recreate context every single time: paste in the email thread, summarize the background, explain the situation. Slackbot operates from ambient context — conversations, files, canvases, channel history, and connected Salesforce data. The gap between what you need to ask and what the agent already understands is dramatically narrower than with any disconnected AI tool. As highlighted in the 2026 TechnoVision report, the power of the chat super app lies precisely in the richness of the context it can draw on, and few enterprise platforms have the depth of organizational context that Slack accumulates naturally over time.

Such large amounts of message history could, however, hinder efficient searching efforts and context gathering. This is why every message in Slack passes through a post-message processing pipeline within milliseconds of delivery: indexing, notifications, event routing, and crucially, the preparation of that content for later retrieval. This means that by the time you ask Slackbot a question, the unstructured data produced by months of team conversations has already been processed, structured, and made queryable. As such, Slackbot does not need to do slow, expensive synchronous extraction when you ask a question. The groundwork has already been done. This is what makes Slackbot responses immediate and contextually grounded rather than generic.

Taking action

The real architectural significance of Slackbot goes beyond retrieval. Slackbot can take action — like creating records and logging interactions in Salesforce or managing calendar events in Google — with a human-confirmation step before anything is written back, except where permissions or policy have pre-authorized the action. This design pattern keeps humans in the loop, not by slowing everything down but by making the agent’s proposed action visible and confirmable in the same surface where the conversation is already happening.

Under the hood, this follows the “tools in a loop” pattern where the agent receives a user request, identifies the tools it needs to fulfill it, calls those tools in parallel where possible, feeds the results back into its reasoning loop, and repeats this until it has enough to respond. Keeping the human at the helm, Slackbot requires explicit human approval before execution (that is, before modifying external systems). The agent suspends execution, surfaces an approval prompt directly in the conversation, and only continues once the user confirms.

This way of keeping the user in the decision seat — without adding friction as the approval prompt appears inline, in the same conversation where the request was made — is what makes Slack so effective as the system of engagement. The same interface your users already trust has seamlessly been extended. Perhaps the most underappreciated architectural decision Salesforce made in building Slack as the system of engagement is what we chose not to build: a new interface.

Enabling easy adoption

Enterprise AI tools frequently struggle with adoption not because the intelligence is lacking but because the interface is foreign. A new panel, a new workflow, a new mental model — and suddenly your rollout plan depends on change management rather than value delivery. Slackbot sidesteps this problem entirely by building on infrastructure that already exists: the DM channel and the thread.

By default, every Slack user already has a direct message channel with Slackbot, created automatically at onboarding. Conversations with Slackbot are implemented as threads within that channel; this is the same threading model users already understand from every other conversation in Slack. Responses stream in as ordinary Slack messages, formatted with the same Block Kit components that power notifications, app messages, and workflow outputs throughout the platform. Consequently, when Slackbot was launched, there was no new UI to learn. 

This is a lesson worth carrying into your own agentic architecture work. The interfaces your users trust are the ones they already use. Rather than building something new, consider making something familiar dramatically more capable. 

Powering the agentic super app: MCP and the A2A protocol

The ability of Slackbot to surface information and take action is powerful on its own, but the real unlock for architects is what happens when you extend that intelligence across your entire ecosystem. That’s where two emerging, standardized protocols come in: MCP and A2A.

These aren’t Slack-specific technologies. They’re open infrastructure that any platform can adopt, and their adoption by Slack signals a meaningful shift in how enterprise systems will talk to each other. MCP standardizes how agents work with other systems. A2A is focused on how agents work with other agents.

MCP: connecting agents to your data

MCP, open-sourced by Anthropic, provides a standardized way for AI assistants to securely connect to the systems where an organization’s data lives. 

Think of it as a universal adapter. Instead of building a custom integration for every tool in your stack, MCP lets AI models:

• Discover available tools, actions, and data sources dynamically
• Pull the right context into the interface to execute user intent
• Operate across back ends without hardcoded, point-to-point connections

For architects, MCP is the answer to the integration sprawl problem. Rather than managing a web of bespoke connectors, you expose your systems via MCP and let the agent determine what to call and when.

A2A: orchestrating multi-agent workflows

As workflows grow in complexity, single agents give way to multi-agent ecosystems. The A2A protocol allows specialized agents to coordinate, delegate, and exchange structured tasks with one another behind the scenes.

Imagine a user asking in Slack: “Summarize last quarter’s pipeline and flag any deals at risk.” That single intent might require:

• A CRM agent querying Salesforce
• A data agent pulling from your analytics warehouse
• A summarization agent synthesizing the output

With A2A, these agents can coordinate autonomously, and the user just gets an answer. No tab-switching, no manual assembly.

What this means for your architecture

By leveraging MCP and A2A, Slack enables developers to build headless agents and seamlessly integrate AI systems, such as Agentforce, Claude, or Perplexity, directly into the flow of work. The key design principle: your apps become behind-the-scenes providers, and the agent becomes the primary interface.

For architects, the implication is clear. The systems you build today need to be ready to be discovered by agents, not just navigated by humans. That means clean APIs, well-structured data, and a bias toward interoperability.

Where to start?

The shift from dashboard-centric to conversation-centric enterprise design isn’t coming. It is already here. The Slack architecture demonstrates that a lightweight, decoupled messaging layer, combined with powerful agentic protocols, can become the operating environment for intelligent work.

For architects, the question isn’t whether to engage with this paradigm. It’s where to begin.

Key takeaways

• Slack features a decoupled architecture (thinkers + talkers, Vitess, Flannel) that provides a reliable, scalable foundation for agentic workflows.
• The Slackbot architecture (context gathering and human-approved action taking in a familiar UI) represents the missing piece to put the super app into practice and build an agentic system of engagement.
• MCP gives AI agents a standardized way to discover and connect to your organization’s systems and data.
• A2A enables multi-agent collaboration, letting specialized agents delegate and coordinate across complex workflows.
• The future of enterprise UX is conversational: apps become providers, and agents become the interface.

Start your Slack journey

Here are some resources to get you and your organization moving:

• Slack Platform Documentation: Explore the building blocks for Slack apps and agents
• Slack Developer Relations Blog: Architecture patterns and developer stories
• Agentforce + Slack: See how Agentforce integrates with Slack for real-world agentic workflows
• MCP Documentation: Deep dive into the Model Context Protocol
• A2A Protocol: Explore the Agent-to-Agent spec
• Slack Community: Meet other experts
• Slack.dev: Source for all the developer resources you’ll need