Cómo Slack ve MCP, agentes y el futuro “multiplayer” (Full Transcript)

[00:00:00] Speaker 1: This is the moment where we get to put our amazing product leaders in the, I wouldn't say it's super hot, but maybe like medium spicy seat. And we really want to kind of address, A, your questions. So if you have a question for our product leaders, please go ahead and ask. We put a link out. There's a QR code as well. I'm sure we'll flash that up here. But we are looking to get your questions answered. I have some prepared questions that I want to go through, because I think it's important. We've been looking at trends and things that people have been asking in the community. And yeah, we'll kind of get to it. I guess to set the stage, by the way, my name is Jillian Bruce. I lead our ecosystem marketing team here at Slack at Salesforce. And I am thrilled to be joined by these amazing product leaders here on stage. We have Rod Garcia, you all know very well, our VP of engineering. We have Nate Botwick, who's also a VP of platform for product. We have the amazing Curtis Kempel, who's our head of DevRel. And then we've got Greg Rybicki, who's our head of partner engineering. All right. So we just heard this amazing keynote, saw a lot of great positioning, saw a lot of great examples and demos. But I want to kind of go quickly down the line and do, like, a first fast break kind of question. So multiplayer, what does that mean? How is that significant? Rod, we'll start with you and kind of go down the line.

[00:01:28] Speaker 2: Multiplayer, I think, is pretty much what we do every day in Slack. When you're in a channel or collaborating in a canvas is when you have multiple people collaborating in a project, now though, with an agent. That agent being part of the collaboration and the flow of work.

[00:01:44] Speaker 3: Yeah, for me, I think the big thing is with all these tools, people are able to move a lot faster. But if they're moving in different directions, the team or the organization as a whole doesn't actually accelerate or move faster. So when I think about bringing agents into channels, it's really about enabling that alignment of the entire teams. The whole team can actually accelerate and move faster.

[00:02:08] Speaker 4: Following up on that, I think it's also about bringing multiple agents into that same flow. Like, one of my favorite things to see in Slack is a thread where I just get to see a complete, like, thought, problem, anything just go from a team coming together to collaborate, bringing in the proper agents to solve specific problems along the way. And it, you know, culminating in some kind of, it's done, this artifact, this thing. It's a really unique experience and it's something you only get to see in Slack.

[00:02:38] Speaker 5: Yeah, I would say velocity as well. You know, if we're getting all these time savings from these new tools, we're doing more with less. If you're in a single-player environment, you're really not getting the efficiency. So in multiplayer, you need agents in there, you need your co-workers in there, in real time getting that information and taking action. So it just gives you the velocity you need.

[00:03:00] Speaker 1: Thank you. All right. Well, the other big thing I think everyone's really interested in is MCP. So this is a totally different way of thinking about how we're building these days. How does this change how you think about architecting what you're building? Nate, I'll start with you.

[00:03:17] Speaker 3: Yeah, I think the big thing has been really kind of designing around the non-deterministic nature of how these tools work. So different from traditional APIs where you very deterministically plan out exactly what the steps that's going to happen. With LLMs, MCP, you have to really design in a non-deterministic fashion. So we put a lot of effort into the descriptions of the tools, the response that comes back so it's easier for an LM to kind of handle that and reason about it without making additional tool calls. Then also setting up a lot of evals and testing so that as we add new tools, we understand if anything breaks or the quality of certain types of prompts has gone down. So we're still learning along with everyone else in this industry. So please give us your feedback, but yeah, it's been a lot of fun and it's been great building with everyone.

[00:04:18] Speaker 1: Yeah, it's a big shift. All right, I want to talk about some of our favorite people in this ecosystem that are really important is our admins, right? Now we saw in the demo that Slackbot can now take action in Salesforce on your behalf and take action on your behalf. How do we think about governance when it comes to how you're building these agents and accessibility? Rod, how are you thinking about this?

[00:04:43] Speaker 2: Yeah, this is perhaps one of the largest challenges because also we need to keep in mind the end user experience, right? So there's something, attention that we need to work really hard to get very well. Fundamentally, at the end of the day, the end user permissions, that's something that we need to make sure follows through the entire session, the agent execution. And also, since we're an open platform, we need to help our partners as we're integrating more deeply together to say, okay, this Slack user has access to these systems, to the data warehouse or the Google Drive, et cetera, and how we have the agent to the metadata of this tooling integration to be context aware and user aware of the permissions. And we work really close also with our customers to understand exactly that contrast need without sacrificing the flexibility of the user experience. It's something that we work really hard every day to keep that tension and narrow that very well while keeping the developer ergonomics.

[00:05:41] Speaker 1: Yeah, thank you for that. Okay, we have, maybe we're going to get a little medium spicy here. Let's do it. You guys ready for a little medium spice? All right, so these are some of the topics that kind of have really come up that we've seen thematically in the community. Well, one thing is obviously data, right? Data is really critically important these days. You know, some people are calling it, it's the new gold. It's really important that, especially as builders and developers and admins, you have control and understand how your data is being accessed and used. How do we address any concerns about, oh, you know, Slack and data access and data security? Sorry, I'm going back to you, you're in engineering here.

