Rick Faulk [00:00:00] Having a dedicated physical AI solution that works in a warehouse is much more compelling for operators and a much more scalable business model than what a lot of these other businesses are doing. The form factor that a lot of them are looking at, which is the bipedal feet, is probably a recipe that's not gonna work in warehouses.

Most companies in the robotic space that I talk to, a lot of them fail, and they fail because they don't understand the client's problem. Big difference between a robot looking for a problem and a problem looking for a robot.

Brian Heater [00:00:27] One of the conversations I keep having over and over again in the physical AI space is this lack of real-world data.

You have an incredible number of robots out in the field. What can be done with the actual data that you're actually out there processing and collecting right now?

Rick Faulk [00:00:43] We've done over seven billion picks. As we speak right now, we are probably doing 150 picks a second right now, a second. Each pick we do, we learn something that we can make it more productive for the client.

Brian Heater [00:00:56] A lot of these companies decided, hey, we're gonna leapfrog from AMRs to humanoids and skip anything that might be in between. To a certain extent, the Array strikes me as that in-between space.

Rick Faulk [00:01:08] There's two ways to automate a building you could argue today. One is with humanoids that are designed to do 100 different things, none of them particularly well, or something like Array that's dedicated to do one thing and do it unbelievably well.

But having said that, we don't have our head in the sand. I think eventually humanoids may get there. I think over the next five years, it's gonna be a big challenge.

Brian Heater [00:01:40] Welcome to Automated. I'm Brian Heater, the managing editor at the Association for Advancing Automation. Here's a great talk with somebody that we've been looking to get on the show for a minute. Rick Faulk is the longtime CEO of Locus Robotics, and he knows more about scaling and deploying industrial robots than just about anyone else in the world.

It's a unique bit of insight, and I certainly learned a lot from the conversation. If you're enjoying the show and also learning a lot from these conversations, don't forget to like and subscribe. Check out the newsletter over at automated.fm. And with that, here is Rick Faulk of Locus Robotics.

One of the things Jasmine told me in the lead-up to this conversation was that this is actually the third headquarters for Locus. Not only is this the third headquarters, but everything was generally in this vicinity. Is that right?

Rick Faulk [00:02:34] Yeah, it is, it is the third, Brian. Well, actually, it's really the fourth. We started out in a building in Devens, Massachusetts, which was Quiet Logistics. Locus spun out of that, and then we moved to a smaller facility about two miles from here.

Brian Heater [00:02:49] Smaller than this, not smaller than the first facility?

Rick Faulk [00:02:52] Actually, much smaller than the first facility because the first facility was Quiet Logistics, which was a big warehousing operation, and Locus was in the back of that. And then we moved to a smaller building right down the street.

There was only probably three or four thousand feet. No manufacturing, no operations. It was a really small building. And now we are in three buildings in the area. We're in one in Nashua, New Hampshire, which is our R&D facility, one in Tewksbury, which is primarily a storage and shipping facility, and then here at Locus Park, which is where we're at now.

And we do everything here from manufacturing to refurb. We have most of our team here. We have folks that work around the world, but a lot of our mechanical engineers here, a lot of our software folks and the like.

So yeah, we're in three buildings.

Brian Heater [00:03:40] Initially, what was the relationship between Quiet Logistics and Locus? It started as something like a side project, would you say? A spinoff?

Rick Faulk [00:03:49] Well, I wouldn't say it was a side project or a spinoff. It was a major problem. And I believe great businesses are built out of major problems, and Locus was. So what happened, we were running a 3PL, Quiet Logistics, and we decided the best way to run that business was to automate it, and we did.

We automated it with a company called Kiva, which ironically is located about three miles that way, which is now Amazon Robotics, and we were one of the largest Kiva customers in the world. We had 250 robots, solving all the problems in logistics of getting volume out the door and doing it at the lowest cost.

And then Amazon came along in 2012 and decided they wanted to buy Kiva, and they did. Amazon actually toured our building before they bought them. Of course they did, and then they decided that robotics was so strategic to them that they took the product off the market. So we had a big problem, and the problem was either to go back to a manual operation -- that seemed not the best idea in the world.

We actually scoured the world to find a robot to buy. Couldn't find one, and then decided that the best path was actually to build a robot. So we actually incubated inside that building. We started in literally the back corner of Quiet Logistics. But the great thing about that is, first of all, we understood the 3PL business, understood distribution, but really understood the client's problem.

