Community Session: Chat SDK AMA

Hello everyone. Welcome to another Bersell community session. This week I am joined by Malta and Matt. And I just want to remind everyone if you are participating in the chat, please follow the code of conduct. But we are welcoming any and all questions about chat SDK. Welcome guys. Awesome. Thank you for having us. Hi everybody. I'm Matt. I'm joined today by Malta and we are going to talk all things chat SDK. Uh if you're not familiar with it, it is an open TypeScript library we've built so that you can bring your agent to your users no matter what platform they are on. And to get started, I want to hear the origin story. So where did this all come from? Yeah, so hi again. My name is Malta. I'm uh both the CTO for Cell but also the author of Chad SDK. So, um I'm in that role here today. Uh don't ask any strategy questions. Like the the the origin story of Chad SDK kind of came kind of together over like essentially all of 2025. Like we were investing more and more into especially Slack bots and there was always this like question like can we ship this to other platforms besides Slack? And the ultimate answer was always no because it would be like quite a bit of work and only like some incremental value and then we wouldn't dock for ourselves which would be so much more difficult. And so we you know we never really did it and I so I you know as I was looking at these apps I was always thinking can we can we make a can we make a nice way of of building this in in one shot. Um, but then I looked at all these APIs and was very very like afraid really of of building uh like on top of them because they seemed so daunting and and and and multiaceted. Now fast forward to the very very end of last year uh Opus 4.5 came out and I was like this is my time and it was the holidays. It was the holidays. Yeah. And I remember saying hey Malta what does this look like? How are we going to do this? and you came back with not an answer but an actual library to answer my question. Yeah. Yeah. Yeah. So I was like I was I was I was I was hacking around. Um, and like the thing is about this type of thing is that it actually is still very painful to build because there's real APIs and they're not really in the training data and so like you still have to like do a lot of uh figuring things out, but at least you you kind of some of the majority of them work was was taken over. Um, and so yeah, I I still I decided to like give it a go and kind of over the holidays built the initial version of of of chat SDK. um took us like another months or so to kind of get it ready for for for shipping. But that's the origin story. So I think it's it's like it was kind of obvious that this was needed, but like it was also too daunting to build and then AI kind of helped us push it over the edge. Yes. Everyone at Versell is a builder. So Amy, do you want to kick us off with our first question? Yeah. You know, anytime we have a new open source project, I think one of the most common questions that I see is how open is it? Like is this locked down to just forcel? Do we need to use versatile AI infrastructure or can I use this anywhere? Definitely. I think especially with the chat SDK, it is just a TypeScript library and it's not even tied to a front end or backend framework. You can use this in any JavaScript application. Uh you can host anywhere that you can host JavaScript. You can ho use the chat SDK and it's not tied to any other primitives of the cloud other than just a serverless function to handle a web hook event. What do you think, Malta? Yeah, exactly. Not even a serverless function, right? Like it's literally like it's really just a library. Um it's like React like you know where you can just you know you can use it wherever. Um it it's not tied in in any way whatsoever to to structure. You can think of it as just it's not chat SDK is not the agent. It's just the layer to take a web hook event and give the context to an agent that you've built with any framework that you've chosen. And then I think a really great example of this is recently, you know, we built the first version of the teams adapter and now Microsoft Teams team has taken ownership of that as well. Yeah, that's right. I was actually super super blessed by this because because uh it's it I mean yeah that I was fighting getting teams to work um and they not only did they take over maintenance they they rewrote the adapter because they apparently shipped a new API um and they essentially just ported um their the existing implementation to the new API which I think is a win for them. So they get distribution on the new API, hopefully fewer users on the old stuff. And I mean, we very much appreciate it because there is quite a bit of effort getting this to be great on every platform that we support. And a huge win for developers because they didn't have to go learn the new Microsoft Teams API, but their application or agent now benefits from the new adapter. No code changes needed on their end. Yeah. And this case is actually completely backward compatible thing. So like you have to do nothing at all except upgrade chat SDK and and you get to take advantage of the new API and and you know I mean they might have handled a few edge cases whatever like you know since they're the actual teams team they're they know best how to use their API. Um but but as the user of chat SK you don't ne necessarily need to know this. Um, by the way, it's actually something we we I I think one of the value of chat as a KK is obviously it's meant to be used in this like multiplatform fashion, but I I would actually not be surprised if most users actually don't use it that way. Just use it for one like platform. Exactly. Um, at the same time, right, but you know, all these APIs are so like they're often they're kind of they're either badly documented or they were not designed to be used in an idiomatic fashion in like a TypeScript ecosystem. So I think people are just like having an easier time using chat SDK um even if it's only for one of the adapters. Yeah. And that's what we did with Vzero. We built Vzero for Slack with the chat SDK and I think the best part is is we choose to go to another platform. It's a very easy engineering effort to go to that new platform. Um the next question I hear a lot about and then we'll go to the live chat. JSX. So I built a lot of Slack agents prior to chat SDK and I had used block kit and I was used to react and I love JSX and that was probably one of the biggest uh benefits and something I was so excited about with chat SDK was bringing JSX. So what was that like? Yeah, I think the the the evolution of chat decay was that you know I obviously wanted to have support for interactive elements and so I was first thinking about how to properly abstract this in in in you know in inside of uh the JSDK and the the two things that were kind of going on in my mind was that first of all there should be great markdown support. Mhm. um because that's what the you know obviously chat SDK can be used for nonAI applications but it's really meant to be used in this fashion where you hook it to an agent so that for that markdown was really important and the other thing was that I wanted like regular TypeScript Javas to have a really good time um and so the idea was essentially to say okay we do have this like internal representation of the UI that can be rendered to the to the different chat bots But and and then map that intermediate inter representation to like underlying APIs like blockit. Mhm. and then have on the other hand essentially quote unquote front ends which are like the the the the representation that you as an engineer use right and so that reusable that could be markdown for example right you parse the markdown to an a then you render it to bucket or you uh have the JSX which is more or less directly mapped to the intermediate representation right um and to maybe for folks who don't know as well how how JSX works, right? So, JSX is essentially syntactic sugar for a function call. And um this function call is a function call create element which takes as a first argument the name of the element and then the props and this is a web this is a H1 H2 paragraph. Exactly. That's what it's for, right? But like in reality, you can do anything you want, right? uh like it's because it's just a function call and so you can you can write override that create element function to be uh you know whatever you like including um creating the elements from the intermediate representation of of of chat SDK. Um, the only thing that actually makes this somewhat complicated to build is that this is supposed to work inside of existing React applications and because JSX is not a namespace thing, you don't import it in any way, right? Um, you have to like make sure that you, you know, don't break like say Nex.js or remix, right? Um, but then also it's supposed to be used in applications that might have no idea what React is and what JSX is. And so it supports both these cases. So like it it both plays well with existing JSX applications and it introduces JSX as syntax where that's not so far supported. I if I could challenge the community, I would love to see Shad CNN for chat platforms built with JSX. That is something I I know someone out there is probably already building and I can't wait to see that. Um, and first community question, which platform specific edge cases do we as developers need to be aware of when implementing the SDK? And I think this is a great question with JSX as well is because, you know, Slack Blockkit has a lot of rich interactive UI. Yeah. And other platforms don't have the exact same native rendering. And I know that when we built this, we supported really good fallbacks. So if you use the chat SDK in a way that another platform may not support this, we've we have created awesome defaults and fallbacks for you as a developer. Yeah, exactly. So I think there's there's there's there's multiple elements, right? One of them is the u the rendering layer. I think actually the the starkkest difference though is that originally JSDK was very much designed for platforms that have threats. Mhm. Um now obviously even within them not everyone actually uses those threads, right? Yes. And so you do have to kind of consider that a little bit but um it was very much designed to be used in that fashion. But then people really wanted WhatsApp and Telegram um and we'll add probably iMessage and everything else um in the future. And so for for for that world um you have to understand that there are different paradigms of using a chat app and this cannot be properly abstracted at the chat layer because again like you don't really you have to support both right like and because um so so if you if you work on um in WhatsApp you have to understand that these kind of messages are more or less contextf free um so that's that's that is one thing and and so I try to overall is not meant to be like completely favoring over all differences. And then on the on the UI, it's definitely the case we're always trying to have a feed fallback so that you can write the same code and it kind of does make sense everywhere. Um, and we uh I think in practice it works really well, right? Like in practice the the things you actually want to have supported is supported really well. And uh so I think at some to some degree you all have to do manual testing and see if everything kind of works out the way you want to but um we haven't really seen a case where um people are really struggling with a crossplatform site and also a great case for open source because the community is going to help us show what in practice really means. Exactly. Right. Like I think the um like you will find issues here and there. um please report them and both accept. Yes. Our next question um it seems that chat SDK by being lightweight and stack agnostic in its paradigms is separating the chat from the rest of the agents harness. Do you see a future where with advances in other modalities something like video chat SDK will be possible? Very interesting question. Uh I'll start by saying you're correct and this is something that I I've had to repeat a couple times is chat SDK is not AIS SDK and AI SDK is not chat SDK. They are AI SDK helps you build agents. Chat SDK helps you bring that agent to multiple platforms. So it is a uh a lightweight and stack agnostic type of paradigm. What do you think of video chat SDK? I I mean I think it's really interesting. Uh the I think before we get video chat SDK, we'll get audio chat SDK. Okay. Um and yeah, I mean usually my take is that you you only add abstractions like chat SDK that make building a classification really nice after you've done it a few times, right? Like so I um we've never built a video chat app. I don't think um but I need to think back but like yeah no no it's it's not time yet and especially as you um yeah you have to be kind of very close to the metal. Um I I actually see most of the challenges for something like this on the communication with the eye models and not so much at the communication um to the to the front end to the user who's um communicating in real time. Awesome. Okay, our next question. Can I train it with Opus 4.6 with stock answers and then have it produce answers for free with no cost? So, I think this question highlights, you know, what is chat SDK and what it's not. And you would never train chat SDK. You're not having to write prompts for the chat SDK to create its responses from. That is what AI SDK or other agent frameworks are for. And so the agent framework is where you write tools, you write prompts, you create workflows and chat SDK is only the layer between the platform and your agent. So hopefully that that helps answer that. Uh our next one from YouTube. Can chat SDK be used to track and manage functionalities between Slack and Jira? Yeah, this is a really good question. Um we do like since JR is in here, we do have a linear adapter. We don't have a GR adapter right now. Wouldn't be opposed to adding it. Hi community. Um but I what I do want to add is because there were some some questions around linear as well and and GitHub for that matter which is kind of in a similar vein. Um the chat SDK again is for for for chatting, right? And so linear and Jira are if you really think about it kind of chat applications that render them in a different thread format, right? And so that's what this is for. Um, if you what you absolutely can do is you can use Jazz to listen to people talking on on Slack and then map that into Jira API calls to do whatever you want on Jira. Right. Correct. Um, but Jessica does not care about you doing things on Jira, right? because those are I mean obviously sometimes you would post a message but you might also like I don't know add a label or change the status of a tab assign it to the right person right and so all these things are not a thing you can do in chat SDK because it's really just for the communication you just use the native API of the platform if you want to make like like complicated things on it yes awesome okay so does it our next question is does it support Facebook Messenger uh what's this I think there's a PR are maybe or since we've since we've launched we've had a lot of interest a lot of amazing pull requests and maybe this is a good time to talk about what is the difference between a uh community adapter and the adapters that we've chosen to build and support. Yeah, it's a good that's a that's a good good question and we have a third category which is vendor official. Yes. Um so the in general the way we think about the things that kind of ship with chat SDK it should be kind of the billion user products uh like Slack teams maybe we'll put it at 100 million users but like you know like very large like broadly applicable type of type of platforms and so Facebook Messenger would fully fall into that. I also don't really expect them to give us a vendor official, you know, but if Facebook would like to it would be nice, right? Like um we we would welcome it. Um so so Facebook will fall into this. Um then what we also what we see a lot are for example companies that do some kind of messaging service or like context management. I've seen a couple. That would be another one. Yeah. Um we can talk about that separately but like let's say you you have like your own iMessage service right send um Sandlue they would make a vendor official one right where we kind of say okay this actually is by Sandlue for sandlue which is comes with a bit of a commitment to actually maintain this over time right and then the third category is everyone here can just make an adapter um you know spend couple bucks on whatever right like it's not so difficult and you can connect to whatever you want, right? And maybe that would be some like random small applications that you know wouldn't make the 100 million user cut off for the main um for the main uh chat SDK or maybe you also like maybe there's a feature that for some reason we're not adding a chat SDK teams adapter. You can you know no one's really stopping you from forking it and making your own, right? like because the adapters are fully loosely coupled and so you can just make your own version and I think it's a good time to talk about okay I want to get started how do maybe I'm new to open source I've never opened a pull request to an open source library but I want to build an adapter how do I get started yeah I think for for adapters it's really worth check thinking about the categories right so if you if it's this like 100 million user product that you want to support um then the right thing is to open a call or go to to chat as a K. If it's um for for something more niche, then you would you know literally just go to GitHub stay in your repository um tell your agent to look at the chat SDK repository how you built an adapter and and essentially do make one, right? And all these adapters are basically they they inherit from a base class and then they implement let's say a post message function which like ultimately would always be like some API call to that to the platform that you want to support um using whatever native SDK or maybe even just straight up fetches um to their API. Um that makes sense. Awesome. We have a few more minutes here. So the next one I want to cover is things could get complex with project using multiple providers and apps. Sometimes humans need to be involved in a decision. How does human in the loop look with chat SDK? So I did a AMA on Reddit and I answered this with the AI SDK. Let's say that we're building with the AI SDK. It has a parameter called needs approval. And if you create a tool that needs human approval, you will listen to that stream. It will come back with a type that says, you know, needs approval. And that's when the chat SDK becomes helpful because you can write the UI needed to get the approval using JSX and that JSX component will render on whichever platform. So if you you build the UI to get the approval once and you can use that with any platform. I think this is probably a question I get a lot because whenever you're building an agent, it's how do I how do I give it enough power but still allow the human to decide when things happen. Right? So there's a I I can give you an answer that's um like very practical and very general and then maybe one that's a little bit more aspirational. But so the the the general way how do you implement human in the loop on chat SDK is that you you delegate to your uh to your agent um that it you know wants to be uh that it wants this this this tool called well to to to whatever answer the question right and at some point the agent gets into the state where it says okay I need approval um then you respond on you essentially post a message to the Slack that Slack thread or whatever you're working on. Um, hey, this user uh uh you know the agent would like to perform this action. Uh, do you approve? And you can use, for example, two JSX buttons for yes and no. Right. And I think we have a pull request for call back URL. Yes. I I don't know if that one merged yet. It hasn't. It hasn't merged yet, but so that's the the more inspirational answer. Um but so for now you know you just get the call back um and you you on the server side say okay now now it's approved and you you resume the agent operation at that moment. Um so that's the that's the that's that's the generally like the general pattern is that you can draw these UIs to the to the chat um chat site that people can interact they can um can give approval and then you proceed work. What we're currently working on, so it hasn't shipped yet, is that we are integrating this um in general with the ability for every time we click a button that it calls a web hook, right? And obviously that could be used in a very very general fashion whenever you have um some kind of web hook system, but more specifically um another things for folks to kind of take a look at is the notion of um web hooks in the workflow devkit. Yes. So I don't want to like like do another whole five minute spiel on work with def but workflow defgate is cell's system for writing durable compute for writing uh so for allowing you to write agents that take work for hours and um one of the extremely elegant things in work for defit is that you can literally write something you make a web hook and you send that web hook somewhere else and then you await the web hook which seems like a crazy thing to do because it might take let's five weeks until a user clicks it, right? But you can actually do that in in uh in in workflow. And so you would then take this web hook and that's what you put into the JSX and chat SDK. And so whenever the user decides to to to actually click it, that magic await just like resolves and then it precedes the agent. I think the first time I saw that magic was, you know, it's very typical the first interaction you have with an agent. It says, "Okay, you need to sign in." Yeah. And when I first tried this out, I had to pull and wait and see, is there been a successful signin? Very ugly, a lot of bugs. But with a web hook, I just waited for a successful sign in. And it could wait 30 seconds, a day, weeks. Uh, and it was magical. It just worked. And that was probably one of the best like web hook call back type of situations I've run into. Um, okay, that's about time. Is there anything you want to say before we wrap? I don't have anything in particular, but like I mean basically like this is just an open source library. We we made it because we needed ourselves from the reaction. We've seen that there's a lot of demand. Um we definitely appreciate uh contributions especially again for on the like we have to like fill out our like large scale um adapter uh kind of repertoire like we um I'm not sure we can do iMessage but we also would love to do our C messaging um we chat uh you know whatever your country preferred feature is um I guess with anywhere there's a thread. Yeah. Well, no. We don't need threats anymore. Anywhere there's a conversation. Anywhere there's a conversation to put it. Well, thank you guys. I appreciate your time and I'm really excited to see what you build with the chat SDK. Thank you all. Thank you guys for being here. There's lots of interest in the chat. So, please uh everyone who's trying it out, give us your feedback. We want to know more. Um, and let us know what what adapters you want to add, what what you want to add to it. Open those pull requests. We want to see it. Thank you all.