[00:06:23] Speaker 2: Please. So, you know, I know this has been in the mind of many of you, especially in the last year, but there's something that hasn't changed. The data is yours, it's your data, it's our customers' data, and that hasn't changed. But as we saw in the keynote and everything going on in the industry, there's also a new reality that we need to scale that data access, right, and we need to do it also with safety. And that's where we take our responsibility very serious because customers and all of you trust us to be the place where we can do the work happens, you know, trust with safety. And so, we had to figure out a way to scale our infrastructure to meet this moment. The more than one million weekly active users in the MCP server has represented a challenge. Of course, how we scale our infrastructure and our databases, our data stores, et cetera, right? So, how we continue protecting our customers, also offering a great developer experience, and it's getting all our infrastructure to meet the demand of the ecosystem because now more than ever, you know, customers and partners need us more than ever, and we need to meet the moment with that safety, scalability, and also without sacrificing user experience.

[00:07:35] Speaker 1: Yeah, it's really important. Okay, Greg, I'm coming your way because this is a question about kind of our Slack marketplace and a larger ecosystem. There's been kind of, you know, some discussions about, hey, I've built this great thing, but I want to understand how many people are using it. I want to get some analytics, and there's a little bit of a gap there. Can you talk to that?

[00:07:55] Speaker 5: Yeah. Yeah, I mean, historically, we haven't given developers much, right? We said, you know, we're an event-based system. You can take your events just as well as we can. You can see what's happening. You can see where things are being installed, you know, which does work, but it's not simple. It's not scalable. So we're looking at three ways. One, there's analytics for the developer. There's analytics for the customer, so the admin, the users within the workspace. And then we're looking at it from the partner lens too when you're installed on thousands and thousands of teams. So we have a lot going on right now. We'd love to hear from you, to be honest, like what you want to see. We think we've captured the obvious ones, so we'll share that out to you. But yeah, we'd love to hear what you have for us. So yeah, hopefully soon we'll have analytics for developers, then partners, and then admins as well. Excellent.

[00:08:54] Speaker 1: So we'll tackle it, yeah. Well, you handled the meaty and spicy questions I already had. So before we go to live Q&A, I'm sure we're going to have more, but I want to go a little bit more into kind of bigger picture thinking here, and Kurt, I'm going to come to you with this one. You know, so much has changed with how we're building in the last year, last six months. Where do you see the role of the developer in a couple of years from now?

[00:09:14] Speaker 4: I thought about this all the time. It's a difficult question to ask. The rate of change is just so fast. So it's like, you know, things I'm thinking about will likely not be what we see in two years. But I think some patterns are going to stick through. I think more responsible and ambient agents are going to become a thing. I think eventually we'll hit kind of a flux where people get tired of having to always do the interactions, and we'll want to see agents taking on more responsibilities of their own. I think with that comes a lot of governance and security concerns and stuff like that. But I think what I've been thinking about mostly is just, I think in two years you won't build on Slack so much as build through it. The way everything is going, the way, you know, we're really turning into an operating system, you know, we're the throughput. People are here, and it's connecting things on either end and just slamming it right into you and your team and making things available. I just built, like, from Slack I can now access my personal AI harness on my personal PC. Right now I can just open it up and start working on something. And I think that's the world we're moving to. And I think in two years, much to the point of being able to do things on the go, you'll be connected anywhere to any agentic system and environment that you want, and you'll be able to do it all through Slack.

[00:10:41] Speaker 1: I mean, that sounds exciting. I'm signing up for that. All right. Greg, I'm going to come back to you. I want to talk more about Marketplace again. We saw incredible numbers, right? We got 2,600 plus listings on the Slack Marketplace. We have new agentic listings happening every single day, taking advantage of MCP and RTS. How can you really talk about how Marketplace itself might be evolving to kind of meet this moment and help really be, like, the base for distributing agents? Sure.

[00:11:11] Speaker 5: Yeah. I mean, we've seen incredible volume this past year, and it's just going up and up. Yeah. We mentioned, I mean, we publicly report agents, but then we see tooling, automations through MCP. So, I mean, then we also look at queue time, right? How long does it take us to review applications that maybe some of these people in this room build? So, what we do is two things. We've implemented automated checks further down the funnel, so before you submit, while you're submitting, before you get to us, to try to give you the information that you need in real time. We've also essentially automated most of our reviews through using agents. So, it can be really, really quick. I mean, the problem that we're still trying to solve, frankly, is when things don't go right, when we find things for the first time, when we need to contact developers and ask them kind of more obscure questions. There's still the human touch. We haven't automated that yet. That's the next thing we're going to work on. But yeah, it's an exciting place. In the next quarter, we've already started launching some of this, but you'll probably see the results more next quarter. So when you come to the marketplace, you'll see more AEO and exposure around the internet, not just in Slack, to hopefully help your applications out there. So, some of the stuff we're working on.

[00:12:37] Speaker 1: Help with some discoverability. I like that.

[00:12:39] Speaker 5: Discoverability, yeah. That's great.

