Slack, whose Slackbot assistant has been a fixture of workplace messaging for more than a decade, is rethinking the bot from the ground up. Instead of responding to simple commands or keyword triggers, the next generation of Slackbot is designed to understand intent, assemble context from across channels and threads, and orchestrate multi-step workflows using AI models and connected tools.
In this email Q&A, Kurtis Kemple, Slack’s senior director of developer relations, explains why incremental upgrades to the original bot architecture were no longer enough, how the company rebuilt Slackbot for what it calls the “agentic era,” and what the shift means for developers building AI-powered workflows inside Slack.
Slackbot has existed for over a decade. What signaled to the engineering team that it was time for a fundamental architectural rethink rather than incremental upgrades?
The inflection point really came when we started seeing a disconnect between what our rule-based, command-driven bot could do and how people were beginning to interact with AI in their everyday work. Users weren’t just looking for keyword responses anymore. They wanted Slackbot to understand intent, maintain context across conversations, and actually follow through on complex tasks.
We realized pretty quickly that you can’t just layer AI capabilities onto a decade-old bot architecture and expect it to deliver true agentic behavior. The old system was fundamentally designed around simple input-output patterns: You type a command, the bot executes a predefined action.
But agentic AI requires something completely different. It needs to reason, orchestrate multiple tools, maintain state across interactions, and adapt based on context. This meant rethinking core architectural assumptions from the ground up: how we handle state management, how we orchestrate workflows, how we enable extensibility for developers building on the platform.
This new foundation enables Slackbot to do things like understand cross-channel context, orchestrate multi-step workflows, and integrate with external tools, capabilities that simply weren’t architecturally possible in the old system. The technical debt wasn’t just in the codebase. It was in the fundamental model of what a bot could be. Once we recognized that, incremental upgrades weren’t going to cut it. We needed to rebuild with agentic behavior as a first-class design principle, not a feature bolted on later.
When you talk about “engineering for the agentic era,” what does that mean in practical terms?
In practical terms, it means fundamentally changing how we think about the role of AI in software systems. Instead of treating AI as something that responds to a single query and then disappears, agents need to be built as persistent participants in work. They need to be there alongside you, understanding context over time, and proactively helping you get things done.
From an engineering perspective, this shift is massive. You’re no longer just building systems that execute commands; you’re building systems that can reason over context, decide what to do next, and take action on a user’s behalf. That requires a completely different architecture.
One of the biggest changes is moving away from single-prompt interactions to building robust orchestration layers. Think about what happens when someone asks Slackbot to “catch me up on what I missed.” That’s not a single LLM call. It’s a coordinated workflow that needs to retrieve relevant messages, understand which conversations matter most, synthesize information from multiple sources, and present it in a useful way. The orchestration layer is what coordinates all of those prompts, tool calls, and actions into a coherent experience.
It also means designing for extensibility from day one. Developers building on our platform need the ability to define their own agent behaviors, connect their own tools, and orchestrate their own workflows without having to rebuild the underlying infrastructure for reasoning, state management, and reliability. That’s what engineering for the agentic era really looks like – building platforms that make sophisticated agent behavior accessible and scalable.
Agentic systems rely heavily on context. How did Slack rethink context retrieval and management in the new architecture?
Context is really the foundation of useful agentic behavior, and one of our biggest realizations was that the old model, single-message context or even channel-scoped context, just doesn’t reflect how work actually happens. Work unfolds across channels, threads, DMs, and time. Someone might mention a project in a standup thread on Monday, share a doc in a channel on Wednesday, and then ask you about it in a DM on Friday. For an agent to be genuinely helpful, it needs to understand those connections.
So we had to rethink context retrieval from the ground up. That meant building systems that can pull relevant information across conversations and timeframes, but doing it in a way that’s both performant and respectful of Slack’s core commitments around trust and privacy. Users need to know exactly what data an agent can access and why. There’s no room for ambiguity there. Every context retrieval decision is bound by the same permissions and privacy controls that govern human access in Slack.
The other critical piece was making context composable. Agents need to be able to reason over the right information at the right moment, not everything all at once, and not so rigidly that they break when the conversation shifts. We designed context management so that agents can dynamically assemble what they need: maybe it’s recent messages from a specific channel, maybe it’s a user’s saved items, maybe it’s information from an integrated tool. The orchestration layer decides what’s relevant based on the task at hand, which keeps agents both flexible and interpretable rather than brittle or opaque.
Here’s what that looks like in practice: if someone asks “what’s the status of Project Phoenix?” Slackbot can now pull together the launch announcement from #announcements, the latest updates from the project thread, and relevant DMs, even if “Project Phoenix” was never explicitly mentioned in some of those conversations. That kind of intelligent context assembly simply wasn’t possible with the old architecture.
We recently announced the general availability of Slack’s Real-Time Search (RTS) API and Model Context Protocol (MCP) server. The RTS API enables third-party agents to tap into the context of Slack’s living, real-time conversational data, and the MCP server allows users to trigger agents across their business applications, all while maintaining enterprise-grade security and data permissions. With this functionality, organizations can finally deliver on the promise of enterprise productivity by integrating agents into their daily workflows.
Looking ahead, how do you see agent platforms evolving, and what architectural lessons from Slackbot’s transformation will remain relevant?
I think we’re moving toward a world where agents become genuinely collaborative, not just with humans, but with each other. Right now, most agents handle isolated tasks within a single tool or system. But the future is agents working across tools, coordinating with other agents, and operating seamlessly across teams and workflows. That’s where the real productivity gains will come from.
To get there, composability has to be a core architectural principle. We need to build agent platforms that teams can extend and combine in ways we haven’t even anticipated yet. One of the biggest lessons from the Slackbot transformation was that you can’t predict every use case upfront. If you try to build for specific scenarios, you end up with something rigid that doesn’t adapt as needs evolve. Instead, you need to provide flexible primitives, building blocks for reasoning, orchestration, tool use, and state management, that developers can compose into whatever their specific workflows require.
The other lesson that’s going to remain critical is building foundations that can support capabilities that don’t exist yet. When we started this transformation, multimodal input and sophisticated tool orchestration weren’t table stakes, but we architected for extensibility from the beginning. AI is moving fast, and the platforms that succeed will be the ones designed to evolve. That means clean abstractions, modular systems, and a relentless focus on developer experience so teams can adopt new capabilities without rewriting everything they’ve built.
Ultimately, the platforms that win in the agentic era won’t be the ones with the flashiest features today; they’ll be the ones built on foundations flexible enough to support whatever comes next.
For engineering leaders modernizing legacy systems today, what mindset shifts are most important when preparing for the agentic era?
The first shift is recognizing that developer experience isn’t a nice-to-have. It’s foundational. When you’re building agent platforms, you’re not just shipping features to end users; you’re creating interfaces that other developers will build on. If those interfaces are clunky or opaque, you’ve constrained what’s possible before anyone even starts. Investing early in clean APIs, intuitive tooling, and great documentation pays dividends because it determines how quickly teams can experiment and iterate.
The second shift is designing for learning and evolution, not perfection. With agentic systems, you can’t spec out every requirement upfront because the technology and user expectations are changing so rapidly. You need to build systems that can evolve gracefully, where you can swap out components, add new capabilities, and learn from how people actually use the platform without triggering a full rewrite. That requires both technical discipline around modularity and a cultural willingness to treat your architecture as something that learns alongside your users.
And that brings me to the biggest mindset shift: recognizing that modernization is as much about organizational habits and culture as it is about technology. You can have the most elegant architecture in the world, but if your team isn’t empowered to experiment, if there’s no space for iteration, or if decisions get bottlenecked, you won’t move fast enough. The agentic era rewards organizations that can learn quickly, ship incrementally, and adapt based on feedback. Building that culture, where experimentation is valued, where failure is seen as data, where teams have autonomy, is just as critical as the technical transformation itself.
What excites you most about building in the agentic era?
Honestly, what excites me most is the shift from building tools that people use to building agents that work alongside people. There’s something fundamentally different about creating systems that can surface the right context at the right moment, coordinate complex actions across multiple tools, and reduce friction, all while keeping users in control. It’s not about replacing human decision-making; it’s about amplifying it and removing the tedious overhead that gets in the way of actual work.
From a platform perspective, I’m excited about how this reimagines what’s possible for developers. We’re moving beyond building static features toward creating platforms where teams can design tools that are genuinely adaptive and resilient, systems that learn from how people actually use them and evolve accordingly. That’s a huge unlock for innovation because it means developers aren’t constrained by what we anticipated when we built the platform. They can create experiences that respond to their users’ actual workflows and needs.
But the biggest thing? I think we’re just scratching the surface of entirely new collaboration patterns that weren’t possible with transactional software. When agents can maintain context over time, orchestrate across systems, and work collaboratively with both humans and other agents, you unlock workflows that simply couldn’t exist before. We’re going to see teams solving problems in ways we can’t even imagine yet and building the platform that makes that possible is incredibly energizing.
