Bots That Scale: Nick Thomson of Got Bot

Welcome to the dialogue architects, where we explore how enterprises can thoughtfully design, scale, and govern conversations between humans and machines. Today, we're joined by Nick Thompson, who's joining us from Cape Town, South Africa, the current general manager of Gotbot, a company that's actively consulting Big Brands today with their AgenteGai projects and on LinkedIn, a self-described bot over Lord. Nick, welcome to the podcast. Hey Nick, welcome. So excited to chat with you. I feel like I've seen you in the broader conversational interspace space for a long time now and I'm really keen to kind of hear about your story. One of the things that I love about your experiences, you have a lot of hands-on-keyboard experience with customers and high-level kind of project management experience. So you've really experienced all of the different roles that kind of exist in these types of projects. And I'd love to hear really just to kick off today, tell me your origin story. Where do you come from? How did you end up in the space? What did it look like your journey to hear? Thanks so much Lauren for the intro. It's really nice to be chatting to you. Ross is really deep in a special part of my journey but in a very quick natural, I was running away from sales for a very long time and then six and a half years ago I started a job at GotBot as an account manager and handing a lot of on-the-ground requests. It started very quickly with really jumping into natural language processing and playing around with intense and training with phrases and responses. And then one very faithful day, a senior colleague of mine asked if I could update an API call for one of the servers that we were talking to to fetch information to display to the user and in that moment I wasn't even sure what an API was to be honest. But I thought, look, I'm running away from sales so let's go as deep as we can into the technical side of stuff. And basically from that, that was really the beginning I think of my understanding that there's a limitation with building bots if you don't understand how to write code which can interact with APIs. And basically for me, they're learning what I needed to with JavaScript, with Postman, to then basically building those APIs and then seeing really where that went because I mean a lot of bots just need APIs so if you configure out the way to get the information safely and then show it to the user, it's really quite a copy and pestable exercise. So that was the start of me jumping into the configuration side of APIs with bots. But my deep love I think actually came from NLP and actually interacting with the duckling and entity extractor of RISES a long time ago because as soon as I learned how to write the JavaScript of how to talk to the APIs and fetch the information, the next thing I wanted to do was figure out how I could build and work on something locally because the issue is all of our stuff was in the cloud and you coin exactly build a bot locally and do the thing. So the best way for me to learn about bots was actually first figuring out how to install RISES locally on my computer and then playing around all the different types of content because we were in a place where we were trying to move from an old type of tech into the new type of tech and there's so many cool things that RISES did that's what we were thinking about. So let's try and embrace some of these things. So learning Python was actually purely to run RISES and then I was so excited as soon as I got my action server, fetching real live weather information and I think that's the cool thing with bots is it's actually very satisfying once you you you started the very simple idea of what it can do and then kind of incrementively making it better and more impressive and seeing where the failures are and fixing them and yeah I mean fast forward a few years later I just spent a lot more time training teammates to do certain things so that I didn't need to do all of the on the groundwork and now I spend a lot more of my time making sure that when we're talking to clients or when clients are asking for certain things to be done that I that bit very clear about what is being asked for because the it's very easy to misunderstand and what is being requested and then to potentially even build something that isn't being asked for. So trying to make sure that we actually are aligning on what the intention is because there's 50 different ways that you can accomplish the same thing and trying to just do it in a way that is going to provide return. Yeah I think that's something I've noticed more today than certainly two years ago is how many different ways there are to kind of scramble neck I mean there you could before there is really only so many options and then you really pulled some good bits and pieces out of the Raza archive there from the duckling to you know intent management there's you know now I think folks that are coming into the space from the agente AI arena definitely would would look at those words and think wow you all are a bunch of dinosaurs but they're still active in projects today here and there nonetheless I think it's fun to hear your story because I think that's that parallels very much my experience as well my kind of dive into the technical universe really began with Raza as well I came very much from kind of the drag and drop UI based world of building conversational interfaces and then with Raza you got to move it locally so I think that was that was also a part of my journey either way I'd loved to maybe just to ground our conversation today I'd love to learn a little bit more about your current job role today I got by what are you what are you working on what's your day today activity and then we can dive in because I'd love to hear a little bit more of stories from the field things that you're doing with customers today yeah it's trying to build up it's it's quite a complex quite a complex um role just because there's requests for example where there's technology that's flashy like large language models which everyone wants to have an element of generative AI in their workflows and there's great places for the generative AI but there's also a really great tech in place long before generative AI that can do the exact same job with benefits or more rigid workflows and so what I do find myself doing quite a bit of is tempering down the beliefs of what gen AI is actually capable of because the reality is we've got some excellent workflow mechanisms that don't require any type of gen AI a lot of the time it can just be number selections or read your space to whatever we don't need to always talk to the generative AI to make the decisions so I find myself quite a bit um all things I'm really exciting for all detection things but then also having to communicate the limitations of what the tech can actually do and one of the interesting things is just um with inside africa there's a there's a huge focus on WhatsApp for mobile commas and what what we really find ourselves doing is trying to connect clients who have very high workflow needs so one of our clients for example had so many um tracking order requests as phone calls that were very expensive for them that as soon as we converted that to a link or chatbot workflow that then they could put their tracking order in and then find the information you can very clearly see the increase in uh bot workflows led to a very serious decrease in phone calls so it's not very glamorous a lot of the time but it's trying to find pain points where for example one of the companies that we work with has very complex rooting for certain users so um there's one bot that you can go to but there's essentially 50 different groups that could be coming to the bot in each user has a different group and different groups have ability certain groups can speak to agents certain groups have different benefits and really building this uh menu that can be used by as many people as possible but also being very accustomed to that specific user and one of the interesting things is you just find a lot of clients wanting to still work with number menus instead of button menus some some some industries work really nicely with um button menus that you can kind of navigate your way through but what we finding is that number menus seem to be safe for some things and um building those self-service menus is actually been very helpful for a lot of our clients because last year for example um we were expecting i mean i've seen it get the numbers right in my mind but there were but we were essentially expecting i think it was something like 10 million messages over the course of a month and we received something like 20 million messages in the first three days so we had a very very um and the network that we have is excellent but essentially we needed to scale our systems very quickly to handle the volume because if we didn't scale the systems then there'd be massive delays and the issues it and it became like a media thing where essentially if we weren't going to handle it digitally there's going to be a problem on the ground for the clients so there's a lot of the time and very tense deadlines on resolving problems and some of the really exciting thing actually maybe just another side of it that's um is just touching into um the workflows and marketing mechanisms from advert to workflow to um interaction through a WhatsApp as a channel that's something that's being quite cool where we can essentially send our broad costs to users and help clients manage lists where they can interact with their users and a product catalog following WhatsApp. - That's exactly kind of the similar build pattern that I'm seeing starting to emerge is that you have this kind of like gender to fall back. And then once you figure out those core use cases, pulling them out and making them slightly more, let's say formalized, whether that be, and I'm using the word formalized, because I think there's lots of ways, it doesn't necessarily have to be entirely hard coded, but there's lots of different ways to do that. So I think we're seeing a similar pattern with some of our customers over here as well. I would be curious, especially as we're talking now, we're talking about like dialogue architecture. I think one of your jobs, when you're serving your customers ultimately is to help them set up that architecture, deciding when to use what, where. And that's actually I think becoming one of the most interesting challenges in the sphere today, because there's no rules necessarily, but you have to do it this way or that way. How do you approach these challenges with your customers? Where do you even begin? How do you start to set up these projects? Well, really, some people will come back to what is most important a lot of the time, and that can be answered by, what is most important? It being very quick, it being very cheap, or it being very complicated. And then usually you can find, okay, we want it to be very complicated, and we want it to be both by tomorrow. In that case, the third option, which is price is slightly negotiable. So it's really trying to figure out, like is it a complexity thing because then we need to really work around testing, and then iterative launching, because launching something which has four modules of complexity and testing them all at the exact same time is asking for, it's a QA nightmare, just trying to align with the testers, aligning with the team who's making the changes, making sure that everyone's testing the latest version. Yeah, I think the, I think it's trying to agree with me and trying to understand, is the timeline the most important is the complexity the most important, and then really mapping it up, because I think that that's something, which I thought to a certain extent, AI would solve by mapping it all out, but the thing is what I'm finding is a lot of it, is actually still very hard coded, because it's not like with an API, for example, you can only really speak to the final API, once you've gotten all the information from the previous steps. You can't just go to the last one first, because there's a very specific process for you need to check a few things before you go to that step, before you go to the next step. And I just, I've seen a little bit with the generative AI implementations that we have, is that's multi-step workflow understanding, is just not there, and the reality is, that's where the biggest value is, is getting four pieces of information, handing it over to an agent, sending that close ticket information into their fresh desk, or into their zen desk, or whatever it is, so that the loop is closed. Absolutely, and I think that's actually what you just mentioned is something, a similar theme I've noticed with lots of different practitioners, I'll say, that I've been in the conversational interface space before, let's say the agente AI revolution, is all of us are kind of waiting to go back to these first principles of, hey, we were building conversational AI, so it could do stuff for users, not just give them a paragraph of text. Yes, you got it. I think that's the thing that I feel like we, we all need to collectively keep fighting for, is like at the end of the day, we want these things to actually do things for users. We don't want, just telling them how they could do it themselves, doesn't always solve the problem. So they've really taken self service to the next level there, in terms of figure it out all yourself. Nonetheless, I would be, I'd love to dive now a layer deeper, so once you've kind of figured out your project, I think you said fast, cheaper, complex, pick two. Once you get to that level, what are some of the things that you're noticing in the way that you set up projects today? Is anything changed, or is it pretty much-- One of the things that has been the most amazing implementation is using a tool called Excalibur, which is a completely free tooling. I wonder if I can maybe open one of these things up here, but essentially just using Excalibur as a way to draw up the full diagrams, so that the entire team is on the same-- Yeah, so-- Do you mean like four diagrams, or are you talking about mapping out the architecture of your project? So this over here, okay, maybe, I don't know if you can be able to see the whole thing, but this is just mapping like a validation flow. So it's like-- There's multiple steps where it has to check previous, and then building different menus based on certain variables that have been set. The thing is that we need to have digital mechanism, and usually, Mirror actually works quite nicely as well. I've noticed the lot of people use Mirror because it's really good for collaboration. And then, can you still see me? I'm seeing a stuck. Okay, there. I can see it probably again. So the most important tool really, I would say, is the drawing diagram. So that's what we're scoping, and what we finally bought are prototypes at a very early stage, and something like Mirror is really helpful because you can prototype what the whole flow should look like, make copy updates there, and that can be the single source of truth that the devs then can also use for the latest version. That diagram has probably been the biggest value for us because it shows the teams that we work with, how complex the tech is, but also what can be done. So usually, what happens is as soon as we start drawing the diagram out, the internal team realizes, sure, but we're stuck, we need to build a system internally so that the bot can then do the thing it actually needs to do, and then they end up building their systems so that then we can pass the information back to them. So what's very helpful is when we're doing the diagrams, and we're drawing, and we're plotting, their own teams are part of the process, and then the technical teams start to very early see, they need to now work with their marketing team. The dev team has to work with the marketing team because, and that's the issue that we sometimes see, is that there's so many different teams that are trying to collaborate with one another, that it's very easy to miscommunicate or type up a very long email that no one reads, that has the set of instructions right in the middle of the email that everyone missed. I think we're trying to just make sure, on a diagram level, this is what we're doing, is this, or we all on the same page, because that's, I think, where the team starts to see, okay, we can break this down into different timelines, and then just tracking all of that and the communication back through, this is where we ask, because sometimes the progress doesn't look very quick, because you're building architecture or you're getting APIs connected, and there's actually back end work that is needing to be done before the bot can give the answers. But I think the most important thing is, with that diagram, what it usually does, is it's pulls everyone to the, this is what we're trying to actually accomplish. So, without that, I think we've probably, as soon as we implement that, we save massive amounts of times, a massive amount of time, because there's far less backwards and forwards, and trying to see what we're actually talking about, it's quite clear on the collaborative documents. - Yeah, that would also be my recommendation to anyone that's building a conversation on her face today, is at the end of the day, you need one single source of truth, no matter how hard-coded or how agentic it is, you need some kind of overview of the different user journeys that are available to your users. Even if one of them is a long-tailed search, put it on a piece of paper. So people know that it's there, because once these agents start sprawling into different teams and different subject matter experts and different development teams, back end, it becomes impossible to keep track of all of it. So I think that's for me also, I think a very consistent part of being a dialogue architect at the end of the day is having these single sources of truth. I think this is the case for any vendor that's working in this space. A lot of your roadmap today is driven in many ways by customer demand. And I think we've got customers that I really want to use it. And it does solve an organizational problem, I think. MCP at the end of the day, someone still has to build all of these integrations, but having a part of how it unifies them in one place is an organizational solution. So I think MCP itself is an organizational problem at the end of the day. It doesn't, it doesn't, revolutionary, it doesn't change the fact that you still need to build all of these integrations. And so at the end of the day, our customers still want to use it. And I think it does add some efficiencies to let's say, types of tool calling that you might have within an agent. I think for me, what I think is even more challenging than MCP is actually A to A. So agent to agent protocol. Because at the end of the day, now you need to reach out to an external agent, which is an entirely a black box. You have no internal controls over what that agent can do and the types of things that it can send back to you. So I think for me, that's where I see MCP for me, at least, in some ways, could be guarded with an organization. But as you mentioned, once you think about MCP servers for vibe coders, people that are actually generating code and frankly, people like myself who, I'm not a study developer necessarily, I just happen to have peeled the onion back far enough that I end up in an ID at some point. So I think there's definitely going to be a lot more people like me who probably don't have to know how to immediately say, ooh, this is a dangerous command to be running right now. So when I hear agent to agent what we're trying to solve is, if you imagine like Nissen, South Africa, for example, they have a global, they have South Africa bots. You go to the South Africa bots, but what would be really awesome is if there was ability for the agent down the streets over here or the agent. agents who's in the middle of the upcountry with very little infrastructure around them, would it be possible for us to potentially handle a user who is talking to the main bot over to an agent who is offsite, potentially on a different location because the workflows within GodBot, there's definitely always a need to connect humans to other humans, but sometimes the needs are more granular than just I need to talk to a representative of offsite africa, it could be something down to I need to talk to the person who's in my 5km vicinity and being able to route the conversation to a much smaller network, so trying to figure out how we can build an architecture, that's what I mean by agent. Are you talking live agents then? This is always the vocabulary challenge. I'm talking agent meaning, let's call it bot to bot, that's what I was talking about. Agent to agent, I think that's another piece of the puzzle, I would say, live agent to live agent is another piece of the puzzle, but I see what you mean having that local, especially in South Island, I mean how many languages do you have in that kind of area? I can imagine the level of localization that you would need to provide to provide a good service is quite high, so that being huge. What you just said about the bot to bot is within God bot there's definitely a huge focus on agents, but there's also that the bigger South Africa to the more granular regional bot to bot as well, which that's not at all in production, but it is something that's the next thing that we're solving with our release that is coming out in February next year. So the basis of that is to it's being built around that the bigger node to the smaller branches, being able to essentially do a workflow not just within one bot, but being able to orchestrate the actually the handing of the parcel of information between the one bot to another bot connector that could be in there as well. I mean it's the same thing, it's just where do you store that one of the information, which is the context that the bot then answers its questions from? That's interesting though, it's an orchestration challenge that's bubbling up I think more today than yesterday because now we have like what we're seeing at customers is not necessarily like let's say there is this bot to bot element where maybe you're a car financing bot in your bank and you want to be able to connect to the dealership bot, you know there's kind of that that kind of use case, but on the flip side I think we're also seeing across an individual organization lots of different individual teams are getting budget to work on agents and building on vendors, building on different systems, building with different goals, and I think that's the really interesting orchestration problem that's popping up that we're really trying to solve for here at Raza's, how do we make this all behave like one unified customer experience so that end user does not have to chat to five different agents that are branded differently have a different voice and unify that and that's actually a pretty tricky technological problem because all of them have context some are more agentic than others, it's really a challenge and I think that it but it's an interesting one nonetheless and I think that's where again the whole of dialogue architecture comes in, how do we set this up in document? I think that is such an important thing one of our most one of our clients this year had that exact problem where their problem from a brand perspective was that they had each of their own departments almost had their own bot with their own branding and their own style and the issue is that they don't they needed the they needed experts to really guide them on like what is the best way that we could pull them all into the same thread and then accomplish multiple goals through the same thing instead of trying to each do their own little thing and then only touch two percent of the audience so we're definitely asking that that's a really big thing because I think the what's I think that's happening because company departments are becoming a lot more connected and I mentioned that earlier just with marketing and advertising and marketing teams are seeing I can automate things and then there's the in-house teams which are we need to somehow find a way to handle the volume of things that are coming in and there's two different sides of this and I think that's what we're at least seeing is that there's a lot more internal communication where they need to be alignment and where we find ourselves sometimes having to be the mediator between internal teams saying hey we see what you're doing here we're seeing what you're doing here what happens if we brought you guys together and did that so they and that's where the diagrams come in is we say okay well who's side wins yeah this way what do you think it's really just this negotiation internally with the client with them saying we want to do this thing and then just really using us as the sanity of that's a great idea that's a bad idea or that's excellent if it's do that more and what I love to hear from you Nick in the next kind of section is like if you have any really good compelling stories about things that went wrong that you solved or interesting problems that you've had I remember you talked about empathy that might be an interesting one and I'll kind of tee it off here slowly and let you mold it a little bit but Nick I'd really love to learn kind of to to close out the session today as well I'd love to learn about some of the customer side stories that you've had recently you know things challenges that have popped up that are either new or you had to work hard to resolve what what's been challenging that that you've been working to overcome or everything's been easy that's also good most of the problems that this is something that you probably can't even air is it's like really tiny things like one of our biggest issues in the last two weeks is talking to a client who's having the default fallback intent to get hit less than 2% of the time so we're haggling over how to make the final 0.5% so it's slightly better and this in their mind is quite a serious problem and it's trying to place the success of but it's successful 97.5% at the time and trying to communicate that in a way again it's a communication thing of how we then can provide feedback because I think that's the most important thing as well is being able to very quickly see data that's that's something that's been very helpful for us black Friday for example as we had a retailer do a black Friday special through WhatsApp and us very quickly their website took too much strain so we needed to very quickly cancel the broad cast because we didn't want to send more users to the websites if the website's done and so that that's the quick turning around of working with third parties like WhatsApp or business solution providers is really a bit of the the types of problems that we have Facebook accounts us needing to do the correct process of applying for a WhatsApp number getting it connected to the users what to the brands WhatsApp accounts to their Facebook pages a lot of the protocols that we're needing to guide you guide clients through so that their bots can stay connected to the platforms because they're always changing they've always got these new things and the big problems usually will be when there's a broad cast that is sent that has phrasing that meta says we don't like this for some reason and then it gets banned and then we need to try and unbanned or unblock the main problems that we used to have we're really from from where we were at I would say two years ago with our architecture and we've been able to patch quite a lot of the problems and the biggest the biggest learnings were from in 2025 when I when we were expecting a hundred thousand messages in a period of a month then we got that in a period of a day and it's it's it's just it's when this is when it needs to make a quick adjustment and having to get all hands on deck so that the service downtime doesn't affect the end user it's really those types of things what also happens what also usually happens is us being asked to switch certain workflows off because the clients API is content all the volume so for like a loader for example if I'm some type of generator we're going to find the the best match for you and then 10,000 users hit that thing in the first like hour then the system takes strain and then we need to switch the system off so that's the backend API doesn't have that more done so it's those type of things I mean it's not really ever anything super casus-strophic because of it only really does what we ask it to do so it's not likely ever really surprised by copy that's also one of the things that I feel safe about not embracing Jenna I as much as there's just less heartache and pain of what happens if someone does prompt engineer the thing to say something really bad yeah okay yeah the the brand reputation element of it that makes sense and I think you were mentioning in general the the high volumes how how do you how do you manage the load there what are what are kind of your approaches because I think that's something that you know in some ways that's the best case scenario right lots of people are losing your product but on the flip side obviously it's it's something that needs to be done. to be managed. I was curious because I struggle sometimes with containment, right? Even though it is a classic contact center KPI, but at the end of the day, containment, like all of these people that are working in the contact center who end up also sometimes working on these agents, their whole life mantra and their bonus, it's all tied into containment, which at the end of the day containment can also just be simply refusing to serve the user, but giving them some answer, you know? So I think that's that focus on success metrics for me is so much more interesting and revealing than containment alone, which could simply mean I've just either dumped them this random link that may or may not have been helpful or I've dumped them into this random queue with a hot line that's going to take 20 minutes, you know? And I think that's finding ways to measure success for me. I feel like that needs to be part of our future versus kind of these classic maybe slightly more old school call center metrics, although I know they won't go away nonetheless. Yeah, how do we avoid that? Please rate my feedback. Which, which mostly we notice as well, like in project, high majority of the people that fill out that form are people who are not happy. The people that get solutions like objectively from, you know, reading the transcript don't fill out that form because they're done, they're gone. The people that do fill it out are really angry, so that's something I've noticed. And last question for today, I'd love, you know, we're we're on the the cusp of a new year. So Nick, we're in a new year. It's 2026. What's your prediction? What do you think's going to happen this year? Any hot takes? I think that people are going to lose their faith in agents running the world. I think that we're going to see form or studies of agents that didn't actually do what they were promised or what they're promised to do. And then I think that there's going to be a bit of a hesitation as to just connect an agent into your environment because the reality is that these things are expensive or they can be expensive. They're they're open you up to vulnerabilities. I think that they are going to be far more stories of people who incorrectly install things and get their computer contents deleted and their cloud credentials harvested. And it's obviously not something that is good in any way, but I think that that has to happen for people to realize that when you do give an agent the ability to run as an administrator on your computer without putting it in a protected environment, you really are opening yourself up to vulnerabilities. And I think that the influences of the ones realistically are going to bite that bullet first. Maybe bite that bullet is not a good. There's a lot of influencers, a lot of hype grifters out there. One could argue, but I would agree. I think I think my my twist one is like I think I credit also my colleague Rod in Deverell for this prediction is like he's calling 2026 the economic recognition, the economic reckoning when ROI becomes non-negotiable. And I think that's fair. And I think that also in a sense is the precursor to your prediction. Folks are not going to continue to fund things that don't work. Only things that work survive. And I think and I'm open to anything, you know, however on wherever it is on the agentic scale, I'm happy if it's working and safe and covers are happy. So I think that's that's also where I'm I'm I'm feeling the same direction. No more frivolous agent projects. It has to work has to work in production. Yeah, definitely. All right. Thank you so much, Nick. It's been an absolute pleasure. I wish you the best. I love listening to your stories, especially because you have hands-on keyboard experience working with customers side by side. All the best to you and your customers in 2026. And we hope to see you again. Yeah, thanks Lauren.