[00:12:41] Speaker 1: It's fun stuff. Okay, well, we are going to dip into the live Q&A here in a second, but before we do that, I'm just going to ask you all a nice, fun little roadmap question because everybody wants to know what's going on. Thank you, Greg, for that sneak peek there. So I'd love to hear from all of you. What's one thing that's on our roadmap right now? Of course, forward-looking statement. This is not a commitment. Just reminding you all, only make purchasing decisions based on currently available features and functionality. I've said that about 10,000 times in my career. What's one thing on the roadmap right now that you think would surprise our developer audience?

[00:13:14] Speaker 2: Ooh, there's a lot going on. I think there's one thing that we just recently started, which is we were discussing that as we build enterprises, we're in the flow of work, you want to stay at the top of what's happening in your team and also your integrations on Slack, and those are events. So something that we just started to work in partnership with the NCP working group is to actually how we enable agents on Slack and off Slack to be notified of events that happen on Slack. Because you want to know when there's a new incident happening, your agents, they want to start helping you when those situations happen. So we really wanted to help you also as developers to create a nice interface and abstractions for you to be able to bring your agents to those events. So that's something that I'm really excited about. The team is working together with the rest of the community to figure out what's the right part of the protocol to do that, but that's something I'm super, super excited about.

[00:14:19] Speaker 1: Awesome.

[00:14:20] Speaker 3: Nate? Yeah, I'd say one of the reasons we want to have these events and partner with the developer community is so that we want to hear from you all, and so hopefully the roadmap isn't a complete curveball and surprise. It's really born out of the conversations we have here and what we learn and what you all are trying to do. And oftentimes we see what partners, developers are doing where they're kind of like hacking around our APIs to try and enable something, and that's really good insight for us and actually add to Slack the one-click deployment was really born out of that. We saw partners kind of hacking around what was available, and we were like, wow, that's an amazing opportunity. And we see innovation happening in the ecosystem, and then we want to try and enable that and fuel that further. But I would kind of pile on with what Rod said. I think one thing we're thinking a lot about is enabling more proactivity for agents. That's something we see. That's one of those emerging things where we see people kind of hacking around it and trying to figure out how to make it work, but for agents in Slack to really feel like a coworker and a teammate, I think we have to enable better proactivity, and that means kind of listening to the events that are flowing through and be able to reason about that. And so that's definitely one of the things that I'm excited about.

[00:15:34] Speaker 1: I love it. All right.

[00:15:36] Speaker 4: Kurt, you're up. Developer focus. I'm going to go with developer experience things that are on the roadmap. I feel like right now teams focused on a lot of things that are going to make it very easy for AI-assisted developers, skills, plugins, things like that. I'm just very excited to see that work continue. I think everything that we do to continue to reduce the cost and time to value frees up more time for developers to build things that people find valuable. You can replace all that time you spent scaffolding with iteration and talking to the same people that you actually want to build a solution for. So that's my goal, is to save people time on setup and give them more time for craft.

[00:16:16] Speaker 1: I love that. Greg, you're up.

[00:16:20] Speaker 5: Most surprising. Yeah. I think this is a good one because it surprised me when we decided this last quarter. No, it's a good way. I'm not saying it's negative. But working on Slack product but also being a developer for years on Slack. So iframes and Slack. Finally after all these years. Love it. All right. Well, thank you all.

[00:16:42] Speaker 1: We are going to full-on transition to the questions I did not share with you previously because these are coming in live. We are taking both questions obviously via the link right there on the QR codes. For those of you viewing online, please keep submitting your questions. I am seeing them right here. And then we also have the ability to ask questions here live in the room as well. So you could either use that here in the room or we do actually have some mics in the room. So I think I would like to start, if anyone in the room would like to raise their hand and ask a question live. It's okay. I got plenty of questions here. So all right. We're going to go here. The first question I have is from Daniel Sanchez, one of our amazing developer friendlies out there in the community. Will developers eventually be able to programmatically extend or interact with Slack bots? Who would like to take that? Or at least start it? You can tag team it.

[00:17:36] Speaker 2: I can take a shot. Okay. Let's do it. Daniel, thank you for the question. That's a great question. And I think we're starting the journey with the NCP client, right? We just saw the announcement that later in the summer we're going to release that capability so that you can declare in your apps, Slack apps, the NCP servers, the first party NCP servers that you want to have in that experience. And we're putting it up in the path from there. We have other stuff in the roadmap that I don't know, Gilles or Nate would be really happy talking about it. But I think we're going to start first enabling all of you to integrate in your Slack apps, your first party NCP servers, so that they're available in your team. That's the first step. But I'm curious, we should chat also, Daniel and others, what we're looking for in that experience. But yeah, that's the first shot.

[00:18:27] Speaker 1: Anybody else want to add anything? Nate?

[00:18:29] Speaker 3: Yeah, I agree. I mean, I think we're now starting to add some of the primitives that will enable more extensibility. So, you know, the NCP client is like the big first step in that. So obviously connect to, you know, more tools, both, you know, custom servers that you build or, you know, third party servers. And I think skills is another one of those primitives that will really enable a lot more extensibility and programmability for Slack bot. So yeah, I think we're starting to add some of those pieces together. But yeah, like Rod said, would love to hear more of the details, like what would you like to be able to do with it? Because that's really fuel for us to really, you know, build out and develop the roadmap.

[00:19:08] Speaker 1: Anything else to add, anybody?

[00:19:09] Speaker 4: I think that covered it really well.

