Agentic Supply Chain for Data Center Delivery | Nscale at AIPCon 10

Please welcome Chief Digital and Information Officer of N -Scale, Lauren Herwitz.

Hi, good morning, everyone. So great to be here. What a venue. So every demo you're going to see today will rely on one common resource, and that is a GPU that is running. And at N -Scale, it is our mission to bring those GPUs up. It's running, and at NScale, it is our mission to bring those GPUs

GPUs up. It's running, and at NScale, it is our mission to bring those GPUs online, and we're doing so at an unprecedented scale. We have 8 gigawatts in West Virginia, 1 .2 in Texas, 400 megawatts in Portugal, and the list goes on.

Virginia, 1 .2 in Texas, 400 megawatts in Portugal, and the list goes on.

Every one of those numbers will attach to a cascade of delivery dates, and each one of those dates will require that we build correctly, in parallel, at speed, every single time.

challenge. We design, build, own, and operate AI factories, and we're vertically integrated, which means we control the campus, the building, the power, the cooling, the networking infrastructure, and the GPU deployment as a singular system.

So why is this hard? What do we call Palantir? First, scale. A

data center is multiple buildings. A building is seven. Scale. A data center is multiple buildings, a building is several halls, a hall is hundreds of racks, and each rack has roughly thousands of parts. Multiply across seven active sites, and you are tracking tens of millions of components against thousands of purchase orders and a

supplier base in the high hundreds. Second, the hardware is moving really fast.

Every new chip generation comes with new power and cooling requirements. comes

with new power and cooling requirements. To address this, NScale is pioneering modular design. This means that our halls are engineered to accept new chips. So

modular design. This means that our halls are engineered to accept new chips. So

when NVIDIA moves from Blackwell to Rubin to whatever comes after Rubin, we can accept the new generation without having to redesign the entire building around it. Finally,

you have scarce components with really long lead times. Items like switch gears and transformers have to go into procurement before the final Speakers and transformers have to go into procurement before the final design is locked. So we're placing orders far in advance, knowing that specs will change. And when they do, those revisions cascade through the entire delivery

chain. The industry's standard answer to this has been an old

chain. The industry's standard answer to this has been an old ERP, a lot of asset management software, a lot of project management software, and like an army of expeditors with an ungodly amount of spreadsheets. with an

ungodly amount of spreadsheets. And so to me, the ambition that we have and our obsession with execution, we knew we had to do something very different. We had

to leverage AI to build for AI. And actually, I have to tell you that before I joined Nscale, I spent nearly a decade at Palantir building with some of the most complex organizations on earth. And it was a hugely informative experience, as you can imagine. And I came to Nscale knowing one thing.

can imagine. And I came to Nscale knowing one thing.

above all else to be true, which is that for agents and humans to work together, to really work together, they need a common ontology.

So we started with the outcome and we built backwards from there using Palantir.

We started with our supply chain operating system, which we internally call Delivery 360.

And I'm really pumped to show you the first two things that we built.

Imagine I'm a solutions architect. My job is to manage everything that goes into building a data center captured in a bill of materials, what the industry calls a bomb.

That's a great name. You can think of it as a highly specific list of ingredients, and that list can change for any number of reasons, usually due to a customer request. And just to bring this to life, a minor tweak in a network

customer request. And just to bring this to life, a minor tweak in a network design could mean you have to order 40 ,000 extra cables. So, a revised BOM lands in my inbox.

On the left, you can see that the agent is immediately getting to work on trying to understand this new BOM. These BOMs are messy, they include thousands of lines.

And it's a really great workflow for an agent because the agent can traverse the ontology, looking at things like SKUs and compatibility checks. It is not a raw text diff. So, as you can see here, there are a bunch of changes. raw text

diff. So, as you can see here, there are a bunch of changes. raw text

if so as you can see here there are a bunch of changes the agent is putting them into two piles the first pile is based on everything the agent knows what can we just automatically accept and that pile saves me a load of time the second pile are changes that an engineer like me has to review and the example here you can see there's a mismatch in this top of rack switch

