ADA AI: AI Employees Replace Back Office Workflows

If you're a founder, operator or executive, here's the uncomfortable truth. Your back office is stuck in 2015 if you're drowning in repetitive work, operational inefficiencies and processes that break every time you try to scale Today's guest believes the future of work will not be AI assistants, but AI employees, autonomous agents that think, plan and execute real workflows. Dr. Oliver Lugosch built Razor Group to more than 700 million in annual revenue, managing global operations at massive scale.

He's now building ADA AI, or ADA AI as you can say in German, where AI employees are already replacing entire back office workflows. In this episode we we break down what AI employees can actually do today, where they fail, and how founders can employ their first agents in under 30 days. Get ready. This conversation will fundamentally change how you think about operations.

Welcome to Startuprad IO, your podcast and YouTube blog covering the German startup scene with news, interviews and live events. Today we're joined by Dr. Oliver Glugosz, a founder who has lived through one of the most operationally intense journeys in Germany's startup ecosystem. Oliver co founded the Razer Group, an e commerce powerhouse that scaled to over 700 million euros in annual revenue, navigated global supply chains and estimated executed M and A at the pace that would break most companies.

That experience gave him a firsthand look into the limits of human only operations. The arrows, the repetitions, the scalability ceiling. And it led him to a bold idea. What if startups didn't hire more humans for repetitive work, but deploy AI employees instead?

Today all Oliver is a co founder of ADA AI, one of Europe's emerging leaders in agentic AI, a new category where autonomous agents don't just assist, but act, plan and operate independently. These AI employees handle full fledged workflows from data processing to back office tasks, customer operations, and complex decision paths that previously required entire teams. In this interview we'll explore the real limits of traditional automation, how AI employees differ from chatbots and LLM assistants, where autonomous agents shine and where they break, what founders must know before deploying their first AI employee and how AgentIC AI will reshape the startup workforce over the next five years.

They that was a long introduction. Oliver, welcome. Thank you very much. Thanks for having me.

It is totally my pleasure. I'm very, very curious about those AI employees, especially having a company where I still do maybe more work than needed manually. It is always something I had an eye on but could never really get the time to do it. That is something of real interest and I do believe A lot of founders here will, will really, really listen carefully.

If they can do something like their monthly tax filings, that will be just amazing. But first, let us start. You scaled Razor Group into one of Germany's largest E commerce operations. What was the moment where you realized the traditional human only back office model simply wouldn't scale anymore?

Wow. Very good question. Very good question. Let me think back to the time when we founded Razor Group.

I did this with three other founders back in summer of 2020. It was just a few months after the pandemic hit. So everything was changing, everything was in a turmoil. Things were changing at a rapid pace.

And so we started our journey based out of Berlin, getting in touch with e commerce companies, small e commerce companies that we first had to explain to, you know, that you can actually sell your business, right? You can find a buyer and sell your business to somebody else and have a, you know, life changing exit event. That was what we started with and that was, was more, that is what most of Razer was focused on, right? Getting these deals, finding these companies that you could acquire.

My role as CEO and co founder was to think about the operations before we had any operations, right? Everybody was chasing these deals and these companies. And I was thinking, okay, once we close those deals, once we buy these companies, what do we do? How do we operate, right?

Starting obviously with a small team, having a few people on board, the first deals started to come in. I think we acquired our first company in October of 2020, like two, three months after founding the, the company. And it was all, you know, setting up the absolute basics, setting up structures, setting up responsibilities, setting up processes. And I very clearly remember this first company that we acquired.

Everything was hands on, right? Everything was Excel files, very, very manual. Everything was double checked by a, by a colleague, human, human interventions. Nothing was, was really system based.

We did know that we would grow very rapidly. So at that time we already checked what ERP system do we want to use, right? We already thought about scalability, had that process running and ultimately even went live with our ERP at the turn of the, of the year, just like five, six months after founding the company, we were live with our erp. We, we chose Oracle netsuite back then.