[00:19:11] Speaker 1: Great. All right. So next question we have, again, I'm going to have opportunity, anybody in the room would like to raise their hand? No? It's okay. Just keep going through here. I got plenty. I guess. All right. All right. So this is a question from Scott Patton. Yes. Thank you. One of many, I see. So Scott's asking, how does Slack view the dividing line between deterministic automation via Workflow Builder and agentic or MCP agents? Will there be any interoperability between the two?

[00:19:47] Speaker 3: That's a good question. Yeah, I think there definitely needs to be interoperability between the two. I think, you know, the workflows are great when you want, like, some prescriptive, very deterministic steps, but we see more and more that people want to add some, you know, reasoning or LLM aspects or steps in there. And so we just released the first part of that, where you can have a custom prompt step to generate a response, and you can pass that response back into future steps in the workflow. Then we also want to make it easier to, like, hand off to an agent from within part of a workflow, too. And it could be bidirectional, too, where, you know, agents, you're starting with a natural language, you know, back and forth with an agent, and then that agent calls a workflow to complete some set of deterministic steps. And so, yeah, we really want to, you know, build on that interoperability, because I think there's a lot of use cases where you do want to mix determinism, you know, with the kind of natural language, you know, multi-step back and forth.

[00:20:56] Speaker 2: Something also in that space, Scott, I think a lot about, and we work with the team, is all of us, most of the time, we're not thinking about, oh, I'm going to interact with this part of the system because it's deterministic, and this other part of the system is non-deterministic, right? And I think, again, if we go back to our mission, you know, making working life simpler, more pleasant, and more productive, is that how we help our users to understand that, without having to get into the entire automation lingo, and have to understand, you know, a workflow or a trigger, and then a skill and an agent, and we lost them, you know, in the process. So something we're working really hard is that how we leverage those two dimensions in a way that is just a task, right? And we help you to understand there's a primitive that we can guarantee you that will always give you the outcome you're looking for, versus there's another that most of the time, you know? So that's something that we're prototyping a lot, something that, at the end of the day, it's like a recipe in the kitchen, where you need to try the ingredients, taste the soup, you know, remove ingredients, and keep doing until you find exactly the right balance and the recipe you want. And it's perhaps, to be honest, one of the most gnarly challenges right now in how we make agentic AI more human, because we don't have time to start thinking about, oh, yeah, I'm going to put here in a workflow and this other activity in a prompt. We need to simplify all that to help you so you can focus on what's most important for you. So this is something that we're actively working on. We have multiple, you know, work streams and prototypes to really feel that tension. So it's got hit us up, you have insights, and we would love your feedback, because you got really to the core of one of the challenges in the user experience of the agentic AI era.

[00:22:53] Speaker 1: This is why we have the developer advisory board, right?

[00:22:55] Speaker 2: Amazing. Good plug.

[00:22:58] Speaker 1: All right. Another question here. We got a question from Vlad Schlossberg, who's one of our amazing Slack community group leaders here in San Francisco. Vlad, I saw you earlier. Good to see you again. All right. Vlad wants to know, what other block kit blocks are on the roadmap?

[00:23:13] Speaker 6: Ooh. That's a good one. Vlad wins.

[00:23:16] Speaker 1: There he is. He's in the back. There he is. There he is.

[00:23:20] Speaker 3: Thank you, Vlad. That's a good question.

[00:23:22] Speaker 2: Thank you, Vlad.

[00:23:23] Speaker 3: Take it. Another one? Yeah. So, we just released a handful of the carousel and cards, and we've got data tables coming. It's a better way of presenting more things in a tabular format. We want to support richer visualizations of data as well. And we also wanted to have better blocks that are for layouts, so that an agent can kind of craft the right UI and layout on the fly. And that's really what we're trying to enable, is the agent response to feel dynamic and kind of fit for the job of the task or the request that came in. So, we definitely have a handful that we're working on right now. Hopefully they are flexible, so that blocks are built in a way where you can kind of compose them in different ways. So, it unlocks a lot of different types of visualizations and renderings that you can create. But again, we would love to hear your feedback. What would you like to see? This is something that we are heavily, heavily invested in right now. So, very open to feedback and what you would like us to build.

[00:24:41] Speaker 4: I'd love to pile onto that one, because it's just such a big one. My favorite that we've released is code blocks, right? So, yeah, copy and syntax highlighting, wonderful. On top of that, aside from blocks themselves, it's also about enabling agents to be able to properly structure them. Know when a layout is optimized or good, as opposed to just, you know, correct, right? We'll render. And to that end, we're trying to experiment with opening up APIs, like validating block kit so agents can converge on a correct result, as opposed to having to try to get it right the first time, right? Like determinism versus non-determinism. So, with non-deterministic systems, let's give them the ability to get it right the second time.

[00:25:27] Speaker 1: That's awesome. All right. We have a question here. We might have to phone a friend. From the audience, it looks like.

[00:25:32] Speaker 4: Oh, we have an audience question.

[00:25:33] Speaker 1: Amazing. Let's move. Hooray. Hey, everyone.

