# Slack Code: Enterprise AI Multiplayer Strategy

**Podcast:** Chain of Thought | AI Agents, Infrastructure & Engineering
**Published:** 2026-09-02

## Transcript

Maybe this might not be a completely crazy idea to have Slack sort of act as a mix between like an IDE and like a GitHub for your team, shortening the distance between I notice a problem and I can fix the problem.
Context is the real nugget.
Slack code and code channels is just a V1 of what multiplayer AI could look like.
Slack is making AI coding a team sport.
Slack code puts coding agents like ClaudeCode and Devon into shared channels where a whole team can watch the work, steer it, review the diffs, and ship all within Slack.
Will Slack be the enterprise harness for AI?
Let's explore on today's chain of thought conversation with Slack Chief Product Officer Jamie DeLang.
I am your host, Connor Bronson.
Make sure you have subscribed.
You've got your notifications turned on so the next episode finds you.
Jamie, though, is the focus for this episode.
Jamie has spent nine years at Slack turning search, machine learning, and now agents into product, and her team just shipped Slack code.
Slack's bet is that AI at work is a multiplayer.
Agents belong in the channels where teams already work, not in a private chat with a single person.
Jamie, congratulations on the Slack code launch.
What's the reaction been like inside Slack and out?
Well, I think the thing, well, thank you, first of all, for the congrats on the launch, and thank you for having me on the podcast.
My pleasure.
I think the thing that has been, I guess, most surprising to me externally is how many people we've been able to show sort of the authentic capabilities of Slack with this launch.
I think truthfully, a lot of companies have already been operating this way.
You know, we brought on our launch partners like Devon, like OpenAI, like Anthropic.
The truth is they've been shipping code in Slack for quite some time, and I will give you a little bit behind the scenes.
In fact, for some of them, it was a little bit difficult early on to get them to understand why you would even need this.
They were like, oh, we've already solved all of that.
We already just ship code with our agents, and it's totally fine.
And I don't want my agent interaction to be any different than interacting with a person.
I think those companies sometimes underestimate how far along the adoption curve they are and how, you know, sometimes people need to be shown a little and you need to meet your users where they're at.
And I think what I love about Slack code and code channels is it's just the smallest set of sort of affordances inside of a normal Slack environment.
They really show you.
what could be possible working with multiple agents against a development environment in Slack.
And, you know, having been at Slack for nine years, there have been so many times where we've, you know, had customers doing incredible things with Slack.
We've been doing incredible things with Slack ourselves.
But for a new user who hasn't broached that, who hasn't like...
dreamed up that creative solution, it can be really difficult to bring them along.
And I think Slack code just makes that future so much more accessible to, you know, developers everywhere and even non-developers who, you know, haven't, you said, like we mentioned earlier, there was the press at the launch event, you know.
Being able to write code inside of Slack, people who have no business writing code can write code inside of Slack as well.
So I'm ecstatic with the launch reception.
I think it's gone about as well as I could expect it to.
The team internally is really excited.
And I'm just, so I see this as one step.
in a journey of making Slack work a lot better for people and agents working together.
And it has been a really exciting one.
I really like that perspective because I think you're spot on that there is a wide distribution of where people are in their adoption journey.
And part of that is external perceptions of AI.
Part of it's what type of work you're doing and where AI has really developed frontier capabilities.
Coding is obviously an area where we're seeing a huge impact.
And before we get into the details of this and how to do multiplayer AI correctly, or at least how to do it correctly today, I want to say a quick thank you to our presenting sponsors for season four of Chain of Thought, Walrus Memory, which gives AI agents portable, verifiable memory at walrus.xyz.com and Sphix, delivering reliable enterprise webhooks at link.svix.com.com.
And as we have this conversation around multiplayer AI, It's interesting to look at where we are with coding today.
A couple of years ago, I think when people were using AI to code, they were copy pasting from, you know, an open AI chat or from a cloud chat.
And then we got Slack and, or then we got it in terminal.
Then we started adding agents into Slack.
And yeah, I've worked with a cursor agent or a cloud agent to try to code something within Slack.
But I have seen the...
capabilities over the last, call it six months, really improved there from when I was first doing it.
It used to be I could do a quick bug fix and now the ability for those agents to gather context just seems vastly improved.
How has your team made this decision to center coding agents within the context-rich Slack environment?
And when are you giving them a ton of information?
How versus when are you deciding to let them be sandboxed?
Yeah, so...
First of all, I think this is something, I just want to acknowledge what you're saying up front about how much this has changed, how much the capabilities have changed with coding agents.
I think the reason we feel like this is a good bet for Slack right now is because coding agents themselves are just so much more capable.
They're so much more like a teammate.
The job of being an engineer these days is so much more about.
managing people and delegating tasks.
It's just that those people are not people, they're agents, and you're chunking off work into discrete tasks and sending your agents off to do it.
It's very, very different than the sort of copy-paste, stack-overflowy style of AI coding from a few, a year, year and a half ago.
Feels like decades ago at this point.
Time is so messed up right now.
I could not tell you when anything is.
I distinctly remember a step function change sort of around the holidays last year.
And I think that's when we started to think maybe this might not be a completely crazy idea to have, you know, Slack sort of act as a mix between like an IDE and like a GitHub for your team.
It's not replacing either of those things, but it's kind of bridging some of the work that those things do into a channel.
People, I think, started to see their clods or their codex agents, whatever coding agent they're working, started to see it a little bit more like a teammate, that it started to be like, okay, that's going to make sense inside of Slack.
The permissions model is really interesting.
And I think the truth is we're not actually making that decision of where the context is given to the agent.
We're giving our...
users that ability.
So today, an agent that's working inside of a channel has access to that channel.
It could have access to, you know, depending on how it's installed, it could have access to all of public channels inside of your instance.
But it's really you're deciding where the agent gets the context.
And with code channels, the thing that's really interesting is when you instantiate it to make that PR, it's just taking the context from the channel, from the conversation that it was instantiated in.
So it's not, you know, rooting around in random corners of your Slack.
It's really taking that.
grounding context of the conversation that you were just in and using that to inform its decision.
It may have context about Slack from, you know, other interactions that you've had with it.
It may be building its own memory system.
All of the agents that operate in Slack kind of manage their own memory in their own ways.
We don't currently have a service for memory management specific to agents.
It's something we're interested in thinking about.
We're really basing the context off of the same exact permission model that you have inside of Slack.
And it turns out that that model of channels with, you know, files and conversation and app access, that actually is a pretty durable model for what agents need in terms of permission and context.
Stuart Butterfield, who I worked with for a very long time, very closely.
These are called channels arbitrary containers for digital objects.
At some point, Canvas has inherited that definition as well.
But it turns out that's what agents really love is arbitrary containers for digital objects that they can then take and turn into, you know, knowledge or understanding or the simulation of knowledge or understanding.
Right.
And that that's the model that we're working off of.
You have less, I think, of a chance of an agent gaining access to information that it shouldn't have access to from Slack.
You have more of an agent operating in the loop with humans.
So it's really easy to create these loops inside of a channel.
The notification system inside of Slack is kind of built for loops, human loops in the past and now agent loops today.
And I think.
I am constantly, I would say I'm constantly surprised by the ways in which the primitives of Slack just need like a little bit of zhuzhing to make them work really well for agents.
And what we're hearing from the frontier companies is that that's what they want, too.
They want their agents to operate a lot like the ways that people have operated.
And a lot of the core concepts of Slack and the flexibility that Slack has, I think, lends itself very, very well to having both.
broad shared context and very specific grounded context, depending on the constraints that you would like your agent to operate in.
To your point about Slack being well set up for this, I mean, A, there's just a ton of information flowing there, right?
So you can decide what to provide.
B, Slack has been set up with access permissions.
You have private channels.
This is not a new primitive for Slack.
And so I can totally see how as we start to add what I would think of as digital co-workers.
I wrote a piece on this a couple of years ago, calling agents at the time, like, you know, your junior digital co-workers, and sometimes a little more senior now.
I mean, like, it just makes so much sense to have them there where other work is happening if you're a distributed company in any form.
And mechanically, I think it's interesting to talk about specifically what Slack code is as well, because...
You and I are both jumping in and be like, oh, yeah, well, I mean, like we interacted with coding agents in Slack before that.
Not everyone has done that.
Like I have a Hermes instance running on my personal Slack that I use for this podcast.
Lots of people are not doing that.
Some are.
But what actually happens mechanically when a code channel comes into existence?
What's happening?
Yeah.
Yeah.
So in order to have access to any of this, first of all, you need a coding agent to live.
in your Slack.
So first, the first thing you need to do is go download one of our launch partners right now.
So you could get, you know, the Anthropic agent, get Claude, get Devin, get the GitHub agent, get that inside of your Slack.
At its base, what's going to happen is that agent, when you at mention it, so you basically tag it into your conversation, it's going to have access to a number of APIs that humans don't have access to today.
What it's going to be able to do at that point is to spin up a channel.
There's a special channel.
We're calling them code channels that has some unique affordances that normal channels don't.
For one, it's going to.
have like an entry point in the channel that you created in that's going to allow anybody who was in the previous conversation to now join that coding session.
When those folks join the coding session, they're going to get authenticated into basically a development environment.
Depending on how the agent's set up, they'll have suddenly access to a whole bunch of development tools, which is amazing.
As somebody who is not a developer getting access to developer tooling.
is probably the biggest hurdle for my personal development.
I think it took me two months to get my Cloud instance set up, like all everything right.
So instantaneous access to being able to commit code.
You'll also be able to see a number of things about what the agent is doing.
So the agent can publish special context to the composer, for instance.
It can post code diffs in the channel as artifacts.
You can see HTML being rendered that the agent is developing.
You can check out the code.
You can do anything that the agent could do inside of a development environment, directly inside of Slack.
And then we're pulling a lot.
We're asking our partners, and the partners are actually ones developing this, to pull a lot of the development context into the channel and push it to the Slack channel itself.
The other thing that's great about all of this is because channels...
tends to clutter up one sidebar, we all know.
And you might be thinking, oh my God, the last thing I need in this lifetime is another channel.
The channel actually winds down when the task is completed.
And I think that's a really cool thing about, that we've sort of discovered in the building of co-channels, is that when you tie a channel explicitly to a project lifecycle, You can do a lot more active channel management and that can help with things like noise as well.
So, I mean, really at its base, what's happening is that the agent is accessing a whole bunch of APIs and kind of building its own little development environment for you and all your friends to be able to build with it.
I find this fascinating because one of the things I learned.
as we were preparing for this episode, is that Anthropic say they now do the majority of their coding in Slack and that this usage pattern is part of what led to this decision around code channels.
Can you tell me a bit more about that?
Yeah, so we work really closely with Anthropic.
They're one of our best partners.
And they...
push a lot of code through Slack because it's where the conversation is happening.
I think if you talk with anybody at Anthropic about what it looks like to develop product at Anthropic, they are not generally writing really long product requirements docs.
They're not generally even like filing bugs necessarily against a project.
An issue is mentioned in a channel and they at mention Claude and then Claude goes and does the work.
So they've really shortened the loop.
between problem discovery and like product execution.
And that's why a lot of the code is being pushed through Slack.
It's not because Slack has the most wonderful interface.
They invest a lot of time in their cloud interface.
It's because that's where the conversation is happening, where somebody says, oh, wouldn't it be nice if, or I would really like to, blah.
Or I noticed this, you know, unfurl.
This is an example for me today.
My boss was like, I noticed this unfurl is really not looking really great on this message.
So like the message attachment looked really bogus.
And instead of now bugging me and my direct, which he, did do first, he then was like, hey, spec, that's our internal coding agent.
He was like, could you just fix this for me and propose some alternatives?
So it's shortening the distance between I notice a problem and I can fix the problem.
That's really the thing that separates these very, very AI forward companies from the folks who are just using AI to maybe do the same thing that they were doing before a little faster.
And it's not, I would say it's not just anthropic.
Like we heard the same thing from Devin.
I've heard the same thing from the folks at GitHub.
Like anybody who's trying to really shorten that time from idea to execution in a nonlinear way is thinking about how can I get the tools as close to the conversation as possible?
Because the conversation is where.
the issue emerges, right?
You can imagine other kinds of flows flowing off of other systems of record as well.
But the thing that's challenging about that is you don't always have eyes on.
So like if you have it, just tickets are being filed in, you know, your JIRA, your ServiceNow, and you have agents just executing off of them.
You have to have a lot of trust in that agent for it to just go do that automatically.
And a lot of people aren't there yet.
And a lot of those systems can also be really clunky and cumbersome to work with.
So in a lot of instances, it's just easier to send a message and then tag in your old pal Claude to fix it, you know?
Totally get that.
I think I have a good example of this actually in my own work where I do automated transcription of my calls, either with Gemini Notes or through Granola.
Claude workflow, or it works with Codex as well, that just goes through and every time notes appear in my inbox, it pulls them and says, okay, let's pick up all the action items here and let's either file them or get started on them, depending on the category of them.
But there is still a trust barrier there where it's like, yeah, I know I said a bunch of stuff that I'm eating, but how good was the transcription that was just taken?
How accurate is this agent in understanding?
the context that I've already pre-provided.
And I use like my own context harness for that is how I think about it where it's like, oh, here are all the things I'm working on.
You know this.
But there's, I still have an approval step for most of this baked in for myself because yeah, there is a little trustworthy.
And that's just with me.
That's not with me having a bunch of coworkers who I am.
That's just for my podcast.
I don't have five coworkers who are trying to go back and forth on something.
How do you handle when you've got multiple people trying to steer one agent in parallel in that code channel?
Well, I think this is where culture actually becomes really critical.
And at Slack, we've always had a very collaborative product development culture where product managers, engineers, designers tend to work really closely together, very synchronously.
One of our product principles is prototyping the path.
We don't really believe in writing really large PRDs and then shipping them down the line.
A lot of the product development that we do internally is about touch and feel.
It's about getting something like it just right.
And what I've experienced internally when we're doing multiplayer coding sessions is that if there's a high level of trust amongst the team and...
I know that my lead engineer is going to be able to steer the agent more correctly in terms of, you know, the product, the engineering quality, the code quality, the security.
It's going to know why the test didn't pass, et cetera, et cetera.
The designer might have some input on design.
I'm going to have input on a lot of things.
I also generally assume that.
The engineer will have some input on the product as well, the designer.
But if we all have a lot of respect for one another's expertise and we hold our ideas a little bit loosely and we know that like, you know, we might need to come up with a few options, might need to iterate to get to something that feels good.
A multiplayer session can be really great.
I think the same thing is true for engineering only coding sessions or multiplayer interactions where, you know.
A really good engineering culture has a process around code review and has a process around even like pair programming.
There's culture that's built into that.
And if you don't get the culture right, you're not going to get really good code reviews.
You're not going to get massive PRs that one person is just going to plop on your lap and tell you, figure it out.
And I think we're all kind of figuring out what that culture needs to evolve to as we move to agents.
Not just in terms of like, how do you actually do a code review when you have a whole coding agent factory just like writing code for you all day long?
But, you know, how do we how do we inflect on trust?
How do we inflect on taste?
And I think doing that together will actually be much more productive, even if it feels a bit rough in the beginning and maybe, you know.
you're steering the agent in different directions, it's better to be doing that in the same session because eventually you'll converge.
Whereas if you don't do that in the same sessions, you're going to get very far in your opposite directions and then you're going to have to come back and reconcile.
I think it's similar to, you know, I am not an engineer, but I've worked in very engineering heavy cultures.
And it is my understanding that you should generally not keep your code in a branch for too long.
and then try to merge it because that would cause you a problem.
But if you're in a multi-agent channel or a multiplayer agent channel, you're not in a branch.
The branch is public the whole time.
And I think there are cultural shifts that will have to happen to make that work depending on your team.
But some teams are already kind of built for it.
They're like, yeah, this is great.
Let's do it.
It's always...
You know, there's always the engineer who loves sitting next to the designer.
And if they could give the designer just the tools to be able to push things a little themselves, they would love that and vice versa.
And so I think as our roles are kind of collapsing and we're all figuring out what does it look like to go from that idea to code now, doing it as a team is going to be a lot more productive than trying to do it each individually on our own.
Season four of Chain of Thought is also presented by Walrus Memory.
I spent much of this year talking to guests about agent memory, and we're all having challenges that go beyond simple session handoff.
You explain your code base to one AI coding tool.
You get it tuned to what you need.
But when you look to handoff to a new model family, you find yourself having to confront the same memory and context problems.
Walrus Memory is solving agent amnesia with a portable memory layer for agents.
Walrus Memory takes your agent's memory anywhere you need it.
The context your agent builds can be read back later from a different app in a different runtime, weeks out, and you set the rules for who reads and writes it.
Python and TypeScript SDKs with native MCP support.
I'm glad to have them behind Season 4 of Chain of Thought because this is a key problem confronting AI builders in 2026.
Learn more at walrus.xyz slash cot.
Culture matters a lot.
I'm...
certain there are plenty of companies that are struggling with this transition because they already had challenges in their engineering culture and those blockers are being exacerbated by the massive amount of code that is now able to be shipped.
We have shifted left where the problems are and if you didn't already spend time trying to solve that part of your engineering and product culture, it can totally be something that's a challenge for you to implement.
And I think it speaks to the need to not only solve your technical systems, but your social technical systems, and those have to work in concert together.
And honestly, it also speaks to me about the entire strategy behind what I'm seeing from Slack, where you added Claude Tag, you have an MCP, you've got Slackbot, obviously.
Code channels are the newest example of an argument that Slack has been making for a while that agents should go where the work already is.
But that's certainly playing out beyond coding.
What's driving usage across Slackbot?
Well, I think the thing that's interesting about Slackbot in particular is that the first thing that people generally reach for with Slackbot is just solving problems that they have inside of Slack.
I can't find this.
Can you help me summarize this?
Catch me up on what's going on.
I think the next level of adoption that happens with Slackbot, and this is really what we're seeing.
internally and at some of our customers who have become a lot more mature with it is that they're starting to use Slackbot for more work.
For instance, internally, we've had it a bit longer, but recently Slackbot launched Surfaces, they're called.
So they're like a...
interactive artifact.
It's basically like a tiny little HTML site that Slackbot can build for you based on any number of inputs, including any connected MCPs.
And you can build dashboards with it.
You could build slide decks.
You could build a map.
You could build an interactive report.
You could build a game if you really felt like that was the thing you wanted inside of your Slack.
But you can do a lot of really fun stuff with it.
We've just seen the usage like go crazy.
And I think one of the barriers I think that we're all trying to figure out is how do you have these agents that are inside of your Slack introduce themselves?
How does a person get to know an agent?
And, you know, you get to know a coworker by working alongside them, right?
You get to understand.
what things they're good at and what things you might not talk to them for based on interactions that you have with them repeatedly over time.
The problem is if you're only, say like I have somebody on my team, I always go to them every week for an analytics report.
I never ask them anything else about themselves.
I never ask them, you know, what they're doing.
I don't take the time to get to know them.
I might not know that actually analytics is only like a quarter of their job.
And it turns out that they're really, you know, great at design or they have a passion for, I don't know, music.
And I could actually be getting music recommendations from them.
And I think what I have found both in my personal use, of agents at times.
And what I think we see in the numbers is it's really easy for humans to think about them as just being a tool.
And they ascribe a certain quality to that tool.
They use the tool for one job.
We tend to think of most tools as being good at one thing, even though they could do a lot of different things.
And I think that's a risk with agents.
And actually, one of the reasons...
I think it's really critical to get them in channels and have more shareable social artifacts, even for one-on-one interactions.
So going back again to Slack button as an example, even early on, we just say search summarization, basic Slack tasks.
Then you introduce skills and skills become shareable inside of Slack.
And you can see the usage and the sophistication just grow exponentially as people build skills for themselves and then share those skills with other people inside of Slack because Slack is social.
Next thing is MCPs.
So you have one person connecting an MCP.
And then because Slack is team-based and not solo player, Slackbot now has access to all of those MCPs.
And you could see, oh, somebody on the data team actually thought that this...
HES, this analytics, MCP would be really useful for me.
And I can just get it set up in one click.
So I think having these agents operate inside of a social environment where you can get to know them, you can see how other people interact with them.
You can see, you know, even artifacts of how other people interact with them.
You can see things that they've done for other people.
Helps you better understand how you might use it yourself.
And I think, you know, there are lots of ways you can try to solve for this.
I know a lot of companies are creating their own like repos for skills.
They're creating like learning Fridays where everybody like shares clips of what they're doing.
But the nice thing about doing this in an environment like Slack is that the exhaust of everybody just doing that work just becomes visible to you.
You just see it in channels.
It just, you happen across it and there's a sort of internal viral adoption that can happen in a social environment like Slack.
It's really like figuring out that you have a really killer teammate who can do a ton of different stuff and a lot less like reading the manual for, you know, your new Windows machine, which I think sometimes even that working with LLNs can feel a bit like that.
Agents in Slack are the equivalent of water cooler conversations with your teammates for the agentic era is what I'm hearing from you.
Because I definitely think there's an argument for the value of in-person work at times where there is osmosis that occurs.
You see teammates, you run into them in the hallways and you learn things from them.
And Slack is that central corridor for teams that are worldwide or that are geo-distributed.
And as we work more and more with agents, I think there is an increasing benefit to having a centralized means of communicating with them, or at least the majority of your communication with them, so that that can be consumed by others and they can learn from you by osmosis or by intentionality.
Yeah, absolutely.
I think it's the thing that I keep telling my team is that, you know, as we're thinking about what the future of working with agents looks like.
We have a unique opportunity at Slack to make that future very human.
And I think there's a world where each of us goes off into our own little corners.
We work with our agent in our solo terminal.
And each of us gets locked in with our agent, our agents, our army of clods.
And we reinforce our previous bias.
We become more and more like ingrained in maybe a single track way of thinking or go deep, deep down a rabbit hole.
And that could allow us to be very productive, but it might not allow us to be creative in the way that, you know, we could be if we were bumping into unknown variables like other human beings or other human beings agents who might be doing different things than what you would have expected.
And I think there is something very, you know.
uniquely valuable about these messy social spaces and being able to bring agents into them, I think will allow us to maintain a lot of our humanity as we figure out how to, you know, become much more productive and we figure out what access to these like really powerful tools will allow us to do in the future.
I think it'll...
Having agents in social spaces will allow us to just dream a lot bigger.
This is a really interesting point.
And I don't think you're wrong that there's a lot of value in this effect because...
Otherwise, I think we see a lot of folks who feel like they're constantly chasing information where it's like, oh, what's happening on Twitter?
What's happening on LinkedIn?
You know, I need to read the substack, watch this podcast.
You should watch this podcast for the record.
And figure out like, what's the new thing that someone's doing?
What can I learn from them?
And there is a ton of value in that, but it takes a lot of work beyond just doing the work.
And so if you can create situations where while you're doing the work, you learn from others.
And from their approaches, there's definite benefits to that.
But I can imagine for certain teams, this comes back to culture again, to your point earlier, of how do we set up our business and our lives for a future where we're not just collaborating with humans, but we're collaborating with agents.
And many of us are already there today.
Do you have thoughts about how other leaders need to be thinking about that cultural org chart piece?
As I know you were on Dev Interrupted, my old show, huge fan of their work.
You talked about companies putting hundreds of custom agents onto their org charts.
How do we have to change what we do to adapt to this reality?
Yeah.
Also, as soon as I mentioned the Slack code launch, somebody immediately was like, but who owns the code?
Like if a product manager ships it, who owns the code?
clear one correct answer for what it's going to look like for every company.
You know, in just the same way that there isn't a clear one single answer to how you should organize your company.
I think it's that sort of serious of a question.
It has as much gravity as what is my org structure going to be.
And, you know, I remember when I was first entering the tech universe.
It was a time of radical transformation.
Lots of companies were growing extremely, extremely quickly.
And people were experimenting with a lot of new organizational models, right?
There was like the no hierarchy model where everybody could just do whatever they wanted and we would figure it out in the end.
There were like a lot of like almost the opposite, like GM, like fully integrated business models.
You have the matrix model, which is sort of like what Slack still operates as today.
And I think we're going to see a lot of similar organizational experimentation with agents.
I think the one thing that I would piece of advice, I guess, I would give to companies who are trying to figure out, like, what do I want my culture to look like with agents inside of it?
Is to write down the things that you really love about your company culture.
Like, just, you know, what is your culture?
What do you want your culture to continue to be?
Again, when you're a high growth company, you think about this kind of thing a lot.
You know, what are the things that we want to keep as we grow?
Because culture isn't, you know, something written down in documents.
It's actually how you operate.
And you have to look at how you're operating and how it fits against that culture.
Transversely, you also want to say like, hey, what are the things we don't want?
Like, what is like super not working for us?
And what are things that we think an agent could solve?
And then.
Figure out how to solve that with agents.
Don't just assume that the agent is going to solve that.
So, for instance, if you have a very cumbersome development process that involves, you know, lots and lots of checks across many, many different teams, don't just assume that, like, having faster...
coding agents is going to solve that problem.
Because now those coding agents, whatever code they write, however much code they write, it's still going to have to go through like 20 checks from 20 different teams, unless those teams are also starting to think differently about the value that they create inside of your organization and the services that they provide.
And so I think it's almost like at a whole company level, you have to figure that out.
At an individual team level, you have to figure that out.
The other thing I'll mention, just because we were talking about shifting left earlier, is I think everyone I'm talking to who's doing this successfully is also thinking from an outcomes-based perspective.
So as an individual, my job as the product leader of Slack is to build a great product organization that delivers incredible products to market.
That's my job.
My job is not to hold quarterly all hands.
My job is not necessarily to build a gigantic team.
My job is not to have everybody write the best PRDs ever.
My job is to, at the end of the day, make people's working lives simpler, more pleasant and more productive and to build an organization that can achieve that.
And if I'm not doing that, I'm not doing my job.
And so I shouldn't I should think about a gentic.
outcomes that service that goal instead of just thinking, how do I help people write PRDs faster?
Right.
Like that might not actually be the pain point.
Maybe we just don't even need PRDs.
Maybe we just chuck the PRDs entirely.
And so I think where I'm seeing people kind of get stuck is when they're thinking about automating a process.
And I think that's really like enticing because it's so easy and it's just right there.
But then you end up automating lots and lots of processes.
And you just end up with the same kind of bottlenecks we were talking about before.
Because again, probably on every one of those processes, you want to have a human in the loop.
And now you've just created like a massive chain of make work that now the agents are doing instead of the people.
Season four of Chain of Thought is delivered by Sphix.
We spend a lot of time talking about what agents need in production.
And one of the least glamorous answers is the vets.
Your customers want agent workflows that react to things happening inside your system, which means your API needs webhooks that actually work.
Not just a post request and a prayer.
Retries, ordering, idempotency, replay protection.
Sphix does that as a service, and they wrote standard webhooks.
The spec that Anthropic, OpenAI, and Google bailed against.
If your API doesn't have reliable webhooks, that's turning into a lost deal.
Join Brex, Drada, Daytona, and many others on Sphix.
Get started at link.svix.com slash C-O-T, or go to the show notes to grab the link.
Qualified startups will get $12,000 in credits, $50,000 for YC companies.
I can't recommend Sphix enough.
I'm a huge fan of their open source project.
I've actually contributed a bit myself, and they're so easy to integrate with.
I think you'll really enjoy it.
Check out Sphix.
Head.
Link.svax.com slash C-O-T.
One of the ways we can solve this over time is through recursive self-improvement or learning loops, if you want a more simplified version.
What is Slack doing to enable learning loops based off of past Slack code or other agentic interactions in Slack?
Obviously, this comes down to some extent to how teams want to set up their context sharing, their memory, etc.
But what are you doing to set up for that feature?
Yeah.
So I think my answer for right now is that having all of the context available inside of Slack gives you really great up to date, like access to, I don't know, almost like case law, like everything that's happened before that looks similar to this.
So one thing agents are really good at doing inside of Slack with Slack data.
married to coding data or married to Jira data, ServiceNow data, is to be like, oh, this incident looks like this other incident that happened before.
And it's not just because the code looks similar.
It's because the way people are talking about it looks similar.
You know, there's human patterns that you can attach as well.
And so I think that that sort of...
fact that you're building an archive as you're interacting inside of Slack gives you a self-improving loop.
What we're not doing actively yet, but some agents are doing for themselves.
So like, for instance, Claude Tag does this.
We'll build memory on like a per-channel basis.
So it's writing rules to make itself better at being Tag in that channel.
And I think that's something that over time we can think about.
How do we...
help just build that as a primitive into our platform so that you could have multiple agents sharing the same memory.
Agents could, of course, you know, have their unique memory as well.
But are there things that we want to just write sort of to like history so that people can access that more efficiently instead of having to access a big chunk of the Slack corpus and then make sense of that?
That's definitely not something we have yet, but it's something we've actively been talking with the team about.
I love that you brought up case law here.
I actually just sat down with the CTO of Thomson Reuters to talk about their new model, Thomson, they launched that's focused for legal AI.
And one of the big things they did, because it's so important in their field, is they have a really crucial, like, pageant pending, it sounds like, citation ledger that the model always has to use.
Are you exploring...
citations of other Slack conversations?
Is that something that's already being implemented within some of the agent capabilities in Slack?
Yeah.
So a lot of our most used sort of APIs and the APIs we're most focused on making agentic at scale right now are related to search.
So what most agents that are operating in Slack will do is do a quick like, how do I use Slack context to ground myself to make sure that I understand what I'm doing and I behave correctly?
And I think, you know, people, it could be obvious to think about, of course, people want their agents inside of Slack because that's where people are interacting.
And that's great.
But actually, the context is the real nugget.
It's the thing that makes your, you know, your instance of Claude in your Slack really good for your company as opposed to, you know, You're off the shelf, Claude.
And I think that's one of the really big appeals of something like Claude Tag.
Obviously, you will get more interaction with it as well because it will be in the place where people are.
Then there will be more exhaust.
And you get this really amazing virtuous cycle where people can sort of like leverage the Slack corpus to cite it.
Slapbot itself, our agent that you get on board with Slack, is very, very heavy on citation.
So it almost...
always cites something from Slack at a minimum.
It very rarely just tells you something.
Like, I think I've seen it happen like once or twice.
But we've really, you know, thought carefully about the system prompt and tried to ground it in the context of Slack as much as possible.
And as you connect more MCPs, it just gets more and more grounded in more and more context.
But the nice thing about Slack...
for better or worse, is it's a place where everything kind of ends up, you know, the files that you're sharing, the the HR benefits, you know, that need to happen.
Like it ends up sort of being this accidental knowledge management system.
And it's not always the best at knowing what's correct, but it's really good at knowing what's most important, most recent.
And it's pretty good at knowing what's most engaged with.
And if you put those things together, you mostly get what's most accurate to the moment.
Like, especially I think in today's world, there's a huge recency, you know, benefit.
Like if you can get the most recent thing, it's much more likely to be correct than an outdated knowledge management system.
And so my hope is that over time.
you know, as companies are normalizing a lot more into Slack, it's not that we would completely overtake the knowledge management burden.
You could choose to live on the edge and have no knowledge management whatsoever inside of your company.
And that's fine.
Early days at Slack, we definitely had nothing other than Slack.
That was it.
You had to go to Slack to find what you're looking for.
But Slack can definitely be the sort of like, the augmentation to whatever knowledge management you're trying to do and can help actually you get a lot more benefit out of that as opposed to, you know, a lot of the companies I hear who are trying to build their own sort of Slack bot, their own out-of-the-box general purpose.
Everybody in my company has access to all of the information that's important.
They end up basically becoming librarians and having to hire.
sometimes even hire teams of librarians to build the knowledge store that those agents are operating off of.
And my experience has been, at least, that you can get a lot of that for free by just pulling it into the conversation that people are having.
Because the conversation is often far more accurate than the moment that someone has stopped to write it down in a brief.
Yeah.
One of the big benefits, obviously, of agents in Slack is the tribal knowledge piece where there's just bits of information that are there that unless you are in calls, you may not otherwise get if you haven't been around the org.
And I find it really interesting and I think smart that you are using both interactions on a channel, like something was said, here's what the interaction looked like, and recency to prioritize.
That probably does get you most of the way there, given how fast things are changing.
You know, if something is a recent response, it's probably more up to date.
But I can imagine that there is just a challenge with context bloat because so much happens in Slack.
And then if I start pulling in my Salesforce or other CRM, and now suddenly I'm getting all these recordings of sales calls or whatever else, which is very common, there's just a ton of information.
How do you prioritize in those situations, depending on what you're trying to do?
Yeah.
So we have, I would say we have two answers for this.
One for Slackbot internally, and I have a less good answer for you for external agents, but I promise to try to make that better as soon as we can.
So on Slackbot, we spent a lot of time optimizing the Slackbot search.
And it's like, it's a multi-pass search.
It is, it's doing a lot of work to try to get.
through the context to get the right context before it goes to the LLM.
So we do a lot of work in the application layer to sort of like hunt around in the search tool to find the good stuff to bring it to you.
We don't yet have that available to third-party agents.
They're hitting our search API, which is good, but it's not that sort of like a gem tick multi-pass.
And so one of the things we're working on in the second half of the year is bringing more of that process, like doing a lot more data handling for agents that are working inside of Slack so that you don't have to do all of that as a developer.
I don't think you would ever take away the raw sort of data hose where if you want to do all of your own context window management, go for it.
If you want to just get an agent set up really quickly inside of Slack and have it be able to operate off of the Slack context instantaneously without a lot of like extra work to manage rate limits and manage just like data context window management on your side, we could do that a lot more efficiently for you.
And that's something we've heard from customers who are really invested in making these sort of.
making their own sort of Slack bots, making their own like Uber agents run inside of Slack.
They want us to do a little bit more of that data processing for them so that they can do more of the marrying the data with other external sources as well.
Because the Slack data is so robust.
I guess for lack of a better word, it can sometimes be a bit challenging to manage.
Yeah, I have definitely had that experience when I'm trying to find something in Slack where overall the search is great, but there's just a lot in there.
Right.
Or if you're like, I will sometimes be like, I want you to, as a CPO, I'm like, I want you to catch me up on what's going on in this project.
And so it's not a specific channel.
It's like got a fan out.
It's got to look over all the channels I'm a member of, find anything related to the project.
It's probably doing some like, it's traversing some like.
you know, adjacency.
So it finds a keyword and then it'll spin off five searches that have related keywords that sort of like give it a cluster of interest and then it'll pare down what's in that and then it'll use that to build the summary.
And I think that kind of multi-pass search is a thing that that's the kind of thing that we would like to try to make more available to folks building on the platform as well.
I'm curious if you personally are using mostly prompted agents or are you do you have like a variety of projects where you have an agent that checks in every week with you and says hey here's what's happening I'm not sure how it would work for your role honestly I got both I have both so It's all so I will say I am a heavily devoted user of Slack bot because I promised the team that I will push it to its limits as much as I can.
And so I have a lot of recurring tasks that Slack bot does for me.
Everything is basic as like, tell me whose birthday is coming up this week, because like, I'm going to forget.
And I will ask it to tell me that it can it can do that based on.
Other agents and also I think we're working on getting it more access to like profile information and workday data potentially.
So right now it reads it from other messages that I'm choosing not to read because I decided it's all noise.
The next is I have it do a web search and it's not I didn't tell it to do a web search.
It decided to do a web search.
I told it that I wanted to know what's going on in the industry with AI competitors on a weekly basis.
And I want to know the most recent news.
So Slackbot knows me.
It knows my role.
It knows the things that I'm working on and what I care about.
It will then look across who it's decided are competitors.
I can inflect on that, but it did a pretty good job.
And then it will tell me the news that's relevant to me, given my job as CPO Slack.
I don't know, it does, it tells me what's shipping every week.
It gives me red light, green light, yellow light status on a number of things.
And then I also have a chief of staff and an assistant that use it really aggressively to build content for me.
So that's been fun.
I have to do a daily briefing for me as well.
And I started sharing that with my assistant.
And my chief of staff, because I have access to a ton of stuff that they don't have access to.
And that's really been illuminating because they're like, oh, now I see why that person is hollering at me to have that meeting.
It's because this really important conversation happened because I'm not doing a very efficient job necessarily of passing all the information through.
Sharing context.
A much better job than I am.
Yeah.
Awesome.
Jamie, I've really enjoyed this conversation.
It's been fantastic talking to you about how Slack is building this next era.
And I can't wait to see what else you have in store for us at Dreamforce and beyond.
Is there anything we didn't touch on that you want to highlight here as we start to wrap up?
I mean, I think the biggest thing that I kind of want to just sort of double down on as we think about Slack code is I really think that this is just similar to how You know, the coding agents got a lot of traction and you see a lot of those coding agents turn into general purpose knowledge work agents as they got just generally better at things.
I think code, Slack code and code channels is just a V0, a V1 of what multiplayer AI could look like.
For engineers, the PR, you know, for you, it might be a podcast.
You might want to have one for per episode, you know, potentially where you're working with your agents on an episode.
It might be for me a deck I have to deliver to Mark Benioff.
Anybody on any team is going to have collaborative work that they need to do and having a place for that work and the agents.
to come together around the life cycle of that project, I think is going to be hugely beneficial.
Yeah, like I said at the start of the episode, I think there is a massive opportunity for Slack to be the context harness for enterprises and the central plane where most agents are operating and interacting with their human team members.
So it's going to be fascinating to see how you put it together.
Jamie couldn't be more excited to have had you on the show.
Is there anywhere for folks to go to follow you or follow your work?
Oh, you can follow me on LinkedIn.
I try to post on there pretty regularly.
And I post musings on Medium if you're into that as well.
But Slack.com has the latest on everything that's going on with Slack.
The team is doing far more interesting things than I am, I promise.
Well, I can't wait to explore it.
And you're encouraging me to try to do even more with my agents in Slack.
So, Jamie, thanks again for joining us.
And thank you, everyone, for listening.
We hope you enjoyed the conversation.