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.
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?
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.
The gap between model potential and real-world deployment isn’t a model problem — it’s an architecture problem. Explore how the four layers of the agentic enterprise close that gap.
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.
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:
This separation means Slack can optimize each layer independently, scaling delivery without touching business logic and vice versa.
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.
The Slack Engineering blog covers the distributed systems, infrastructure, and design decisions behind the platform. A technical read for architects who want to understand what they’re building on.
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.
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.
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.
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.
Watch this Slack School episode where you meet the new and improved Slackbot and learn how Slackbot can help you search, prep for meetings, and stay on top of what matters.
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, 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:
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.
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:
With A2A, these agents can coordinate autonomously, and the user just gets an answer. No tab-switching, no manual assembly.
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.
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.
Here are some resources to get you and your organization moving:
Get monthly curated content, technical resources, and event updates designed to support your Salesforce Architect journey.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。