[00:25:37] Speaker 7: My name's Tirith from PwC. Just had a quick question for you guys. So, in the demo, we saw, like, a single agent use case, where, you know, like, cursor might come in into a chat for a bug and give us a recommendation. But how does, like, MCP work when we have, for example, multiple agents, like, in a single workflow? Let's say you have cursor providing the actual, like, fix itself, you have another agent that's doing QA, maybe another doing the deployment.

[00:26:03] Speaker 1: So, it's like agent multiplayer. Yeah.

[00:26:09] Speaker 4: Right now, it just happens in the flow of work. Right? So, like, I see this all the time. This is actually what I was calling out before about when I see threads like that, where I see, you know, pulling in Figma designs, right? And then the website team is using V0 or cursor or whatever to take that, create a PR preview, right? And then they're working together on it and iterating. And then they come back until it's finally finished, and a landing page is live. And I can click on it right there. And I see the preview on furl and block kit, right? And, like, the agents were involved in the flow of work. And it's not, like, agent to agent in the sense of, like, a programmatic handoff, which, honestly, I kind of prefer. It's agents working with people. And then you just, hey, V0, can you take this design and make a web page out of it, a landing page? Yeah. Got you. And it just goes and does it. So, it should feel like that. It should feel natural. Like, you just, whichever agent is the next right one to pick up on the next step, just at mention it right in channel or thread, and you're ready to go.

[00:27:09] Speaker 5: Yeah. That's a lot. Oh, sorry. Go ahead, Greg. I was going to. I would add one thing. We have this. So, we have events in Slack, and we released metadata on top of events a few years ago. And it's kind of been this sleeper feature. But it's being used lately to trigger other agents in the flow of work, whether that's a channel or a thread. Metadata is hidden from the end user, but apps and agents can hear and listen to it. So, that's one area to look at. It's really interesting. It's evolving now.

[00:27:44] Speaker 1: Yeah.

[00:27:45] Speaker 3: I was going to say something similar. I think this is one of those areas where we see people trying to, like, hack things together, which is usually a really good sign for something that we should, an opportunity for us to kind of productize or formalize something a lot more. And so, the ways we see it kind of getting hacked together now is, you know, an agent app mentioning another agent and then using message metadata to basically pass context over in that message. Which is super interesting and really cool that that, you know, is possible and that you can make it work. But you do have to kind of, like, hack it together. And so, I think it is, you know, an opportunity for us to, you know, formalize that a bit more.

[00:28:21] Speaker 2: But there's also another dimension in your question that you mentioned, which is NCP. Right? And when we look at Slack as the place where work happens and you have your NCP service here, then the question is, well, how you can enable your agents to use your NCP servers you already have available. Right? So, that's a big question that we've been seeing also in the community and customers and something in the top of our mind. Because ultimately, going back, again, I'm very obsessed with the point of Slack is a place for humans, for teams, for people to collaborate. And we need to have access to their tools. Right? So, and we haven't really yet find a good abstraction that helps that experience for agents to be more seamless. So, if you have ideas, I would love to hear about it. But perhaps I can see the glimpse a little bit in the direction you're thinking. And I think that's perhaps the next hill that we need to figure out. So, yes.

[00:29:20] Speaker 1: Excellent. Great answers. I see... Oh, we've got more hands. See, you broke the ice. Thank you so much. Okay.

[00:29:27] Speaker 6: We have a question right here. Do I turn this on? Okay.

[00:29:30] Speaker 8: It's on. Hey, guys. Steven from Tightknit. Hey, Steven. One of the things we struggled with is plugging our Slack app into our development cycle. In particular, we have a lot of tools that will let us spin up a preview version when someone opens a PR on Git, for example. But we've always struggled to try and get Slack into there. So, for example, a developer could try out their changes, just scoped to what they're putting up in a PR. Is there anything in the pipeline to help out with that?

[00:30:04] Speaker 4: I love that question.

[00:30:06] Speaker 1: Also, you all have to check out his pants when he stands up, everyone. I think it's the first ever... Oh, my goodness. Yeah. There we go. For those of you viewing online, they are Slack slacks. They're pretty amazing. I mean, you see it.

[00:30:18] Speaker 2: That's awesome. Kurt, you want to take that one?

[00:30:20] Speaker 4: Yeah. So, this is something I've been thinking about a lot. And, you know, it kind of reminds me of, like, I had to build a lot of apps for Apple, right? For the App Store. And you end up in a similar situation. It's like you have this one instance of your app, but you need it available both in production, you need it available scoped to test. And so, right now, something that I'm thinking about a lot, I have no idea what will actually form of this, but is a layer of kind of like settings or extension or configuration that sits above the application itself. I don't know what that looks like. But essentially, now we have one app, but we can target that to specific environments, to specific scopes, to production, to what we want to do with it. A company that does this very well, I think, is Expo.dev, a focus on CICD and pipelines and tooling for React Native or mobile apps. And so, they use a very similar pattern. I think it would be something that we should look into.