And in that fall of after the first acquisition, the second came a third came right, and there was still a pace that you could manage, right? You hire another colleague, another specialist for logistics, another one maybe for E commerce operations. But when this wave of acquisitions came around, where we heard, okay, in January, we might do four to six acquisitions that was my oh shit moment, pardon my French. That was exactly.

That was the moment where I thought, okay, you can never hire at high quality at that pace, right? How do you do this? And so it was the beginning of thinking even more in terms of scalability, even more in terms of automation. Standardization.

The first step for us was to standardize the integration process, right? Understand what are the basic steps that you need to do, in what order, how do you standardize the entire process so that you can handle four to six integrations per month. And that was really the first piece that we had to get in line to. Then also in second step, think about the operations, right?

Once you integrate that company, it is part of your landscape, it's part of your IT infrastructure, of your system, process infrastructure, team infrastructure, then how do you operate it? And so we always thought in these waves, starting with the integration all the way to operations, and then improvement, continuous improvement, implementing more and more standardization, operations, automation and all of these things. I was thinking about a company that acquires a lot of other company, aggregates them.

I would instantly have in mind like one big machine. And you take. Get rid of as many individual processes as possible and add all those processes to as efficient working central machine as possible. Absolutely.

Try to standardize as much as possible, right? Because if you standardize, you can repeat. It's a blueprint, right? This is the plan, go execute.

You can use some basic automation. We are not talking about LLMs yet, right? LLMs have not been anywhere in mainstream at that time, 2020. But it was more of if then connections, right?

If there is an email coming in, then execute that. Or if somebody pulls a project from a certain stage to the next one, you automatically send that set of documents to a certain person, right? So yeah. And this IFTT logic was already around in the 90s in Excel.

Exactly. Why do you think the back office and operational processes remain so repetitive, manually error prone and resistant to automation in. Even in tech companies, there's a certain degree to which they need to be in certain companies. But why even in tech companies, you do everything in front of us to apply LLMs, to apply agents, to make it as easy as possible.

And then in the back office you start working paper basement stamps. Yeah, very good question. I think it has two main components, really. One component is still of technical nature, right?

Before LLMs, you could not automate the process of understanding communication, right? How do you automate an email communication process? Right. There was no tool that could understand, for example, a supplier's message.

And then reason think through what the appropriate answer is, and then put that answer into an email and send it. There was just no technology. Right. And that technology, these large language models, have now only been around really for a couple of quarters.

Right. So it's still a novelty in terms of technology, but it is available. It is feasible nowadays, so that problem is solved. I think the other side of the coin is the topic of trust.

Trust and accountability. Right. Because when it comes to decisions and to actions, even if it's just as small as a communication to a customer, to a supplier, companies tend to still trust humans more than machines. Right.

And if there is a decision that needs to be taken, for example, on changing delivery dates, on accepting a certain change, then structures and organizations rather trust a human to take that call because that human would be accountable for the outcome. And how do you hold a machine accountable to something? Right. I think that's the second element that.

I think that, that, that's an important question everybody needs to answer in the future. It's, it's, I do believe the same question. How do you hold a company accountable? How can you hold an AI agent accountable?

It will more or less end up to. To be the accountability of some human either in charge of those agents or the person who coded those agents. What do you think? I agree.

I think it's a process that we'll go through finding exactly how these things are settled. But we do have examples nowadays. Right. So who is responsible ever?

I'd say classical automation fails. Right? It's the party who set up that automation or who agreed to maintain it, to oversee it. Right.

You clearly define this upfront. And I think we're moving into a world where you need to define it between the parties. And it's typically something that needs to develop over time. Kind of what is the standard that everybody agrees to and how is that all figured out?

I think that's a process that we are in the middle of seeing the development of. I'm very sure a lot of people who are deploying or thinking about deploying AI agents are now thinking, huh, that's a good question. Never thought of that. What was like the spark moment that led you to the idea of an AI employee autonomous agent that can run a full workflow?

It really was a thought that came up during the entire journey of Razor Group. Right. That journey for me was roughly five years long. I just explained what happened in the first few months.