And frankly, being in the building, we could actually develop solutions during the day, test them at night, make sure they worked, and then iterate the next day. Yeah, it was actually a great way to build and iterate a great product. And in some cases we give Amazon credit for founding Locus.

Brian Heater [00:05:31] Yeah, that's an element of the story that I hadn't heard before, that Amazon actually came by and toured the facility. Were you -- or was Quiet Logistics aware at the time that they might be scouting Kiva?

Rick Faulk [00:05:41] Well, they were. They were very upfront about it. And I wasn't there at the time, but as I understand it, they wanted to tour facilities to get a good read on the tech and efficiency gains and that sort of thing.

And again, I wasn't there, so I don't know the exact context, but it was clear shortly after the visit that they wanted to buy Kiva, and of course they did. And like I say, it worked out great for Locus because that was the stimulus behind forming the business.

Brian Heater [00:06:10] Yeah, but it sounds like even then, so you know, 2011, 2012, Kiva having robotics automating those systems was already showing an ROI for the company.

Rick Faulk [00:06:21] Yeah, it was. And it was an ROI that was measurable. We could pass those costs on to our clients in a good way by reducing their cost. It also allowed us to get volume out the door and meet SLAs. One of the challenges with that solution, though, it had to be deployed in basically a new building. You have to go down to bare concrete to actually deploy that solution.

Brian Heater [00:06:45] Greenfield.

Rick Faulk [00:06:46] Exactly. Sort of a greenfield building. We actually had to gut that building to deploy it, which at the time was the right thing to do. But the problem is, with fixed automation, you're fixed in what you can ship every single day.

It's like a big vending machine, if you will. And we learned from all that. The nice thing about Locus, we can scale up and scale down based on demand. With fixed automation, you have to buy -- we call it sort of for Easter Sunday. You have to build a church for Easter Sunday. So you've got to build the capacity, and with fixed automation, you've got to build that capacity to handle peaks.

That's one lesson we learned -- operators really wanna scale up and scale down their solutions. And the other thing we learned was most operators don't wanna gut a building to deploy automation.

There are 130,000 to 140,000 buildings around the globe that are actually existing buildings that have to be automated. And these are operators that don't wanna gut that building to actually deploy automation. So yeah, we learned a bunch about how to operate a building and how to build an automation solution that could scale around the world.

Brian Heater [00:08:05] One of the things that I learned talking to companies like you is, seasonality is a big part of those ups and downs. So obviously, Christmas rolls around, and all of a sudden there's a huge demand, and then that ebbs. But also just throughout the year, there are peaks and valleys for these companies.

Rick Faulk [00:08:20] Yeah, we have a lot of accounts. Obviously around the holidays, there is a huge peak, and we ship literally around three thousand bots out of here right behind us for peak, and that allows accounts to scale up, and then we get them back after peak. Probably fifteen, twenty percent of them actually stick because clients realize they need them. Once we get them back, we refurbish them downstairs.

But to your point, there are other peaks that exist. We have accounts -- apparel companies as an example, back-to-school companies, I can't mention the names, but they have to scale up and scale down. Well, I can mention one -- Staples as an example. They have back to school, and that implies a lot more volume that ships in certain times of the year, in August and September.

We have other accounts that run big Mother's Day sales. We have bots literally being shipped today to handle other seasonal peaks. So we get a lot of that, and the nice thing about it is it isn't just one peak. We have accounts that scale up and scale down throughout the year, and this is the biggest strategic problem they have, other than labor, is to scale up and scale down to meet those needs, and we allow them to do it.

Brian Heater [00:09:31] Getting back to the formation of the company -- easier said than done, "Hey, let's start a robotics company." We know what the solution is. What are the first steps to that process, in terms of actually turning from a logistics company to, as you said, sort of a back-room robotics company and starting that early R&D?

Rick Faulk [00:09:56] Most companies in the robotic space that I talk to, a lot of them fail, and they fail because they don't understand the client's problem. And the nice thing about being incubated inside a warehouse and having the DNA of understanding that problem, you avoid that problem. There are a lot of -- frankly, the Boston landscape is littered with robotics companies and hundreds of millions of dollars that went into technologists who really understood robotics, really got robotics, but didn't know the client problem.

They were a robot looking for a problem as opposed to a problem looking for a robot. And Locus was just the opposite. And that's a big part of our success. We understand the problem. We can talk the client's language when we go in there. It allows us to develop features and functionality and solutions that really cater to their problems. So big difference between a robot looking for a problem and a problem looking for a robot.