[00:31:20] Speaker 2: There is another point also there, which is, as part of the development lifecycle, you know, to your point, you open the pull request with your team, and you want to test that integration in the context of a fresh workspace, so that you can have a snapshot, right, in the baseline and run your test and then you tear down the workspace, right? And real talk, I think there's an opportunity there that we haven't really worked completely and solved. Josh will kill me if I say this, but Josh, you can kill me after. I think we have the developer program in which you can provision a lot of sandboxes, and maybe perhaps on the road, we can extend that functionality to an API that allows you to trigger that to a GitHub action and tear up and tear down a Slack team. There's a lot of complexities there. Again, we come back there to the need to make customers all their data security and make sure that there's no abuse, and there's always a line that we need to keep in check. But for sure, the developer program opens a door for us to perhaps extend that functionality, the provisioning of the workspaces, Josh, now to exactly use it to the Slack CLI, and you connect that to your GitHub action. So that's a great point, and honestly, through the years, we constantly open the question when you look at the software development lifecycle, how we make that testing much easier, and the developer program and that tear up, tear down workspace for you to develop is the first shot in that direction, and hopefully soon we can have time to extend that to the CLI.

[00:32:54] Speaker 5: I'm only going to suggest hacks all day, by the way. You saw we announced add to Slack, so being able to auto provision Slack apps with one click. I think that's an interesting area to explore as well when we release that to GA, being able to spin up whatever application based off the previous one. Yeah. So more to come there. Good.

[00:33:19] Speaker 1: Good meaty question. All right. I saw a couple hands over here. One hand. All right. Is there another hand I'm ignoring? All right. Hello.

[00:33:27] Speaker 9: I'm Wilhelm. I made a simple poll for Slack half a lifetime ago. I think it has its 10th birthday this year. And like... Yeah.

[00:33:36] Speaker 2: Yeah. Happy birthday.

[00:33:38] Speaker 9: Yeah. It's been around for a while, this ecosystem. It's nice to be here. And like Curtis, I spent a lot of time the past six months or so building an OpenClaw inspired personal agent in Slack, and it's incredible. In Slack, it's so much better than doing it in WhatsApp or one of these other places. So good. And that's been great. One challenge, which actually kind of builds a little bit on the last question, is agents love feedback loops, right? Love feedback. So they can actually use the code that they just wrote, actually run it, use it, and see it from a user's perspective, right? So my challenge has been that, especially with all these amazing new blocks you all have been adding, the agent doesn't really know them yet. They're not in the training data. It puts them under the new blocks together. And even though Blockit's beautiful, you can build things in Blockit that don't look very good or that don't work that well, right? So what I want my agent to see after it's actually written all this new code is actually what it looks like for the end user in Slack, right? So how can I not just spin up a new Slack ad hoc and the new PR, but also have the agent experience that new Slack experience I just built itself? Because the state of the art is like taking a screenshot, right, in a browser, which is just like... It's not very good, and it's very slow, and especially with Slack, it's not great. So I'm just curious how you're thinking about that. And obviously, I don't know what the solution is for this, but I feel like it would be a huge unlock if we could somehow have our agents be the user as well and experience the new... Yeah. I think you get the idea.

[00:35:11] Speaker 4: Absolutely. I think it ties into what I was talking about before, about enabling agents to converge on an optimal outcome. And I think one part of that in making it more visible to them... I'm also making a push, ideally, hopefully, to make Block Kit itself more visible to folks around the web. I would love the idea for... We have Block Kit Builder, and it's amazing. And you can visualize those layouts right there. You can experience them. I would love to take the little canvas that you've built and make that embeddable just anywhere. Any website, anything, like, you know, maybe iframe, whatever. But that would open up the door as well for agents to be able to just take that bit of JSON, understand what's going to render, visually represent it, and then maybe one day even add in actions and support. You could actually, like, eval through the entire flow, right? Of your layout, of your blocks. That's like, for me, I still think that, you know, eventually human in the loop and constraints and all of that is going to move to the API layer, right? And agents are non-deterministic. We know this. They're never gonna get it right the first time. So, you can actually do something like a structured output and then add on top of that the coherence, the fitness or optimization, right? It could be correct and look horrible and be not usable to an end user, but pass a Block Kit validation, right? So, these are things I'm thinking about constantly is that balance between validation and fitness.

[00:36:44] Speaker 1: Awesome. Hey, thank you.

[00:36:48] Speaker 2: I have, actually, it's a really good question also. So, like, over the weekend, I have personal projects, as many of you do, and I was using one of the skills in Cloud Code, the superpowers one. And what I like from the ergonomics of that experience is that the agent is being a web server that allows you to communicate what you see versus what the agent is building. And your question made me think about the challenge we have with Block Kit nowadays is it needs to be semantically correct, and there's a whole translation layer, right, between the JSON schema and then how that renders in the UI. I would love to figure out a path where we can meet you where you are there, right? And I think we have made a lot of investments in the recent months in the Block Kit Builder. It looks amazing, and the team has done an amazing job. Josh, we should add to the ROM, maybe, to abstract something in the CLI, right? Because you're working with Cloud Code, you're jamming, right? You say, hey, I'm building my app, I want to create this JSON payload for blocks. I want to see how it looks. And then right now, the path, the best path would be to use probably the Chrome MCP server and your Cloud Session, which is super slow. I love my friends at Tropics, but it's still very slow, you know? So, maybe there's something we can do to create a lightweight abstraction in the Slack CLI so that we meet you where you are in your Cloud Session, in your Codex Session, and you can validate your blocks. Especially the look and feel, semantically correct, we can figure out that later, but at least, you know, the look and feel, and without having you to go to Shibbolth Share, copy and paste that, deploy it to Slack, and do all that, right? So, that's a great use case. We should figure out a way to do a lightweight abstraction of that and put in the Slack CLI to meet you where you are.

