In this episode of The Dialogue Architects, host Lauren Goerz, Staff Product Marketing Manager at Rasa, welcomes Ludwig Sickert, Co-Founder and CTO of Logen.AI, for a practical discussion on what it takes to design, deploy, and scale voice AI systems that users actually trust.
Episode Description
Trust isn’t something you add to voice AI at the end—it has to be designed in from the start.
In this episode of The Dialogue Architects, Lauren Goerz, Staff Product Marketing Manager at Rasa, sits down with Ludwig Sickert to explore how high-trust voice AI systems are built in real enterprise environments. Drawing on his journey from IBM Watson AI to co-founding Logen.AI, Ludwig shares how conversational systems have evolved from simple FAQ bots into deeply integrated, production-grade voice agents.
The conversation examines why trust is especially fragile in voice interfaces and what teams must do to preserve it. Lauren and Ludwig discuss the importance of integrating voice agents with core IT systems, defining a consistent brand voice, and validating AI outputs to ensure reliability at scale. They also break down common implementation challenges—from handling complex business processes to balancing flexibility with governance.
Looking ahead, Ludwig shares his perspective on the future of voice AI, including emerging opportunities around memory and continuity across conversations, and what those capabilities will require from a trust and design standpoint.
This episode is essential listening for product leaders, designers, and engineers building voice AI systems where accuracy, confidence, and user trust are non-negotiable.
[00:00] Introduction and guest welcome
[00:43] Ludwig’s career journey
[02:01] Building high-trust voice agents
[04:01] Challenges and solutions in conversational AI
[07:06] Voice AI implementation strategies
[15:05] Ensuring high-trust AI systems
[18:43] Technical and business considerations
[26:51] The future of voice AI and memory
[30:12] Closing thoughts and farewell
Ludwig Sickert – LinkedIn
Logen.AI
Learn more about trustworthy conversational AI at Rasa: rasa.com
The Dialogue Architects is a podcast from Rasa, hosted by Lauren Goerz, exploring the craft and strategy behind designing conversational AI in the enterprise. Each episode brings together technologists, designers, and product leaders to unpack how dialogue is built, scaled, and governed in real-world systems.
[00:00:00] 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 Ludwig Sicker joining us from Berlin, Germany. Ludwig and I both started our careers working on conversational interfaces at the IBM Watson AI Team here in Germany, and I'm really excited to learn about his experiences building high trust voice agents as a co-founder and CTO of Logan ai.
Ludwig, it's really great to see you again and welcome to our podcast. I know one of the first things we wanna talk about is your background and career journey. I think the fun part about talking to you is I feel like my career journey at least started a little bit with you in parallel as well, since.
We were both, uh, prior colleagues at IBM before we kind of got to get going in the conversationally AI [00:01:00] space. So maybe tell me a little bit about your journey to conversationally ai. 'cause I think what's cool is you've been in the space for almost the whole time that you've been professionally active or were, was there also something previously that you were working on?
I think, you know me most of the time at IBM before I joined the AI team, I was, was a working student, uh, for during my bachelor's degree, I, I did a few AI. Things there, but mostly I was doing stuff outside of, uh, outside of the AI practice. I was very lucky with like one of my last internships while I was a working student.
I was. Actually working on Watson Assistant for the first time, like this very nice alpha version. It didn't even have a, a proper UI yet in anything. Um, and then we were trying to sell it to a client and that's kind of how it, how it started and how I said then. Okay. Uh, that's kind of something I want to do after I graduate as well.
And then, yeah, I joined, uh, I joined the team in Munich and um, have been doing it all my time at IBM ever since I think. [00:02:00] And now effectively, why don't you tell us about what you're doing now? I know you've, you're currently, um, co-founder, CTO of login, and I'd love to hear a little bit more about how you took the things that you learned at IBM.
Um, we are doing a lot of voice bots, chat bots, or like if you, you wanna wanna call them AI agents now it's, uh, it's all kind of the same thing. And I am mostly involved in the technical part, uh, of it. In my opinion, one of the most important things for a voice bot or AI agent is that it's actually able to do stuff so that you don't just are able to answer FAQ questions, but that you can, uh, fulfill requests for our customers.
Uh, and to do that, you have to integrate. This is. Them with, uh, all the other IT systems that a company has from the start at IBM up to now. That's, I would say, is mostly the part where I am involved. I, I usually like to call it something like AI is the brain that's maybe. [00:03:00] 40% of the project or 50% of the project, and I do all the other things around.
If you have a chat to the phone system, to A-C-R-M-E-R-P, all the different backend systems and uh, that you're able to get the data out of there, put data in there, do it in a safe, secure, and scalable way. That's very much my focus. Uh, that's also kind of what we do at Log AI in general. We are doing implementation projects for our clients where we build voice bots, chat bots, and all these other kinds of AI systems.
But, uh, we ourselves say we are the agency you want to call. If you have like a complex integration going on with your bot, we want to go in and. Solve the, the tough problems, um, when somebody calls us and tells us, okay, nobody else had the, uh, ever managed to, to connect our CRM system with, uh, AI and, um, we, we do it.
Yeah, absolutely. I think that resonates. So [00:04:00] truly for, probably, probably for you as well. 'cause we've both experienced maybe the early days of conversationally I, where we kind of worked our way up from FAQs into a space where we have agents, conversational interfaces that actually do stuff. Mm-hmm. I love that I don't have to write out individual answers anymore, but at the same time, I feel like for me, that's really, you're only scratching the surface in terms of what a conversational interface can do.
We're talking about one of my favorite, um. I remember use cases that you were working on, Ludwig, which I thought was, um, creative and interesting. One of those things that you don't plan to work on in conversation I, but pops up. You would release this, um, WhatsApp, uh, a new WhatsApp channel and of course people can now send you pictures.
So I remember one of the, one of the things that you were telling me is, for example, you might have a nice grandma who now has access to this telecommunications, uh. WhatsApp channel and suddenly does reply all and sends a picture of her Christmas tree. Right? And so all of a sudden you have people who might want, you know, something like they have access to this channel, but suddenly you're getting a whole lot [00:05:00] of new inputs.
What was that like? How did you solve this problem? This was actually very hard to solve in the beginning is just sifting through the data. Like first you have to go through it manually understanding yourself, okay, what's going on? What's our, like the general things that people are sending us. And then, uh, we got to work.
Um, we, we assigned a colleague to, to this task, um, I think full-time, even for a few months, who was, uh, building us some, uh, image classification algorithms. And then we started, uh, making up categories more and more deciding what to do with them and. Finding ways also to, to proactively ask people for images.
In some cases even. Um, and I mean, remember this was all before, um, even most current LLMs, so I was reading papers about like bird and, uh, these very early models. Um, and, and we were. [00:06:00] Using very early OCR and image recognition models. Like right now, you could just send it into, um, OpenAI or whatever, and it would give you a perfect description of what this image is, uh, is containing.
But none of this was possible back then. So we built a very, very elaborate architecture for it. Um, and I think in the end we had like around 10, 15 different image categories and we were able to extract a text from, uh, certain images, like if somebody was, uh, sending us a receipt. Or a bill or something like that, we could extract the customer number from there.
That's, that's one of my favorite early memories of, of conversationally AI is you think you're building one thing, but in reality you actually have to build a lot of other things. And I think maybe that's similar. It's a parallel today because. We spent so much of our time trying to restrict what people can say to us, you know, buttoning it out, really triaging and direct people down paths.
And now let's say the, the surface of conversation is vastly expanded. So I think that's, that's an interesting thing. And it's not just now. [00:07:00] Text as you and I were probably mostly experiencing early on is voice and that's what I really wanted to hear more from you Lu bit. 'cause I, I think we have in-house today really a voice specialist, someone who's not just doing it, you know, in theory but in practice.
So I'd love to hear from you today, you work with customers and you're implementing voice agents. When you start that process, what's kind of your early checklist in terms of setting up a customer for success? Invoice. The, the earliest thing for voice specifically if we're like talking about what I have to do to make voice put a success, is you have to decide what kind of voice you want to have or what kind of branding you want to give, uh, give yourself.
Um, obviously there's like very many different voice, uh, ai, um, providers out there, like 11 lips. You have the agile voices, you have the voices from open AI themselves, and, um, as a company you have to decide for one of them because that's what your agents is gonna sound like from now on, and you can't just change it like [00:08:00] every month.
Um, and ideally you want to have like a unified voice experience. So if you have like 10 different agents, you have to decide, okay, is each agent its own voice? Do they all sound the same because it's the same company, it's the same brand experience. Um, and then you go further from there into like more the specifics, uh, of.
Are people allowed to barge in? Um, how much do I want people to, um, be able to, to adjust what, uh, the agent sounds like or do I want to be very strict about it and always have the same experience for everybody that's calling? But then you all also start, I, I would say going more into the stuff that's not very much just relevant for voice, but more relevant for like AI projects in general these days is, uh, that you have to give your agent a personality.
Hmm. So you go [00:09:00] in, usually we do have a, a workshop together with our clients about this, uh, persona workshop where we mm-hmm. Decide. Okay. Do you answer in short sentences? Do you answer in long sentences? Are you very quirky? Are you very serious? Um, do you explain everything in detail? Which certain terms should you use because they're like your brand terms or whatever.
Um, and all of these sites have, uh, things have to be decided. If you come from like the old world of rule-based conversational AI voice was always very difficult. And it was way easier to start with like chat because. You had the option to give people buttons and whatever, and if you didn't understand them correctly, yeah, you could put them into some kind of guided flow.
But with, uh, generative ai, I noticed it's actually the other way around because, uh, the gen AI is very good at handling slight misunderstandings or mispronunciations or, [00:10:00] and if you have a voice client, it's very easy. And, and, and DGen AI is able to handle all of these faults. But, um, it's very hard to teach the gen AI to use buttons or whatever.
So all of these fancy tools, all of these rich experiences you had crafted before with rule-based bots, suddenly it's very hard to use them. Interesting. Okay. But, uh, but people are used to this kind of thing. Yeah. So. But I am curious, I think you mentioned something really interesting and, and for me, the concept of, of design affordances.
So I think we think of design affordances in the text world as carousels, buttons, links, you know, all those things. Mm-hmm. And then in the voice world, I'm assuming those would be like IVR, you know, press one for something, you know, kind of that classics IVR experience. Nobody, nobody likes that. But I'm interested.
So tell me a little bit more about that. It can definitely be challenging. One, one of our favorite partners, uh, we are, we are using a lot these days. Um, kind of has this solved, which is why we don't really think about it so much. Yeah. What [00:11:00] sometimes happens is if you don't tell the AI exactly like what it expects or what it can expect at a certain point, for example, if you give it, um, a, a postage number or.
Post, post Al in German. I'm sorry, I'm, I'm missing the zip code would be another one. Um, Marvel. That's it. Postcode. Yeah, that's it. Um, and, and a lot of people will say like, 1, 2, 3, 4, 5 for that. Mm. So what, uh, AI will do is will transcribe it with spaces in between. Mm. Um, so you have to tell the AI agent, if you put this number into some, into any kind of backend system, please take out the spaces.
Yeah. Because even if you, and even if you do that, like it might do it in like 99% of all times, but then in 1% of all times it'll leave the spaces in and try to put it into the backend system. The backend system will say, Hey, I can't process this number. There's spaces in there. [00:12:00] Um. So what we resorted to doing was, um, a lot of these things were like precise.
Um, inputs are very necessary. Is that we have a kind of like post um, processing after the AI agent is done, where we just try to anticipate like common mistakes like this. So we just strip this out in a custom kind of connector software, um, before it goes to the actual backend system. System. Yeah. And this action alone of just like handling these very stupid mistakes that AI agents sometimes make, um, outside of the actual AI agent, not trying to rely on it, uh, to, to handle this itself.
Um, that's a game changer. I would say. This is how we went from, I would say, 80% success rate with our backend calls to more than 99% plus, because it's always these kind of small things. But I would say that's also [00:13:00] something you learn. In general in IT projects. Um, and, uh, I mean I've been doing this also as like the rule based bot or like, if you have something like a web form and you expect people to enter something in there in a specific form and just don't do it, they, they put something else in there and then you have to deal it.
Yeah, I still think that's so much more accessible. 'cause I remember when I was working for another large telecom agent, one of the biggest issues I had is that, um, when, when, when we're talking about things like gigabytes in the telecom space, for example, mm-hmm. Germans will put a comma between numbers.
But all of the backend systems at this company had, um, decimal. So, mm-hmm. You had to, I had to do like, do a lot of Googling stack overflow. Try and figure out, okay, how do I twist, you know, flip every single comma into a decimal in this space. Mm-hmm. And I think what's cool is now instead of having to learn that that trade, I can tell, Hey, this is how I want this piece of information to be formatted.
Which I think is a huge, um. Change in [00:14:00] velocity, I think, when it comes to absolutely. Development for slightly non-technical users as well. So I think, I think that's promising. But maybe is that, is that something you've seen as well for yourself as a developer, you know, architect by trade? Well, I mean, I definitely use ai Yeah.
A lot, uh, during my, my normal development work. And I don't want to work without it anymore. Um, when, whenever I'm in, in the train, uh. Shout out to, to Deutsche here, Deban. Yeah. I don't have any That's deban. I don't use my AI agents anymore. Yeah. When it comes to, to voice agents and, uh, AI agents in general, I'm, I'm, I'm a very big fan of like, trust but verify because even if it works in 99% of the time.
I want to have a solution that works a hundred percent of the time. So I, I'm very much a fan of putting guardrails around these AI agents and, and don't trust any of their outputs. Um, anticipate all of these small little mistakes that they can make because a human might make them too. And, um, kind of try to either [00:15:00] solve them directly in the backend before I put the data in there, in there somewhere.
Got it. And I'd be curious to know a little bit more about this. 'cause I think at Raza, one of the things that we've really tried to stand for is high trust ai. So that's something that we're really trying to build for and, and build ways for our customers as well to, to deliver high trust experiences.
What does that look like for you? So you talked about, you know, I, I don't trust the language model. I would say like, we're definitely a skeptic in that category as well. But also, you know how at, at the end of the day. We still need them. They're doing great things for us. How do you go about validating, as you described mm-hmm.
Um, in practice and maybe like, not necessarily on the like developer level, but like Yeah. You know, high level. Are we talking LLM as a judge? Are we talking, you're having review sessions. Humans in the loop? Like what is, what are the strategies that you use to validate? It's definitely both. Um, we, what you want to have ideally is, um, you want to have some kind of automated validation because, um, if you are a large company and you have like [00:16:00] a million calls, uh, whatever, in a month, you can't have any human go through that manually and, and look at it.
You can mainly be, maybe look at a few things in there, but you will, will never catch everything. So you need to have some kind of automated validation. Mm-hmm. And depending on the type of things you want to validate, um, you have to either do it with an LLM as a judge. That's very good for, let's say more.
General open-ended text-based validations like, was this a good conversation? Um, you can give this to an LLM and just say, Hey. Look at this conversation. Was this good? Do you notice anything that could be done better? Mm. And the LLM will will give you an answer that's pretty good most of the time. Um, but obviously you also want to have more, uh, hardcoded validations and, um, making sure that the LLM actually does what it should be doing.[00:17:00]
And so it's, it's very much a combination of all of these things. But then obviously also. You always have cases where you can't analyze them automatically, especially if it's like new problems that you didn't anticipate yet. So what we do always is we go in and still read conversations every day, especially after Goli or if you had many, any big changes.
It's very important to still just go in there, monitor, look at conversations, see what's going on, because you get a very good feeling of, uh, of any issues from that. Absolutely massive support. I would say that's probably like a Raza life rule that we've been trying to evangelize as much as possible is read conversations.
Not all of them, right? As you said, you can't read a thousand conversations, but I feel like as a, as a brand, as a company that's trying to deliver good customer success, good customer experience, it's, it's really challenging to know. Where you're missing scope or where you're missing, um, where you have opportunities to make it better unless you actually read [00:18:00] the conversations.
Mm-hmm. And yes, you could probably prompt and comb through a bunch of data, but still reading it actually, I think really helps designers, tech people understand why. But that's, uh, something we've worked on for a while. And I mean, I think that's also a very good point that you, that you made there about like, you don't just want to find out what goes wrong, but also where you can get better, even though it might be already okay.
Right now, when you start thinking like, what are the things you need to bring to the table and be ready to invest in before you start invoice? We talked about workshops to build persona, to build brand voice, things like that, but there's a technical side to that too. What does that look like? I'm thinking sip trunks, I'm thinking contact centers, things like that.
Where do, where do you even begin? Uh, well, um, you, you begin by taking, taking a good, uh, long look at your business processes and, uh, trying to figure out what you're doing manually right now. Mm-hmm. Um, because most probably you want to have this business [00:19:00] process replicated in some way by UI AI agent. Um, and then you have to go in there into all these systems and, uh, take a look.
Okay. You talked about zip trunks. Um, okay, what telephone system am I using right now? Can I connect this telephone system to AI agents? Um, because I would. Be very happy if every telephony system in the world would, uh, work very easily and be able to be connected to, um, other systems on the internet. But, uh, unfortunately that's not the case.
So that's, uh, usually a very big, uh, question for us, uh, where we ask customers, okay, what are you using there? How can we connect it to other systems? What kind of data can we get out of there or get in there about the customer? Um. And then again, take a look at what your agents are doing right now. Mm.
What kind of processes are they following? Are there like any scripts they are using? Are there [00:20:00] specific systems they are talking to? Is there specific data they are requesting? Um, for example, to authenticate or identify a customer in which, um, in which, uh, order are they doing it? Um, are there specific FAQs they are always answering?
Or do you even have. FAQs or is it just like the knowledge of the agents? Um, and all of these kind of things? Obviously you have to, you have to look at, and what we do with our customers then is, uh, we do flow diagrams, very, very classic for each of the use cases that we want to implement. And then we just see, okay, how does this fit, does it.
Good to them. And uh, obviously that's then where we bring our expertise in there and say, okay, maybe at this point you would need to do something different. Because with an AI agent, it's not that easy to do. Got it. So you actually reduce the attack surface from like a prompt injection or other things by waiting you, you feed the agent effectively information at the [00:21:00] appropriate time.
Yes. So it doesn't have too much information at any given moment. Super interesting. Yeah, that's just a fact. I would say like whatever information you give to the ai, it will use, so you have to be very specific about which information you give to the ai at which point, because if you give the information too early.
It might use it even if you don't intend it, uh, to use it yet. Got it. So I guess you've helped me and I think you, you flipped the script in a good way. So, you know, I started talking about the technology problems, but actually I think what you're saying is, no, no, no business problems. First, let's solve the business problems.
Let's map out what you actually wanna do. You know, direct the scope, understand the scope of what you wanna accomplish before you even touch the technology problems, because that's gonna be the biggest chunk of time or, mm-hmm. Challenge, I guess, because I would say the technology problems, it's just, for me, it's just.
Like any other IT project, um, if you work in enterprise it, um, a lot of times you're just [00:22:00] connecting two systems with each other. So from purely a technical perspective, it doesn't matter if I'm connecting a CRM to an AI agent or to another CRM or to an ERP or whatever, I just need to find some way to get data in and get data out.
Mm-hmm. Um, and usually I have. Some kind of specification for the AI agent, which is the tool call and the tool definition in there, and have some kind of, um, format that the uh, backend system expects. And then I just have to do a translation between these two formats, which. I have to say is always doable.
It might not be nice. It might be very hacky and ugly sometimes, and, um, especially with older systems because, um, most AI agents or AI systems, let's call them these days, are very much trained on using JSON and rest. But if you have an old system that still uses SOAP and [00:23:00] XML as a standard, you kind of have to build some translation in between, because otherwise there, there might be a, a conflict between what the AI wants to put out or what, what the system expects.
Mm-hmm. Clear. Do you have any kind of design philosophies in terms of how you decide, okay, we wanna handle this in a very deterministic way, we wanna handle this in a very. Uh, agentic way, for lack of a better word, uh, you know, probabilistic way perhaps is, is another way to, to talk about it. Mm-hmm. What kind of design philosophies have you implemented so far that's been working for your customers?
Usually I like to start agentic very broad because you have a very high. Let's say, um, volume of possible questions that a customer can ask, and you need to narrow it down first. Mm-hmm. And after a while, you get into a kind of process where you might answer some like side questions, FAQ questions or whatever.
But for example, if you want to book a new [00:24:00] contract, there's four different fields that need to be filled. And you always need to fill these fields, otherwise you can't, uh, continue. So even if you have a very AI the way to do it, um, there's always still like these rules and this process in the background Yeah.
Which needs these four fields. So, um, the deeper you go into these processes. I think the more you go into like deterministic ways and rule based ways where you just need to fill some kind of data in, uh, in order to give an answer to the customer in order to solve a problem or call an API or whatever.
Um, and one other thing, uh, a small thing maybe is um, we do a lot of, uh, let's say variable renaming. Um, mm. Because in large ERP systems, you might have a hundred, 200, whatever, different data types in [00:25:00] there. And each of the data types has an id. But if you give the LLM, uh, let's say a customer, a contract, and you give it an address and whatever, and each of this has a field called id.
It can be very hard for the LLM to differentiate between all these different data types. Mm-hmm. And, uh, ID fields and the probability is high that it will put in the wrong ID into the wrong place. Mm-hmm. So, uh, what we like to do is we just rename the variables because before we return them to the ai, we, instead of having an ID for.
An address, we rename it to address ID instead of ID on a customer. We rename it a customer id. Um, and it can be the same, like this is obviously a very easy example here, but sometimes you have very cryptic field names where. They refer to some kind of internal logic, but you as a human and also an AI agent, would [00:26:00] never guess what this field is about.
So, um, you kind of want to have descriptive field names, uh, that that already helps a lot as well. That's super interesting. So, so just for clarification, you mean as, as. Others might know in like the broader conversational igenic AI space, what we've been calling kind of context variables or slot names or variables.
That's, that's the ID field that you're talking about. Okay. Yes, yes. But also in the data that you get back from, uh, from the systems, it might be good to, to have it filled, uh, or like have it replaced with more speaking names. Absolutely. And looking forward in the future, you know, I know, I know you've worked a ton on voice ai and I love how listening to you talk about your work with your customers, how successful you've been.
Like really just being able to actually in a quick amount of time. Turn out some solid voice projects. That's awesome. But where do you think you still have to go? Where, what haven't you cracked yet in terms of problems in the voice space that you'd like to in the future? Ooh, that's a tough question. One [00:27:00] thing, um.
That I notice, um, which would be great, is, uh, memory over multiple calls. Mm-hmm. Because you have so many people that are calling you for a topic multiple times or that, uh, tell you, Hey, I spoke to you yesterday about this, and most AI systems, or most, let's say even customer service systems are not very good at handling this right now.
Yeah. Um, and if you want to have like a truly personalized and, and very fluent and, and nice experience, you should have all of the information available ideally, and just be able to react to it. But that's kind of the, the, the issue where you get into a conflict with what I said earlier. Uh, you don't want to make too much information available to start because it might use it in ways that you don't want it to use it.
So that's like these, these two things clashing against each other as. Uh, we, we don't have a solution for that yet. [00:28:00] I'm gonna be honest. Like oftentimes to me. Mm-hmm. As also someone who hasn't implemented this, it sounds very nebulous, like agent memory is like a concept that is just sitting somewhere within the agent itself and not in the backend system.
Mm-hmm. So for me, I'm trying to figure out like, you know, is this just floating? You know, they make it sound like memory is just floating in the crowd cloud across all of these different agents. How do you ground this? Like, what would this look like? I'm imagining that I would. Have conversation, history, and maybe I would save in my backend certain problems or problem spaces that the customer just had and then call them up again when, when they, you know, call me back again.
What would that look like for you? You know, to have memory implemented across different calls. You could do it similar to something like retrieval, augmented generation, where you have just. A certain set of documents about a customer in the background, all of the past calls, and the agent can call upon it and inject it into the current context when it's like necessary.
This could even happen automatically in the background. Um, but a lot of that [00:29:00] also, I, I say, is way simpler. And then people are always thinking about it, like in AI terms. But, um. Why not just give the AI agent a customer profile from the start where it says like, this customer called two days ago already, this customer has an open ticket and this is a ticket about, um, you, you already can give all of this information to an AI agent today.
Um, because usually it's available somewhere in the system. But, um, yeah, you have to make sure the AI agent does not use it, um, in ways that you don't want him to use it. Um, so we, we did this in a few projects, actually. Um, very cool, and then implemented it there. But, um, so far we, we haven't gone live with it because, uh, of.
Yeah. All of these unexpected side effects that were happening if you were suddenly giving the AI agent too much information, much and um, not properly grounding it in there. Got it. I love that though. I think that for me, [00:30:00] grounds the idea of memory a lot more. 'cause I'm thinking like, when you put it in the framing of this is just a customer profile, it's another variable in the stack.
Makes sense to me. Um, definitely very tangible or doable, as you would say. Um, it's being done today with your team. So thanks so much for bringing your insights online today, Ludwig. Um, it's been a pleasure to have you and we wish you the best with your customers in the next year. Thank you very much.
Thanks a lot for having me.