And over the next quarters, we built that organization. It grew and grew and grew. And we always saw that there is a lot of manual work required to really keep things running. Right?

You have these, I would say that API of anything which is human led. Humans are the API of anything because they understand things, they can verify things, you can teach them things. And so they are bridging what classical systems like ERPs cannot solve, right? For example, the interaction.

And over these five years, as the, as the organization grew, every, every now and then I was thinking about, wow, this, this, there must be a different way, there must be a better way, there must be a way to automate also these processes that are highly repetitive that you can put into an sop, a standard operating procedure, but the technology just wasn't there. And then in 2024 when, you know, 01 and 4O from ChatGPT, from OpenAI came out, that was really a pivotal moment for me and I think also for a lot of other people, seeing the potential that comes with these models of understanding, communication, of understanding context, of understanding, documents that had this aha moment, wow, now we have the technology that is reliable enough to do these things, to do these previously exclusively human processes now in a machine.

And that was the point where we said, let's go ahead, let's see what we can do with that technology. And that was really the spark for us to embark on the journey. And that actually leads us to the next question. What did you do with those AI employees from Eraser Group?

Experience which operational bottleneck with the biggest cost sync or scalability barrier? And how would an AI employee have solved it? Razer is an E commerce business and Razer sells everyday goods, right? And so the procurement of these goods is very fragmented.

We had a lot of different suppliers from all around the globe, most of which in fact came from, from Asia. And the coordination with all of these suppliers always was a very, very human driven task, a very manual task. Because a lot of suppliers weren't that large, right? They didn't have massive, massive factories.

They may not have had, you know, large teams and also IT teams that work on integrations, standardized interfaces, etc. But they, they had no API. You just could not put your order in your ERP and went over, you had to put it somewhere in your erp, then double it up, send an email, getting confirmation and so on and so forth. A lot of back and forth, right?

Absolutely, 100%, a very, very manual process. And that was the field where we figured, wow, we have a lot of volume, right? Every single product that we buy and then sell to customers goes through that process. We had a lot of fragmentation, right?

I think about 500 suppliers or even more. A lot of different languages at play, right? Sourcing from China, from Vietnam, from India, from all around the globe and all of that variety. And we figured, well, this is something that we want to take up first and set up a trial.

And that trial, taking care of that supplier communication and coordination, right? The exchange of, update of dates, update of quantities, etc. Tackling that that was our first use case that we approached and we just saw the impact that you can create and that was, that was a real eye opener for us. Before we get into the question about your assumption about starting ADA AI, how did you get the name?

Very good question. Sreshta, who is a co founder of mine, she was also a co founder at Razor Group CTO and is now also co founder at ADA AI. She's, she studied computer science in Stanford. So she's a techie through and through.

And I remember it was her idea that we name ADA ADA because of ADA Loveless, which I learned was the first computer programmer. And you know, sounds good, it has a good ring to it. And so I think we went on board with it and like the name so far. When you then started ada, what was your assumption about agentic AI?

And what assumption turned out to be completely wrong? If you go through, you know, LinkedIn, the media, any business related social media out there, you always get the statement, do vertical AI, do highly specialized AI just become the best AI for customs declarations, become the best AI for indirect procurement? And that was something that we heard, that we listened to, but that ultimately for us turned out to not be the right approach. Because when we started to speak to customers, basically asking them, hey, where do you have repetitive manual work?

Where do you have processes that have not been automated yet? Mostly because they include a lot of communication, a lot of language, a lot of unstructuredness in the data. The responses that we got were all over the place, all over the entire supply chain from procurement to distribution, logistics, invoice processing, sales from all parts of the business. And we started to look into these use cases and started to look, okay, what does it take to now build an automation that works end to end?

And that really takes that burden of manual work off of the team's shoulders. And it turns out that all of these are similar in terms of what you need to make them work in the front end. When you look at it at face value, these use cases are very, very different, right? One use case may be supplier communication.