[00:38:34] Speaker 1: Sounds like we're filling up quite a roadmap.

[00:38:36] Speaker 2: Yeah, for Josh, it's like, Josh, I'm sorry, friend.

[00:38:39] Speaker 1: For all of you doing online in the audience who don't know who Josh is, this is one of our amazing PMs over there. And Rod is just giving him a whole bunch of pork. So, there's a question I would love to kind of address, and we might have to phone a friend here in the audience for this, but the question is, how should developers think about MCP versus the existing Slack API? Are they complementary, or is one replacing the other? And I think for this one, I know you all probably have great answers, but we have probably the SME in the room here. So, Rob, if we could get Rob a mic. Welcome back to the stage, Rob. Hello.

[00:39:18] Speaker 6: That's a great question. The way I think about MCP versus API is they are complementary. They are not really, like, one is not going to replace another. MCP is really made for LLM use cases versus APIs are for your traditional deterministic code. For example, even if you're building an agent, what I would expect is you build an agent in Slack, the agent sends a message, the end user sends a message to agent, and agent is going to respond back. That's going to use chat.postMessage API because it's a deterministic flow that your code is going to write. But then there is going to be tools where this agent may need to call Slack Search API, may need to crawl a channel and fetch channel history or read a file. That's just non-deterministic. And MCP server, Slack MCP server, is the best way to do that. You could spin off your own tools and wrap around our APIs, but our MCP server is really made for this use case, and we have spent a lot of time optimizing our prompts, our descriptions. We have read a lot of evals on those prompts, so it's really optimized for lots of different use cases. Our MCP server returns markdown by default. It hydrates IDs instead of just giving you user ID and channel ID. It's going to send you back username and channel name, what LLM really needs. So it's significantly better to use MCPs out of the box rather than trying to spin off your own tools to wrap up around these APIs. So TLDR, if you are writing deterministic code, use APIs. If you are building anything where LLM is going to call the API or tool, use our MCP server.

[00:41:09] Speaker 1: Thank you, Saurabh. I love that. I love that we can phone a friend in the room. All right. We are going to go back. If anyone else in the room have a question... Oh, we've got a hand right there. And then after this question, I am going to go back online. So all of you, we do have probably about 10 more minutes or so to ask questions. There's a lot of questions, so just if you're asking a question online and we don't get to it, I promise we will answer it after this panel, and we'll make sure that our SMEs are in there helping get your questions answered. But let's go to our in-room question here.

[00:41:37] Speaker 10: Thank you. This is Arun from PwC, UX designer. So my question is, we talked about UX or user experience in multiple points, and I understand how we can orchestrate that better, and the solution is going to be so much different in future for our clients. But speaking from a UI point of view, what level of influence will a designer have to create a hyper-focused or hyper-targeted, personalized, rich, interactive UI when I converse with an agent or a Slack bot?

[00:42:14] Speaker 4: Great question. That's a great question. So let's take it. You called out one before, iframes.

[00:42:19] Speaker 5: Yeah. So, yeah, there's a few options. So we do have iframes in a few areas. So we have them through MCP apps, as well as work objects, which I think we talked about earlier. So with that, you can show exactly what you want your end user to see, media, multimedia, whatever. But we hope that you won't have to all the time. We hope that we can keep up with blocks and keep up with supporting, you know, markdown and things that are natively, hopefully, meet your needs. But, yeah, but if you want full control, you can have it now. So, yeah.

[00:42:55] Speaker 2: There's a...that brings a really good point because as we build user experiences, you know, for example, for your customers, of course, you know, those customers want to have a certain defined user experience. But also what's the tension there is, you know, how we can make, again, going back to a Slack mission, you know, making working live more pleasant, more simple, more productive. That also comes to the design system that support that experience, right? So, of course, you know, BlockKit is the answer for extensibility for that. But real talk, in the genetic era, we need to offer other use cases on which we allow you to create that generative UI at the top of that, but perhaps can be richer. We're actively exploring that space right now. You see some stuff in a Slack bot. But we try to be very careful because also you spend all your day in a Slack. So, we don't want to make the noise, you know, especially in larger teams. And in smaller teams, the reality is slightly different. But especially in larger Slack teams where you have hundreds or thousands of people collaborating every day, how we make that experience pleasant, you know? And so, it's attention again. I don't think there's a silver bullet there. And help us to see in your experience as we release these new capabilities that we're exploring, especially to the NCP protocol, how that feels and how you experience it with your customers. Help us to see to the community. And I would love to learn from your use cases and how we can make them better. But there's attention there, you know? And importantly, we need to help you to see the attention so you can make good choices for your customer, right? So, Kurt just published to his team and the developer relations team in the website some of the tips, what makes the experience of an agent great, for example. And we should extend probably that documentation down the road as we release some of these features, what make the interactive experience to NCP protocol great, right? So, then that, more to come. And we would love to learn more about the use cases. Thank you.

