# Slack's AI Strategy: Agents, MCP, and Enterprise Context

**Podcast:** Dev Interrupted
**Published:** 2026-07-07

## Transcript

Welcome back to Dev Interrupted, brought to you by Linear B.
Before we start, my guest today is Jamie DeLange, Slack's Chief Product Officer.
And the idea that stuck with me most from our conversation was how the real org chart lives in Slack.
You learn how your company works by watching where the work lands.
And that's the whole reason Linear B sponsors this show, because the same thing is true of your code.
Once AI helps developers write faster, the honest test isn't code gen, it's what happens downstream in review, testing, and delivery.
That's where you find out whether AI is really helping you ship.
Measuring AI's real impact, keeping it governed, seeing what happens downstream, those are three things Jamie and I kept circling back to, and they're exactly what we think about all day at Linear B.
Now, on to my conversation with Jamie.
Today's guest is Jamie DeLange, Executive Vice President and Chief Product Officer at Slack.
And as our listeners know, I'm a total Slack nerd.
I spend a lot of my time in Slack building agents for my teammates.
And I've formed a lot of opinions, especially over the last year, about what my workspace needs and what kind of space it needs to bring to the mix to make AI powerful.
And in the last year...
I've really had the privilege of being part, I guess, of the Salesforce cinematic universe and going to places like Dreamforce and TDX and getting really keyed in on how Slack and Salesforce are betting on the transformations they're making with their technology, their bets on where the work is actually happening.
And Slack is center stage on that.
I've heard a lot of great panels and discussions at both of those events about the direction that Slack is going.
So I too was like, you know, let's bet on this.
Let's build on this.
And as part of learning more, we had Curtis Kempel from Slack on our show, who even walked me through how he created some of his Slack agents, which was really exciting to dive into.
And that was around the end of last year.
And since then, I've launched a whole fleet of Slack agents for my teammates.
I found a lot of success building on the things that Curtis taught me.
And I've also been so excited about how Slack is.
deepening its partnership with protocols and technology that are powering AI for everyone and helping all of us enact gains and find the best standards moving forward.
So it's exciting to be part of that story.
But centered to all of this is how the Slack, the product, is evolving and changing and meeting the needs of knowledge workers now.
And that's what I'm so excited to dig into, is some of that high-level thinking.
Because here on Dev Interrupted, we love to get aligned about where all of the ships are going.
Because it's pretty stormy seas right now.
So, Jamie, welcome to Dev Interrupted.
We're so excited to have you here.
Thank you.
I'm so excited to be here.
I feel like your intro just spiritually connected us in a really deep way.
I'm so excited to talk to you about everything that we're doing.
Amazing.
Well, now that we're best friends, we're going to dive into a whole chat today about how Slack is transforming.
obviously the opportunities that you've been exploring as a product leader and what you see the AI, the powered world, the Slack world that we're operating in changing into.
So do you want to start with like what your vision is and the opportunities you see?
Yeah.
So I feel like, you know, I'm...
I'm a Slack CPO now.
I've been here for about eight and a half years.
I haven't been the CPO the whole time.
I'm more recently the CPO.
But when I think about the future of Slack, as somebody who's just been here for so long, it's impossible for me to not think about Slack's past and the things that have always made Slack Slack.
Made it the place where people love to work, made it the only piece of SaaS that people really fanboy over.
I want that to continue to be true as we all evolve how we're working.
And so the things that come to my mind in terms of like, what is Slack always been and needs to keep being and maybe even get better at is one, it's the place that people want to work in.
It is human.
It's friendly.
It's fun.
It works the way that people work.
It's not trying to put some rigid structure on top of how you get stuff done in your day, but it's going to be helpful.
It's going to be there just in time to help you get a little bit organized, maybe help you prioritize your work, help you and your team stay on task.
Slack has also always been a platform, or for almost the whole time Slack has been around, it's been a platform.
And we've had this strong belief that the more work you bring into Slack, the better your workers' lives are going to be.
They're not going to have to go into every single SaaS application to get stuff done.
And the more people can look at information together in a channel or look at content together in a channel, the more aligned they're going to be, the more they'll be able to move.
And then finally, all of this needs to be open by default.
It all needs to be searchable.
It all needs to be findable.
So when a new hire starts on day one, they don't have an empty inbox.
They have like a whole...
bevy of channels to like dig back into and they can basically get up to speed super fast because they're just jumping into the conversation but they're not missing the whole rest of the history they have everything so all these things have always been what slack is but now we got agents right like we have llms that can come into the mix and A thing about me is that when I started at Slack, I worked in search and machine learning.
So I had all of these highfalutin ideas about how you're going to turn all of that information in Slack and turn it into knowledge.
And we were going to make Slack the smartest application.
It was going to be super assistive.
And we can actually do that now.
We can do that.
Slack can do that itself with Slackbot.
But more than that, we can be an engine that kind of helps every developer, no matter who they are.
do that for themselves, for their companies.
And so when I think about the future of Slack, it's really extending that original vision of being the place where all of your people, your applications, your information come together in channels to keep everybody aligned and moving forward in the right direction.
And extending that to agents and making sure that Slack is the best place for humans and agents to collaborate.
And making sure that that human and agent collaboration stays human at its core.
And that we have the same kind of flexibility to work in the ways that make sense to us.
That we're not being pulled into like isolated AI chambers where we can only work with robots.
And then we have human spaces where we can work with human spaces.
I think these spaces need to blend a lot.
With agents, it also means we can pull in a lot more work.
Like we used to say that Slack is like, you can pull in the thin work that's just really fast, like web forms, web hooks.
Turns out those were super powerful, right?
But now you can do so much more.
Like you can paint graphs inside of Slack.
You can maybe even like, you know.
review code inside of Slack.
You could completely build your whole website from inside of Slack.
And that's what agents allow for.
And I think as they think about what are we going to build toward, it's continuing to build that environment and that ecosystem that really makes the interaction patterns powerful and delightful and thinking always about the team.
and how the team gets work done, not just about an individual person.
So I think Slack needs to evolve to make humans and agents work together super well, make it the best place to develop your agents, deploy your agents.
Slackbot can be sort of a super orchestrator over all of that in so many ways.
And then we just need to keep making the experience dead simple and delightful so that people want to stay there.
Exactly.
That's simple and delightful.
And the way that it has to transform to meet the individual needs of the worker and what's important to them and the organization in general.
What's really exciting is this vision that you see for Slack is this context world, this equal plane operator where agents and humans can work together and have the views and the outputs that they need to get their work done.
Really what it exposes is that.
much like engineering and the ways that we solve code generation and delivery at scale with AI agents.
Almost that same thing is happening with our knowledge work.
And the sooner and more clearly that we have understandings about where are those loops.
within our org.
What are the windows we need to have into these loops?
And these become channels.
You're like punching holes into your organization to see where these agents are working.
And Slack becomes where you're peering in to do that work.
And then, you know, there's some stuff in there that we're going to touch on a little later when we talk about MCP and protocols and stuff, because then obviously you can bring the whole world.
into Slack now because everything can get bridged into AI conversations.
AI conversations can take advantage of MCP, which can have apps embedded in them now.
So, in turn, natural language and conversations that are happening into live rendered things.
Like you said, you can drive any kind of process that you need from there.
So, then we arrive at a responsibility for a lot of leaders, both non-technical and technical leaders, product leaders, engineering leaders, everyone alike, to think about about how are we going to engineer the harness of our context world, of our Slack world, of our communication world.
Because now that we've acknowledged that, oh, this too is a bunch of loops and a bunch of checks and gates and guards and contacts that goes in and out, how are we going to build it?
And what I've found is that Slack becomes the building block to not only start building it, but express it really quickly, which is its superpower, I think.
And that's like, it's in a lane of its own in terms of where you can take it.
Totally.
I mean, I think like, Stuart, Butterfield used to call channels, they were digital containers for arbitrary objects, which sounds like, you know, that's kind of nonsense.
But exactly that, right?
Like you can, one of the toughest things when you're building an agent is how do you figure out the context layer?
How do you like build up your knowledge graph that's going to power this thing?
How do you keep it up to date?
And one of the coolest things about Slack is it has just enough structure.
for you to be able to like point at like a project or point at a topic, but not so much structure that you're having to stitch together a bunch of different things.
And the conversation itself actually ends up being like the richest context for you to be able to action off of any of like, I don't know, the meatier things like a slide deck or even like a PR, like the more you know about what happened around it, the...
the smarter your agents can be.
Yeah, you're like scattering all these artifacts and all the roads, something needs to lead back to Slack.
It all comes down to good, healthy reporting, information going into Slack, communications happening in Slack and correctly labeled semantic channels that are open and not siloed.
You know, good communication practices we should all be having as organizations in general because it turns out AI amplifies the good and the bad.
Yeah, exactly.
And so before we dive into some of the more exciting technology, and product changes that are powering the ability to do all of that.
I do want to ask, because I'm curious from a practitioner standpoint, you know, the barrier that gets crossed from when you're like doing the single player AI experience to the multiplayer one experience, it becomes profoundly more complex in terms of how you deal with the interactions.
That's something that I've learned just building with them.
But also too, just as like someone interested in the space.
Two years ago, I gave a talk at B-Sides Barcelona about multiplayer AI and how you could use AI chat conversations to basically hack your co-workers' context.
Like, this is an understanding that we need to have as folks that are operating in this space together.
So how do you think about, as a product leader, about securing that kind of space and making sure, too, that it's going to scale for the needs of all of your users that have a huge range of sensitivities for their topics?
Yeah, I think it's really interesting.
It's a topic that we're continuously grappling with.
I think one of the benefits we have here is channels.
And so channels are not only a digital container for arbitrary objects, but they're also an ACL, basically.
And so you can kind of make a pretty good assumption that whatever is pushed into the channel, if an agent has access to that.
and the people have access to that, that's a fine, we're all happy, that's a happy universe.
It gets a little bit more challenging when that agent gets access to tools.
And it's not just looking at the content that you put inside of Slack, but it's looking into some third-party system.
And where we are at right now with that is...
Really allowing for configurability for whatever use case makes sense.
So in some cases, it might make sense to have an agent have fully its own identity and have that identity, like it has its own account in whatever tools it's having access to.
It may also make sense for it to be in a lot where it's passing through your identity and whoever's talking to the agent, now the agent's acting on that person's behalf, it may make sense to throw up a modal or a modal, but like a radio buttons or something to be like, do you want to do this as yourself or do you want me to do it as me?
Like to just like explicitly ask the user.
I think what has become imminently clear to me as we dig into this more is it's really difficult to make a rule that fits everything.
Like everybody's going to have, like you said, a different level of sensitivity.
Everyone is going to have a different use case.
So configurability and even just even that idea of like on the fly configurability, I think could be really powerful so that we're fitting the configuration to the use case and letting the people who are closest to the work actually make that decision.
And I think then it's just about helping people understand the implications of those decisions, whether it's on the developer side or the admin side or the end user side, because there's trade-offs.
There's no perfect answer for what that looks like until, you know, the agents get so smart that they know what's secret and what's not.
But I don't trust them yet.
I don't trust them quite yet.
I don't trust them yet.
You're hitting on exactly how, when we've talked with other leaders about how they think about the security planes, the world within their space, how they think about it too.
It has to be deeply configurable just as much as it has to, the needs of your end users are on a wide range of sensitivity.
Your configs need to expose to that and meet to that level.
But another thing too that we learned recently, we had Tanya Janka, who was OWASP Hacker of the Year last year, and she helped put together the OWASP.
top 10 vulnerabilities for 2026.
And the top one was like vibe coding and developers themselves, like people.
People have become the biggest vulnerability, which is why, like, I think it's important for people to double down on using places like Slack and using, like, user management and control plane surfaces, like what's offered in, like, the supporting Salesforce universe to really understand and identify all of the movers within your system and what they have access to and being able to scale it up and down with the levels of, like, sensitivity that you need.
And, you know, I think it's really easy to, like...
you know, roll your eyes over some people, like just to not necessarily want to double down on that.
But it's like, ultimately, if like your workflows are just logs on a machine somewhere, they're like so sensitive in terms of the amount of work going in and the outputs.
Whereas if it's like siloed away in a specific kind of like channel, a chamber for that particular purpose, you can understand and audit its usage.
You can control it a little bit better.
And ultimately, that's like the kind of control plane that I think knowledge workers need.
We've also been, I think about it at like an administrator level.
So like, you know, more fine grain provisioning for agents, being able to say like these agents can only be operated by these people, potentially getting to a place where we say these agents can only operate in these channels.
This is an allow list for the channels that this agent can be in.
That's something that an admin could set.
But the thing that I think we haven't yet quite figured out is.
Like a lot of the people are not going to be admins.
The builder also needs some visibility into this.
And as the bar, like the barrier to entry on the building is so much lower, like we need, the builder should be able to do that.
And we should make the builder as close to the business owner as possible so that the business owner could also know that.
And ideally, maybe they can't build the agent themselves, but they could troubleshoot it.
Like they could push it in the right direction and see where it's going wrong.
And I think this is...
It's something we've got to figure out for any, both agents and things like skills, anything that you can pass around and is getting leveraged in multiple places.
Like having that kind of observability so that you can inflect on what you've built, it's really important.
And also figuring out how to make that understandable because, you know, this is not just software.
It's not like there's a bug.
I wrote the if statement inverted or something, and now the whole thing went kerflooey.
It's like much more nuanced in helping people, maybe even with other agents, figure out how to inflect on their agent to make it better.
I think, I don't know what it is yet, but I feel like there's definitely a role Slack can play in making that world work better.
Your team's adopted AI, and now leadership wants proof it's driving real business outcomes.
LinearBee is the engineering productivity platform that measures AI impact at the pull request level, so you can see exactly how AI is shaping speed, quality, and efficiency across every team.
LinearBee helps engineering leaders reinvest productivity gains from AI back into their engineering organization.
Stop guessing at your AI ROI and start proving it.
See how at LinearBee.io.
Yeah, I'm even thinking now about how Slack can help organization leaders identify and highlight and elevate.
these AI unlocks that do happen often in a really siloed basis on like a team or team level.
And then like what you said as well, you get a level of skill sharing that becomes really important.
Slack becomes a really great, almost like skills ecosystem with all different ways that it can plug in.
So, you know, skills themselves, an open standard, one that AI users around the world are just like really strongly embracing.
And another one as well as MCP.
And MCP is of course, like been a little bit bit of like a news hype darling child.
It has been the coolest thing ever.
It has been dead.
It has been brought back to life.
It has been really mislabeled, relabeled.
Bets have been taken on and off the table.
And along the way, I think MCPs totally had an identity crisis, but the one thing along the way that it did better than anything else was distribution.
It had a lot of really good stuff, really cleanly in a lot of people's hands in a really scalable way, which, hey, guess what?
It's perfect for AI rollouts, AI and...
Now folks are embracing skills over MCP, has a new working group with the Linux Foundation.
I'm like, can that spec please just hit the MCP protocol already?
So we're all locked in, right, on how these protocols are building for the future.
So, you know, how is Slack also playing in that space?
And you're bringing things like MCP into Slack.
What has it been like to watch those technologies unfold, but then also to participate as like a builder, a contributor?
Well, I think one of the things that's very...
We have the great fortune at Slack of having such a strong developer community and such a strong partner community.
So I think like for pretty much anybody who's really building agents in the ecosystem is thinking about building them in Slack.
Like our partners are incredible.
The individual developers at our companies are incredible and they're all telling us what they need from us.
And the move to MCP was...
pushed in a lot of ways by the community telling us that it's what they needed.
That's when the MCP server came out because we saw the community trying to do a lot of things with our APIs that they weren't designed for that felt to us unsecure and uncomfortable.
And we were like, we got to figure out how to meet this demand, but we've got to do it safely.
And that was our first move to MCP on the server side.
On the client side, we really started to play with things internally.
You know, we built Slackbot ourselves.
We started connecting our own MCP to it.
I think originally we had this idea that we would only have a limited set of partners for MCP because we weren't totally sure on what the level of adoption was going to be.
And we weren't totally sure on what the level of sophistication of that adoption was going to be.
Like, are people going to just publish junk to this and degrade the experience of the agent to such a degree that like, it's not.
It's not really usable anymore.
And we kind of solve for that by allowing our own MCP ecosystem to grow internally.
And like, we're not, you know, we're not Luddites.
We understand how to build technology, but we did have MCPs of varying quality and that allowed us to understand that like...
this is, we're going to be okay with this.
We can do it.
We can have good tool selection.
We can have good logic around the tool selection.
And leveraging MCP is going to give us a lot more power than trying to roll our own tools for every single thing that we might want it to do, or trying to figure out a more robust, like, agent-to-agent protocol.
I think this will get us there a lot faster and provide a lot more flexibility.
I also say, like, highest level.
I want anybody who is thinking about building for agents to be able to build for Slack.
And I also want to thank anybody who's thinking about building agents to be able to easily put those things into Slack.
And that means that we have to have open standards, not Slack-specific standards.
So, you know, I don't think...
I don't think MCP is going to solve everything for everybody.
And I am like you, very interested in skills over MCP.
I think we should get that as soon as humanly possible.
Cause they'd actually just make skills and skills and MCP go together like peanut butter.
Peanut butter jelly.
Okay.
Yeah.
We're all literally the same page.
Yeah.
So I agree with that.
I also think like.
You know, there are places inside of Slack where we're playing around with A to A.
Salesforce is betting on A to A.
We're testing a bunch of different things because we don't know where this whole thing is going to go.
So I think it's being tinkerers is really helpful here.
And then having the, you know, having our ear to the.
thousands of other tinkerers out there who are trying to get their stuff inside of Slack.
I think our ecosystem pulls us in the right direction a lot of the time.
Yeah.
So here's the playbook that I'm hearing then is that, you know, you're standardizing early because it's less expensive to standardize early, but obviously keeping a very open ear and open conversation with all of the tinkers abound internally and externally to like really go through like what works and what doesn't work.
And that requires obviously like a good engineering practice, a good reflection practice, a good ability to like highlight things that are working or figure out like why is this not working.
But also, too, when you bring everyone together to work on that unified problem and you give it a label, then it gives you an opportunity to be such an early influence on where that technology can go.
And MCP is one that I think anybody who's building in the spaces that we are.
where we're building things that are connectors and highways of information for other tools, MCP is absolutely going to be critical for business success, for product success, just for the technology to be safe and scalable.
So acknowledging that and knowing that MCP has to be center stage, it's important to...
partner up with those protocols early.
And this is something that I learned and got a really good deep dive from when we had Tyson Singer.
He's from Spotify backstage and really the kind of person behind the IDP portal.
And what's always been so fascinating to me about that product is that that's not what Spotify is out to do.
Why do they have this first-in-class IDP and they set the standard and everyone just uses backstage because it's awesome, right?
But it's like, one way I really dug into his story and he told me how...
you know, when they were early in figuring out what their IDP was going to look like, it was more strategically and financially and long-term smart for them to just like...
set the standard, make the standard, go with the standard because it was so early in the play because switching later would be so expensive.
But he was saying too in that same conversation that he was like, but if there would have been something really great to latch on to that solve that problem, like that's what we would have built around because that's what we're optimizing for.
So that's why MCP is now.
I see that for a lot of...
big orgs and enterprises, they're building MCP-like things into their product and hedging their bets about where things might go.
But ultimately, we're all still just like one prompt away from doing like the full changeover when everyone else gets on board with, because that's how we engineer these days, when everyone gets on board with where things have got to go.
I'm just curious, like from like a practitioner standpoint, I recently been appointed as like an agentic AI foundation ambassador and MCP protocol was like one of the library of projects within it that, you know, I've been kind of tasked with learning more and evangelizing.
And so I've been going deep in the MCP world.
Like, have you in Slack engineers and product like partnered with the development of MCP as a protocol or do you have plans to do that?
And like, what's that look like as an ecosystem participant for you?
That is a really good question.
I think MCP is one of the areas where we're trying to figure out exactly how far we can go with MCP.
And, you know, I honestly am not, I should know the answer to whether or not we're contributing to MCP.
I don't know off the top of my head.
We all are in some capacity.
Exactly.
Even if no, of course, I'm not saying like, you know, it's slack in the minutes of the MCP channel working group or whatever the case may be.
But the reality is, is that the answer is yes, because of the ecosystem participation that you bring forward.
I think that's the most vital thing.
That's what I'm always.
And then it's also figuring out how MCP fits into the existing ecosystem that we built and how MCP really.
can be a complement to the Slack platform and not like, so developers who are already invested in our platform don't totally have to pivot.
They can invest in MCP and have that be a part of their story and not the whole story.
We've also thought about that from our own sort of, how are we going to allow for, I'll give you the example, like how are we going to allow for UI to be built inside of Slack?
There was a moment, I would say like six months ago, where we were having a debate about whether or not we should.
keep investing in BlockKit at all.
And we had a group of people get together.
I'm getting kind of invested in this conversation already.
We had a group of people get together from the platform team, from the user experience team, from the front-end engineering team, and they came up with a solution set that was basically, you see this out, it's out live now, but you can see that...
BlockKit supports many more dynamic kinds of blocks.
We also have the ability for BlockKit.
We're working on making BlockKit a great translation layer for MCPUI as well.
And so BlockKit is not, BlockKit still exists.
BlockKit is still a really important, robust part of the developer story inside of Slack.
But we have changed what BlockKit means in a lot of ways by allowing for much more flexibility inside of BlockKit.
And I think, you know, Similarly, the message stream inside of Slack is going to continue to be the main carrier of information in and out of Slack.
But we're going to have to really change what can go in those messages.
And BlockKit is a really important part of that story.
But we may also find that we need to have other kinds of things inside of Slack.
We may need to start building more just-in-time UI affordances.
We just recently launched a better Markdown viewer.
I know that's very simple, but having more ways of being able to do the kinds of things that people need to do at work now that are fully supported by the platform and don't feel kind of hacked on.
but extend the platform in a natural way instead of saying like, you know what, forget the Slack platform.
Everything is all MCP all day.
So we're sort of like, I think constantly thinking about how can we get the best out of each kind of technology.
Exactly.
It's acknowledging that MCP is one piece of the puzzle of the chain of things and things to explore.
There's actually...
so much like fog of war, so much greenfield, so much stuff that we haven't seen or figured out that it's like all it takes is a curious spirit to play around with some of these primitives and the new things that are available to start finding new ways of working.
Like that story you just told about Blockkit's like new identity, its transformation as almost like an agentic expression layer is critical because MCP is only as good as the presentation in which it can then serve it up to all of its users, which in the Slack universe is going to be like large.
largely non-technical in a lot of cases.
And so how do you make that really fluent?
Of course, use the UX that they already know and are familiar with.
Don't try to pigeonhole them into some new practice.
You know, anybody who's tried to drag anybody into the terminal in the last six months has found that not to be enjoyable.
And Xtools takes way too long to install.
But all of that aside, it's like it really like calls out that.
Things that we are taking for granted and we already have are going to transform.
And maybe it's just something you're sitting over here and it needs a working group, like in your case, to reevaluate.
In other cases, it's going to evolve on its own.
But we all have to just keep our eyes open to that.
And the most important thing I'll say there, this is what excites me as a practitioner, even a researcher in the space, is that all of this is stuff that you can be experimenting with and building new workflows for and taking notes about.
just like understanding what, how do I operate and orchestrate this context?
And there's actually just so much to write about and share and study and discover.
So it's never been more exciting to be a knowledge worker because like the way that we're reinventing work exists.
And what happens is Slack becomes your workbench.
Like as much as it is like your communication place, it's the place where you go to drive your impact at scale, which is like what becomes really exciting about where it all goes.
Yeah, I mean, I feel like even like the folks who you would think like, I mean, they've got the best audience.
They've got the biggest, most dedicated users.
I feel like we hear from our partners.
They put it inside of Slack and then it just goes.
I mean, I think like, I don't want to get too grandiose.
But in some ways, for the companies that use Slack, like Slack is basically acting like...
It's doing what Google did for the internet for their agents.
Like, it's making their agents discoverable.
It's giving their agents an audience.
It gives their agents backlinks.
It's their own little notebook.
It's their own little notebook.
Everyone was freaking out earlier this year about the notebook thing, and now no one talks about a notebook because it was very weird.
But really, that's like the reality of what you're describing is like, yeah, it becomes the stage.
It becomes the marketplace.
It becomes like the...
the public exchange of those agents in your context.
That messy context is always going to live in Slack.
And you can try as you may to come in there with a crowbar and get it all out and put it in containers and transform it and do an ETL thing.
And they're like, what are you even doing at that point?
Bring the agent into that world with you.
That's the whole power of it being a natural language, you know, thing.
Yeah, and I mean, I think if you do that too, the thing that you get is you don't risk sort of cutting off your data source to feed your thing.
I think like the thing I think about a lot is if we move too much of that, like rich, messy interaction, like if too many people start to try to like meatify it and congest it and be like, okay, I've got this little Slack nugget.
I'm only going to interact with Slack in nugget form over here in my terminal.
Nobody is, who's going to make the, the.
the messy stuff.
And I think as good as agents are, they are also not going to do the kind of human collaboration, the kind of butting heads productively when you need to.
They're not going to tell you you're wrong and fight with you.
Even if they do, it's because you told them to.
I think the agents will only be as good as we are as humans because they need They need our exhaust to kind of learn and get better, at least at this point.
And Slack is a really good way to ensure that that loop keeps happening for you.
As AI writes more of your code, it's more important than ever that you have strong checks and balances in place.
Without them, security risks and spec mismatches slip straight into production.
LinearB provides an independent layer of AI code review with GitStream policy as code that catches risks and enforces your standards before manual review even begins.
Govern your AI workflows without slowing your team down.
Learn more at LinearB.io.
You know, as we've talked a little bit about the vision, about the product, and how we've partnered with these kinds of technologies and brought them closer into the Slack world, because that's the kind of tooling that we need to work with in this context.
You know, a lot of this is like prototyping and experimenting.
And even I was mentioning a second ago about like there's just so much to learn and do.
And something that we really focus on here on Dev Interrupted, too, is focusing on like that day-to-reality of like stepping into production, of taking it to the finish line of otherwise.
delivering it in like a durable and secure and safe state.
And so with Slack, that's a tall order for all of the things that we've talked about before, just because any of.
type of context could be living inside of it.
And before it was just people talking to each other, but now it's people and their agents talking to each other, agents giving humans dashboards and interfaces, humans giving agents commands, maybe somewhere in a channel somewhere, two agents talking to each other and they just need to get turned off.
Who knows it can be just completely chaos.
And so like, I'm curious to think about how you as a product leader, how do you...
prevent the already very complex world of Slack from just becoming this like uncontrollable mental monster for your admins?
So I think I've got two answers for you here.
One is we just really, really need to increase our observability.
Like we just launched over 40 new metrics for Slackbot.
We need to extend that to the whole ecosystem.
Slack should be the best place for you to not only deploy agents, but to understand how your agents are doing, how your agents are impacting your team, how your agents are driving business outcomes.
We also really need to continue to invest in our guardrails.
So we have like confidential channels that are not AI indexed.
We need to continue, we need to expand that out.
But I think we also need to start really thinking about the primitives here.
Like you've got people, you've got data, you've got systems.
And I think we've, for a long time, it's not kind of gotten away with having guardrails that mush those two things together, like two of those three things together in different ways.
And we don't really allow you to control your data flow as much as I think we need to get to.
We also don't allow you to control your people and data context together in the same ways I think we need to.
So we're thinking about new channel types.
We're thinking about new kinds of provisioning.
We're thinking about more auditability.
But one of the things that already exists that is really incredible and kind of like a side effect of all these things being in Slack and working in channels is that, you know, for a lot of companies, there have been a lot of challenges about having a lot of your information inside of Slack for a very long time.
You got a lot of people, humans are messy.
And if you're a company like the size of Salesforce with 70,000 employees, 80,000 employees, something like that.
you know, we're an even larger, we have even larger customers than that.
You're basically running like a social network inside of a company.
There's a ton of stuff happening that, you know, could be good, could be bad.
And so we've added a lot of guardrails already.
So because agents are talking over the same protocol that humans are talking over, you get a lot of that stuff for free.
So you can have DLP inside of Slack.
You could, so you can set rules and say like, if somebody tries to give.
my agent a credit card number and back like out some data and do some internal hacking, that's going to be a problem.
We have things like anomaly detection.
So if there's some weird behavior inside of your application happening, maybe people are switching channels and scrolling back and switching channels and scrolling back.
And maybe that's actually not a person, but you know, somebody has taken over someone's laptop.
You can imagine the same kind of thing for agents where we can say like, this is, this is like malicious agent behavior.
We think.
this is not what you want here.
Also, you know, being able to have things like legal holds and like strong auditability and EKM, I think for a lot of people who are rolling their own agent UI, they don't, they're not thinking about that stuff.
Or if they are, it's not their primary, like it's not their primary thing.
And so I think we've, we've got through a lot of the, at least like the baseline fundamentals of security and compliance and trust in Slack.
And trust is our number one value at Salesforce.
So we're constantly kind of like, okay, what do we need to do next?
What do we need to do next?
But as we evolve it, it's really becoming clear to me that...
eyes in to what's happening is really, really critical.
And then the ability to action on that when you see something.
So for those really large companies, we've also seen that it's really challenging to manage the amount of content you have inside of Slack.
And a lot of them are building this whole developer ecosystem just to administrate Slack.
So we want to think about putting MCP on top of that.
And maybe we have our own out-of-the-box Slack bot can do a lot of the administration for you and you can talk to it via MCP.
You can build your own agent and you can do your Slack admin via MCP.
So we're thinking about how can we leverage the same kinds of tools to help with the problem, basically.
Yeah.
In that world too.
I really love to know what your thoughts on identity and you talked to, you talked on it a little bit in that list of things and also things like ownership, because like for me, I think of somebody and, and this is somebody who's like, I tinker with and have a lot of these agents who do a lot of different stuff.
But for me, when I go wrangle them or I find them and then they're in their channels, it feels like for me as the agent wrangler, the agent builder, there's not like an intuitive way that it all gets linked back.
And even like people can understand the umbrella of the impact, you know, sometimes something happens in a channel where my agent, you know, provided an insight somewhere and then I later find out after the fact, it would be cooler if that kind of information could be more surface to me.
But also too, where people, when they see that cool bot that helped them, there was a more clear thing that laid their flag where it was like, it was this guy who built me that made all of these insights possible.
And so like thinking about the ownership of work, also the hierarchies of people, because, you know, I almost feel like this become the real, like people say now, like the real prod lives, you know, the real thing.
your real code lives in production.
You have to observe it in production now rather than like, look at like the, the tests and the CICD to know what your code really does.
You look downstream.
The same thing is here.
Like you sure you have your org chart in like ripple or something.
We've talked about this on the show, but you know what?
Your org chart is really over in Slack.
You peer in and you can see your people and you see what agents work to them.
You see the context, like black holes within your organization where everything is going in and something coming out somewhere.
So it just becomes like, how do you think about those identity problems too?
I mean, so I've heard customers dealing with this in a bunch of different ways.
And I will say upfront that this is one of those places where everything's kind of shaking out at the moment.
We have a customer assemble who...
speaks of us a lot, who has like hundreds of agents and they've put them all on the org chart.
So they all clearly have a manager.
That org chart is also reflected inside of Slack.
So inside of Slack, you can see like who are the people who are responsible for the agents.
Those agents are all like...
owned by business owners, basically.
So they're treated like employees.
They have like performance metrics that they need to hit.
I think that's one model on like on one side.
And then on the other side, you have...
agents that are strictly operating off of like an OAuth model, where it's more like a tool call for the individual and the agent is only working on behalf of the human.
It doesn't take any independent action.
Or if it did take an independent action, that would be logged back to the person.
And I think probably different use cases are going to end up using different, those two models, like one of those two models.
The thing that I keep coming back to Which goes back to what I was saying before about like builder culture and having making sure that the agency is close to the business is having maybe developer and business owner not be exactly the same thing for now.
But ideally, those become the same.
Ideally, you can have.
a person who is the business owner.
So your agent that you built is also like on your team and people can give you kudos about like how your, how your agent did.
And that comes back to you.
Um, or in the same way that I can observe my team when they're operating in public channels, at least I can monitor sort of like what is, you know, I have like four Katie's on my team.
What is that Katie doing this week?
And I can get it.
Yeah, exactly.
And ideally you could get, you could set up routines.
You could get proactive insights around that.
I think my, my kind of like holy grail there is if you could sort of get close to treating agents like employees and saying, you know, this is the performance metric for, even if it's just like a.
something like, say, like Cloud Tag that just launched.
It's like one identity, but across many different surfaces.
Like in each of those channels, it might have like, it's working toward the objective of the channel, right?
And so then you could attribute how much of that, how that team interacting with the agent in that channel contributed to the objective.
And that gives you a better sense of...
real ROI, which I think is something we're all kind of like chasing at the moment.
It also gives shape to how you work.
Like what you just described becomes that loop, you know, that we talked about earlier, those things within like your context world that you're engineering.
And, you know, in this conversation, we've covered so much ground in terms of like the technology and how it's getting adopted into what I think is one of the most critical.
surface planes of, you know, knowledge work, especially right now.
And, you know, we've covered a lot of stuff, but, you know, just before we wrap things up, Jamie, as well, I was curious, like, are there things that are under the radar that you think maybe people are sleeping on or not paying attention to or directions that this is going that you don't think this conversation touched on?
You have a profound kind of like bird's eye view on where this kinds of stuff is pointing.
I mean, I think one is the...
One of the things that I think maybe we're having the conversation in not exactly the right way yet is I think we keep trying, like there's a lot of conversations about where the agent's like going to live, where's the data going to live, like who's going to own which layer of the stack.
And I'm just not totally sure that it's going to shake out that way.
Like that like there will be one company that like.
only sits at the context layer and there will be like a different application that only sits at the agent layer.
I think we're going to see a lot more bleed.
And maybe I think about that because Slack is a little bit all over the place in each of these areas, but so are so many different companies.
And I assume we will see some consolidation in certain parts of the service architecture.
But I also see...
such an opportunity for like mass diversification.
One of the things Slack has always strived to do is to make everybody a maker, right?
To be able to say like, I can make a low-code, no-code workflow and I can make my whole team operate super well because I...
just honestly like how to bot do a weekly update in channel and that's actually enough to get us over the line into good.
There are tons of problems in every company, in every person's life that are just sort of like, wouldn't that be nicer if?
And I think we'll see a ton of explosion in different parts of the stack in terms of innovation.
We're far from the...
everything kind of like coming together under one player right now.
And I think even as we start to see consolidation in certain areas, I also observe a backlash to that almost immediately.
Like people are like, we're not ready.
We're not there yet.
So, you know, I think, again, standardizing on things like MCP that are open, that people can contribute to, like that feels like that's a moment for the community to get together and figure out where we're going.
And I love that.
I think...
Sort of assuming that one player is going to win somewhere in terms of like the service architecture, the model architecture.
I just don't think we know enough to know.
Yeah, there's a long way to go.
There's too many stakeholders.
There's too many constituents.
There's too many hats in the ring.
But also there's too many buyers that each do their own thing.
And that's the whole name of the game is that it can be tailored so specifically.
So no, it can't just be one monolithic winner in the end.
You're going to get these really hyper-specialized niche winners for certain stuff.
The spicy take I heard in there and what you were saying is that every application, every SaaS platform is a data lake now.
becoming a data lake.
They want to become the place where all the data gathers because that's how you do that next level insights in places.
So in a world where everyone wants to be a data lake, you should probably be like, you know, way down in the, in the Valley.
You should be like at the, at the below sea level where stuff is draining, right?
Where, where all of the knowledge is going.
And, and that's the kind of places like that we've seen in the engineering world, like be critical and source and center of attention is the, the Git forge.
Like that is the drain where everything in your engineering org is going.
And that's not to say a drain is something bad.
It's just the direction all the water's going.
But then like over here and all the knowledge working stuff, that's what's happening too with all that stuff's going into your communication layer for most folks at Slack.
And so I think that is exciting.
Everyone wants to be the lake.
Maybe the water stops there along the way, but it still keeps going to its final destination.
I would say also maybe the better thing is to be like a...
both a lake and a river.
I think the thing that Slack gets right is that we have a sense of the current, right?
We know what's most recent.
We know what people are interacting with.
And so, and this is true, the more data you connect inside of Slack, the more ability you get for like box files to come inside of Slack, your Canvas stuff to come inside of Slack.
You can see who's touching what.
So you have this like constant engagement, good context.
And that lets you know, Like when you put something in a lake, it just sits there and you don't know what's most relevant because it's all just in the lake.
But we have a sense of movement.
And I think that that's what gets you velocity.
Amazing.
Well, this has been a fantastic chat.
Jamie, thank you so much for joining me on the show, for demystifying all sorts of things about Slack and the burning questions that I've been having.
Like I said, it's just been a...
been a big privilege for Devontrapped and myself to be so close to the Slack and the Salesforce world.
And just before we wrap up, is there anywhere you want to point folks to to learn more about you or the stuff you're working on right now?
Oh, yes.
For sure.
So I really just wanted to...
plug our recent MCP client launch for Slackbot.
You can now publish MCP server with your app.
It's really great.
Slackbot can use it out of the box.
People can build skills off of it.
It's, I think, a really incredible way to get more context out of your Slack.
And in terms of places to go, I would check out the Slack dev site.
It's amazing.
There's tons of cool stuff in there.
We're constantly updating it.
It got a refresh recently.
It's real cute.
So go check it out.
Amazing.
Well, we'll include links to that in our show notes so people can go build.
And for those listening, if you're curious about building on Slack, you know, there's lots of resources, myself included.
So don't be a stranger.
Both Jamie and I would love to hear from you about what you thought about our conversation today.
And if you're listening and you made it all the way this far, then you clearly loved this conversation.
So please give Jamie and I a big plus one thumbs up on whatever platform you're listening or watching this on.
And be sure to read the accompanying newsletter that comes out on LinkedIn and Substack.
for all of the juicy gossip in between.
So, Jamie, thank you again for coming on the show.
It was a blast having you here.
Thank you.
It's been great.