WEBVTT 1 00:00:00.320 --> 00:00:03.960 If you're a founder, operator or executive, here's the 2 00:00:03.960 --> 00:00:07.720 uncomfortable truth. Your back office is stuck in 3 00:00:07.720 --> 00:00:11.520 2015 if you're drowning in repetitive 4 00:00:11.520 --> 00:00:15.280 work, operational inefficiencies and processes that 5 00:00:15.280 --> 00:00:18.640 break every time you try to scale Today's guest 6 00:00:18.640 --> 00:00:22.000 believes the future of work will not be AI 7 00:00:22.000 --> 00:00:24.720 assistants, but AI employees, 8 00:00:25.040 --> 00:00:28.550 autonomous agents that think, plan and 9 00:00:28.630 --> 00:00:31.870 execute real workflows. Dr. Oliver 10 00:00:31.870 --> 00:00:35.590 Lugosch built Razor Group to more than 700 million in 11 00:00:35.590 --> 00:00:39.350 annual revenue, managing global operations at 12 00:00:39.430 --> 00:00:42.910 massive scale. He's now building ADA 13 00:00:42.910 --> 00:00:46.590 AI, or ADA AI as you can say in German, where 14 00:00:46.590 --> 00:00:50.230 AI employees are already replacing entire back office 15 00:00:50.390 --> 00:00:53.890 workflows. In this episode we we break 16 00:00:53.890 --> 00:00:57.610 down what AI employees can actually do today, 17 00:00:58.250 --> 00:01:01.770 where they fail, and how founders can employ their first 18 00:01:01.770 --> 00:01:05.570 agents in under 30 days. Get ready. 19 00:01:05.570 --> 00:01:08.810 This conversation will fundamentally change how you think about 20 00:01:08.890 --> 00:01:09.690 operations. 21 00:01:15.930 --> 00:01:18.890 Welcome to Startuprad IO, 22 00:01:19.530 --> 00:01:23.100 your podcast and YouTube blog covering the German 23 00:01:23.100 --> 00:01:26.540 startup scene with news, interviews and 24 00:01:26.780 --> 00:01:28.060 live events. 25 00:01:31.020 --> 00:01:34.740 Today we're joined by Dr. Oliver Glugosz, a founder 26 00:01:34.740 --> 00:01:38.060 who has lived through one of the most operationally intense 27 00:01:38.220 --> 00:01:41.900 journeys in Germany's startup ecosystem. Oliver co 28 00:01:41.900 --> 00:01:45.540 founded the Razer Group, an e commerce powerhouse that 29 00:01:45.540 --> 00:01:49.340 scaled to over 700 million euros in annual revenue, 30 00:01:49.580 --> 00:01:53.350 navigated global supply chains and estimated executed M and A 31 00:01:53.350 --> 00:01:56.950 at the pace that would break most companies. That 32 00:01:56.950 --> 00:02:00.590 experience gave him a firsthand look into the limits of human 33 00:02:00.590 --> 00:02:04.230 only operations. The arrows, the repetitions, the 34 00:02:04.230 --> 00:02:07.909 scalability ceiling. And it led him to a bold 35 00:02:07.909 --> 00:02:11.670 idea. What if startups didn't hire more humans 36 00:02:11.670 --> 00:02:14.470 for repetitive work, but deploy 37 00:02:15.110 --> 00:02:18.960 AI employees instead? Today all Oliver is a co 38 00:02:18.960 --> 00:02:22.240 founder of ADA AI, one of 39 00:02:22.240 --> 00:02:26.000 Europe's emerging leaders in agentic AI, a 40 00:02:26.000 --> 00:02:29.520 new category where autonomous agents don't just 41 00:02:29.680 --> 00:02:33.360 assist, but act, plan and operate 42 00:02:33.360 --> 00:02:37.080 independently. These AI employees handle full fledged 43 00:02:37.080 --> 00:02:40.080 workflows from data processing to back office tasks, 44 00:02:40.480 --> 00:02:44.170 customer operations, and complex decision paths that 45 00:02:44.170 --> 00:02:47.690 previously required entire teams. In this 46 00:02:47.690 --> 00:02:51.130 interview we'll explore the real limits of traditional automation, 47 00:02:51.450 --> 00:02:55.130 how AI employees differ from chatbots and LLM 48 00:02:55.130 --> 00:02:58.890 assistants, where autonomous agents shine and 49 00:02:58.890 --> 00:03:02.730 where they break, what founders must know before deploying their first 50 00:03:02.730 --> 00:03:06.450 AI employee and how AgentIC AI will reshape the 51 00:03:06.450 --> 00:03:10.180 startup workforce over the next five years. They 52 00:03:10.250 --> 00:03:13.930 that was a long introduction. Oliver, welcome. Thank you very 53 00:03:13.930 --> 00:03:17.770 much. Thanks for having me. It is totally my pleasure. 54 00:03:19.130 --> 00:03:22.730 I'm very, very curious about those AI employees, 55 00:03:23.530 --> 00:03:27.370 especially having a company where I still do 56 00:03:28.010 --> 00:03:31.690 maybe more work than needed manually. It is always something 57 00:03:31.770 --> 00:03:34.970 I had an eye on but could never really get the time 58 00:03:35.450 --> 00:03:39.150 to do it. That is something of real interest and I 59 00:03:39.150 --> 00:03:42.710 do believe A lot of founders here will, will really, 60 00:03:42.790 --> 00:03:46.230 really listen carefully. If they can do something like their 61 00:03:46.230 --> 00:03:49.990 monthly tax filings, that will be just amazing. But 62 00:03:49.990 --> 00:03:53.550 first, let us start. You scaled Razor Group into one of 63 00:03:53.550 --> 00:03:57.390 Germany's largest E commerce operations. What was the moment where 64 00:03:57.390 --> 00:04:01.190 you realized the traditional human only back office model simply 65 00:04:01.190 --> 00:04:04.830 wouldn't scale anymore? Wow. Very 66 00:04:04.830 --> 00:04:08.510 good question. Very good question. Let me think back to the time when we founded 67 00:04:08.670 --> 00:04:12.430 Razor Group. I did this with three other founders 68 00:04:12.910 --> 00:04:16.550 back in summer of 2020. It was 69 00:04:16.550 --> 00:04:20.350 just a few months after the pandemic hit. So everything 70 00:04:20.350 --> 00:04:24.150 was changing, everything was in a turmoil. Things 71 00:04:24.150 --> 00:04:27.310 were changing at a rapid pace. 72 00:04:27.710 --> 00:04:30.960 And so we started our journey 73 00:04:31.600 --> 00:04:35.360 based out of Berlin, getting in touch with e 74 00:04:35.360 --> 00:04:39.040 commerce companies, small e commerce companies that we first 75 00:04:39.040 --> 00:04:42.880 had to explain to, you know, that you can actually sell 76 00:04:42.880 --> 00:04:46.560 your business, right? You can find a buyer and sell your business 77 00:04:47.200 --> 00:04:50.520 to somebody else and have a, you know, life changing 78 00:04:50.520 --> 00:04:54.160 exit event. That was what we started with 79 00:04:54.400 --> 00:04:58.030 and that was, was more, that is what most of Razer was 80 00:04:58.030 --> 00:05:01.790 focused on, right? Getting these deals, finding these 81 00:05:01.790 --> 00:05:05.510 companies that you could acquire. My role as 82 00:05:05.510 --> 00:05:09.230 CEO and co founder was to think about the operations before we 83 00:05:09.230 --> 00:05:12.870 had any operations, right? Everybody was chasing these deals and these 84 00:05:12.870 --> 00:05:16.630 companies. And I was thinking, okay, once we close those deals, once we buy 85 00:05:16.630 --> 00:05:19.830 these companies, what do we do? How do we operate, right? 86 00:05:20.710 --> 00:05:24.550 Starting obviously with a small team, having a few people on board, 87 00:05:25.270 --> 00:05:28.700 the first deals started to come in. I think we acquired our first 88 00:05:29.010 --> 00:05:32.810 company in October of 2020, like two, three months after founding 89 00:05:32.810 --> 00:05:36.370 the, the company. And it was all, 90 00:05:36.370 --> 00:05:39.970 you know, setting up the absolute basics, setting up structures, 91 00:05:40.050 --> 00:05:43.250 setting up responsibilities, setting up 92 00:05:43.250 --> 00:05:46.930 processes. And I very clearly remember this first company 93 00:05:47.010 --> 00:05:50.850 that we acquired. Everything was hands on, right? Everything 94 00:05:50.850 --> 00:05:54.410 was Excel files, very, very manual. Everything 95 00:05:54.410 --> 00:05:58.210 was double checked by a, by a colleague, human, human 96 00:05:58.210 --> 00:06:01.770 interventions. Nothing was, was really system 97 00:06:01.770 --> 00:06:05.450 based. We did know that we would grow very rapidly. 98 00:06:05.450 --> 00:06:09.210 So at that time we already checked what 99 00:06:09.210 --> 00:06:12.730 ERP system do we want to use, right? We already thought about scalability, 100 00:06:13.210 --> 00:06:16.930 had that process running and ultimately even went live with 101 00:06:16.930 --> 00:06:20.650 our ERP at the turn of the, of the year, just 102 00:06:20.730 --> 00:06:24.490 like five, six months after founding the company, we were live with our 103 00:06:24.490 --> 00:06:28.130 erp. We, we chose Oracle netsuite back then. And in 104 00:06:28.130 --> 00:06:31.750 that fall of after the first acquisition, 105 00:06:31.990 --> 00:06:35.510 the second came a third came right, and there was still a pace 106 00:06:35.830 --> 00:06:38.950 that you could manage, right? You hire another colleague, another 107 00:06:39.350 --> 00:06:42.870 specialist for logistics, another one maybe for E commerce 108 00:06:42.870 --> 00:06:46.070 operations. But when this wave of 109 00:06:46.230 --> 00:06:49.830 acquisitions came around, where we heard, 110 00:06:49.830 --> 00:06:53.590 okay, in January, we might do four to six 111 00:06:53.670 --> 00:06:57.480 acquisitions that was my oh shit 112 00:06:57.480 --> 00:07:00.880 moment, pardon my French. That was 113 00:07:00.960 --> 00:07:04.560 exactly. That was the moment where I thought, okay, you can never 114 00:07:04.640 --> 00:07:08.440 hire at high quality at that pace, right? How do you do 115 00:07:08.440 --> 00:07:12.160 this? And so it was the beginning of 116 00:07:12.160 --> 00:07:15.840 thinking even more in terms of scalability, even more 117 00:07:15.840 --> 00:07:19.680 in terms of automation. Standardization. The first step for us 118 00:07:19.680 --> 00:07:23.480 was to standardize the integration process, right? 119 00:07:23.480 --> 00:07:27.210 Understand what are the basic steps that you need to do, in 120 00:07:27.210 --> 00:07:30.690 what order, how do you standardize the entire process so that you can 121 00:07:30.690 --> 00:07:34.370 handle four to six integrations per month. 122 00:07:35.730 --> 00:07:39.490 And that was really the first piece that we had to get in line 123 00:07:39.810 --> 00:07:43.570 to. Then also in second step, think about the operations, right? Once 124 00:07:43.570 --> 00:07:47.210 you integrate that company, it is part of your landscape, it's part of your 125 00:07:47.210 --> 00:07:50.890 IT infrastructure, of your system, process infrastructure, team 126 00:07:50.890 --> 00:07:54.670 infrastructure, then how do you operate it? And so we 127 00:07:54.670 --> 00:07:58.070 always thought in these waves, starting with the integration all the way to 128 00:07:58.070 --> 00:08:01.150 operations, and then improvement, continuous improvement, 129 00:08:01.630 --> 00:08:05.470 implementing more and more standardization, operations, 130 00:08:05.950 --> 00:08:09.470 automation and all of these things. I was 131 00:08:09.470 --> 00:08:12.590 thinking about a company that acquires a lot of other company, 132 00:08:12.750 --> 00:08:16.470 aggregates them. I would instantly have in mind 133 00:08:16.470 --> 00:08:20.080 like one big machine. And you take. Get 134 00:08:20.720 --> 00:08:24.520 rid of as many individual processes as possible and 135 00:08:24.520 --> 00:08:28.000 add all those processes to as 136 00:08:28.000 --> 00:08:30.880 efficient working central machine as possible. 137 00:08:32.000 --> 00:08:35.720 Absolutely. Try to standardize as much as possible, right? Because if 138 00:08:35.720 --> 00:08:39.560 you standardize, you can repeat. It's a blueprint, right? This is the 139 00:08:39.560 --> 00:08:43.040 plan, go execute. You can use some basic 140 00:08:43.040 --> 00:08:46.680 automation. We are not talking about LLMs yet, right? LLMs have not been 141 00:08:46.680 --> 00:08:50.470 anywhere in mainstream at that time, 2020. But it was 142 00:08:50.470 --> 00:08:54.190 more of if then connections, right? If there is an email coming 143 00:08:54.190 --> 00:08:57.870 in, then execute that. Or if somebody pulls a project from a certain 144 00:08:57.870 --> 00:09:01.270 stage to the next one, you automatically send that set of 145 00:09:01.270 --> 00:09:04.430 documents to a certain person, right? So yeah. And this 146 00:09:04.669 --> 00:09:08.430 IFTT logic was already around in the 90s in 147 00:09:08.430 --> 00:09:11.910 Excel. Exactly. Why do you think the back office and 148 00:09:11.910 --> 00:09:15.670 operational processes remain so repetitive, 149 00:09:16.470 --> 00:09:20.230 manually error prone and resistant to automation in. 150 00:09:20.790 --> 00:09:24.310 Even in tech companies, there's a certain degree 151 00:09:24.470 --> 00:09:28.150 to which they need to be in certain companies. But 152 00:09:28.630 --> 00:09:32.350 why even in tech companies, you do everything in front 153 00:09:32.350 --> 00:09:36.150 of us to apply LLMs, to apply agents, to make it 154 00:09:36.310 --> 00:09:39.990 as easy as possible. And then in the back office 155 00:09:40.150 --> 00:09:43.430 you start working paper basement stamps. Yeah, 156 00:09:44.150 --> 00:09:47.710 very good question. I think it has two main components, 157 00:09:47.710 --> 00:09:51.310 really. One component is still of 158 00:09:51.310 --> 00:09:54.950 technical nature, right? Before LLMs, 159 00:09:55.030 --> 00:09:58.789 you could not automate the process of understanding communication, 160 00:09:58.789 --> 00:10:02.550 right? How do you automate an email communication process? Right. 161 00:10:02.550 --> 00:10:05.950 There was no tool that could understand, for example, a 162 00:10:05.950 --> 00:10:09.580 supplier's message. And then reason think 163 00:10:09.580 --> 00:10:13.420 through what the appropriate answer is, and then put that answer into an 164 00:10:13.420 --> 00:10:17.100 email and send it. There was just no technology. Right. And that technology, these 165 00:10:17.100 --> 00:10:20.460 large language models, have now only been around really for a couple of 166 00:10:20.460 --> 00:10:23.860 quarters. Right. So it's still a novelty in terms of technology, but 167 00:10:24.260 --> 00:10:27.980 it is available. It is feasible nowadays, so 168 00:10:27.980 --> 00:10:31.820 that problem is solved. I think the other side of the coin is the 169 00:10:31.820 --> 00:10:35.390 topic of trust. Trust and accountability. Right. 170 00:10:35.630 --> 00:10:39.390 Because when it comes to decisions and to actions, even if 171 00:10:39.390 --> 00:10:43.150 it's just as small as a communication to a customer, to 172 00:10:43.150 --> 00:10:46.750 a supplier, companies tend to still trust 173 00:10:46.750 --> 00:10:50.510 humans more than machines. Right. And if there is a decision 174 00:10:50.590 --> 00:10:54.390 that needs to be taken, for example, on changing delivery dates, on 175 00:10:54.390 --> 00:10:57.670 accepting a certain change, then structures and 176 00:10:57.670 --> 00:11:01.430 organizations rather trust a human to take that call because that human 177 00:11:01.430 --> 00:11:05.160 would be accountable for the outcome. And how do you hold a machine accountable to 178 00:11:05.160 --> 00:11:08.840 something? Right. I think that's the second element that. I 179 00:11:08.840 --> 00:11:12.680 think that, that, that's an important question everybody needs to 180 00:11:12.680 --> 00:11:16.360 answer in the future. It's, it's, I do believe the same question. How do you 181 00:11:16.360 --> 00:11:19.680 hold a company accountable? How can you hold 182 00:11:19.920 --> 00:11:23.560 an AI agent accountable? It will more or 183 00:11:23.560 --> 00:11:26.880 less end up to. To be the accountability 184 00:11:27.200 --> 00:11:31.040 of some human either in charge of those agents or the person 185 00:11:31.200 --> 00:11:33.360 who coded those agents. What do you think? 186 00:11:35.570 --> 00:11:38.370 I agree. I think it's a process that we'll go through 187 00:11:39.010 --> 00:11:42.850 finding exactly how these things are settled. But we do have examples 188 00:11:42.850 --> 00:11:46.410 nowadays. Right. So who is responsible ever? I'd say 189 00:11:46.410 --> 00:11:50.130 classical automation fails. Right? It's the 190 00:11:50.130 --> 00:11:53.250 party who set up that automation or who 191 00:11:53.810 --> 00:11:57.370 agreed to maintain it, to oversee it. 192 00:11:57.370 --> 00:12:01.080 Right. You clearly define this upfront. And I think we're moving into a 193 00:12:01.080 --> 00:12:04.000 world where you need to define it between the parties. 194 00:12:04.800 --> 00:12:08.520 And it's typically something that needs to develop over 195 00:12:08.520 --> 00:12:11.440 time. Kind of what is the standard that everybody agrees to 196 00:12:12.480 --> 00:12:16.160 and how is that all figured out? I think that's a process that 197 00:12:16.560 --> 00:12:20.000 we are in the middle of seeing the development 198 00:12:20.080 --> 00:12:23.920 of. I'm very sure a lot of people who 199 00:12:24.080 --> 00:12:27.440 are deploying or thinking about deploying 200 00:12:27.440 --> 00:12:31.000 AI agents are now thinking, huh, that's a good 201 00:12:31.000 --> 00:12:34.780 question. Never thought of that. What was 202 00:12:34.940 --> 00:12:38.700 like the spark moment that led you to the idea of 203 00:12:38.780 --> 00:12:41.660 an AI employee autonomous 204 00:12:42.140 --> 00:12:45.580 agent that can run a full workflow? 205 00:12:46.380 --> 00:12:50.220 It really was a thought 206 00:12:50.220 --> 00:12:53.580 that came up during the entire journey of Razor Group. Right. 207 00:12:53.980 --> 00:12:57.820 That journey for me was roughly five years long. I just explained 208 00:12:57.820 --> 00:13:01.070 what happened in the first few months. And over the next 209 00:13:01.390 --> 00:13:05.150 quarters, we built that organization. It grew and grew and grew. 210 00:13:05.950 --> 00:13:09.550 And we always saw that there is a lot of manual work 211 00:13:09.710 --> 00:13:12.990 required to really keep things running. Right? You have these, 212 00:13:13.390 --> 00:13:17.070 I would say that API of anything which is human 213 00:13:17.070 --> 00:13:20.910 led. Humans are the API of anything because they understand things, 214 00:13:20.910 --> 00:13:23.550 they can verify things, you can teach them things. 215 00:13:24.590 --> 00:13:27.950 And so they are bridging what classical 216 00:13:28.030 --> 00:13:31.430 systems like ERPs cannot solve, right? For 217 00:13:31.430 --> 00:13:35.070 example, the interaction. And over these five years, as the, 218 00:13:35.070 --> 00:13:38.910 as the organization grew, every, every now and then I was thinking 219 00:13:38.910 --> 00:13:42.470 about, wow, this, this, there must be a different way, there must be a better 220 00:13:42.470 --> 00:13:46.230 way, there must be a way to automate also these processes that are 221 00:13:46.230 --> 00:13:49.230 highly repetitive that you can put into an 222 00:13:49.630 --> 00:13:53.150 sop, a standard operating procedure, but the technology 223 00:13:53.310 --> 00:13:56.820 just wasn't there. And then in 2024 when, 224 00:13:57.220 --> 00:14:01.060 you know, 01 and 4O from ChatGPT, from OpenAI 225 00:14:01.140 --> 00:14:04.940 came out, that was really a pivotal moment for 226 00:14:04.940 --> 00:14:07.620 me and I think also for a lot of other people, 227 00:14:08.580 --> 00:14:12.259 seeing the potential that comes 228 00:14:12.259 --> 00:14:15.820 with these models of understanding, communication, of understanding 229 00:14:15.820 --> 00:14:19.260 context, of understanding, documents that had this 230 00:14:19.260 --> 00:14:23.010 aha moment, wow, now we have the technology that is 231 00:14:23.010 --> 00:14:25.890 reliable enough to do these things, to do these 232 00:14:26.210 --> 00:14:29.850 previously exclusively human processes now 233 00:14:29.850 --> 00:14:33.610 in a machine. And that was the point where we said, let's go ahead, 234 00:14:33.610 --> 00:14:37.450 let's see what we can do with that technology. And that was 235 00:14:37.450 --> 00:14:40.690 really the spark for us to embark on the journey. 236 00:14:41.490 --> 00:14:45.090 And that actually leads us to the next question. What did you do 237 00:14:45.170 --> 00:14:48.610 with those AI employees from Eraser Group? 238 00:14:48.690 --> 00:14:51.920 Experience which operational bottleneck 239 00:14:52.400 --> 00:14:55.280 with the biggest cost sync or scalability 240 00:14:55.920 --> 00:14:59.760 barrier? And how would an AI 241 00:14:59.760 --> 00:15:03.520 employee have solved it? Razer is an 242 00:15:03.520 --> 00:15:06.800 E commerce business and Razer sells 243 00:15:07.200 --> 00:15:10.560 everyday goods, right? And so the 244 00:15:10.720 --> 00:15:14.480 procurement of these goods is very 245 00:15:14.480 --> 00:15:18.160 fragmented. We had a lot of different suppliers from 246 00:15:18.160 --> 00:15:21.610 all around the globe, most of which in fact came from, from 247 00:15:21.610 --> 00:15:25.330 Asia. And the coordination with all 248 00:15:25.330 --> 00:15:28.170 of these suppliers always was a very, very human 249 00:15:28.970 --> 00:15:32.770 driven task, a very manual task. Because a lot of suppliers weren't that 250 00:15:32.770 --> 00:15:36.570 large, right? They didn't have massive, massive factories. They 251 00:15:36.570 --> 00:15:40.290 may not have had, you know, large teams and 252 00:15:40.290 --> 00:15:42.570 also IT teams that work on integrations, 253 00:15:43.610 --> 00:15:47.070 standardized interfaces, etc. But they, they had no 254 00:15:47.070 --> 00:15:50.670 API. You just could not put your order in your ERP and 255 00:15:50.670 --> 00:15:54.510 went over, you had to put it somewhere in your erp, then double 256 00:15:54.510 --> 00:15:58.350 it up, send an email, getting confirmation and so on and so forth. 257 00:15:58.350 --> 00:16:01.670 A lot of back and forth, right? Absolutely, 100%, 258 00:16:01.909 --> 00:16:05.670 a very, very manual process. And that was 259 00:16:05.910 --> 00:16:09.270 the field where we figured, wow, we have a lot of volume, right? 260 00:16:09.510 --> 00:16:13.190 Every single product that we buy and then sell to 261 00:16:13.190 --> 00:16:17.030 customers goes through that process. We had a lot of fragmentation, 262 00:16:17.190 --> 00:16:20.990 right? I think about 500 suppliers or even more. A lot of 263 00:16:20.990 --> 00:16:24.790 different languages at play, right? Sourcing from China, from Vietnam, 264 00:16:25.030 --> 00:16:28.790 from India, from all around the globe and all of that variety. 265 00:16:29.350 --> 00:16:33.030 And we figured, well, this is something that we want to take up first 266 00:16:33.030 --> 00:16:36.630 and set up a trial. And that trial, taking 267 00:16:36.630 --> 00:16:40.470 care of that supplier communication and coordination, right? The 268 00:16:40.470 --> 00:16:44.110 exchange of, update of dates, update of quantities, 269 00:16:44.110 --> 00:16:47.910 etc. Tackling that that was our first use case that we 270 00:16:47.910 --> 00:16:51.510 approached and we just saw the impact that you can 271 00:16:51.510 --> 00:16:55.150 create and that was, that was a real eye opener for us. 272 00:16:56.590 --> 00:17:00.150 Before we get into the question about your assumption about 273 00:17:00.150 --> 00:17:03.310 starting ADA AI, how did you get the name? 274 00:17:05.870 --> 00:17:09.550 Very good question. Sreshta, who is 275 00:17:09.710 --> 00:17:13.489 a co founder of mine, she was also 276 00:17:13.489 --> 00:17:16.969 a co founder at Razor Group CTO and is now also co 277 00:17:16.969 --> 00:17:20.689 founder at ADA AI. She's, she 278 00:17:20.689 --> 00:17:24.329 studied computer science in Stanford. So she's a techie through and through. 279 00:17:25.449 --> 00:17:29.049 And I remember it was her idea that we name 280 00:17:29.529 --> 00:17:33.049 ADA ADA because of ADA Loveless, which I 281 00:17:33.049 --> 00:17:35.929 learned was the first computer programmer. 282 00:17:36.889 --> 00:17:39.880 And you know, sounds good, 283 00:17:40.680 --> 00:17:43.800 it has a good ring to it. And so I think we went on board 284 00:17:43.800 --> 00:17:47.400 with it and like the name so far. When you then started 285 00:17:47.400 --> 00:17:50.760 ada, what was your assumption about 286 00:17:50.920 --> 00:17:54.520 agentic AI? And what assumption turned out to be 287 00:17:54.520 --> 00:17:58.200 completely wrong? If you go through, 288 00:17:58.760 --> 00:18:02.440 you know, LinkedIn, the media, any business related 289 00:18:03.000 --> 00:18:06.400 social media out there, you always get the 290 00:18:06.480 --> 00:18:09.800 statement, do vertical AI, do highly 291 00:18:09.800 --> 00:18:13.600 specialized AI just become the best AI for 292 00:18:13.920 --> 00:18:17.440 customs declarations, become the best AI for 293 00:18:18.000 --> 00:18:21.800 indirect procurement? And that was something that 294 00:18:21.800 --> 00:18:25.440 we heard, that we listened to, but that ultimately 295 00:18:25.440 --> 00:18:28.720 for us turned out to not be the right 296 00:18:29.120 --> 00:18:32.520 approach. Because when we started to speak to 297 00:18:32.520 --> 00:18:36.140 customers, basically asking them, hey, where do you have 298 00:18:36.220 --> 00:18:39.500 repetitive manual work? Where do you have processes 299 00:18:39.820 --> 00:18:43.460 that have not been automated yet? Mostly because they include a lot of 300 00:18:43.460 --> 00:18:46.380 communication, a lot of language, a lot of 301 00:18:47.180 --> 00:18:50.780 unstructuredness in the data. The responses that we got 302 00:18:51.100 --> 00:18:54.940 were all over the place, all over the entire supply chain from 303 00:18:55.020 --> 00:18:58.300 procurement to distribution, 304 00:18:58.620 --> 00:19:01.080 logistics, invoice processing, 305 00:19:02.760 --> 00:19:06.600 sales from all parts of the business. And we started to look 306 00:19:06.600 --> 00:19:09.960 into these use cases and started to look, okay, what does it take 307 00:19:10.280 --> 00:19:14.040 to now build an automation that works end to end? And that 308 00:19:14.040 --> 00:19:17.800 really takes that burden of manual work off 309 00:19:17.800 --> 00:19:21.520 of the team's shoulders. And it turns out that all of 310 00:19:21.520 --> 00:19:25.280 these are similar in terms of what 311 00:19:25.280 --> 00:19:29.060 you need to make them work in the front end. When you look at 312 00:19:29.060 --> 00:19:32.820 it at face value, these use cases are very, very different, right? 313 00:19:33.060 --> 00:19:36.260 One use case may be supplier communication. A supplier 314 00:19:36.820 --> 00:19:40.580 notifies you of delays, or a supplier Notifies you of 315 00:19:40.900 --> 00:19:44.540 change of quantity, right? It's completely different when you compare it 316 00:19:44.540 --> 00:19:48.300 to, I'm processing order in a, in a food 317 00:19:48.300 --> 00:19:51.940 business, right? I'm processing small individual orders from 318 00:19:51.940 --> 00:19:55.660 small retailers, right? I get emails, I need to interpret the email, need to 319 00:19:55.660 --> 00:19:59.340 pull out the items from the email and put them into the erp. Two 320 00:19:59.340 --> 00:20:02.940 very different use cases. But if you look under the hood, 321 00:20:03.180 --> 00:20:06.900 what you need to make them work is really comparable because 322 00:20:06.900 --> 00:20:10.140 what are the elements that you need? You need to be able to understand 323 00:20:10.300 --> 00:20:13.740 communication, number one. Number two, you need to 324 00:20:14.220 --> 00:20:17.940 match certain data in an unstructured way to another 325 00:20:17.940 --> 00:20:21.500 set of data, right? Because people don't use exact 326 00:20:21.500 --> 00:20:25.300 namings of products, people don't use exact phrases, but 327 00:20:25.300 --> 00:20:29.060 you have to do what we call fuzzy match. You need to be integrated 328 00:20:29.140 --> 00:20:32.580 into these different systems. You need to have an 329 00:20:32.580 --> 00:20:36.180 engine that understands context. You need to 330 00:20:36.180 --> 00:20:39.980 have a user interface, right? Because you need to think, what does the team do? 331 00:20:39.980 --> 00:20:43.540 The team needs to interact with the AI. And there are a couple more elements 332 00:20:43.540 --> 00:20:47.300 and modules you could call them. And we identified that 333 00:20:47.300 --> 00:20:50.340 these by themselves are quite repeatable. 334 00:20:51.470 --> 00:20:55.190 They are quite, you know, you just need to arrange them a little 335 00:20:55.190 --> 00:20:59.030 bit, you need to readjust them a little bit, but you can reuse them. And 336 00:20:59.030 --> 00:21:02.430 that was something that came out through the interaction with other 337 00:21:02.430 --> 00:21:05.630 customers, listening to them, going through the process of 338 00:21:06.110 --> 00:21:09.790 figuring out how do you build these automations? That then told us, well, 339 00:21:09.790 --> 00:21:13.550 actually just being vertical, being extremely narrow 340 00:21:13.870 --> 00:21:17.470 is not what yields the best result for the customer. 341 00:21:17.550 --> 00:21:20.990 But being able to think horizontally across the entire 342 00:21:20.990 --> 00:21:24.730 supply chain, across the entire, entire process landscape that you 343 00:21:24.730 --> 00:21:28.530 have in a company is really what, what turns 344 00:21:28.530 --> 00:21:30.410 out to create the most value for the customer. 345 00:21:33.770 --> 00:21:37.250 A lot of companies out there really love the idea of 346 00:21:37.250 --> 00:21:40.330 automation, but feel the real autonomy. 347 00:21:41.850 --> 00:21:44.810 Where do you see the biggest misconceptions about those 348 00:21:44.970 --> 00:21:48.810 autonomous agents? And from my experience, I used to be 349 00:21:48.810 --> 00:21:52.610 a management consultant a couple of markets and what I always have in mind 350 00:21:52.610 --> 00:21:56.020 is night trading. Like, like the Knights in 351 00:21:56.020 --> 00:21:59.740 Armor Night Trading group there was 2012, 352 00:21:59.980 --> 00:22:03.820 bankrupted by an algorithm going, going crazy. Within a 353 00:22:03.820 --> 00:22:07.100 day, they lost almost half a billion US dollars. And 354 00:22:08.620 --> 00:22:11.820 I'm just waiting for the headline news that an autonomous agency 355 00:22:12.220 --> 00:22:15.660 has also done this for a company making the bankrupt. But 356 00:22:16.540 --> 00:22:20.180 before we get into that, because you should not simply say, 357 00:22:20.180 --> 00:22:23.700 okay, let's work, it'll all be fine. You need to manage 358 00:22:23.700 --> 00:22:26.280 that. Do you see as the biggest 359 00:22:26.360 --> 00:22:30.120 misconception about autonomous agents 360 00:22:30.120 --> 00:22:33.800 in general? I think the biggest misconception is 361 00:22:33.800 --> 00:22:37.320 probably around the fact that we are already There 362 00:22:38.280 --> 00:22:41.720 to have true and 100% 363 00:22:41.880 --> 00:22:45.680 autonomy in its purest sense. When we 364 00:22:45.680 --> 00:22:49.120 speak about autonomy, I think there are certain degrees of 365 00:22:49.120 --> 00:22:52.230 autonomy. There's a spectrum of autonomy in 366 00:22:52.310 --> 00:22:55.950 executing certain tasks, right? I think on the very 367 00:22:55.950 --> 00:22:59.790 far end of the spectrum there's this human, human autonomy, right? If you have 368 00:22:59.790 --> 00:23:03.430 a worker and they get the task to get the best deal 369 00:23:03.510 --> 00:23:07.230 on supplying a certain material, then they would go ahead. 370 00:23:07.230 --> 00:23:10.150 They first create a plan, okay? I need to find out who are all of 371 00:23:10.150 --> 00:23:13.910 the relevant suppliers. Then I make a plan for the negotiation. I 372 00:23:13.990 --> 00:23:17.590 have them sent over test samples, right? I do the quality check. 373 00:23:17.670 --> 00:23:21.390 I in parallel need to check with accounting to set up the vendors in the 374 00:23:21.390 --> 00:23:25.170 ERP, etc. It's a multifaceted approach, right? 375 00:23:25.170 --> 00:23:29.010 With different systems interacting with different scenarios that 376 00:23:29.010 --> 00:23:32.810 you have to go through. This is the far end of autonomy, right? But if 377 00:23:32.810 --> 00:23:36.210 you start to cut it down and take away some of these 378 00:23:37.170 --> 00:23:40.650 dimensions and put it into one process, which is, for 379 00:23:40.650 --> 00:23:44.170 example, there are orders incoming, right? There's communication 380 00:23:44.170 --> 00:23:47.650 incoming. That communication has your products, 381 00:23:47.810 --> 00:23:51.610 it has a delivery date, it has an address, then this can also 382 00:23:51.610 --> 00:23:55.430 be automation, sorry, it can also be automation, autonomy, but 383 00:23:55.430 --> 00:23:58.710 in a far less complex way, right? And I think the 384 00:23:58.710 --> 00:24:02.270 misconception that is, that is very dominant still out there is 385 00:24:02.430 --> 00:24:06.110 we are at this far end that AI is possible 386 00:24:06.430 --> 00:24:10.190 to do what a human can do in all its facets and think about 387 00:24:10.190 --> 00:24:13.870 all of the possibilities. But what we see when you 388 00:24:13.870 --> 00:24:17.710 really apply AI and LLMs in a company 389 00:24:17.950 --> 00:24:21.710 in production scale, then what works right now is 390 00:24:21.710 --> 00:24:25.470 this, what I mentioned at the other end of the autonomy spectrum, right? You 391 00:24:25.470 --> 00:24:28.410 have to give the AI AI guardrails. You have to 392 00:24:29.130 --> 00:24:32.690 ensure that whatever should be deterministic, if 393 00:24:32.690 --> 00:24:36.450 then remains deterministic and is not overruled by an 394 00:24:36.450 --> 00:24:40.090 LLM because of its probabilistic nature, right? 395 00:24:40.570 --> 00:24:44.090 And I think that this misconception of we are already there, 396 00:24:44.330 --> 00:24:47.610 I think that's very dominant and it's a little bit dangerous because the 397 00:24:47.610 --> 00:24:51.210 expectations for LLMs and what they can do are completely 398 00:24:51.210 --> 00:24:54.860 overhyped, right? If you really want to have LLMs and 399 00:24:54.860 --> 00:24:58.500 AI work at scale, start with this beginning. Start with these 400 00:24:58.500 --> 00:25:01.900 processes that are well defined. Start with these processes 401 00:25:02.700 --> 00:25:06.420 where also humans exactly know what to do. And it's repetitive 402 00:25:06.420 --> 00:25:09.940 and it's clear we are not there yet at this 403 00:25:09.940 --> 00:25:13.660 very, very far end of, you know, full and true and 100% 404 00:25:13.660 --> 00:25:15.740 autonomy in all of its facets. 405 00:25:18.860 --> 00:25:22.630 I totally believe so. There are still a lot of 406 00:25:22.630 --> 00:25:26.470 jobs. You think, oh, the employees know what to do, but Then 407 00:25:26.710 --> 00:25:30.430 you realize at one point, well there's this aspect 408 00:25:30.430 --> 00:25:34.230 that it's not totally defined and we need to do decision. Well, there's 409 00:25:34.230 --> 00:25:37.910 this one, there's that one. You need to know X, you need to know Y. 410 00:25:37.990 --> 00:25:41.590 So even simple tasks are 411 00:25:42.470 --> 00:25:46.110 difficult sometimes, especially if you need to teach 412 00:25:46.110 --> 00:25:48.470 it through to machine. 413 00:25:50.090 --> 00:25:53.610 We go later into our founders world and they you'll talk about 414 00:25:54.010 --> 00:25:57.770 the one operational failure that kept you up at night and 415 00:25:58.010 --> 00:26:01.130 an AI employee would have helped to prevent. 416 00:26:02.010 --> 00:26:05.690 Let's talk a little bit about obstacles and how to overcome 417 00:26:05.690 --> 00:26:09.450 them. So we already talked a little bit about challenge, 418 00:26:09.450 --> 00:26:12.970 how far AI is. But what was the hardest technical 419 00:26:13.130 --> 00:26:16.550 operational challenge in building AI 420 00:26:16.550 --> 00:26:20.270 employees and how did you solve it? The biggest 421 00:26:20.270 --> 00:26:23.670 challenge really is to grasp 422 00:26:23.830 --> 00:26:27.510 what I would call context. Because 423 00:26:28.950 --> 00:26:32.670 if a process stays within the defined boundaries and 424 00:26:32.670 --> 00:26:36.430 everything is plain vanilla, then it 425 00:26:36.430 --> 00:26:39.870 is not as challenging to, you know, build the 426 00:26:39.870 --> 00:26:43.350 automation, run the automation. But as you mentioned, these exceptions are 427 00:26:43.430 --> 00:26:47.030 what makes it really, really interesting. And behind 428 00:26:47.030 --> 00:26:50.590 these exceptions still there can be rules. But these 429 00:26:50.590 --> 00:26:54.430 rules are typically just in the heads of those people that execute the 430 00:26:54.430 --> 00:26:57.990 process, right? So if I go back to the example of receiving 431 00:26:58.070 --> 00:27:01.790 orders, let me say this is a company that produces some food 432 00:27:01.790 --> 00:27:05.430 product and there are smaller companies that order from them, retailers 433 00:27:05.430 --> 00:27:08.710 or other small companies, then 434 00:27:10.150 --> 00:27:13.950 the context that may be in the head of the operators who previously 435 00:27:13.950 --> 00:27:17.670 received those orders and put them into, into the system, they 436 00:27:17.670 --> 00:27:21.030 may know, you know, a certain customer has certain 437 00:27:21.830 --> 00:27:25.390 conditions for the order, certain delivery days. You can only deliver on 438 00:27:25.390 --> 00:27:29.110 Mondays, Tuesdays and Wednesdays. These kinds of things typically are 439 00:27:29.110 --> 00:27:32.790 not encoded in the erp. They are not encoded in some file, 440 00:27:32.790 --> 00:27:36.630 they are just in the hands of these operators, right? Or for 441 00:27:36.630 --> 00:27:40.390 a certain customer, you have to interpret their language slightly differently, 442 00:27:40.390 --> 00:27:44.070 they refer to a product differently, right? And that context, 443 00:27:44.630 --> 00:27:48.430 that is really what drives complexity and also 444 00:27:48.430 --> 00:27:52.070 what makes it hard for LLMs and AI 445 00:27:52.150 --> 00:27:55.910 if you don't teach it properly to work at that scale. 446 00:27:55.910 --> 00:27:59.670 Because it becomes very frustrating for the team member, right. If it always have 447 00:27:59.670 --> 00:28:03.230 to correct the AI for the same exact thing, right? The 448 00:28:03.230 --> 00:28:06.790 AI over time needs to understand that context, 449 00:28:06.950 --> 00:28:10.710 these very, very special things that again only sit in the head of the 450 00:28:10.710 --> 00:28:14.150 operators. And that is something that, that we came across very early in our 451 00:28:14.150 --> 00:28:17.550 journey and that we solved with what we call our context 452 00:28:17.550 --> 00:28:21.350 engine. It's a part of the product that is absolutely critical 453 00:28:21.910 --> 00:28:25.150 to drive the efficiency and drive the 454 00:28:25.150 --> 00:28:28.830 accuracy of ADA over time because it 455 00:28:28.830 --> 00:28:32.510 captures that context that once again sits in the head 456 00:28:32.510 --> 00:28:35.750 of the operators exclusively in the head of the operators. 457 00:28:36.150 --> 00:28:39.550 And that was a real unlock for us to make sure that this 458 00:28:39.550 --> 00:28:42.790 context gets enriched, codified and used 459 00:28:43.190 --> 00:28:45.350 for the, for the operations going forward. 460 00:28:47.190 --> 00:28:50.550 Yes, that, that knowledge that is locked up 461 00:28:51.110 --> 00:28:54.910 in the mind of an employee, worst, worst case of 462 00:28:54.910 --> 00:28:58.550 a former employee, it's good when they retired because they like, like 463 00:28:58.550 --> 00:29:02.030 to come in again and talk about their job. But if they got 464 00:29:02.030 --> 00:29:05.510 fired, you won't get that knowledge back. So I 465 00:29:05.670 --> 00:29:09.350 totally understand what you're going for. You 466 00:29:09.350 --> 00:29:13.130 also bump if you do process optimization and some stuff so 467 00:29:13.130 --> 00:29:16.610 that there's always a lot of stuff that's not written down. 468 00:29:17.890 --> 00:29:21.010 Without naming confidential clients. What type of 469 00:29:21.010 --> 00:29:24.610 workflows are your employees already replacing 470 00:29:24.610 --> 00:29:28.210 today? The use cases 471 00:29:28.690 --> 00:29:32.410 really come from all parts of the organization. A lot of 472 00:29:32.410 --> 00:29:36.170 use cases, of course are in procurement, in the procure to pay 473 00:29:36.170 --> 00:29:39.650 cycle, but also in order to cash on the distribution 474 00:29:39.650 --> 00:29:42.830 side, in invoice 475 00:29:42.830 --> 00:29:46.470 processing, booking of invoices, you 476 00:29:46.470 --> 00:29:50.070 can think about applications even in other 477 00:29:50.070 --> 00:29:53.710 areas. So what we build 478 00:29:53.870 --> 00:29:57.630 is again customized. It fits to 479 00:29:57.630 --> 00:30:01.470 the specific process at the customer and it can be as 480 00:30:01.470 --> 00:30:05.070 easy as processing order confirmations 481 00:30:05.390 --> 00:30:09.150 from your suppliers, checking any differences and 482 00:30:09.150 --> 00:30:12.910 putting that into the ip. It can be part of your 483 00:30:14.200 --> 00:30:17.960 sales process. Right. If you think about a company that has 484 00:30:17.960 --> 00:30:21.520 large B2B customers that do an annual review of the 485 00:30:21.520 --> 00:30:25.280 contracts and discount negotiations, there's 486 00:30:25.280 --> 00:30:28.760 also a use case that we are, that we've built where 487 00:30:28.760 --> 00:30:31.640 the sales team interacts with ADA 488 00:30:32.200 --> 00:30:35.880 requesting the confirmation for certain discounts they 489 00:30:35.880 --> 00:30:39.720 want to offer. ADA does the calculation of whether this is within 490 00:30:39.800 --> 00:30:43.550 range and then gives the green light to the sales reps to go ahead and 491 00:30:43.780 --> 00:30:47.500 and interact with the customers and offer them these terms. Right. That is also 492 00:30:47.500 --> 00:30:51.220 a use case that we've built. There is a use 493 00:30:51.220 --> 00:30:54.820 case of matching incoming goods 494 00:30:54.900 --> 00:30:58.580 against the purchase order and against the invoice that was 495 00:30:58.580 --> 00:31:02.140 issued. Right. Which would be a three way match or you can even extend to 496 00:31:02.140 --> 00:31:05.620 a four way match. Right. Also, a previously human process 497 00:31:05.780 --> 00:31:09.500 of combining all of these data points, validating 498 00:31:09.500 --> 00:31:13.170 all of these documents and then acting in case of a 499 00:31:13.170 --> 00:31:16.930 discrepancy. That's also a use case that we've built. So there are many, many different 500 00:31:16.930 --> 00:31:19.290 use cases across the entire supply chain. 501 00:31:20.970 --> 00:31:24.250 And beyond that you can automate nowadays. 502 00:31:25.210 --> 00:31:29.050 What always comes to mind for me, keep in mind, I have a finance 503 00:31:29.050 --> 00:31:32.330 background, I work there a lot, is accounting processes. 504 00:31:33.210 --> 00:31:36.650 Because the funny thing is I once talked to 505 00:31:36.970 --> 00:31:40.690 a friend, if you're creative and you're creative in finance, 506 00:31:40.690 --> 00:31:43.890 you'll be rich. If you're creative and you are creative in 507 00:31:43.890 --> 00:31:46.930 accounting you'll go into jail. Right. So 508 00:31:47.490 --> 00:31:51.330 there are very certain limits that you, very 509 00:31:51.330 --> 00:31:54.930 strict rules that you have adhered to. But I do believe 510 00:31:55.490 --> 00:31:59.050 the potential that something goes wrong. There is also one of the 511 00:31:59.050 --> 00:32:02.290 reasons why we'll see this likely later on. 512 00:32:02.530 --> 00:32:06.170 Talking about tax filings. Yeah. If you have a 513 00:32:06.170 --> 00:32:09.720 mistake in there and usually you need to pay 514 00:32:10.190 --> 00:32:13.710 like a thousand euros a month in taxes and then it 515 00:32:13.710 --> 00:32:17.310 ends up 10 billion, you do have a problem. 516 00:32:19.950 --> 00:32:23.790 Yeah. Let's go a little bit into your playbook. 517 00:32:23.790 --> 00:32:27.150 What's like the biggest lesson for founders when 518 00:32:27.230 --> 00:32:30.670 identifying which workflows of theirs are 519 00:32:30.670 --> 00:32:34.230 ripe for agentic automation? And keep in mind, I think with the 520 00:32:34.230 --> 00:32:37.860 counter. Great guys. Very good 521 00:32:37.860 --> 00:32:41.380 point. No, when I think about 522 00:32:41.460 --> 00:32:45.220 founders, you 523 00:32:45.220 --> 00:32:48.500 should start thinking about LLM based or AI based 524 00:32:48.500 --> 00:32:52.300 automation when you have understood a process. I 525 00:32:52.300 --> 00:32:56.100 think that is a very good starting point because if you're still figuring out, 526 00:32:56.260 --> 00:32:59.900 if you're still testing, then you know, what are you going to 527 00:32:59.900 --> 00:33:03.360 automate? How do you going to tell the AI or the LLM 528 00:33:03.990 --> 00:33:07.350 or the system that you want to build what to do? Right. I think 529 00:33:07.590 --> 00:33:11.270 first comes the clarity of what's supposed to happen. How is it supposed to 530 00:33:11.270 --> 00:33:14.910 happen? How will it help me? And does it have scale? That really makes sense 531 00:33:14.910 --> 00:33:18.630 Because I tell you, building something that works 532 00:33:18.870 --> 00:33:22.630 reliably across, you know, all of the 533 00:33:23.190 --> 00:33:26.990 incoming signals that you can have, the variety of, you know, day 534 00:33:26.990 --> 00:33:30.690 to day operations takes time and takes effort. It 535 00:33:30.690 --> 00:33:33.930 may be reduced by now because there are all of these different tools that you 536 00:33:33.930 --> 00:33:37.570 can use, like you know, these Copilot Studios and N8N 537 00:33:37.570 --> 00:33:41.130 and all of these self serve environments which are certainly 538 00:33:41.130 --> 00:33:44.930 helpful, which you can certainly use. But you still need to have a 539 00:33:44.930 --> 00:33:48.450 good understanding of where you want to get to. Right. And that can only happen 540 00:33:48.610 --> 00:33:52.130 if you are clear about the process that you want to, that you want to 541 00:33:52.130 --> 00:33:55.890 automate. But if you have that, then I can encourage you to already start 542 00:33:56.410 --> 00:33:59.770 when you're building a company to already start very early on. Right. Because 543 00:34:00.570 --> 00:34:04.410 it certainly helps you to scale yourself and scale your time 544 00:34:05.050 --> 00:34:08.770 because you can move from doing these things to monitoring these 545 00:34:08.770 --> 00:34:12.410 flows and get more things done in a 546 00:34:12.410 --> 00:34:13.690 shorter time period. 547 00:34:16.650 --> 00:34:20.170 For our audience and the founders are listening, I was 548 00:34:20.170 --> 00:34:23.610 wondering think one repetitive process in your startup 549 00:34:23.870 --> 00:34:27.590 that breaks every week. Got it. Great. Keep that in mind as we 550 00:34:27.590 --> 00:34:31.430 move to the next section. Talking a little bit about 551 00:34:31.430 --> 00:34:35.070 your tactical framework here. Could you walk us through 552 00:34:35.310 --> 00:34:38.990 like 30 day deployment blueprint for onboarding 553 00:34:39.230 --> 00:34:42.350 a company's first AI employee. And 554 00:34:43.470 --> 00:34:47.230 when I think about onboarding and all the stuff you need to add in. Have 555 00:34:47.230 --> 00:34:51.079 you ever heard a politician talked about taxing AI 556 00:34:51.079 --> 00:34:54.719 employees? A very good 557 00:34:54.719 --> 00:34:56.439 question, taxing AI employees. 558 00:34:58.759 --> 00:35:02.319 No, I have not heard about that so far. But it's a very interesting 559 00:35:02.319 --> 00:35:03.719 thought, Very interesting thought. 560 00:35:06.599 --> 00:35:10.039 What's the playbook or what's the approach? So first, 561 00:35:10.599 --> 00:35:14.279 similar to my answer about, you know, when founders should think about 562 00:35:14.439 --> 00:35:18.060 AI based automation, you first need to have the use case clear, 563 00:35:18.060 --> 00:35:21.860 right? What is the process that currently creates a lot of pain, a lot 564 00:35:21.860 --> 00:35:25.500 of headache and ties up very valuable 565 00:35:26.300 --> 00:35:29.980 human resources, human capacities. And if you have that clear, 566 00:35:30.140 --> 00:35:33.820 then it's all about understanding that process in depth, really. Going 567 00:35:33.820 --> 00:35:37.580 through, going through the systems, going through the decision trees. Some of those 568 00:35:37.820 --> 00:35:41.580 may be obvious, some of those may be hidden. And you really only find 569 00:35:41.580 --> 00:35:45.090 out those rules when you go in, when you ask 570 00:35:45.090 --> 00:35:48.650 questions, and when you understand it in more depth. And 571 00:35:48.650 --> 00:35:52.450 we've really encountered quite a few times that having 572 00:35:52.450 --> 00:35:56.050 both a manager and the operator in the same meeting going through that 573 00:35:56.050 --> 00:35:59.850 process, some things emerge where 574 00:35:59.850 --> 00:36:03.410 both had discrepancies. Manager thought, it's handled this way. 575 00:36:03.410 --> 00:36:07.090 The operator says, no, no, no, we have to do it that way because 576 00:36:07.090 --> 00:36:09.910 of reason. Xyz, that happens quite often 577 00:36:10.710 --> 00:36:14.150 and that's a good thing because it creates clarity, it creates visibility. 578 00:36:14.710 --> 00:36:18.430 And very, very often we also have an element of 579 00:36:18.430 --> 00:36:22.070 changing business processes as we uncover them, as we go through 580 00:36:22.070 --> 00:36:25.670 them, the teams that are involved often agree to 581 00:36:25.670 --> 00:36:29.390 change certain things about the process because it makes the 582 00:36:29.390 --> 00:36:32.990 process better. We are not talking about automation, we're just talking about a 583 00:36:32.990 --> 00:36:36.800 shit process being a shit process. Sorry for my language. And a good process 584 00:36:36.800 --> 00:36:40.440 being a good process. And if you go into depth on these processes, you often 585 00:36:40.440 --> 00:36:44.080 find these shortcomings that you can fix right 586 00:36:44.080 --> 00:36:47.840 then and there, just changing how it's supposed to work and 587 00:36:47.840 --> 00:36:51.680 how the sequence should be. Now, if you have done that, if you have 588 00:36:51.680 --> 00:36:55.480 really understood what the process is, then we go ahead and we develop, right? 589 00:36:55.480 --> 00:36:59.200 We develop custom, we develop this bespoke for our customers. So we 590 00:36:59.200 --> 00:37:02.470 need a little bit of time, a few weeks to do that. But when we 591 00:37:02.470 --> 00:37:05.310 are done, we hand over the 592 00:37:05.950 --> 00:37:09.710 ready product. ADA is doing what ADA is supposed to do. And 593 00:37:09.710 --> 00:37:13.510 the customer can test from top to bottom. The customer can 594 00:37:13.510 --> 00:37:17.230 test on all different, you know, scenarios with 595 00:37:17.230 --> 00:37:20.950 live data. And we really appreciate feedback 596 00:37:20.950 --> 00:37:24.710 during that time because we can incorporate the feedback very, very quickly from one day 597 00:37:24.710 --> 00:37:28.510 to the next. And so over a short period of time, a week or two, 598 00:37:28.960 --> 00:37:32.680 we iterate up to a point where ADA creates a lot 599 00:37:32.680 --> 00:37:35.880 of value for the team and the team sees the value because the team has 600 00:37:35.880 --> 00:37:39.720 interacted with ADA a lot and sees that it can take over a lot 601 00:37:39.720 --> 00:37:43.520 of these processes and can help them really meaningfully in the day to day work. 602 00:37:43.520 --> 00:37:47.360 They really feel that they have less burden on their 603 00:37:47.360 --> 00:37:51.000 shoulders and then you're ready to go live. And that is 604 00:37:51.000 --> 00:37:54.760 typically a phase of 30 days. Maybe a little more, maybe 605 00:37:54.760 --> 00:37:55.280 a little less. 606 00:37:58.860 --> 00:38:02.620 I was, I was also putting myself in the shoes of those 607 00:38:02.620 --> 00:38:06.460 employees. And what do you know what's really cool? Because you can 608 00:38:06.460 --> 00:38:10.220 outsource the most boring Nerf and 609 00:38:10.220 --> 00:38:13.940 will breaking repetitive tasks to 610 00:38:13.940 --> 00:38:17.580 an AI agent that you have in your job 611 00:38:17.580 --> 00:38:21.340 and that usually helps. So I think there are a lot of people 612 00:38:21.930 --> 00:38:24.730 who are really interested in helping you there. 613 00:38:25.290 --> 00:38:28.690 Oliver, Normally we would go into an ad break, but we're 614 00:38:28.690 --> 00:38:32.450 recording for already more than 40 minutes. So 615 00:38:32.450 --> 00:38:36.130 I would suggest we make this part one and say 616 00:38:36.130 --> 00:38:39.850 goodbye and then have a part two. What do you say? Love 617 00:38:39.850 --> 00:38:43.690 it. Let's do it. Okay, guys. Oliver, thank 618 00:38:43.690 --> 00:38:47.050 you very much. We will be back with part two with 619 00:38:47.050 --> 00:38:48.970 Oliver and ADA AI. 620 00:38:54.210 --> 00:38:57.570 That's all, folks. Find more news streams, 621 00:38:57.730 --> 00:38:58.850 events and 622 00:38:58.850 --> 00:39:03.250 interviews@www.startuprad.IO. 623 00:39:03.650 --> 00:39:05.810 remember, sharing is caring.