[00:45:02] Speaker 1: And you can find that great resource on slack.dev, my favorite website.

[00:45:06] Speaker 9: Oh, yeah.

[00:45:07] Speaker 1: All right. We're going to go back to some online questions here. We have lots of SDK questions. This one is from Taharqa Zubari. The question is, this is a fun one. When is the Salesforce Apex SDK going to be updated to be on par with the current Slack features?

[00:45:26] Speaker 6: Ooh.

[00:45:26] Speaker 1: Spiced level just went real high on that one.

[00:45:30] Speaker 4: We actually have answers for some of this now.

[00:45:34] Speaker 2: I got to get you that one too. So, real talk. I think, you know, we've been focused for the last year to make the story of integration between Slack and Salesforce, again, seamless. Because we don't really want either the Salesforce admins or the Slack admins and also the end users to really have to think about end user auth. How do I manage the permissions? Does this Slack user have access to this account object in Salesforce? Again, we're back to our Slack mission to make that simpler, more pleasant, more productive. So, we released a lot of features last year. And we've been really focusing in making the experience in Lex amazing for Salesforce channels, agent force, deep integration between both platforms. And we've been discussing with the team actively because we have the Slack Apex SDK in beta that we released years ago. And we started the active conversation. In fact, we had a meeting with the product team and the engineering team roughly two or three weeks ago. We started discussing some of this area. The concrete answer in the short term, we have built a lot of Legos in integration for you to use right now. There's a lot of flow steps, for example. If you want to create your Salesforce flow and interact with the Slack, there's a whole rich library of more than 15 flow steps available for you. And also, the deep integration with agent force that allows you to publish your agent force agent into Slack. And you can create the custom Apex managed package and all that, and expose that to agent force and let your users in both platforms to be exposed to them. So, we want to feel that experience, how that experience plays out for developers, because you're very familiar with custom flow steps, for example, right? We want to feel that, what it means for you, and maybe you can extend that with the current library, and we'll take it from there. So, if you have ideas and friction points, I would love to hear them, because actually, that will help us to inform our strategy and our roadmap. So, yes.

[00:47:39] Speaker 1: I feel like you'll get a lot of ideas.

[00:47:42] Speaker 2: No, please. Please.

[00:47:46] Speaker 1: Anything else to add? I know, Kurt, you and I have been talking about this for years.

[00:47:48] Speaker 4: Yeah. Yeah, we're actively working on just what Rod said. It all starts with the integration. You know, there's... It has to be, like, frictionless. If you're spending time thinking about permission sets, and are these users actually connected and doing that? Much like with agents, right? We wanted to reduce the cost of creation and iteration, so you can actually build something that people need in solving problems. And we want to do that same thing with AgentForce and with Salesforce. And so, yeah, the approach for the SDK first is, like, largely, let's make sure that once you install this package, everything just works, TM, right? And then from there, we'll start building out the Apex classes and the things that you need to now actually have this, like, you know, fully-fledged connection and experience. But, yeah, auto-slack for the win.

[00:48:39] Speaker 1: Love it. Oh, yes. Okay, we're at the end of our time here, so I have one last rapid-fire question. So, give me, like, one or two lines. I know it's hard. There's a lot to say. What's the one thing you want every developer in this room and viewing online to do today? And I'm going to reverse it. I'm going to start with Greg.

[00:49:00] Speaker 5: To do today?

[00:49:03] Speaker 1: Or maybe, you know, later this afternoon, tomorrow, you know.

[00:49:07] Speaker 5: Yeah, I would get a sandbox up and running. They're great. We give you usage, users, all the features in there. Maybe most of you have them already. But just spin one up, you get everything in there. That's what I would do.

[00:49:22] Speaker 4: Okay. I love it because it's a perfect follow-up. And then immediately install the CLI and run Slack create agent and just explore. Just look at what it's got set up. Look at how it works. Understand how to build a production-ready agent in no time. And just look at how fast you can have something connected to that sandbox. And then just think about now how you can put all the rest of the time into actually building, you know, the thing that you want, your idea, and bringing that to life.

[00:49:51] Speaker 1: Love it. Nate?

[00:49:53] Speaker 3: I'll go try the Slack MCP server. It's just amazing the context that it adds to your agent right away. And also, the actions it enables your agent to take within Slack, all of the box. And so, I think it's just so powerful. So, if you haven't tried it yet, I'd say try that.

[00:50:11] Speaker 2: For me, I just have two real quick gigantic SDK. Please, as Kurt was saying, just try it out, check it out, use it. And at the top of that, use the new blocks. Help us to understand how that feels as you're building your new use cases in the top of the platform. So, we're going to continue supporting you in this journey.

[00:50:29] Speaker 1: I love it. Well, thanks, you guys. My thing I want everyone to do today is check out our hackathon, which we're launching right now, today. First ever Slack hackathon in a very, very long time. So, please, get your teams together, go check it out. It's a great opportunity to build with all of these things that you just told everybody to check out. You can use all those to build for this hackathon. Thank you so much, panelists. Let's give a round of applause for our panelists. And thank you all so much for tuning in and for being here. And we hope you have a great rest of your Slack Dev Day. Take care.

[00:51:01] Speaker 3: Thank you. Thanks, y'all.