Brian Heater [00:10:53] But in terms of the actual building of the robot -- again, Jasmine was talking about some of the early days, about being in there with two robots and they were, obviously, kinda bumping into each other. There was a lot of learning that had to go on, it sounds like, really quickly in order to not scale up, but to actually start deploying.

Rick Faulk [00:11:11] Well, there was. I can remember -- I didn't found Locus. I came on board very, very early, before we had one robot in the field. But when I was interviewing, I of course wanted to demo the solution, and there were three robots running at the time.

And during my interview, I of course wanted to play with the solution, that sort of thing. And the three robots kept colliding into one another. This is just three robots, and one of them actually collided into me, as a matter of fact. And of course, the founders at the time talked about how those are natural problems in building a business, and they were.

So those were the early-day problems of getting just three or four or five robots running so they actually navigate around a building. Well, if you fast-forward a number of years, we're ten years into it now. We had clients at peak that would run 700 robots -- hundreds and hundreds of robots in a million square feet, and the robots didn't collide. They knew where to go, operated efficiently, charged automatically, and it's just a whole different environment now.

But that was the problem in scaling. And we have one of our accounts, DHL, who talks about how innovation isn't innovation unless it can scale. And we sort of took that to heart day one. Those three robots that we had running early on, we understood very, very quickly we had to get to 20, and then to 50, and then to 100, and then to 500, and now up to 1,000.

There's a lot of complexity that goes into that. And we're able to do it, and I'm a little biased, but we have the best engineers in the world that allow us to scale at those levels. For accounts to deploy around the globe, they really have to be able to do that.

Brian Heater [00:12:58] I'm talking to companies in 2026 that are telling me how difficult it is to source parts and to scale manufacturing. Backing up well over ten years, I assume it must have been that much more difficult in the early days -- I assume a fair share of assembly was happening on site. How were you actually building these things, putting them together, and delivering them to customers?

Rick Faulk [00:13:25] Good question. So initially, we built everything in-house, everything. There was a method to our madness because we wanted to learn the challenges and problems and costs and everything else, so we built everything initially. We literally hand-built probably our first 5,000 robots or so right down the street.

And we learned very quickly that we couldn't build them all ourselves and scale. So we went to contract manufacturers. We actually have two, one in Vermont, one in Massachusetts, who build the raw components. The CMs manufacture the base and the mast that goes on the robots, all the guts on the inside. We design them all and give them the specs, and then we do final assembly and test downstairs right behind us.
So we'll get those two major components in, knit them together, and it takes about two hours of labor to actually do that, and then we'll brand them here. We have a branding room downstairs where we'll do wraps and that sort of thing. The way we think about it, we do the final mile. We have the contract manufacturers do the first five miles, if you will, the detailed assembly, and they're very good at it. It allows us to scale up and scale down.

You don't want to build a manufacturing facility to produce thousands and thousands of bots when our peak throughout the year fluctuates. But CMs can deal with that. So we design it, spec it, give those plans to CMs. They build out those core component parts, and then we do final assembly and test and then shipping from here.

Brian Heater [00:15:03] This is something that's just occurring to me as I'm saying this, but if there's a little bit of irony -- in building what are these specialty machines, a lot of it does have to happen with human labor and does have to happen by hand.

Rick Faulk [00:15:17] Well, it does. We minimize the human labor component of it in the way we design it. For example, we design wiring harnesses. It sounds like a simple thing, but instead of having --

Brian Heater [00:15:30] Everyone says, whenever they talk about automotive manufacturing, the wiring is always the hard thing.

Rick Faulk [00:15:34] The wiring is the hard part. Yeah. So instead of having ten wires that have to be connected in different spots, which takes manual labor to do that, we have one wiring harness, as an example. So
it allows us to minimize the labor that goes into it, and we standardize that over time.

And literally in a robot downstairs, it'll only be about two hours of labor that goes into it. So we've dramatically simplified the process, which allows us to scale. The CMs take them a few more hours than that to actually assemble the robot, but once we get it in here, it's only a couple hours of labor to actually do that final assembly, configuration, and branding. We've got it down to, I like to think, somewhat of a science.

