speaker-0: Hello, welcome to the Robotics Stack Podcast. Today we're joined by AK Schultz, co-founder and CEO of SVT Robotics, to talk about getting robots, warehouse systems, and other automation systems working together and why that's sometimes harder than it sounds. This is episode 23. My name is Oscar. And my name is Leo. AK, welcome to the Robotics Tech Podcast. We are very happy to have you here today. First, we
speaker-1: Thank you for having me.
speaker-0: are going to dive into your background and the journey that SVT Robotics has been. But first I would like to ask you a little question, which is, what was the moment when you created SVT Robotics eight years ago that made you realize that getting into automation at the time was the right call for you?
speaker-1: Yeah, so interestingly enough, I started my engineering career as in the nuclear engineering field and and I got recruited into robotics by a Swiss company and during the interview process they showed me a forklift that was driving itself. And now this is in two thousand four, so this is still a relatively new concept of self driving vehicles, and the moment I saw it I was like, I'm in Right. I'm totally in. I left the world of nuclear behind, didn't even look back. And over the course of almost not quite fifteen years, I had deployed somewhere in the magnitude of three quarters of a billion dollars worth of robotics projects. Right. So working with really large companies, you know, Walmart Target, Glaxo Smith Klein, Baxter Healthcare, Galloway, Coca-Cola, all these different types of industries. But the the one that really helped me crystallize the problem statement was working on A very well-known electric car company that was building a very large assembly line out in California for electric cars. And it was such a big project. My estimate is about a billion dollars worth of automation going in at one time. No one company was really big enough to do it ourselves, right? So we were there with our biggest competitors. And witnessing how all the different competitors wrote software made me realize that wow, we're all terrible at this. We are all Writing software that is gonna be obsolete and unsupportable and just the process of getting companies to work with each other is a massively difficult one. And I compare it to getting the Batman and Joker to be friends, cooperate with each other and get something done. And imagine like ten companies like that all trying to get software ridden on the fastest timeline that has ever been set for an assembly line in history, right? It made me realize that no one's incentivized to solve this integration problem. And so really only way to do it is to start a company that effectively became the Switzerland, the technical Switzerland for industrial automation and enterprise systems. And the key to that was we don't build robots and we don't write enterprise software. We focus on fully on defrictionizing the adoption of technology. And even more importantly, once it's adopted. having it done in a way that it's still upgradable. You can still add new pieces of tech, you can without encumbering the wrest. And that assembly line moment was the moment where it's like, wow, this isn't just a problem for our company. It's an industry wide problem. And I recently did a a rough back of the napkin estimate on how many bespoke custom code interfaces there are in the United States. And my estimate, just in industrial automation, is about one point five million custom code interfaces in the US. And flash forward to now when we're trying to tie AI into these systems, if we do it the old way, we'd have to write one point five million interfaces to AI and it would yet again be unmaintainable. Right. So like this is not a thing that can scale and frankly we built it with AI in mind, even though eight years ago AI was still really confined to machine learning. Right. So it wasn't quite ready to scale up like it is today. Yeah.
speaker-0: How do these integrations look like?
speaker-1: We thought about this. In fact, we basically spent about six months at the whiteboard because what we didn't want to do is make the same thing over. And the question we asked ourselves was, okay, companies all use different protocols, you know, communication protocols. They're using different messaging structures and schemas. Even companies that like a warehouse management software company, like a inventory master, basically it's a list of all the different products they have. You can tell all the same data is pretty much there. It's just that the headers are named something different and the organization of what field is first and second and third is different. So the schemas are different. And then you have just the nature of how they communicate. Are they periodic? Do they change when the state changes? All these things are different and it makes it so that when you're combining two things, you're basically having to adapt to each other in all these different ways. And so we would write these interfaces and we do back at the old company, we would always budget three thousand hours for every single project, no matter how boring the project was. And it was because of all these different little weird little things. The other thing is the modern interfaces like rest are very different than how you would communicate to a mainframe. And by the way, there are still something like eight hundred AS four hundred mainframe systems still in operation right now in the industry. It's a huge number. Those can communicate in very primitive fashions like flat file communication, right? So all these things are so incredibly different and there's all these different facets. So the question then is how do you make this work in a world that is inherently chaotic? The answer that most people will say is we have an API, like we saw with through APIs, right? You hear us so many times. But what inherently you're saying is, okay, we have an API that makes us interoperable. What you're saying is I can be interoperable, but the world has to change. To what I do. So as long as world everyone in the world changes to how I do it, then we're interoperable, which is an absolute joke, right? Like anytime you hear that, I giggle, right? And so we have to operate in a world where everything is inherently different. And by the way, we have to assume that legacy tech is always gonna be present, right? We have to live in a world where s the state of the art will be legacy in five years or less. And so a lot of times companies will say, We're gonna implement this. whether it's robotics or AI, we're gonna implement it once all of our systems are upgraded to the state of the art. By the time you you start rolling through, the first one you upgraded is now already legacy by the time you get to the last one. And so you have to live in this chaotic world. And so what we have done is say, okay, the principles are this ignore the molecules of how things look in the physical world and focus on data structures. And number two, nothing talks to anything directly. They are completely abstracted. And so the irony of integration and orchestration is that in order to get things to work with each other, they can't know about each other. They have to be oblivious to the fact that other stuff is there. They just have to transmit data and receive data in the way that they want to. And so what we've done is we've found a way to essentially build what we call these things called softbots that use companies or blue chip their standard API so that They can run their product as they have built it without adjustment or change, which means that anybody who is working with us, they do not have customizations in their product, right? And that's the difference. Like the customizations in the product is really what gets you. That's the unsupported side. And the beauty of this is, you know, in the old way of just writing bespoke code, it's actually not that hard to write custom code, right? It's not complicated. relatively small amount of code. That's easy. What's hard to do is write integrations that are free of technical debt that are upgradable. This is the hard bit. And the more you add, the harder it gets. So like if you imagine writing two in one interface to two different things, that's pretty easy. Well you add in another one, okay. Then suddenly you decide, well, I'm going to tie these two together. And we're going to add another one. We're going to tie this to that. Pretty soon, the more technology you're adding that you're adding to make your business more efficient, you're actually making it harder to add more. You're making it harder to change it. And effectively your company becomes fossilized, becomes rigid every time you add a new piece of tech. But if nothing is aware of anything, all these pieces can be upgraded at will, right? They can be changed at will. And as long as the communication contracts are still enforced, you can do it. It's completely abstracted. And this gives you flexibility on changing your business, adding a new piece of tech. And now it's even more crucial because the cyber vulnerability space right now we've seen four X the cyber vulnerabilities that are showing up this year than last year. And it's all driven by AI, right? And every time that happens, you have to upgrade part of the technology stack. And that means that all you have to test is this piece instead of all the pieces interwoven, right? So there's just in the documentation, just in the meetings, just in the regression testing, all that stuff, man, the the savings are immense. It's the only way to do it in my opinion, but the whole concept is pretty radical. So there's still a lot of companies that want to do it the old way. So that was a very long answer to a very short question. Sorry about that.
speaker-0: I I'm just trying to make it a little bit more tangible for the people that have no idea what we're talking about right now. As far as I understand it, you're basically letting different robotics vendors, for example, connect to one central point instead of building these custom integrations for a warehouse management system and so on. But yeah, maybe in your words or also already with a little example, how do you see?
speaker-1: This. Okay. I just gave you the nerd level eight version. So I'll do nerd nerd level one, right? So imagine the USB protocol, right? Everyone thinks of USB as a cable, but it's not. it's basically a means of communication. And back in the old days before USB, every printer had its own basically a floppy disk that would make it work with your particular computer in that particular operating system. Right. And if you went from Apple to an IBM, that printer is effectively a brick now. And now that doesn't actually matter. It doesn't matter who made the computer, it doesn't matter what operating system. It doesn't matter if you went from Windows, I don't know, 3.0 to XP, right? It doesn't matter. Your printer still works because of the USB protocol. And all that's happening at a motherboard level. Well, making that work now at an enterprise system level, it's the same. general principle. It's a means by which you can simplify all the communication so that you can still use your old HP printer from 10 years ago or the one that you buy today or you swap out for a brother and then you get a new computer and you decide you don't like Windows anymore and you want to go to Mac, you still have all these printers that still work, right? And that's really the the beauty of this. It's not a complicated concept. It's just that there's so many fragmented companies that don't really want To have a standard communication protocol because they use the communication protocol as a means to capture a customer and make it harder to leave. And so this really gives the customer much more flexibility. And frankly, it helps them manage their vendors better, right? But it's also good for the vendors because they don't have to change their stuff for all these different companies. These things we call them softbots. They're little software robots that are there to translate software and convert however. You're communicating into a a common language and a common protocol. And it also puts everything on a common timestamp, right? And the timestamp is so essential. Even small changes and timestamps can make a big difference. If you think about if everything's running in the same timestamp, it's really hard to determine causality when something goes wrong when you don't know if the data sets are operating on the same temporal, same timeline basis, right? I sail a lot and so I have a bunch of cameras. that I use on my sailboat. And it used to be very hard to like edit the video because you didn't know which one started and there's no clacker. I don't have a clacker on my sailboat. Right. But GoPro has this feature where they'll all start at the same time. And it does it based on GPS time. So it's they're all starting exactly the same time. So all the videos synchronized. And that is a huge benefit. It's just in that stupid application of trying to make some footage for my sailboat, right? Like, but in the world of root cause analysis, without assurance that you're on the same timestamp, it makes it very difficult to do any analytics. Again, nerd level starting to creep up on the nerd level again. Apologies.
speaker-0: That's okay. That's why we are here. I have a question about the type of project that you were working on before switching to this unified software approach. You mentioned large automation projects that included you and your competitors for large electric car manufacturers in California to avoid naming any name. So in that case, I'm curious how does it work concretely at this time before, you know, again the unified software platform that you mentioned? It's like you come into their assembly like. Not their warehouse, or maybe both, or maybe it's both at the same time. I don't know. And you come up with existing hardware of the shelves that you buy from someone else, or do you make your own hardware? We understood that you make your own software on top, and your competitors in the same place also make their own software on top. So hence the need for a unified application on the software side. But on the hardware side, for example, in this case, are you and your competitors working in the same place, providing the same thing, or not necessarily? Can you work us for that?
speaker-1: So I make no robots. So we're a robotics company that makes no robots, right? But for me, robotics is more software these days than it is hardware, right? When you really think about it. It's really software with this metal puppet that's attached to it, right? So when I think about the software world, I always think in terms of electrons rather than molecules. So we don't make any besides the moment I start building robots, I remove my Switzerland status, right? So it's important for me to never build a robot. If we go back to this California automotive company, imagine that you need 10 different robots, but you have this manufacturing software that tells you what to make. In the case of most cars these days, the cars that come, they have all these different options, right? Different interiors, different rims, maybe different engines. And as the car comes down the assembly line, they gotta present the exact parts that going on that car at that exact time, right? Almost like custom building cars right there on the assembly line. And we knew hundreds and hundreds of cars in advance what was going to be at that point, at that time, at that minute, at that second, and what parts needed to show up at that exact time. And so this data came from a central piece of software. It's a enterprise software called Manufacturing Execution, which essentially is coordinating the assembly line activities, right? And so that data comes down and Generally, when you look at these large enterprise systems, they originally built to tell human beings what to do. And human beings are really good at taking a broad task and breaking it down into little tasks. Like if I tell you to go pick something up from over there, you just go do it. You don't think, okay, first I need to know which door I go through and how many feet to walk, whether or not I do this or that. The robots need a lot more granularity. So that in itself is more difficult. So you to be very, very prescriptive. And they also care about how I tell you to do things. If I say go pick that up, I could say go pick that thing up, or I could say, Hey, can you go get that for me? Or I could say, walk over there and grab that, right? You would say, it's all the same sentence, right? But a robot really wants it to be in a certain communication level, right? And so how all these different systems communicate, they all want it in a certain way and they want the detail that they want. So how do you make it so You write all this software. Well, everyone brings their documentation and says, this is how we do it. The other side says, Well, this is our documentation and this is how we do it. And they don't match. So what they do is they spin both of those pieces of documentation and they write a brand new document on how they're going to communicate with each other. So instead of one company changing their software, both company changes their software. Imagine that happening 10, 15 times. And so this is all done through meetings. It's all done through long sessions and whiteboarding. It takes months specifications. And then those specifications have to be taken back to engineers and everything has to be tested. And no one really productizes integration code, which means all that integration code has to be tested. It can't be relied upon like the product testing. Right. So and then you test one integration, but then the more companies you add, you have to test all these cross integrations. And it gets harder and harder. And the more stuff I always said once you go past five integrations, the problem just becomes insanely difficult. Three is manageable, five is really hard, six is infinity, right? It's in it's so difficult. And the amount of time you spend in meetings alone. Is crucial. If nothing actually talks with each other directly the way we do it, then all you care about is I just need to know how you communicate. I build something to you that translates you into this common approach. And then we never have to do it again for the rest of time. if you don't change the way you communicate, then I don't care. Just do it the way you do it forever. And you can upgrade and change your product all you want. Just don't change how the information that you send out and receive. Then we're good to go. And same thing for all the different systems. So then everybody is transmitting into this common approach and receiving, and they don't actually know how many other systems are there. No idea. The other thing is interesting is in a bespoke system, if I am transmitting to you, only the two of us can actually see that data. But that data that we're sending may be usable by six other systems. Well, there's no way to get that data over there. And so A new interface gets written for the same data transacting, right? Over and over again, as opposed to if I take data from one player, I can actually enable all these different systems to use that data. So there's no new interfaces being bidden. On top of that, just think about the compute and basically the cloud costs of transacting the same data instead of just consuming the data, transmitting once and consuming it many, many times. And then on top of that. You think about how AI would work, how do you insert AI into all this? Well, if AI is just operating and looking at the data from a central data like highway, then it doesn't care how many little roads there are around the highway. It just cares about the data in the main highway and it can push the make decisions and push data back down. And then anybody connected to the highway, any one of those robot companies can look at that AI decision and use it. So the ability to reuse and recombine. It's just completely transformed and altered, right? And one of our biggest customers is DHL. They have essentially taken our product and they're just rolling with it. They're amazing. They're they've done a fantastic job. They went from doing two sites at their first year. I think they're doing something like 25 this year. And by the way, they're using our software without our team. They're completely independent. They don't use any of our services. And all those softbots are right, they're theirs. They're not SVTs, they're DHLs. their their property. So it gives companies the freedom to operate and scale as fast as they want to scale. Yeah.
speaker-0: Yeah, that's what's going to be my next question about that, is that once your software is is deployed at a customer site, do they need ongoing support? Do you have to deploy a consultant just like Salesforce does to be there on a full time basis? But apparently not, since DHL is doing it on its own.
speaker-1: Right. So generally what we find is that when we onboard a new customer, by site, our goal is by site three, by deployment number three, they're on their own. Now some companies get there faster. Some are good to go on the first go. Some companies don't. They they're like we are not a software company. We make washing powder and that's all we want to do. So we want you to do all the work. So if that's the case, then we support them. A lot of our Customers are integrators. And some people say, well, you're getting rid of integrators. No, no, we're not getting rid of integrators. This is a tool set for integrators. Most of our software is deployed by third party integrators. And those integrators are helping the customer, right? So from a support standpoint, our support is mainly product support. Now, if we wrote the softbots, we'll provide the individual support, but we ran the stats the other day and we are averaging one call per facility per year. in downtime. So one downtime event per company per facility per year. So the product is insanely stable. Generally, if there's a downtime event, it's because the robot company is down or the WMS is down. But because of the nature of how we communicate, the moment there's a downtime event, there's near instantaneous root cause analysis on who is at fault. And it's because when you click on a log, it actually displays the decision tree. And it will show you it's robot company two is the problem, not company three. That means that it saves hours of downtime. Because generally when a factory goes down, the guys on assembly line don't know that it was, a communication error in this JavaScript sitting on this robot. They have no idea. They just know assembly line's not running. And so what happens is they call all the vendors. All the vendors get on the phone and they argue about whose fault it isn't for like two hours and eventually you figure out who it is. Well, two hours you're not making cars, right? One of the Toyota Camry plants builds a Toyota Camry every thirty seconds. There's two cars a minute. if you're down an hour, it's 120 cars. Multiply that times the sales price, think about how much money. And so if you can eliminate that one hour of arguing and instantaneously say it's you, go work on it, then you take it down from hours to minutes of downtime. And that's that's a huge myth.
speaker-0: It and in the case of DHL, what are they specifically connecting? I mean they're logistics, so I assume it's some management system that they have, and then the robotics vendors, and how many are they connecting, for example?
speaker-2: I wanna see...
speaker-1: Probably 10 or 12 different robot companies are using and they're connecting them to three major WMSs, but there's multiple versions of the WMS. So you look at all the different versions of the three companies of WMS, there's probably like six or seven. So it can be any combination of those, but they're adding new ones. They're writing connections to robot companies that we've never connected to before now, and which is really awesome. I love the fact that they're self sufficient like that. So the vendors agent, the most deployed ones are Locust Robotics. They use Geek Plus, Gray Orange, Six River, High Robotics. There's Robust dot AI. There's others. I can't even think of them all, but that's like just the f the ones that are off the top of my head. And then I'd say the two dominant WMSs are Manhattan and and Blue Yonder. This is kind of public information. They talk about this all the time. So I'm not disclosing anything. that you couldn't read. So it's any combination of those. And a lot of the WMSs are AS four hundred. So the mainframes, which seems silly, but man, those mainframes are super solid. They're highly performant and they don't go down. So you'd be surprised how many companies mandate that the mainframes are still used. They're not going away. And we're just as comfortable communicating to a cloud-based warehouse software to a mainframe. It doesn't actually matter to us.
speaker-0: Do you see customers also wanting to connect your software to other things beyond robotics, for example?
speaker-1: Yeah. More and more, I want to say two thirds of our connections are software to software. And a lot of it's in the warehouse, but we're seeing applications elsewhere. We've got, one of the most famous hospitals on earth is using our software. We're seeing applications in retail. There's government applications as well. So we have multiple government applications. We built the software to transcend industries. And the way we did this is we looked at the world. through data and verbs. So if you think about this, a mobile robot moving a box, to make that happen, you need to tell the robot where to go, what to get, and where to take it, right? And then the robot needs to say, I finished and I did it and I dropped it here. Right. Well, that doesn't matter if it's a small box or a pallet. Makes no difference digitally, right? Well, on top of that, I don't care if it's a robot, it could be a forklift, right? Because the guidance system Instead of being silicon is made out of meat, right? we're interpreting the tell me where to go. I'm looking at the screen and interpreting it, but the screen had to be populated, right? All that data had to be populated on the screen. It's just that the guidance system is a human being. So I don't care about that. And I don't actually care if it's a a tractor trailer moving boxes. I don't care if it's an airplane. It's a movement. It's where to go, what to get. And then everything else is like the business data. It's a trucking manifest instead of an e-commerce order. So by ignoring the molecules, I don't really care. I don't care if it's, I don't know, helicopter delivering supplies or an Amazon delivery van is the same. So all these transactional data structures are the same. The other thing is you realize that there's a very finite amount of verbs in the world. The root verbs that are in existence are actually much smaller than you actually think. So let's just take the word go, right? To move. Well you think there's gotta be more. Well what is walking? Well that's move. It's go, right? What is skiing? What is driving? What is flying? These are all permutations on that root verb. To be, right? To create something is all the same. something is, something's made, right? So or things are transformed. So the number Is much smaller. Now there's an infinite number of nouns. So if you can cope with an infinite number of nouns and you can cope with it infinite number of adjectives and adverbs, but the verbs are all the same, well, you can get really scalable on your architecture by looking at the commonality and by having that really nerd level understanding of how what they call the primitives work. You can make things transcend any industry. I don't care what it is, it still applies. I don't care if you're delivering food in a restaurant, it's no different than if you're delivering a Amazon box to your front door. It's the same thing.
speaker-0: Are you using LMs internally for this softbot, for example? Like if you say like you work with words and you see it as a almost like a software robot, I could see giving the software robot almost like an agent, right? Give them like access to an LM and let them configure certain things.
speaker-1: Yeah. So we we do that for the writing. We thought about doing it constantly. in other words, making it so that every interpretation just uses NLMs or, AI in general, right? There's a problem with that, and that's token spend. It's better to do it once, lock it down, use the tokens for the writing instead of just doing it over and over and over again. 'Cause the cost would just explode. We use it to generate the softbots, but then you lock it down. You actually do want it locked down. There's many reasons. Just on the cybersecurity, you kinda want this stuff to be static because by its very nature, the communication is you're connecting two things that are not in the same network and that's a vulnerability, right? So you really want the connection code to be locked down. Otherwise, there's a vulnerability risk there. Also, we think about, bad actors and how they would use it, right? So we're SOC two, type two certified. So we get audited and pen tested. regularly, right? we're constantly looking at vulnerability. So this is very top of mind for us.
speaker-0: So the softbot essentially is local or the the clients host themselves.
speaker-1: So a lot of our customers are hosted by SVT. So we're true cloud, but then a lot of our customers, I'll tell you half, maybe even more than half, are private cloud. So where they're using Azure or AWS or, you know, Google to host the software themselves, but they're managing it through, you know, Azure. Then there's true on prem, which is really rare these days, where it's like a standalone machine. The only time we see that is government applications where, just security. They did want an air gap, but that's pretty rare. So most of the time it's I would say private cloud or or our cloud, one of the two. And incidentally, we can actually deal with an on prem, a robot that's true on prem, another one that is hosted within the customer's cloud, and then a WMS that's true cloud and then a mainframe. We don't care what is being hosted in what way. It all is abstracted and made normal. Yeah, we're obsessed about abstraction, keeping things separated. It also means that you can upgrade really easily. So you can go from the mainframe to a cloud-based system. You just have to change that one connector and nothing else is impacted. In fact, we could run two warehouse management systems, and we have done this where a new one comes online and rather than just doing the hard switch, which I don't know if you've ever been involved in a major enterprise upgrade or swap over. when that happens, it's like Armageddon. The world ends, nothing is moving, nobody can get their stuff. It's terrible. And what we do is we say, just leave the first one running, turn on the other one, and we'll just divert some of the volume over to this one. You know, send one order. Send ten. Right. If it starts working, you feed it ten percent. You feed it twenty. And then you just scale this one up and scale this one down. Something goes wrong, you swap it back, right? Till you're comfortable, and then eventually this one's running. The robots have no idea that it's receiving commands from two different places. And when it's saying I'm acknowledging I finished, it has no idea it's routing it to two different places. It just knows that it's being spit into the highway. What off ramp it gets on, it doesn't actually know. It has no idea. And so this is the beauty of the abstraction. It changes the way you can upgrade. It means that we can upgrade platforms at will. So as more companies add more and more tech, this is just so crucial. Right. And y if you were to talk to a lot of companies, they're frozen. They can't get anything done because changing one thing requires changing ten things. And this is this is the enemy of progress. It's like the anti technology. So the irony is the more tech you add, the harder it is to add more tech, right? It's supposed to make you easier, but no.
speaker-0: harder. Have you seen cross company use cases where let's say there are two companies and they're both integrating a softbot and maybe they're working together in some shape? I could see possibly some synergies there, right?
speaker-1: Yeah, are you talking robot to robot? What do you mean in particular?
speaker-0: I've no specific idea how that would look like, but I imagine let's say they have similar data that is interesting for them, right? Because you're also doing analysis then they wanna share the analysis data or something like that.
speaker-1: Without doubt. The data that's transacted all becomes transparent. When you're black boxes communicating with black boxes, the custom interface is black pipes, right? So the data flowing through it's the customer's data, but they don't actually have access to it, which is nuts, right? Or they get access to the stuff that someone wants them to see, as opposed to this transparent pipe where it's all flowing and it's all visible and everything is consumable. Well, once you embrace that as a company, I can say, well, man, I my product would be better if I had access to this other kind of data. And so that company Y makes that data and at any customer that company Y is at and I'm at, we can actually make our product better by using the data from their product without changing each other's product at all. So yeah, it's all there. The industries that do this well, the smartphone industry, like iOS was groundbreaking, Android followed suit, like enabling all these companies to work near each other without having to to work with each other. you think about on your phone, all the apps are using the accelerometer, a lot of them are using notifications, like GPS is we use all the time. Well they're all subscribing to that GPS data, but if I upgrade Yelp in the middle of navigating to a store, I don't have to shut down Apple Maps to upgrade Yelp. It just They're independent of each other. It doesn't shut the GPS down and shut all the other stuff down. And that's the power of abstraction. It's a what they call a pub sub model, publication subscription, where it's not one hard communication line. Once industry understands it, we're at a point now where we're transacting, I think well, we're above this now. We're doing about a half a billion transactions a month right now. It took us about four years to get to two billion transactions and and that happened as of December thirty first of twenty twenty five, so not even a year ago. And so now we're doing two billion every four months. Once we hit peak season, we'll probably do closer to a billion a month for the next three months. So it was about to skyrocket here. What
speaker-0: Be the smallest client that you will work with? Let's say I'm a small warehouse operating something. What would be the smallest use case where you could see SVT robotics being useful?
speaker-1: We have customers that have one facility. We have customers like DHL has two thousand five hundred, right? Two thousand five hundred is a very big number. It's not about how big you are, it's about their team and their ability to embrace the concept of this, right? And to really take ownership of it. We have companies that are pretty small that have just run with the product. And then we have someone like DHL who has been very public about working with us. They have two teams that are doing this stuff for us, one in North America or in the Americas and one in APAC and EMEA. And they're just going. And I think we've done something like six or seven deployments internationally this year. And no one from SVT has ever gotten a passport stamp. And our first one was in Australia, our first international project. I was really hoping to get a passport stamp for Australia, but unfortunately it was unnecessary for us to go because of how we do things. So I'll have to go to Australia. For my own purposes.
speaker-0: And and how do you charge to customers? Is it by connected system or usage or some license?
speaker-1: Yeah. So for every what we call an engine, usually one engine is for one facility, but a lot of customers have one engine, they sub run multiple facilities off of it. And then we charge by connector. So it's the base, the root license, then the connectivity licenses from there. And that's an annual subscription. But with that, they get all inclusive support and upgrades. And if they're cloud or they don't even have to do the upgrades themselves, we just do it. It's just a push process.
speaker-0: So the smallest type of scenario where you would say it makes sense is okay, you have one system and then let's say two robots connecting.
speaker-1: Most of our deployments start at one robot and one enterprise system, just two connections. The larger benefits starts to get when you're adding more and more, but it usually all starts with just one connection. The benefits there alone are still enough to justify it. The downstream effects, like I'm excited about how AI is gonna be useful. Well, just vibe coding, right? So one of our integrators, they held a vibe coding event where the operator customers invented applications and they vibe coded on there. Well the problem with vibe coding is it's one thing to code something. It's another thing for that code to be used and supported and maintained and scanned for vulnerabilities and so on and so forth. So IT departments are terrified of vibe coded applications from operators, right? It's like it's their worst nightmare. But if you take that logic and encapsulate it in a softbot, then you inherit all our cybersecurity capabilities. All the authentication is inherent in every softbot. So it's enabling customers to take their power back. And it enables operators to actually get functionality that they need right now instead of going through a one year project that it's approved 25% of the time.
speaker-0: Yeah, was wondering when you s spoke about token spend, that if it might be an option for a customer to s have on demand token spend and pay an upgrade, for example, to do some sort of operation there.
speaker-1: We haven't done that yet because IT is usually the customer for us. They usually pay, are the ones who pay. They want to know what the price is gonna be. They are afraid of these open checkbooks, especially when the tokens can be used by anybody in the company and suddenly it's like unlimited budget for everybody, right? So how do you wall it off? I think someday we we will get to more of a token model, but for now, the model we have is aimed at making a predictable budget and for our and for our end customers. See. I have a question.
speaker-0: I have a question about humanoid deployment. what's your take on it? And do you see it happening already or not? Or is it just wishful thinking?
speaker-1: now. What I would say
speaker-2: Eww.
speaker-1: is the business case for using it on earth. It's not so much about the humanoid form. It's the humanoid from the waist down form that I think is a problem. Most industrial applications we have a paved concrete, right? we don't have any factories that are in the middle of a dirt floor. My argument is that if the Serengeti was a parking lot instead of rough ground, we would have evolved with wheels because wheels are way better. Than legs, right? On a transportation basis. Now, the torso is a different thing altogether. The degrees of freedom that the torso house is pretty massive. And so if you look at the cost of just keeping a robot standing without having wheels, it's a lot of battery usage. It's a lot of motors. It's a lot of compute just to keep it standing. And for me, I think the best use for a humanoid. a biped, if you will, is in maybe agricultural applications. It could be military applications, or if you're going to Mars, I could see it'd be very useful on Mars, right? But in factories, I would rather have a torso and wheeled robot combined. That's me personally. And by the way, when you say is it gonna it's gonna happen. It's not a question of if, it's a question of when. It really comes down to compute. It comes down to energy. Battery usage is absolutely crucial. Right. So if you're you're consuming a lot of power just to stand up, then you're gonna be swapping batteries nonstop or charging nonstop. And robots don't earn money when they're charging. They only earn money when they're they're doing stuff, right? So it's a question of economics and applications. And I think it's more nice to have. There's the four legged robots and stuff. Those really hadn't gotten that much industrial traction in warehouses and such because it's easier to have a rolling vehicle. It's cheaper. It just is. So business cases just Not quite there. But for Amazon delivery vans, I could see it. walking upstairs and carrying boxes upstairs, that would be really nice to have. I I would say that anytime you see uneven terrain, that's where I see biped robots being interesting to me. And it doesn't actually have to be biped. It could be quadruped, whatever, four legged. Four legged actually could be better because again, you don't have to balance, right? So there's there's applications for that.
speaker-0: And when you look at the company landscape, specifically companies that have not automated yet, but from your point of view could automate, what do you think hinders them and how can you incentivize speeding this process up?
speaker-1: One is a mystery to me because when I started doing this, I'd say less than five percent of the North America market was automated. And I think I don't know if we even crossed ten percent twenty years later, right? I had figured back in twenty fifteen, Amazon is just crushing it. And I figured, okay, now everyone's gonna jump on. Well, what happened was all the CEOs were like, We need robots. And then the organizations were like, How? We don't know how we don't have the people. So if you look at a company like Amazon or Tesla, well, those are the two that pop in mind right now, but like Amazon and Tesla, they're fundamentally software companies at their heart. Tesla's a software company that happens to make cars. Amazon is a software company that happens to deliver products to you. As opposed to most retailers, they are retailers that happen to have software or I'm an automotive company that happens to have software, not the reverse. And there's a lot of companies, their IT departments are very, very small. relative to their enterprise. And if you're a company that makes washing powder, your core competency is making washing powder. But you're not a tech company per se. And so the problem with that is the moment you take on robots, again, remember I said robots, they need very specific instructions. So telling human beings what to do is just easier because human beings they can hear anything and adapt it in their brain. Robots don't do that. They just they're not good at it. Now, will they become good at it someday? Yeah. They could. Again, it's more compute. It's more all of this, right? But in order to make robots work, you need to have technical chops in the organization. And so if you don't, you have two choices. You either make a team from scratch that can do all this, probably stealing people from a company that's good at it, or you use integrators completely. And those integrators, they have their own finite capacities. And then on top of that, anything that is built. has to be supported. And I think the biggest bottleneck in all of industry right now is company IT departments like and customer IT departments ability to support and upgrade. They're spending as much time upgrading stuff as they are putting new stuff in. In fact, that's the bulk. You know, the bulk of what they do is support and upgrade. And every once in a while they add a new system, right? Like if you think about what percentage of an IT department is there to maintain what's already there. versus adding new stuff, it's a relatively low percentage. So those IT departments are generally the longest timeline. Their timeline is they're longer than making the robots themselves. It's mainly the time it takes to write specifications and then just getting in the queue to do the work. Right. It's the one of the most precious resources in the industry is the time of the in-customer IT departments. And because of how we do things, we love to think that we're helping those IT departments solve their problems because they can rapidly onboard stuff and then the supportability is relatively simple. They save money on the install and they save money on the ongoing TCO to total custom ownership.
speaker-0: Do you also work with customers from absolutely zero that have no automation going?
speaker-1: We have, I would say it's really tough for them to do to go from zero. It's possible. But generally what happens when a company does a robot for first time, they hire a guy from a company. And that guy is the guy or the person, you know, like and and they're alone in all of this, right? And so it takes a lot to build, you know, think about robotics. In the early days, like a company could get away with Like a software engineer, a mechanical engineer, an electrical engineer, right? That's enough to be useful, right? The amount of disciplines now, just software alone, right? Software, think about IT. IT is not one department. It's not people who write software. There's a cybersecurity team. There's the team that manages all the servers and infrastructure. There's the people who are maintaining the network. There was one company where they had one guy whose entire job was to maintain barcode standards. That's his only job. Right. He worked in an IT department and he was Mr. Barcode, right? there's so many disciplines within this that if you don't have those disciplines, it's really it takes a long time to build up. I've just been so impressed with DHL's capability. They've invested early in all this and they've got just a solid, solid team. And they've got a huge head start on many companies. They recognize the need to invest in their team. That is a decade ago, maybe longer. So if you are new to robotics, You have to decide who am I going to partner with or am I going to build it my own? My recommendation is partner with somebody and start building a team alongside. Because if you try to hire one person and that person is going to save your company with robotics, it is probably going to fail because there's so many capabilities that you need and there's no one human being that contains it all. I have some of the most experienced guys in robotics in the industry working for us, and there's not one single person who can do it all. in our company, even with the wealth of experience we have. You have to be humble about how difficult it is to actually pull this off. And a lot of times, I'm a CEO, so I'll say that I probably cause this too. But CEOs will be like, put in robots, go, go do it. I don't care what it takes. Just go do it. Right. And that one sentence, they don't understand the that's one sentence, but it causes ten thousand sentences to have to be done. Right. And and now the new one is go get the go use AI. Go do it. But What it takes to put all that in place, all the infrastructure, all the team, it's actually quite big. So the companies that invested back then are reaping the benefits, like Target and Walmart. They were investing in obviously Amazon. Those capabilities have been there for decades now. If you're just getting started, you're gonna have to partner or else you'll never get off the ground. But I would say once you partner it, start building a corresponding team that matches up to the integrator partner you're using. if you ever want to be able to stand on your own. If you don't have a counterpart, just look at the roster of the integrator you're using and say, okay, I need one of those, one of those, one of those, one of those, one of those. Then you'd have the capability, right? Yeah. And it's better to have more than one of any one because, people can leave. So and if you lose that one person, you're screwed. So Okay.
speaker-0: Interesting. But explaining them the incentive of robotics, you don't think that's an issue anymore. Most people
speaker-1: Well see that. Obviously that's to be a business case, right? There's robots deployments that I don't know, it's like robot jewelry, right? Like I've seen companies do robots just because they wanted to show they were advanced, right? Eventually those robots get ripped out because someone like looks at the bill and says, Wow, we're paying this much to do this. This is kind of crazy. So there has to be a business case eventually. Somebody, the CFO is gonna get a hold of it eventually, right? And so it's pretty clear that Well, frankly, it's not about cutting jobs. It's the fact that you can't hire enough people to do the work. Most companies are are automating because they simply cannot staff up their company. Or they're a turnover of, operational personnel. They go from one facility to another for, they get a one dollar raise per hour and they switch companies. There's very little loyalty these days and people don't stay with one company anymore. There's no retirement plans or anything. So they just switch. Pretty soon your most unstable employee base are your robots. They're the ones that they don't leave. They don't quit for a better job. And frankly, I I'm a believer in using human beings where we're really good. We are really good at grabbing things, right? really good at assembling things. But that's a lot harder for robots to do. But driving something, a thousand meters, a robot can do that. And when a human being is walking a thousand meters, they're not doing the interesting things with their hands. Right. That's w hand-eye coordination is really the superpower of a human being. Motion across ground, there's much better organisms than the human being. We're really kind of sucky at it. You know, the cheetah is way faster. The elephant can carry more than us, right? It's way cheaper for robots to move stuff than it is for a human being. And carry more, it can go faster. So I'd say the number one business case that I see is elimination of walking. is the number one driver of business case in in robotics.
speaker-0: Interesting. AK, thank you so much for being on the Robotics Stack Podcast. It was really insightful. I think it was a different angle that we have not seen before on this channel. A very unique company that you're building. This was episode 23. My name is Oscar. Hey, my name is Leo. Bye.
speaker-1: Thanks. Cheers.
speaker-1: Thank you for having me.
speaker-0: are going to dive into your background and the journey that SVT Robotics has been. But first I would like to ask you a little question, which is, what was the moment when you created SVT Robotics eight years ago that made you realize that getting into automation at the time was the right call for you?
speaker-1: Yeah, so interestingly enough, I started my engineering career as in the nuclear engineering field and and I got recruited into robotics by a Swiss company and during the interview process they showed me a forklift that was driving itself. And now this is in two thousand four, so this is still a relatively new concept of self driving vehicles, and the moment I saw it I was like, I'm in Right. I'm totally in. I left the world of nuclear behind, didn't even look back. And over the course of almost not quite fifteen years, I had deployed somewhere in the magnitude of three quarters of a billion dollars worth of robotics projects. Right. So working with really large companies, you know, Walmart Target, Glaxo Smith Klein, Baxter Healthcare, Galloway, Coca-Cola, all these different types of industries. But the the one that really helped me crystallize the problem statement was working on A very well-known electric car company that was building a very large assembly line out in California for electric cars. And it was such a big project. My estimate is about a billion dollars worth of automation going in at one time. No one company was really big enough to do it ourselves, right? So we were there with our biggest competitors. And witnessing how all the different competitors wrote software made me realize that wow, we're all terrible at this. We are all Writing software that is gonna be obsolete and unsupportable and just the process of getting companies to work with each other is a massively difficult one. And I compare it to getting the Batman and Joker to be friends, cooperate with each other and get something done. And imagine like ten companies like that all trying to get software ridden on the fastest timeline that has ever been set for an assembly line in history, right? It made me realize that no one's incentivized to solve this integration problem. And so really only way to do it is to start a company that effectively became the Switzerland, the technical Switzerland for industrial automation and enterprise systems. And the key to that was we don't build robots and we don't write enterprise software. We focus on fully on defrictionizing the adoption of technology. And even more importantly, once it's adopted. having it done in a way that it's still upgradable. You can still add new pieces of tech, you can without encumbering the wrest. And that assembly line moment was the moment where it's like, wow, this isn't just a problem for our company. It's an industry wide problem. And I recently did a a rough back of the napkin estimate on how many bespoke custom code interfaces there are in the United States. And my estimate, just in industrial automation, is about one point five million custom code interfaces in the US. And flash forward to now when we're trying to tie AI into these systems, if we do it the old way, we'd have to write one point five million interfaces to AI and it would yet again be unmaintainable. Right. So like this is not a thing that can scale and frankly we built it with AI in mind, even though eight years ago AI was still really confined to machine learning. Right. So it wasn't quite ready to scale up like it is today. Yeah.
speaker-0: How do these integrations look like?
speaker-1: We thought about this. In fact, we basically spent about six months at the whiteboard because what we didn't want to do is make the same thing over. And the question we asked ourselves was, okay, companies all use different protocols, you know, communication protocols. They're using different messaging structures and schemas. Even companies that like a warehouse management software company, like a inventory master, basically it's a list of all the different products they have. You can tell all the same data is pretty much there. It's just that the headers are named something different and the organization of what field is first and second and third is different. So the schemas are different. And then you have just the nature of how they communicate. Are they periodic? Do they change when the state changes? All these things are different and it makes it so that when you're combining two things, you're basically having to adapt to each other in all these different ways. And so we would write these interfaces and we do back at the old company, we would always budget three thousand hours for every single project, no matter how boring the project was. And it was because of all these different little weird little things. The other thing is the modern interfaces like rest are very different than how you would communicate to a mainframe. And by the way, there are still something like eight hundred AS four hundred mainframe systems still in operation right now in the industry. It's a huge number. Those can communicate in very primitive fashions like flat file communication, right? So all these things are so incredibly different and there's all these different facets. So the question then is how do you make this work in a world that is inherently chaotic? The answer that most people will say is we have an API, like we saw with through APIs, right? You hear us so many times. But what inherently you're saying is, okay, we have an API that makes us interoperable. What you're saying is I can be interoperable, but the world has to change. To what I do. So as long as world everyone in the world changes to how I do it, then we're interoperable, which is an absolute joke, right? Like anytime you hear that, I giggle, right? And so we have to operate in a world where everything is inherently different. And by the way, we have to assume that legacy tech is always gonna be present, right? We have to live in a world where s the state of the art will be legacy in five years or less. And so a lot of times companies will say, We're gonna implement this. whether it's robotics or AI, we're gonna implement it once all of our systems are upgraded to the state of the art. By the time you you start rolling through, the first one you upgraded is now already legacy by the time you get to the last one. And so you have to live in this chaotic world. And so what we have done is say, okay, the principles are this ignore the molecules of how things look in the physical world and focus on data structures. And number two, nothing talks to anything directly. They are completely abstracted. And so the irony of integration and orchestration is that in order to get things to work with each other, they can't know about each other. They have to be oblivious to the fact that other stuff is there. They just have to transmit data and receive data in the way that they want to. And so what we've done is we've found a way to essentially build what we call these things called softbots that use companies or blue chip their standard API so that They can run their product as they have built it without adjustment or change, which means that anybody who is working with us, they do not have customizations in their product, right? And that's the difference. Like the customizations in the product is really what gets you. That's the unsupported side. And the beauty of this is, you know, in the old way of just writing bespoke code, it's actually not that hard to write custom code, right? It's not complicated. relatively small amount of code. That's easy. What's hard to do is write integrations that are free of technical debt that are upgradable. This is the hard bit. And the more you add, the harder it gets. So like if you imagine writing two in one interface to two different things, that's pretty easy. Well you add in another one, okay. Then suddenly you decide, well, I'm going to tie these two together. And we're going to add another one. We're going to tie this to that. Pretty soon, the more technology you're adding that you're adding to make your business more efficient, you're actually making it harder to add more. You're making it harder to change it. And effectively your company becomes fossilized, becomes rigid every time you add a new piece of tech. But if nothing is aware of anything, all these pieces can be upgraded at will, right? They can be changed at will. And as long as the communication contracts are still enforced, you can do it. It's completely abstracted. And this gives you flexibility on changing your business, adding a new piece of tech. And now it's even more crucial because the cyber vulnerability space right now we've seen four X the cyber vulnerabilities that are showing up this year than last year. And it's all driven by AI, right? And every time that happens, you have to upgrade part of the technology stack. And that means that all you have to test is this piece instead of all the pieces interwoven, right? So there's just in the documentation, just in the meetings, just in the regression testing, all that stuff, man, the the savings are immense. It's the only way to do it in my opinion, but the whole concept is pretty radical. So there's still a lot of companies that want to do it the old way. So that was a very long answer to a very short question. Sorry about that.
speaker-0: I I'm just trying to make it a little bit more tangible for the people that have no idea what we're talking about right now. As far as I understand it, you're basically letting different robotics vendors, for example, connect to one central point instead of building these custom integrations for a warehouse management system and so on. But yeah, maybe in your words or also already with a little example, how do you see?
speaker-1: This. Okay. I just gave you the nerd level eight version. So I'll do nerd nerd level one, right? So imagine the USB protocol, right? Everyone thinks of USB as a cable, but it's not. it's basically a means of communication. And back in the old days before USB, every printer had its own basically a floppy disk that would make it work with your particular computer in that particular operating system. Right. And if you went from Apple to an IBM, that printer is effectively a brick now. And now that doesn't actually matter. It doesn't matter who made the computer, it doesn't matter what operating system. It doesn't matter if you went from Windows, I don't know, 3.0 to XP, right? It doesn't matter. Your printer still works because of the USB protocol. And all that's happening at a motherboard level. Well, making that work now at an enterprise system level, it's the same. general principle. It's a means by which you can simplify all the communication so that you can still use your old HP printer from 10 years ago or the one that you buy today or you swap out for a brother and then you get a new computer and you decide you don't like Windows anymore and you want to go to Mac, you still have all these printers that still work, right? And that's really the the beauty of this. It's not a complicated concept. It's just that there's so many fragmented companies that don't really want To have a standard communication protocol because they use the communication protocol as a means to capture a customer and make it harder to leave. And so this really gives the customer much more flexibility. And frankly, it helps them manage their vendors better, right? But it's also good for the vendors because they don't have to change their stuff for all these different companies. These things we call them softbots. They're little software robots that are there to translate software and convert however. You're communicating into a a common language and a common protocol. And it also puts everything on a common timestamp, right? And the timestamp is so essential. Even small changes and timestamps can make a big difference. If you think about if everything's running in the same timestamp, it's really hard to determine causality when something goes wrong when you don't know if the data sets are operating on the same temporal, same timeline basis, right? I sail a lot and so I have a bunch of cameras. that I use on my sailboat. And it used to be very hard to like edit the video because you didn't know which one started and there's no clacker. I don't have a clacker on my sailboat. Right. But GoPro has this feature where they'll all start at the same time. And it does it based on GPS time. So it's they're all starting exactly the same time. So all the videos synchronized. And that is a huge benefit. It's just in that stupid application of trying to make some footage for my sailboat, right? Like, but in the world of root cause analysis, without assurance that you're on the same timestamp, it makes it very difficult to do any analytics. Again, nerd level starting to creep up on the nerd level again. Apologies.
speaker-0: That's okay. That's why we are here. I have a question about the type of project that you were working on before switching to this unified software approach. You mentioned large automation projects that included you and your competitors for large electric car manufacturers in California to avoid naming any name. So in that case, I'm curious how does it work concretely at this time before, you know, again the unified software platform that you mentioned? It's like you come into their assembly like. Not their warehouse, or maybe both, or maybe it's both at the same time. I don't know. And you come up with existing hardware of the shelves that you buy from someone else, or do you make your own hardware? We understood that you make your own software on top, and your competitors in the same place also make their own software on top. So hence the need for a unified application on the software side. But on the hardware side, for example, in this case, are you and your competitors working in the same place, providing the same thing, or not necessarily? Can you work us for that?
speaker-1: So I make no robots. So we're a robotics company that makes no robots, right? But for me, robotics is more software these days than it is hardware, right? When you really think about it. It's really software with this metal puppet that's attached to it, right? So when I think about the software world, I always think in terms of electrons rather than molecules. So we don't make any besides the moment I start building robots, I remove my Switzerland status, right? So it's important for me to never build a robot. If we go back to this California automotive company, imagine that you need 10 different robots, but you have this manufacturing software that tells you what to make. In the case of most cars these days, the cars that come, they have all these different options, right? Different interiors, different rims, maybe different engines. And as the car comes down the assembly line, they gotta present the exact parts that going on that car at that exact time, right? Almost like custom building cars right there on the assembly line. And we knew hundreds and hundreds of cars in advance what was going to be at that point, at that time, at that minute, at that second, and what parts needed to show up at that exact time. And so this data came from a central piece of software. It's a enterprise software called Manufacturing Execution, which essentially is coordinating the assembly line activities, right? And so that data comes down and Generally, when you look at these large enterprise systems, they originally built to tell human beings what to do. And human beings are really good at taking a broad task and breaking it down into little tasks. Like if I tell you to go pick something up from over there, you just go do it. You don't think, okay, first I need to know which door I go through and how many feet to walk, whether or not I do this or that. The robots need a lot more granularity. So that in itself is more difficult. So you to be very, very prescriptive. And they also care about how I tell you to do things. If I say go pick that up, I could say go pick that thing up, or I could say, Hey, can you go get that for me? Or I could say, walk over there and grab that, right? You would say, it's all the same sentence, right? But a robot really wants it to be in a certain communication level, right? And so how all these different systems communicate, they all want it in a certain way and they want the detail that they want. So how do you make it so You write all this software. Well, everyone brings their documentation and says, this is how we do it. The other side says, Well, this is our documentation and this is how we do it. And they don't match. So what they do is they spin both of those pieces of documentation and they write a brand new document on how they're going to communicate with each other. So instead of one company changing their software, both company changes their software. Imagine that happening 10, 15 times. And so this is all done through meetings. It's all done through long sessions and whiteboarding. It takes months specifications. And then those specifications have to be taken back to engineers and everything has to be tested. And no one really productizes integration code, which means all that integration code has to be tested. It can't be relied upon like the product testing. Right. So and then you test one integration, but then the more companies you add, you have to test all these cross integrations. And it gets harder and harder. And the more stuff I always said once you go past five integrations, the problem just becomes insanely difficult. Three is manageable, five is really hard, six is infinity, right? It's in it's so difficult. And the amount of time you spend in meetings alone. Is crucial. If nothing actually talks with each other directly the way we do it, then all you care about is I just need to know how you communicate. I build something to you that translates you into this common approach. And then we never have to do it again for the rest of time. if you don't change the way you communicate, then I don't care. Just do it the way you do it forever. And you can upgrade and change your product all you want. Just don't change how the information that you send out and receive. Then we're good to go. And same thing for all the different systems. So then everybody is transmitting into this common approach and receiving, and they don't actually know how many other systems are there. No idea. The other thing is interesting is in a bespoke system, if I am transmitting to you, only the two of us can actually see that data. But that data that we're sending may be usable by six other systems. Well, there's no way to get that data over there. And so A new interface gets written for the same data transacting, right? Over and over again, as opposed to if I take data from one player, I can actually enable all these different systems to use that data. So there's no new interfaces being bidden. On top of that, just think about the compute and basically the cloud costs of transacting the same data instead of just consuming the data, transmitting once and consuming it many, many times. And then on top of that. You think about how AI would work, how do you insert AI into all this? Well, if AI is just operating and looking at the data from a central data like highway, then it doesn't care how many little roads there are around the highway. It just cares about the data in the main highway and it can push the make decisions and push data back down. And then anybody connected to the highway, any one of those robot companies can look at that AI decision and use it. So the ability to reuse and recombine. It's just completely transformed and altered, right? And one of our biggest customers is DHL. They have essentially taken our product and they're just rolling with it. They're amazing. They're they've done a fantastic job. They went from doing two sites at their first year. I think they're doing something like 25 this year. And by the way, they're using our software without our team. They're completely independent. They don't use any of our services. And all those softbots are right, they're theirs. They're not SVTs, they're DHLs. their their property. So it gives companies the freedom to operate and scale as fast as they want to scale. Yeah.
speaker-0: Yeah, that's what's going to be my next question about that, is that once your software is is deployed at a customer site, do they need ongoing support? Do you have to deploy a consultant just like Salesforce does to be there on a full time basis? But apparently not, since DHL is doing it on its own.
speaker-1: Right. So generally what we find is that when we onboard a new customer, by site, our goal is by site three, by deployment number three, they're on their own. Now some companies get there faster. Some are good to go on the first go. Some companies don't. They they're like we are not a software company. We make washing powder and that's all we want to do. So we want you to do all the work. So if that's the case, then we support them. A lot of our Customers are integrators. And some people say, well, you're getting rid of integrators. No, no, we're not getting rid of integrators. This is a tool set for integrators. Most of our software is deployed by third party integrators. And those integrators are helping the customer, right? So from a support standpoint, our support is mainly product support. Now, if we wrote the softbots, we'll provide the individual support, but we ran the stats the other day and we are averaging one call per facility per year. in downtime. So one downtime event per company per facility per year. So the product is insanely stable. Generally, if there's a downtime event, it's because the robot company is down or the WMS is down. But because of the nature of how we communicate, the moment there's a downtime event, there's near instantaneous root cause analysis on who is at fault. And it's because when you click on a log, it actually displays the decision tree. And it will show you it's robot company two is the problem, not company three. That means that it saves hours of downtime. Because generally when a factory goes down, the guys on assembly line don't know that it was, a communication error in this JavaScript sitting on this robot. They have no idea. They just know assembly line's not running. And so what happens is they call all the vendors. All the vendors get on the phone and they argue about whose fault it isn't for like two hours and eventually you figure out who it is. Well, two hours you're not making cars, right? One of the Toyota Camry plants builds a Toyota Camry every thirty seconds. There's two cars a minute. if you're down an hour, it's 120 cars. Multiply that times the sales price, think about how much money. And so if you can eliminate that one hour of arguing and instantaneously say it's you, go work on it, then you take it down from hours to minutes of downtime. And that's that's a huge myth.
speaker-0: It and in the case of DHL, what are they specifically connecting? I mean they're logistics, so I assume it's some management system that they have, and then the robotics vendors, and how many are they connecting, for example?
speaker-2: I wanna see...
speaker-1: Probably 10 or 12 different robot companies are using and they're connecting them to three major WMSs, but there's multiple versions of the WMS. So you look at all the different versions of the three companies of WMS, there's probably like six or seven. So it can be any combination of those, but they're adding new ones. They're writing connections to robot companies that we've never connected to before now, and which is really awesome. I love the fact that they're self sufficient like that. So the vendors agent, the most deployed ones are Locust Robotics. They use Geek Plus, Gray Orange, Six River, High Robotics. There's Robust dot AI. There's others. I can't even think of them all, but that's like just the f the ones that are off the top of my head. And then I'd say the two dominant WMSs are Manhattan and and Blue Yonder. This is kind of public information. They talk about this all the time. So I'm not disclosing anything. that you couldn't read. So it's any combination of those. And a lot of the WMSs are AS four hundred. So the mainframes, which seems silly, but man, those mainframes are super solid. They're highly performant and they don't go down. So you'd be surprised how many companies mandate that the mainframes are still used. They're not going away. And we're just as comfortable communicating to a cloud-based warehouse software to a mainframe. It doesn't actually matter to us.
speaker-0: Do you see customers also wanting to connect your software to other things beyond robotics, for example?
speaker-1: Yeah. More and more, I want to say two thirds of our connections are software to software. And a lot of it's in the warehouse, but we're seeing applications elsewhere. We've got, one of the most famous hospitals on earth is using our software. We're seeing applications in retail. There's government applications as well. So we have multiple government applications. We built the software to transcend industries. And the way we did this is we looked at the world. through data and verbs. So if you think about this, a mobile robot moving a box, to make that happen, you need to tell the robot where to go, what to get, and where to take it, right? And then the robot needs to say, I finished and I did it and I dropped it here. Right. Well, that doesn't matter if it's a small box or a pallet. Makes no difference digitally, right? Well, on top of that, I don't care if it's a robot, it could be a forklift, right? Because the guidance system Instead of being silicon is made out of meat, right? we're interpreting the tell me where to go. I'm looking at the screen and interpreting it, but the screen had to be populated, right? All that data had to be populated on the screen. It's just that the guidance system is a human being. So I don't care about that. And I don't actually care if it's a a tractor trailer moving boxes. I don't care if it's an airplane. It's a movement. It's where to go, what to get. And then everything else is like the business data. It's a trucking manifest instead of an e-commerce order. So by ignoring the molecules, I don't really care. I don't care if it's, I don't know, helicopter delivering supplies or an Amazon delivery van is the same. So all these transactional data structures are the same. The other thing is you realize that there's a very finite amount of verbs in the world. The root verbs that are in existence are actually much smaller than you actually think. So let's just take the word go, right? To move. Well you think there's gotta be more. Well what is walking? Well that's move. It's go, right? What is skiing? What is driving? What is flying? These are all permutations on that root verb. To be, right? To create something is all the same. something is, something's made, right? So or things are transformed. So the number Is much smaller. Now there's an infinite number of nouns. So if you can cope with an infinite number of nouns and you can cope with it infinite number of adjectives and adverbs, but the verbs are all the same, well, you can get really scalable on your architecture by looking at the commonality and by having that really nerd level understanding of how what they call the primitives work. You can make things transcend any industry. I don't care what it is, it still applies. I don't care if you're delivering food in a restaurant, it's no different than if you're delivering a Amazon box to your front door. It's the same thing.
speaker-0: Are you using LMs internally for this softbot, for example? Like if you say like you work with words and you see it as a almost like a software robot, I could see giving the software robot almost like an agent, right? Give them like access to an LM and let them configure certain things.
speaker-1: Yeah. So we we do that for the writing. We thought about doing it constantly. in other words, making it so that every interpretation just uses NLMs or, AI in general, right? There's a problem with that, and that's token spend. It's better to do it once, lock it down, use the tokens for the writing instead of just doing it over and over and over again. 'Cause the cost would just explode. We use it to generate the softbots, but then you lock it down. You actually do want it locked down. There's many reasons. Just on the cybersecurity, you kinda want this stuff to be static because by its very nature, the communication is you're connecting two things that are not in the same network and that's a vulnerability, right? So you really want the connection code to be locked down. Otherwise, there's a vulnerability risk there. Also, we think about, bad actors and how they would use it, right? So we're SOC two, type two certified. So we get audited and pen tested. regularly, right? we're constantly looking at vulnerability. So this is very top of mind for us.
speaker-0: So the softbot essentially is local or the the clients host themselves.
speaker-1: So a lot of our customers are hosted by SVT. So we're true cloud, but then a lot of our customers, I'll tell you half, maybe even more than half, are private cloud. So where they're using Azure or AWS or, you know, Google to host the software themselves, but they're managing it through, you know, Azure. Then there's true on prem, which is really rare these days, where it's like a standalone machine. The only time we see that is government applications where, just security. They did want an air gap, but that's pretty rare. So most of the time it's I would say private cloud or or our cloud, one of the two. And incidentally, we can actually deal with an on prem, a robot that's true on prem, another one that is hosted within the customer's cloud, and then a WMS that's true cloud and then a mainframe. We don't care what is being hosted in what way. It all is abstracted and made normal. Yeah, we're obsessed about abstraction, keeping things separated. It also means that you can upgrade really easily. So you can go from the mainframe to a cloud-based system. You just have to change that one connector and nothing else is impacted. In fact, we could run two warehouse management systems, and we have done this where a new one comes online and rather than just doing the hard switch, which I don't know if you've ever been involved in a major enterprise upgrade or swap over. when that happens, it's like Armageddon. The world ends, nothing is moving, nobody can get their stuff. It's terrible. And what we do is we say, just leave the first one running, turn on the other one, and we'll just divert some of the volume over to this one. You know, send one order. Send ten. Right. If it starts working, you feed it ten percent. You feed it twenty. And then you just scale this one up and scale this one down. Something goes wrong, you swap it back, right? Till you're comfortable, and then eventually this one's running. The robots have no idea that it's receiving commands from two different places. And when it's saying I'm acknowledging I finished, it has no idea it's routing it to two different places. It just knows that it's being spit into the highway. What off ramp it gets on, it doesn't actually know. It has no idea. And so this is the beauty of the abstraction. It changes the way you can upgrade. It means that we can upgrade platforms at will. So as more companies add more and more tech, this is just so crucial. Right. And y if you were to talk to a lot of companies, they're frozen. They can't get anything done because changing one thing requires changing ten things. And this is this is the enemy of progress. It's like the anti technology. So the irony is the more tech you add, the harder it is to add more tech, right? It's supposed to make you easier, but no.
speaker-0: harder. Have you seen cross company use cases where let's say there are two companies and they're both integrating a softbot and maybe they're working together in some shape? I could see possibly some synergies there, right?
speaker-1: Yeah, are you talking robot to robot? What do you mean in particular?
speaker-0: I've no specific idea how that would look like, but I imagine let's say they have similar data that is interesting for them, right? Because you're also doing analysis then they wanna share the analysis data or something like that.
speaker-1: Without doubt. The data that's transacted all becomes transparent. When you're black boxes communicating with black boxes, the custom interface is black pipes, right? So the data flowing through it's the customer's data, but they don't actually have access to it, which is nuts, right? Or they get access to the stuff that someone wants them to see, as opposed to this transparent pipe where it's all flowing and it's all visible and everything is consumable. Well, once you embrace that as a company, I can say, well, man, I my product would be better if I had access to this other kind of data. And so that company Y makes that data and at any customer that company Y is at and I'm at, we can actually make our product better by using the data from their product without changing each other's product at all. So yeah, it's all there. The industries that do this well, the smartphone industry, like iOS was groundbreaking, Android followed suit, like enabling all these companies to work near each other without having to to work with each other. you think about on your phone, all the apps are using the accelerometer, a lot of them are using notifications, like GPS is we use all the time. Well they're all subscribing to that GPS data, but if I upgrade Yelp in the middle of navigating to a store, I don't have to shut down Apple Maps to upgrade Yelp. It just They're independent of each other. It doesn't shut the GPS down and shut all the other stuff down. And that's the power of abstraction. It's a what they call a pub sub model, publication subscription, where it's not one hard communication line. Once industry understands it, we're at a point now where we're transacting, I think well, we're above this now. We're doing about a half a billion transactions a month right now. It took us about four years to get to two billion transactions and and that happened as of December thirty first of twenty twenty five, so not even a year ago. And so now we're doing two billion every four months. Once we hit peak season, we'll probably do closer to a billion a month for the next three months. So it was about to skyrocket here. What
speaker-0: Be the smallest client that you will work with? Let's say I'm a small warehouse operating something. What would be the smallest use case where you could see SVT robotics being useful?
speaker-1: We have customers that have one facility. We have customers like DHL has two thousand five hundred, right? Two thousand five hundred is a very big number. It's not about how big you are, it's about their team and their ability to embrace the concept of this, right? And to really take ownership of it. We have companies that are pretty small that have just run with the product. And then we have someone like DHL who has been very public about working with us. They have two teams that are doing this stuff for us, one in North America or in the Americas and one in APAC and EMEA. And they're just going. And I think we've done something like six or seven deployments internationally this year. And no one from SVT has ever gotten a passport stamp. And our first one was in Australia, our first international project. I was really hoping to get a passport stamp for Australia, but unfortunately it was unnecessary for us to go because of how we do things. So I'll have to go to Australia. For my own purposes.
speaker-0: And and how do you charge to customers? Is it by connected system or usage or some license?
speaker-1: Yeah. So for every what we call an engine, usually one engine is for one facility, but a lot of customers have one engine, they sub run multiple facilities off of it. And then we charge by connector. So it's the base, the root license, then the connectivity licenses from there. And that's an annual subscription. But with that, they get all inclusive support and upgrades. And if they're cloud or they don't even have to do the upgrades themselves, we just do it. It's just a push process.
speaker-0: So the smallest type of scenario where you would say it makes sense is okay, you have one system and then let's say two robots connecting.
speaker-1: Most of our deployments start at one robot and one enterprise system, just two connections. The larger benefits starts to get when you're adding more and more, but it usually all starts with just one connection. The benefits there alone are still enough to justify it. The downstream effects, like I'm excited about how AI is gonna be useful. Well, just vibe coding, right? So one of our integrators, they held a vibe coding event where the operator customers invented applications and they vibe coded on there. Well the problem with vibe coding is it's one thing to code something. It's another thing for that code to be used and supported and maintained and scanned for vulnerabilities and so on and so forth. So IT departments are terrified of vibe coded applications from operators, right? It's like it's their worst nightmare. But if you take that logic and encapsulate it in a softbot, then you inherit all our cybersecurity capabilities. All the authentication is inherent in every softbot. So it's enabling customers to take their power back. And it enables operators to actually get functionality that they need right now instead of going through a one year project that it's approved 25% of the time.
speaker-0: Yeah, was wondering when you s spoke about token spend, that if it might be an option for a customer to s have on demand token spend and pay an upgrade, for example, to do some sort of operation there.
speaker-1: We haven't done that yet because IT is usually the customer for us. They usually pay, are the ones who pay. They want to know what the price is gonna be. They are afraid of these open checkbooks, especially when the tokens can be used by anybody in the company and suddenly it's like unlimited budget for everybody, right? So how do you wall it off? I think someday we we will get to more of a token model, but for now, the model we have is aimed at making a predictable budget and for our and for our end customers. See. I have a question.
speaker-0: I have a question about humanoid deployment. what's your take on it? And do you see it happening already or not? Or is it just wishful thinking?
speaker-1: now. What I would say
speaker-2: Eww.
speaker-1: is the business case for using it on earth. It's not so much about the humanoid form. It's the humanoid from the waist down form that I think is a problem. Most industrial applications we have a paved concrete, right? we don't have any factories that are in the middle of a dirt floor. My argument is that if the Serengeti was a parking lot instead of rough ground, we would have evolved with wheels because wheels are way better. Than legs, right? On a transportation basis. Now, the torso is a different thing altogether. The degrees of freedom that the torso house is pretty massive. And so if you look at the cost of just keeping a robot standing without having wheels, it's a lot of battery usage. It's a lot of motors. It's a lot of compute just to keep it standing. And for me, I think the best use for a humanoid. a biped, if you will, is in maybe agricultural applications. It could be military applications, or if you're going to Mars, I could see it'd be very useful on Mars, right? But in factories, I would rather have a torso and wheeled robot combined. That's me personally. And by the way, when you say is it gonna it's gonna happen. It's not a question of if, it's a question of when. It really comes down to compute. It comes down to energy. Battery usage is absolutely crucial. Right. So if you're you're consuming a lot of power just to stand up, then you're gonna be swapping batteries nonstop or charging nonstop. And robots don't earn money when they're charging. They only earn money when they're they're doing stuff, right? So it's a question of economics and applications. And I think it's more nice to have. There's the four legged robots and stuff. Those really hadn't gotten that much industrial traction in warehouses and such because it's easier to have a rolling vehicle. It's cheaper. It just is. So business cases just Not quite there. But for Amazon delivery vans, I could see it. walking upstairs and carrying boxes upstairs, that would be really nice to have. I I would say that anytime you see uneven terrain, that's where I see biped robots being interesting to me. And it doesn't actually have to be biped. It could be quadruped, whatever, four legged. Four legged actually could be better because again, you don't have to balance, right? So there's there's applications for that.
speaker-0: And when you look at the company landscape, specifically companies that have not automated yet, but from your point of view could automate, what do you think hinders them and how can you incentivize speeding this process up?
speaker-1: One is a mystery to me because when I started doing this, I'd say less than five percent of the North America market was automated. And I think I don't know if we even crossed ten percent twenty years later, right? I had figured back in twenty fifteen, Amazon is just crushing it. And I figured, okay, now everyone's gonna jump on. Well, what happened was all the CEOs were like, We need robots. And then the organizations were like, How? We don't know how we don't have the people. So if you look at a company like Amazon or Tesla, well, those are the two that pop in mind right now, but like Amazon and Tesla, they're fundamentally software companies at their heart. Tesla's a software company that happens to make cars. Amazon is a software company that happens to deliver products to you. As opposed to most retailers, they are retailers that happen to have software or I'm an automotive company that happens to have software, not the reverse. And there's a lot of companies, their IT departments are very, very small. relative to their enterprise. And if you're a company that makes washing powder, your core competency is making washing powder. But you're not a tech company per se. And so the problem with that is the moment you take on robots, again, remember I said robots, they need very specific instructions. So telling human beings what to do is just easier because human beings they can hear anything and adapt it in their brain. Robots don't do that. They just they're not good at it. Now, will they become good at it someday? Yeah. They could. Again, it's more compute. It's more all of this, right? But in order to make robots work, you need to have technical chops in the organization. And so if you don't, you have two choices. You either make a team from scratch that can do all this, probably stealing people from a company that's good at it, or you use integrators completely. And those integrators, they have their own finite capacities. And then on top of that, anything that is built. has to be supported. And I think the biggest bottleneck in all of industry right now is company IT departments like and customer IT departments ability to support and upgrade. They're spending as much time upgrading stuff as they are putting new stuff in. In fact, that's the bulk. You know, the bulk of what they do is support and upgrade. And every once in a while they add a new system, right? Like if you think about what percentage of an IT department is there to maintain what's already there. versus adding new stuff, it's a relatively low percentage. So those IT departments are generally the longest timeline. Their timeline is they're longer than making the robots themselves. It's mainly the time it takes to write specifications and then just getting in the queue to do the work. Right. It's the one of the most precious resources in the industry is the time of the in-customer IT departments. And because of how we do things, we love to think that we're helping those IT departments solve their problems because they can rapidly onboard stuff and then the supportability is relatively simple. They save money on the install and they save money on the ongoing TCO to total custom ownership.
speaker-0: Do you also work with customers from absolutely zero that have no automation going?
speaker-1: We have, I would say it's really tough for them to do to go from zero. It's possible. But generally what happens when a company does a robot for first time, they hire a guy from a company. And that guy is the guy or the person, you know, like and and they're alone in all of this, right? And so it takes a lot to build, you know, think about robotics. In the early days, like a company could get away with Like a software engineer, a mechanical engineer, an electrical engineer, right? That's enough to be useful, right? The amount of disciplines now, just software alone, right? Software, think about IT. IT is not one department. It's not people who write software. There's a cybersecurity team. There's the team that manages all the servers and infrastructure. There's the people who are maintaining the network. There was one company where they had one guy whose entire job was to maintain barcode standards. That's his only job. Right. He worked in an IT department and he was Mr. Barcode, right? there's so many disciplines within this that if you don't have those disciplines, it's really it takes a long time to build up. I've just been so impressed with DHL's capability. They've invested early in all this and they've got just a solid, solid team. And they've got a huge head start on many companies. They recognize the need to invest in their team. That is a decade ago, maybe longer. So if you are new to robotics, You have to decide who am I going to partner with or am I going to build it my own? My recommendation is partner with somebody and start building a team alongside. Because if you try to hire one person and that person is going to save your company with robotics, it is probably going to fail because there's so many capabilities that you need and there's no one human being that contains it all. I have some of the most experienced guys in robotics in the industry working for us, and there's not one single person who can do it all. in our company, even with the wealth of experience we have. You have to be humble about how difficult it is to actually pull this off. And a lot of times, I'm a CEO, so I'll say that I probably cause this too. But CEOs will be like, put in robots, go, go do it. I don't care what it takes. Just go do it. Right. And that one sentence, they don't understand the that's one sentence, but it causes ten thousand sentences to have to be done. Right. And and now the new one is go get the go use AI. Go do it. But What it takes to put all that in place, all the infrastructure, all the team, it's actually quite big. So the companies that invested back then are reaping the benefits, like Target and Walmart. They were investing in obviously Amazon. Those capabilities have been there for decades now. If you're just getting started, you're gonna have to partner or else you'll never get off the ground. But I would say once you partner it, start building a corresponding team that matches up to the integrator partner you're using. if you ever want to be able to stand on your own. If you don't have a counterpart, just look at the roster of the integrator you're using and say, okay, I need one of those, one of those, one of those, one of those, one of those. Then you'd have the capability, right? Yeah. And it's better to have more than one of any one because, people can leave. So and if you lose that one person, you're screwed. So Okay.
speaker-0: Interesting. But explaining them the incentive of robotics, you don't think that's an issue anymore. Most people
speaker-1: Well see that. Obviously that's to be a business case, right? There's robots deployments that I don't know, it's like robot jewelry, right? Like I've seen companies do robots just because they wanted to show they were advanced, right? Eventually those robots get ripped out because someone like looks at the bill and says, Wow, we're paying this much to do this. This is kind of crazy. So there has to be a business case eventually. Somebody, the CFO is gonna get a hold of it eventually, right? And so it's pretty clear that Well, frankly, it's not about cutting jobs. It's the fact that you can't hire enough people to do the work. Most companies are are automating because they simply cannot staff up their company. Or they're a turnover of, operational personnel. They go from one facility to another for, they get a one dollar raise per hour and they switch companies. There's very little loyalty these days and people don't stay with one company anymore. There's no retirement plans or anything. So they just switch. Pretty soon your most unstable employee base are your robots. They're the ones that they don't leave. They don't quit for a better job. And frankly, I I'm a believer in using human beings where we're really good. We are really good at grabbing things, right? really good at assembling things. But that's a lot harder for robots to do. But driving something, a thousand meters, a robot can do that. And when a human being is walking a thousand meters, they're not doing the interesting things with their hands. Right. That's w hand-eye coordination is really the superpower of a human being. Motion across ground, there's much better organisms than the human being. We're really kind of sucky at it. You know, the cheetah is way faster. The elephant can carry more than us, right? It's way cheaper for robots to move stuff than it is for a human being. And carry more, it can go faster. So I'd say the number one business case that I see is elimination of walking. is the number one driver of business case in in robotics.
speaker-0: Interesting. AK, thank you so much for being on the Robotics Stack Podcast. It was really insightful. I think it was a different angle that we have not seen before on this channel. A very unique company that you're building. This was episode 23. My name is Oscar. Hey, my name is Leo. Bye.
speaker-1: Thanks. Cheers.