A supplier notifies you of delays, or a supplier Notifies you of change of quantity, right? It's completely different when you compare it to, I'm processing order in a, in a food business, right? I'm processing small individual orders from small retailers, right? I get emails, I need to interpret the email, need to pull out the items from the email and put them into the erp.

Two very different use cases. But if you look under the hood, what you need to make them work is really comparable because what are the elements that you need? You need to be able to understand communication, number one. Number two, you need to match certain data in an unstructured way to another set of data, right?

Because people don't use exact namings of products, people don't use exact phrases, but you have to do what we call fuzzy match. You need to be integrated into these different systems. You need to have an engine that understands context. You need to have a user interface, right?

Because you need to think, what does the team do? The team needs to interact with the AI. And there are a couple more elements and modules you could call them. And we identified that these by themselves are quite repeatable.

They are quite, you know, you just need to arrange them a little bit, you need to readjust them a little bit, but you can reuse them. And that was something that came out through the interaction with other customers, listening to them, going through the process of figuring out how do you build these automations? That then told us, well, actually just being vertical, being extremely narrow is not what yields the best result for the customer. But being able to think horizontally across the entire supply chain, across the entire, entire process landscape that you have in a company is really what, what turns out to create the most value for the customer.

A lot of companies out there really love the idea of automation, but feel the real autonomy. Where do you see the biggest misconceptions about those autonomous agents? And from my experience, I used to be a management consultant a couple of markets and what I always have in mind is night trading. Like, like the Knights in Armor Night Trading group there was 2012, bankrupted by an algorithm going, going crazy.

Within a day, they lost almost half a billion US dollars. And I'm just waiting for the headline news that an autonomous agency has also done this for a company making the bankrupt. But before we get into that, because you should not simply say, okay, let's work, it'll all be fine. You need to manage that.

Do you see as the biggest misconception about autonomous agents in general? I think the biggest misconception is probably around the fact that we are already There to have true and 100% autonomy in its purest sense. When we speak about autonomy, I think there are certain degrees of autonomy. There's a spectrum of autonomy in executing certain tasks, right?

I think on the very far end of the spectrum there's this human, human autonomy, right? If you have a worker and they get the task to get the best deal on supplying a certain material, then they would go ahead. They first create a plan, okay? I need to find out who are all of the relevant suppliers.

Then I make a plan for the negotiation. I have them sent over test samples, right? I do the quality check. I in parallel need to check with accounting to set up the vendors in the ERP, etc.

It's a multifaceted approach, right? With different systems interacting with different scenarios that you have to go through. This is the far end of autonomy, right? But if you start to cut it down and take away some of these dimensions and put it into one process, which is, for example, there are orders incoming, right?

There's communication incoming. That communication has your products, it has a delivery date, it has an address, then this can also be automation, sorry, it can also be automation, autonomy, but in a far less complex way, right? And I think the misconception that is, that is very dominant still out there is we are at this far end that AI is possible to do what a human can do in all its facets and think about all of the possibilities. But what we see when you really apply AI and LLMs in a company in production scale, then what works right now is this, what I mentioned at the other end of the autonomy spectrum, right?

You have to give the AI AI guardrails. You have to ensure that whatever should be deterministic, if then remains deterministic and is not overruled by an LLM because of its probabilistic nature, right? And I think that this misconception of we are already there, I think that's very dominant and it's a little bit dangerous because the expectations for LLMs and what they can do are completely overhyped, right? If you really want to have LLMs and AI work at scale, start with this beginning.

Start with these processes that are well defined. Start with these processes where also humans exactly know what to do. And it's repetitive and it's clear we are not there yet at this very, very far end of, you know, full and true and 100% autonomy in all of its facets. I totally believe so.

There are still a lot of jobs. You think, oh, the employees know what to do, but Then you realize at one point, well there's this aspect that it's not totally defined and we need to do decision. Well, there's this one, there's that one. You need to know X, you need to know Y.

So even simple tasks are difficult sometimes, especially if you need to teach it through to machine. We go later into our founders world and they you'll talk about the one operational failure that kept you up at night and an AI employee would have helped to prevent. Let's talk a little bit about obstacles and how to overcome them. So we already talked a little bit about challenge, how far AI is.