Brian Heater [00:16:15] It's interesting because I come from a bit of a consumer electronics background, so I look a lot towards the smartphone -- all the innovations there that led to the ability to manufacture a lot of other different devices. And I don't know if there's a parallel that can be drawn to robotics, especially because you're working with those contract manufacturers, but just because they're set up to build the first five miles, as you said, of your machine, doesn't mean that another company can necessarily come in and utilize the work that you've done.

Rick Faulk [00:16:48] Yeah. CMs specialize in building lots of different things in volume, and there are a bunch of different CMs that specialize in different devices. We're fortunate to have two in New England who are really good at robotics and manufacture other robots in addition to ours. But again, whether you're manufacturing a robot or a healthcare device -- and they do a lot of that -- or a security machine, they're really good at doing that.

The key with CMs is you have to have your BOM cost down, and it's gotta be stable. What CMs don't like is part changes all along. They like one consistent design that they can run with, build a line, and build it out for a year or two. So we're at the point with Origin and Vector where the designs are stable. The contract manufacturers can actually order the parts and buy them with confidence that those are gonna be consistent for the next few years.

Great business for them. Allows us to scale. We get shipments in here every week from CMs -- the base units and the mast -- and then again we do that final assembly and test, and it works out really, really well.

Brian Heater [00:17:52] It strikes me too that using, or relying to a certain extent on off-the-shelf components, is also pretty useful when it comes to actually building these robots.

Rick Faulk [00:18:01] No, it is. We have a very large team that does software, and that's all developed on one platform that runs those robots, as well as Origin and Vector. It's basically standard parts other than the plastic and metal that are custom for us, which allows us to actually build, program, and run those bots.

I think the key thing is having that stable design and also a very small number of robots that you can configure different ways. I like to say we have a thousand different robots, but we only have two. And I say that because we can configure our robots different ways. We don't customize, we configure.

On our Origin and Vector, for example, we have many, many different accessories that go on that robot. Same core robot that gets manufactured at the CM -- we effectively have different shelf types and printers and that sort of thing that go on that base device to allow for configuration at that account versus customization.

And I talk to a lot of robotics businesses who say, "We'll do anything for the client. We'll design this and design that and make these changes." It's a very difficult business to scale when you do that. So we allow for all that, but we've done it with a strategy that says have two core form factors, our Origin and our Vector, and soon to be Array, but configure those in lots of different ways. We have literally hundreds and hundreds of different shelf types that go on that, printers and that sort of thing. It makes it easier for us to scale and gives the client exactly what they want.

Brian Heater [00:19:41] I talk to a lot of humanoid companies who pride themselves on building full stack, and part of building full stack for them is all of these custom components -- custom actuators, custom screws -- and that is gonna be incredibly difficult to scale.

Rick Faulk [00:19:56] You hit the nail on the head.

Brian Heater [00:19:58] And the screw.

Rick Faulk [00:19:59] Well, yeah, the nail and the screw, and the hammer and the wrench. Very, very difficult to scale. They're doing some exciting things. I think it's gonna be a ways off before there are use cases inside a warehouse. They may eventually get there, but it's a very difficult call to scale.

And the form factor that a lot of them are looking at, which is the bipedal feet, is probably a recipe that's not gonna work in warehouses for all the reasons that you might imagine. But the key thing -- you're exactly right -- very hard to scale. And they're also trying to develop software that is generic in nature so it can do lots of different things: fold laundry, make a burger, and work in a warehouse.

Interesting at some level, and they're gaining a lot of investor attraction. But the reality is, having a dedicated physical AI solution that works in a warehouse is much more compelling for operators and a much more scalable business model than what a lot of these other businesses are doing. That's how we think about it. Let's go in with a dedicated physical AI product that does one thing and does it unbelievably well, as opposed to worrying about burgers and laundry and delivering goods.

Brian Heater [00:21:08] I'm sure that over the years investors came to you and said, "Hey, can this move over to this space, and can you stick an arm on it and do these things?"

Rick Faulk [00:21:19] Well, we got that question all the time in the early days, and we still get it. You know, why can't you go into hospitality? Why can't you go inside hotels? Why can't you go into restaurants? Why can't you do all these things? The answer is, we could do all those things. But from my perspective, it's a recipe for failure.

In this business, if you're focused, do one thing unbelievably well in a massive market -- which is what logistics is. There are 130,000 to 140,000 buildings around the globe that all need to be automated. Why do we need to worry about restaurants and all these other places we could go into? It's a whole different sales process, different value prop, different integration with systems, and it's a recipe for a big challenge in growing a business.