so as an engineer i can understand the implication of moving between this one switch and the other i'm okay with this change but i don't one switch and the other, I'm okay with this change, but I don't necessarily understand the implications of the switch on timelines and budget. The agent is one step ahead of me, looking through the ontology, the purchase orders and understanding the implications of moving from the old switch

to the new one. It surfaces three recommendations for me. First, I can add this new switch to my existing order. Same supplier, same delivery date, it's going to cost me half a million dollars. half a million dollars. So I task the agent to do some homework. I tell it to go figure out where I can put this old switch in inventory. Maybe I can use it at a different site.

So it goes off and does some homework. Meanwhile, I'm looking at my other two options. I can amend my existing purchase order, take out the old switches, put in

options. I can amend my existing purchase order, take out the old switches, put in the new ones. I don't have to spend any extra money, but my delivery date gets pushed out by nine days. Third option, cancel the order entirely, put in a new order with a new supplier, but I have to take a risk on the delivery date. Probably what with a new supplier, but I have to take a risk

delivery date. Probably what with a new supplier, but I have to take a risk on the delivery date. Probably won't meet my SLAs, doesn't feel like a good option.

While I've been thinking about this, the agent's doing homework, it comes back and it says, actually, I've consulted all the other build schedules and we can send this old switch to a different site. Great, option one is clearly the best, I'm going with that one. Switch is handled, the order is placed, and I can continue working through

that one. Switch is handled, the order is placed, and I can continue working through this inbox that would have taken me five to ten times more time than it does now. five to ten times more time than it does now. And the real

does now. five to ten times more time than it does now. And the real key thing here is that this decision gets codified into the ontology. So that judgment call compounds into every future agent decision making, meaning it gets surfaced to every single engineer in the company. But good orders don't mean anything if they don't arrive

on time. And so our our second use case was around delivery

on time. And so our our second use case was around delivery and we used the same ontology, the same foundation, and we built this other workflow in a fraction. Montology, the same foundation, and we built this other workflow in a fraction of the time. So what you see behind me is our delivery dashboard and it helps understand and mitigate the impact of delayed deliveries. We have 13 shipment in

flights and they're mapped against build schedules in real time, which is very cool. We

have a 92 % on -time rate, great, and one shipment at risk. In this

case, a power supply module is delayed by 12 days. The agent has already traced the cascade already traced the cascade and identified that a customer date will slip since the agent already knows the approved vendor list for the site the performance history of those vendors as it relates

to this particular part as well as current supply chain disruptions and things like weather patterns it suggests an alternate supplier there's a cost premium of 42k it's a trade i'm willing to accept because i know that if we do i can get this back on track and i can deliver on time the agent deliver on time. The agent drafts the supplier communication and the Gantt has already updated on

on time. The agent drafts the supplier communication and the Gantt has already updated on screen. And the next step here for us is actually to get the agent to

screen. And the next step here for us is actually to get the agent to draft the purchase requisition to send to the finance department, which engineers typically don't like doing, so that's a way. So these two workflows in Delivery 360 are what it looks like to build the operational core of your company AI natively. But the

supply chain is just the starting point for us. We're taking the same approach and applying it to workforce planning, site operations. for us. We're taking the same approach and applying it to workforce planning, site operations, purchasing and a number of other areas across the business. The thing that I'm really excited about and the thing that compounds this

the business. The thing that I'm really excited about and the thing that compounds this AI native approach is that we're pushing everyone at N -Scale to be a builder.

And so the compounding effect will come from subject matter experts building on top of the ontology. And actually last week one of our corp dev VPs shipped a really

the ontology. And actually last week one of our corp dev VPs shipped a really compelling use case that he calls the contract agent and he's using the ontology in a really called the contract agent and he's using the ontology in a really creative way to solve a problem that only he knew existed and that's the paradigm shift the people who understand the problem space are going to be the people who build

the solutions and the wild thing about doing this at n scale is that we are doing it from the beginning we're not going to get to it later we're not going to launch a transformation program we are doing it from day one so we use ai to build for ai but in the end it still comes down to your stellar to build for AI. But in the end, it still comes down

to your stellar people just with the ceiling taken off of what they can do.

And that is the company we're building. And it's how we're going to bring 10 gigawatts of compute power online. Build after build, faster every time. Thank you.