But what was the hardest technical operational challenge in building AI employees and how did you solve it? The biggest challenge really is to grasp what I would call context. Because if a process stays within the defined boundaries and everything is plain vanilla, then it is not as challenging to, you know, build the automation, run the automation. But as you mentioned, these exceptions are what makes it really, really interesting.

And behind these exceptions still there can be rules. But these rules are typically just in the heads of those people that execute the process, right? So if I go back to the example of receiving orders, let me say this is a company that produces some food product and there are smaller companies that order from them, retailers or other small companies, then the context that may be in the head of the operators who previously received those orders and put them into, into the system, they may know, you know, a certain customer has certain conditions for the order, certain delivery days.

You can only deliver on Mondays, Tuesdays and Wednesdays. These kinds of things typically are not encoded in the erp. They are not encoded in some file, they are just in the hands of these operators, right? Or for a certain customer, you have to interpret their language slightly differently, they refer to a product differently, right?

And that context, that is really what drives complexity and also what makes it hard for LLMs and AI if you don't teach it properly to work at that scale. Because it becomes very frustrating for the team member, right. If it always have to correct the AI for the same exact thing, right? The AI over time needs to understand that context, these very, very special things that again only sit in the head of the operators.

And that is something that, that we came across very early in our journey and that we solved with what we call our context engine. It's a part of the product that is absolutely critical to drive the efficiency and drive the accuracy of ADA over time because it captures that context that once again sits in the head of the operators exclusively in the head of the operators. And that was a real unlock for us to make sure that this context gets enriched, codified and used for the, for the operations going forward.

Yes, that, that knowledge that is locked up in the mind of an employee, worst, worst case of a former employee, it's good when they retired because they like, like to come in again and talk about their job. But if they got fired, you won't get that knowledge back. So I totally understand what you're going for. You also bump if you do process optimization and some stuff so that there's always a lot of stuff that's not written down.

Without naming confidential clients. What type of workflows are your employees already replacing today? The use cases really come from all parts of the organization. A lot of use cases, of course are in procurement, in the procure to pay cycle, but also in order to cash on the distribution side, in invoice processing, booking of invoices, you can think about applications even in other areas.

So what we build is again customized. It fits to the specific process at the customer and it can be as easy as processing order confirmations from your suppliers, checking any differences and putting that into the ip. It can be part of your sales process. Right.

If you think about a company that has large B2B customers that do an annual review of the contracts and discount negotiations, there's also a use case that we are, that we've built where the sales team interacts with ADA requesting the confirmation for certain discounts they want to offer. ADA does the calculation of whether this is within range and then gives the green light to the sales reps to go ahead and and interact with the customers and offer them these terms. Right. That is also a use case that we've built.

There is a use case of matching incoming goods against the purchase order and against the invoice that was issued. Right. Which would be a three way match or you can even extend to a four way match. Right.

Also, a previously human process of combining all of these data points, validating all of these documents and then acting in case of a discrepancy. That's also a use case that we've built. So there are many, many different use cases across the entire supply chain. And beyond that you can automate nowadays.

What always comes to mind for me, keep in mind, I have a finance background, I work there a lot, is accounting processes. Because the funny thing is I once talked to a friend, if you're creative and you're creative in finance, you'll be rich. If you're creative and you are creative in accounting you'll go into jail. Right.

So there are very certain limits that you, very strict rules that you have adhered to. But I do believe the potential that something goes wrong. There is also one of the reasons why we'll see this likely later on. Talking about tax filings.

Yeah. If you have a mistake in there and usually you need to pay like a thousand euros a month in taxes and then it ends up 10 billion, you do have a problem. Yeah. Let's go a little bit into your playbook.

What's like the biggest lesson for founders when identifying which workflows of theirs are ripe for agentic automation? And keep in mind, I think with the counter. Great guys. Very good point.