So our strategy is really simple. Let's stay focused on one thing, a massive market, and do it unbelievably well and be the best in the world at doing it.

Brian Heater [00:22:12] One of the conversations I keep having over and over again in the physical AI space is this lack of real-world data. You have a lot of real-world data. You have an incredible number of robots out in the field. You're out there collecting it. What can be done with the actual data that you're actually out there processing and collecting right now?

Rick Faulk [00:22:34] That's a really good question. I love to talk about it because that is the thing that makes Locus different from a lot of other businesses in the world right now. As we speak right now, if you look at the counter in the other room, we're probably doing 150 picks a second right now. A second. And that counter runs twenty-four hours a day, seven days a week. It'll scale up and scale down.

Every single one of those picks, we're learning something that no one else is learning. We've done over seven billion picks. Seven billion picks. DHL just made an announcement a few weeks ago. DHL has done a billion picks with Locus robots, and it is just an insane amount of data that we're collecting.

So what are we doing with it? Think about this as the data flywheel. At each pick we do, we learn something that we can make it more productive for the client. As an example, on our robots right now, we have agents that are running. One agent that runs is looking out through the cameras, looking at what it sees. If it sees a forklift, for example, it could see a forklift, could see a human, could see a cart or whatever.

If it sees a forklift, it'll take that data that it's learned -- that this is now a forklift -- and it will take action. For example, if a robot runs into a forklift, it's gonna lose, and probably get destroyed, and we have some good experience of that before we launched this agent. So when a Locus robot now sees a forklift, it will actually take action and do something. The "do something" could be turn around and go the other way. It could be sit there, depending on how long the forklift is there. It could be take action and go to another pick.

So it's an example of using that data -- knowing what a forklift looks like from the billions of picks we've done and the AI engine behind all this -- and taking action.

Another example is what we call system-directed labor. So what's happening in that warehouse right now: we have robots traveling around, we have humans traveling around, and we know the most efficient path you as a human have to take based on your past work and based on the work in the system. We know your most efficient path to get to your next pick. Based on the data that we're gathering around the system right now, we know where the humans are, we know where the picks are, we know where the robots are traveling from and to, and we tell you as a worker what to do. We have an agent over your shoulder telling you what to do using an AI algorithm to maximize your efficiency as a human.

So those are just two examples. Let me give you a third. With Array that we're launching, we're collecting data on every single pick. So if Array is doing a pick and it has to pick a roll of tape, as an example, Array will learn from all the data it's collecting that you don't wanna pick a roll of tape in the center, because it's not gonna pick it. So over time, through data and through AI, we learn that if you have to pick a roll of tape, you pick it on the side, not in the center. Simple example, but it's just one of millions of picks we'll do with Array to understand where to pick that based on the data to maximize success of the pick.

So we're using lots of other ways, but those are just several examples of how we're using data to be more effective.

Brian Heater [00:25:59] So you mentioned Array. I was really interested -- you and I spoke a couple months back about the system. I'm surprised it didn't get more coverage, and I think a lot of that again is because humanoids are sucking a lot of the oxygen out of the room.

A lot of these companies decided, "Hey, we're gonna leapfrog from AMRs to humanoids and skip anything that might be in between." To a certain extent, the Array strikes me as that in-between space, right? It has wheels, it has a manipulator, it is picking. But the difference is, this thing is actually going to ship in the near future.

Rick Faulk [00:26:45] Intentionally, we did not want to get a lot of coverage over the last several months because we hadn't really launched it yet.

Brian Heater [00:26:51] Well, I apologize for writing about it.

Rick Faulk [00:26:53] Not a problem. So we actually launch it April thirteenth at MODEX, and we have a big launch planned. So we expect a lot of coverage.

But you're exactly right. There are two ways to automate a building you could argue today. One is with humanoids that are designed to do 100 different things, none of them particularly well, or something like Array that's dedicated to do one thing and do it unbelievably well, and that's the difference.

Humanoids also have all the problems that you talked about: cost and ROI. If you believe most of the cost figures out there for humanoids, they're measured in hundreds of thousands of dollars, and the ROIs really aren't there for humanoids today. That cost will come down over time and be more competitive.

But at the end of the day, the whole secret is doing one thing and doing it really well versus lots of different things. The other thing about a humanoid in a warehouse -- if it's going to pick something out of a bin, it's gotta do something with it. Just because it picks something doesn't mean that's the end of the task. It's gotta do something with it. Is it gonna walk 50,000 feet to drop it in a tote or a box? Probably not. So again, it's an example of thinking through the workflows, what's best based on the use case.

And it's really hard to find a use case for humanoids in a building right now that's really, really effective, versus Array. Array will do everything autonomously. When I say everything, I mean picking, replenishment, slotting, counting, sorting -- all of that automatically with one form factor designed to do that one thing in a massive market.

Again, with a humanoid, maybe over time it would work, but you've gotta deal with all the problems of cost, complexity, and all the things that present challenges for warehouse operators. But having said that, we don't have our head in the sand. I think at some point, humanoids may play a role doing certain things. The question is what, and how you can get an ROI for clients, because that's what they're interested in. "Hey, does it work? Is it safe? And can I get an ROI with that product?" And eventually humanoids may get there. I think over the next five years, it's gonna be a big challenge.

Brian Heater [00:29:12] I want to break down the ROI piece a bit because I'm kind of curious -- when you mention ROI, what does that mean in bare terms? Is it minutes saved?

Rick Faulk [00:29:23] It is minutes, but it translates to dollars. The nice thing about Locus, unlike a lot of other fixed automation solutions, we have a very low upfront capital cost. Basically, we have a RaaS model -- robots as a service -- you pay a monthly fee, and your only upfront cost is the integration that has to happen between the WMS and LocusONE, and we do charge a small installation fee upfront.

So most of our clients get an ROI of less than twelve months on those costs, and after that, everything is OPEX savings -- everything. And with Array, basically it's the same way. Array is going to be a very expensive solution for us to actually deploy, but we believe our clients want the RaaS model. We've educated the market that the RaaS model is the way to go in deploying automation. So there is a large upfront capital cost that we have as a business to actually deploy that, but we're going to do it because we think that's the best solution.

Brian Heater [00:30:25] Array is obviously a pretty dramatic departure in terms of form factor from the other systems. Is that why it's going to be so expensive for you to deploy it?

Rick Faulk [00:30:35] It is. It's a much bigger robot, much more complicated. There are over 1,000 parts in Array. It's ten feet tall, weighs 1,000 pounds. Origin weighs around 80 to 100 pounds -- much lighter. So many more parts, much more industrial-strength for that use case. And so it is going to be more expensive, and we're gonna charge more for it because we're taking out all the labor. But the value prop for clients will still be at the Origin ROI level or even better, based on our initial data.

Brian Heater [00:31:16] How difficult of a problem was the manipulation on a machine like that?

Rick Faulk [00:31:21] It was honestly really, really hard. And it was hard because we didn't invent arms, we didn't invent vacuum and suction. But most of those deployments right now in logistics or even in industrial deployments, you have a fixed station, you have building air, you have building power, and that makes it really easy to do vacuum-based picks.

But with Array, it's a mobile device. Things are moving. You don't have the power, you don't have the vacuum to be able to do the things you can do with fixed stations. So it was really, really hard. We've been developing Array for over three years, and a big part of it was solving that mobile manipulation problem in an environment that is moving, that is mobile. You don't have the vacuum power that you have with building air, which means you don't have the suction to get the grasp. And you also have to do it at a cost where you can deliver an ROI for the client and have a good business model for Locus.

So between cost and functionality and form factor, it was a big, big challenge, and like I say, it's taken us three years to do it. But we've got it figured out, and we believe come this fall when we roll this out at scale, we can pick seventy to eighty percent of the SKUs being shipped in e-com today with Locus Array. So we can do most of that volume.

And with Origin and Vector, we can go to a client and say we can do a hundred percent of your SKUs -- between pick and pass, between Arrays and Vectors and Origin, we can do a hundred percent of your SKUs, and we'll do each one in the most cost-effective way based on whether it can be picked with Array or not. The first choice will be Array. If we can do it, do it with Array and do it with no labor -- that'll be the first choice. If we can't, we'll pass it to Origin or Vector.

Brian Heater [00:33:17] I'm curious what, for a system like this and for a company like Locus, a pilot looks like. Again, I'm talking to humanoid companies about pilots, and oftentimes it's two or three robots, set aside. Obviously a lot of logistics companies, certainly manufacturing companies, don't wanna stop the line in order to experiment with these systems. How fully are you actually able to integrate these systems into existing programs?