No, when I think about founders, you should start thinking about LLM based or AI based automation when you have understood a process. I think that is a very good starting point because if you're still figuring out, if you're still testing, then you know, what are you going to automate? How do you going to tell the AI or the LLM or the system that you want to build what to do? Right.

I think first comes the clarity of what's supposed to happen. How is it supposed to happen? How will it help me? And does it have scale?

That really makes sense Because I tell you, building something that works reliably across, you know, all of the incoming signals that you can have, the variety of, you know, day to day operations takes time and takes effort. It may be reduced by now because there are all of these different tools that you can use, like you know, these Copilot Studios and N8N and all of these self serve environments which are certainly helpful, which you can certainly use. But you still need to have a good understanding of where you want to get to.

Right. And that can only happen if you are clear about the process that you want to, that you want to automate. But if you have that, then I can encourage you to already start when you're building a company to already start very early on. Right.

Because it certainly helps you to scale yourself and scale your time because you can move from doing these things to monitoring these flows and get more things done in a shorter time period. For our audience and the founders are listening, I was wondering think one repetitive process in your startup that breaks every week. Got it. Great.

Keep that in mind as we move to the next section. Talking a little bit about your tactical framework here. Could you walk us through like 30 day deployment blueprint for onboarding a company's first AI employee. And when I think about onboarding and all the stuff you need to add in.

Have you ever heard a politician talked about taxing AI employees? A very good question, taxing AI employees. No, I have not heard about that so far. But it's a very interesting thought, Very interesting thought.

What's the playbook or what's the approach? So first, similar to my answer about, you know, when founders should think about AI based automation, you first need to have the use case clear, right? What is the process that currently creates a lot of pain, a lot of headache and ties up very valuable human resources, human capacities. And if you have that clear, then it's all about understanding that process in depth, really.

Going through, going through the systems, going through the decision trees. Some of those may be obvious, some of those may be hidden. And you really only find out those rules when you go in, when you ask questions, and when you understand it in more depth. And we've really encountered quite a few times that having both a manager and the operator in the same meeting going through that process, some things emerge where both had discrepancies.

Manager thought, it's handled this way. The operator says, no, no, no, we have to do it that way because of reason. Xyz, that happens quite often and that's a good thing because it creates clarity, it creates visibility. And very, very often we also have an element of changing business processes as we uncover them, as we go through them, the teams that are involved often agree to change certain things about the process because it makes the process better.

We are not talking about automation, we're just talking about a shit process being a shit process. Sorry for my language. And a good process being a good process. And if you go into depth on these processes, you often find these shortcomings that you can fix right then and there, just changing how it's supposed to work and how the sequence should be.

Now, if you have done that, if you have really understood what the process is, then we go ahead and we develop, right? We develop custom, we develop this bespoke for our customers. So we need a little bit of time, a few weeks to do that. But when we are done, we hand over the ready product.

ADA is doing what ADA is supposed to do. And the customer can test from top to bottom. The customer can test on all different, you know, scenarios with live data. And we really appreciate feedback during that time because we can incorporate the feedback very, very quickly from one day to the next.

And so over a short period of time, a week or two, we iterate up to a point where ADA creates a lot of value for the team and the team sees the value because the team has interacted with ADA a lot and sees that it can take over a lot of these processes and can help them really meaningfully in the day to day work. They really feel that they have less burden on their shoulders and then you're ready to go live. And that is typically a phase of 30 days. Maybe a little more, maybe a little less.

I was, I was also putting myself in the shoes of those employees. And what do you know what's really cool? Because you can outsource the most boring Nerf and will breaking repetitive tasks to an AI agent that you have in your job and that usually helps. So I think there are a lot of people who are really interested in helping you there.

Oliver, Normally we would go into an ad break, but we're recording for already more than 40 minutes. So I would suggest we make this part one and say goodbye and then have a part two. What do you say? Love it.

Let's do it. Okay, guys. Oliver, thank you very much. We will be back with part two with Oliver and ADA AI.

That's all, folks. Find more news streams, events and interviews@www.startuprad.IO.

remember, sharing is caring.