Rick Faulk [00:33:46] I advise robotics businesses to eliminate the word "pilot" from their vocabulary. The reason being, it's a recipe for a pilot, and what you should wanna do is full-scale deployments -- that's what we wanna do.

Now, having said that, there will be initial deployments with Array. We have one going on right now with DHL in Columbus, and another one rolling out in several months. And they're not rolling out with hundreds of Arrays to start with -- it'll be a small number, but we'll get it down, make any design changes we have to make, learn the math of it, so we can go to a client with confidence and tell them what they can expect with Array.
And once we develop that layer of confidence -- that we know what the UPH rates are, some of the issues and challenges, the form factors, and that sort of thing -- we can roll it out at scale. So we don't generally like to do pilots because it's a recipe for being at it for months and months with sort of no commitment on either side.

So we like upfront to go in with confidence where we can say, "We're gonna do this deployment. We know how many robots you need. We know what the ROI is going to be. And if it doesn't work, we'll adjust it." And we do that with our RaaS model. The nice thing about the RaaS model is we can scale up and scale down, where if we went to a client and said, "Hey, you've gotta buy 40 Arrays, and let's hope they're gonna work," it's a much easier way going with a RaaS model because we can make some mistakes upfront around bot count and that sort of thing, and we have a lot to learn, but we can scale up and scale down and make adjustments.

Brian Heater [00:35:21] One of the unspoken things when we talk about humanoid pilots that we don't see in the videos or notice is that there aren't really humans around. And that's always been one of the big differentiators for Locus, right? These are designed to work alongside people. In terms of Array, in terms of the early testing, in terms of safety and getting them out there, how do you test them?

Rick Faulk [00:35:46] To your point, Array is designed to be used without humans at all. In the initial deployments, the first deployment, we do have a fence around it. Not that we needed it, but it felt like the right thing to do because we wanna learn and not make mistakes.

But Array is designed with maximum safety involved. We have a number of safety sensors on it, a number of special braking units, because it is a heavier robot, and the safety zone around Array is larger than our Origin. With Origin, you can literally dance with it -- they're amazingly nimble. Array won't be quite as nimble as Origin. Well, it was never designed to be, and doesn't have to be. But we have a very large safety zone around it. And with LIDAR and cameras, we're able to control that.

We're using the same safety stack that we use with Origin and Vector, and we have literally seven billion picks of data, so we know how to navigate around humans. And with Array, humans don't have to be with Array. So we really don't expect any problems or challenges at all.

Brian Heater [00:36:55] The bar must be really high, especially because you're already selling in Europe, you're already selling in Asia, and there are different standards in different places across the world.

Rick Faulk [00:37:05] There are. And Europe honestly has higher safety standards than the US, and we built Array and designed it to be compatible with those safety standards. When we ship, our Europe launch will be a little delayed because we have some testing we have to do. But we designed it day one to be compatible with all those requirements.

Brian Heater [00:37:33] You alluded to this a bit, but Array being designed to be fully autonomous means there won't be, at least when it's fully deployed, humans in the loop. What does that ultimately mean for people in the warehouse setting?

Rick Faulk [00:37:49] These jobs in warehouses right now are very hard to fill for clients -- incredibly hard to fill. Turnover is measured in double digits. In some accounts, double digits a week. Any worker that we replace with Array will probably find another job within that warehouse. It could be in the packing function, receiving function, that sort of thing.

So although we will be reducing labor with Array, for the most part, most every single one of those workers will find another job within the building. And that's what we're seeing frankly with Origin right now -- we do take a good bite out of that labor problem. Array will be a bigger bite, but generally those are jobs that either have gone unfilled, or will end up in another spot in that building. And that's generally what happens for the most part with automation today.

Brian Heater [00:38:40] And are you ultimately creating different, more roles in the field when it comes to actually deploying and interacting with the robots?

Rick Faulk [00:38:50] Yeah, we are. There are more higher-value jobs than the repetitive jobs of doing picks that we are creating. One is simply managing Locus within buildings. I was in a building several months ago, and a gentleman came up to me and was so proud of the fact that he was the orchestrator and the manager of the Locus system in that building, and his former job was being an associate doing picks. Now he's managing the whole Locus deployment in that building, and he was so proud that he got elevated up to that, and he's making more money as a result of it.

So there will be more and better jobs because of automation -- and not just with Locus, but automation in general. It's exciting times for anyone deploying automation. And a part of it is retraining those workers. We have a whole program where we actually train them on skill sets to be able to manage our system. It really is exciting.

Brian Heater [00:39:41] That's interesting. How does a worker actually get involved with one of your programs?

Rick Faulk [00:39:49] Typically, it happens within the building, where they identify folks that are champions for Locus, and we'll take them under our wing and provide training. Our CS staff provides training.

Brian Heater [00:40:01] They nominate somebody effectively?

Rick Faulk [00:40:03] Yeah. We have Locus University. We have a number of online courses, and then we actually certify them for being Locus capable. We have a whole course around, for example, maintenance and repairs that we train workers how to do. We train them how to manage the actual deployment, how to manage induction and the workforce on the dashboards and all that. And again, we do that through Locus University and our on-site CS organization. Something we take very, very seriously, and it's in our best interest to have folks that really understand our solution on-site.

Brian Heater [00:40:38] One thing I've always been curious about -- we talked about one of the big selling points of your system being that it is a brownfield solution, that you can just sort of plop this in the middle of an existing warehouse. But have you noticed that in spite of that fact, warehouses are still starting to maybe slowly build to accommodate more robots?

Rick Faulk [00:41:00] We see it both ways. It's very hard to automate a building that was built ten, fifteen, twenty, even fifty years ago. Really, really hard to do it. There's infrastructure there, things in the way. Warehouses are messy places, as you know, so very hard to automate existing brownfield buildings. And objectively, there are only a handful of companies in the world that can do it. I'm a little biased, but I think we're the best in the world at doing it. We've sort of proven that.

But increasingly, we're finding now that about twenty-five percent of our business is in greenfield buildings. So we have accounts -- I can't mention any exact names -- that actually started in brownfield buildings and are now building greenfield buildings specifically for Locus. And the nice thing about it is we can do both. We can take Array into a brownfield building. We'll have to clear out a little area to put dedicated racking in, but we can actually stick an Array also in brownfield buildings and have Array, Origin, and Vector run in total across that building. So yeah, it's gonna be cool.

Brian Heater [00:41:58] At the beginning, we talked about Amazon effectively being responsible for the company existing. And it strikes me that Amazon sort of over the years has continued to be a big motivator for people adopting these systems, right? Because Amazon has continued to shape people's expectations as far as shipping and logistics.

Rick Faulk [00:42:18] That's exactly what they've done. Amazon has set the bar on expectations around safety in the building -- which they're very, very good at -- SLAs, delivery time, and also cost. They've set the bar, and they've done a great job with it. Others have to model after that. And we have other accounts, like DHL and a host of others, who are also setting the bar really, really high, and others have to replicate that.
If you're a 3PL today and you're bidding out a new account -- going after that account to win the business -- and you don't do it with an automated solution, I guarantee your costs are gonna be higher, and your SLAs are gonna be slower, and it's gonna be very hard for you to win that business.

So that's why right now almost fifty percent of our business is with 3PLs, because they know they have to automate. And if you're building a new building today -- and there will be literally billions of square feet of buildings built over the next three or four years -- if you're not building a solution today that's automated, you're gonna be behind the curve.
All those new greenfield buildings have to be automated, and all these brownfield buildings have to be automated to compete. To meet the SLAs, to meet the cost, they have to be automated. And they will be over time. It's not gonna happen next week, next month, or even in the next three or four years, but over the next decade all these buildings are gonna have to be automated. And any new building going up that's not being built for automation -- I think it's insanity.

Brian Heater [00:43:52] So do you feel like it is still, in spite of everything, possible to be competitive with Amazon as a logistics company?

Rick Faulk [00:44:00] With automation you can be competitive. Yeah. Amazon has set the bar, and they're very, very good at it. But with the solution we provide -- with Locus you can get an Amazon-like cost structure and Amazon-like SLAs. With Origin and Vector, and with Array, you can even beat it.

Brian Heater [00:44:19] Well, Rick, thank you so much for taking the time.

Rick Faulk [00:44:21] You're welcome. Thank you, Brian.

Brian Heater [00:44:23] Thank you to Rick, thanks to Jasmine, and the rest of Locus for accommodating us for several hours on a Monday at your headquarters. Great conversation. Thanks to you as always for watching. If you've been enjoying the show, please like and subscribe to it and our newsletter of the same name. You'll find all of that over at automated.fm. And we will see you next week with another episode of Automated.