AI in Energy Development: Speed vs. Accuracy, and How to Have Both

• Match the tool to the decision: deterministic software builds the data foundation, AI agents handle "light reasoning at scale," and human experts make the final call on high-stakes decisions.
• Ask three questions before trusting an AI output: What data is it using? How fast can it learn from your feedback? What would it cost to be wrong?
• Trust starts with the data. Paces also uses agents to reconcile conflicting substation data, such as voltage, owner and operator, before that data feeds any decision.
• Expert feedback compounds. Every correction from Paces power, permitting and development experts goes back into the product, so the same prompt returns better results the next time.
• Speed and accuracy shouldn't be a trade-off. A site screening campaign that used to take a week of analyst time can now be done in an afternoon, with experts vetting the results.

Kyle Baranko
Head of Product, Paces

Tony Wagler
Director of Development, Paces

Can AI speed up power site selection without sacrificing accuracy?

Yes, if AI agents handle the volume and experts vet the outputs before decisions with real money at risk. Paces uses this approach to compress a week-long site screening campaign into an afternoon.

What are the most common reasons a data center site is a no-go?

The biggest is a lack of capacity at the substation, where required upgrades push timelines or costs too far. Other common project killers are zoning with no precedent for rezoning, too much distance from distribution lines or fiber, and local moratoriums or community opposition.

Which Paces modules matter most to data center developers?

Power analysis that models capacity and upgrade costs as closely as possible to the utility's own methodology, tracking of local sentiment and moratoriums, and backup and bridge power buildability. The local zoning and permitting module is among the most requested.

Is project data secure when using the Paces agent?

Yes. Each organization's data is siloed within Paces, and the agent can only access the projects and custom data in your own organization.

Does Paces train AI models on customer data?

No. Paces doesn't train large language models. It builds the tools, prompts and workflows around foundation models from Anthropic and OpenAI, and product improvements come from the Paces product team.

How are developers handling long interconnection timelines for data centers?

Many are looking at behind-the-meter bridge power. That means tracking changing interconnection processes, such as batch studies, and modeling what solar and storage can actually be built on-site as a bridge or as backup power.

Why not build your own version of Paces with Claude Code or Codex?

A first version is easy to build, but Paces has years of nationwide geospatial data, Critical Energy Infrastructure Information (CEII), and data synthesized from multiple vendors. It also runs multi-model agent workflows built side by side with in-house developers.

Alright. Hello, everyone. Thank you for joining our webinar today. Just a reminder for everyone on why we're here.

Today, Tony and I were talking about how to leverage AI and infrastructure development, both within the Paces product and some rules of thumb that we've, gathered from working, closely with AI systems and internally as we've built, the product of Paces itself. We will be recording this webinar. So we'll be following up in a couple, days with the recording. So, in case you miss anything, don't sweat it.

Feel free to drop questions in the chat at any point, and we'll cycle to those questions at the end. So we've got about, like, thirty five minutes of content for you covering both some slides and a couple demos that Tony and I will walk you through, and then we'll open it up for questions and discussion.

A little bit of background on ourselves before we get into the meat of it. My name is Kyle. So I lead product at Paces.

I've been here for about three and a half years, and my background, has always been at the intersection of the energy industry and, data science and AI. My job at Paces in its simplest form is basically to decide where AI should and should not touch the development workflow. And then specifically working closely with our customers, Tony, and our software engineers to design design the guardrails and the fallback systems to ensure that outputs from AI systems are trust... Trustworthy to make actual critical, development decisions.

Before we... Like, before I pass it to Tony, I just wanna share, like, a little bit about, like, some of the themes that I'll be hitting on, over the course of of the hour, in particular related to our product philosophy.

The way we think about building with agents at paces is really leaning into, what we've seen a lot of our software engineers do within the last six months. So I don't know how closely many of you work work side by side, with, you know, software engineers or AI engineers. But, really, what's remarkable, about, like, some of the the, you know, the engineers at Paces is that they don't necessarily write code anymore. What they've become is essentially managers of teams of agents.

And so they basically dictate to an agentic system, whether that's Cloud Code, Cursor, Devon, other products on the market. And those tools go out and actually build a lot of the the nuts and bolts of our software system and come back to the human for review. So this has really turned, the the job of the software engineer into much more less grunt work and much more critical thinking, more review, more design discussions, and really multiply their productivity, like, tenfold. And so, really, what I'm interested in in collaborating with Tony and a lot of our customers on is, you know, within one month, we...

Or within one year, we expect the development workflow to work very, very similarly to what we're seeing our software engineering team produce. So that'll be, like, a common theme throughout this content is, like, what are the actual mental models we need to to get to that future and unlock a lot more productivity.

So with that, I will pass it to Tony so he can give a a bit of an intro and background himself as well.

Yeah. Thanks, Kelly. Great to be here with you all. My name is Tony Waggler, and I lead the development as a service team at Paces.

Throughout, I might reference DAS, and that stands for development as a service. But prior to joining Paces, I came from a renewable energy development background myself. I was with a company called Nexamp doing battery storage development primarily in the Northeast for a couple of years. And then prior to that, I was with Total Energies, which is a a large integrated energy company.

I was doing both DG Bess and solar across the world in a number of markets and got to really see development end to end.

Throughout the development life cycle, though, I grew quite frustrated with how slow things moved in some cases, and a lot of the manual work that seemed to be, inefficient at times. And so I joined PACE about a year and a half ago.

And since I've been here, been working closely with Kyle on the product and and software engineering team, but really working on building out a development team within Paces that acts as an extension of our customers, meaning taking projects from siting and and origination through to NTP. And since we've been here, we've worked really closely on taking the manual work, anything that's, repeated or anything that we're spending too much time on, and seeing where we can automate with the same output and quality, that we would if, if if we on the team were doing that ourselves. So in short, I'm trying to automate my own job away on the manual work, so that I can spend a lot more time on the relationships that matter with the utilities, with the AHJs and towns, as well as the capital allocation piece because that's still best done, with... Within our team.

So to set the stage, a couple years ago, it would have taken probably a week's worth of analyst time to do a full site screening campaign, meaning that you would get a a shortlist, and you'd have to go through that and manually check sites. And that could ultimately eat a lot of time that that can be compressed by tools that we've been building at Paces. So today, what that looks like for us is compressing that whole process down to an afternoon in just a few hours. And that sounds like a win because you can get to good sites much more quickly in in the...

In a compressed environment where the grid is still constrained. Obviously, with the the, load build out with data centers across, the country, time is of the essence, but at the end of the day, the edge is still trust. It's great to get to a number of sites very quickly, but the foundation still has to be trust on whether a project should move forward or not. So in short, if it's if it's fast but it's wrong, then that could be a difference of hundreds of thousands, if not millions of dollars, or sitting in on a queue position for over a year that you never wanted to be in.

Sweet. And speaking a little bit to how we get there. Right? How do we solve the the the challenges that Tony's teams are facing and developers are are facing as a whole in this, increasingly competitive environment?

What I like to think about when we're building, AI systems are two things. The first is the division of labor, between the different types of information entities involved, I guess, you could say, as well as the hierarchy within, like, your data platform of where you want to leverage AI and and specifically a lot of the advances we've seen in agents and LLMs. So speaking to the, division of labor first, I kinda divide it into three things. The first is a lot of the classical deterministic software and, like, exchange transfer...

Extract, transfer, and load of data pipelines, that really form, like, the common corpus of data or the foundations of the system. Right? So what we are thinking about here within maybe the context of the Paces product are all of the deterministic data pipelines with set inputs and outputs that take in and munch on tons of geospatial data that we feed into the product itself, as well as a lot of the a p...

Like, the back end APIs and deterministic software that we use to do things like calculate your buildable acreage for different environmental settings, for example. The separate the separate category is LLMs and agents. These entities are great at taking information and structuring data. Right?

More open ended research tasks or taking a bit more open ended disc...

You know, instructions from a user and using those deterministic tool...

Tools to achieve a specific end.

Essentially, what I like to phrase this is, like, light reasoning at scale. And then where humans are are most helpful within this workflow is, like, the deep reasoning, the critical thinking. Right? So overseeing this entire system, being inserted at specific junctures where the cost of, like, an incorrect decision is fairly high, as well as most importantly, like, feeding that information back into the system so that overall, the agents and the data can improve, and it can...

Basically, we can have an improving flywheel over time. The other axis from which to compare, an AI system is really thinking about, like, the hierarchy within the workflow of where you're leveraging agents. So it's not just necessarily, like, raw data at bottom, agents in the middle, humans at the top. We found it's very, very helpful, of course, to think of agents as taking, like, instructions from Tony, using the different data and tooling and APIs, and then producing some presentable output, like submitting an interconnection application or creating, like, a permitting brief.

But we've...

Where we've also found a lot of help is...

Or a lot of value from AI and agents is, like, inserting them even deeper at the foundational lever. Right? So when you're thinking about building massive geospatial data pipelines to get substation data, you wanna have, like, really high quality for voltage, owner information, operator information. You can have different data pipelines coming from different public and private sources, but the instances where maybe that data conflicts or there's additional textual information that you can use and you can reason through to override and provide, like, a confidence score or just more reliable foundational information, that's another case where you can deploy agents at scale to kind of, like, clean up data in a way that's, like, not necessarily deterministic.

And so we found a lot of success basically incorporating agents even at the foundational step of our workflow with human review as well in order to, provide that, like, common corpus of of deterministic tools for the rest of the platform and that the work agent sitting on top actually consume.

I've been talking for a bit. So, yeah, Tony, anything you'd like to to add here or, you know, give your perspective of how you see this from the developer point of view?

I think, yeah, you hit the nail on the head, but at the end of the day, as mentioned, trust in the...

Even in that foundational, layer is gonna make the output much more trustworthy when we use that in DaaS. I'd like to think of any output from an agent as something I'd be receiving from a con...

Consultant. I believe that it's it's good information, but I'll always triple check it and vet it before I'm making, real development decisions where there's development spend at risk or you're progressing a project into next phases. So we always vet the outcomes of anything that is agentic, and a lot of the information information that that we would maybe tweak a little bit, it's not necessarily wrong, but might not have the exact read a lot of time...

A lot of times in in development, the subjective read on good data matters just as much. So all that feedback then goes back to the product team, the software engineer, so that the next output is more recursive and and better, and better in terms of actual development outcomes.

Alright. So I guess a couple years ago without AgenTic tools, as mentioned, doing a long search just to get to a number of sites, could have taken a week, but today with my new habits using tools, this can get...

Be be done about an afternoon. Historically, I've had to go through different filters and talk about exactly what criteria I'd like to see in in a search outcome for sites I'd like pursue just at the site selection origination level. But what we're training internally is an agentic tool where we can speak in natural language, and then the outcome would be just what you'd get if you had done the full flow on your own with the the historic tool. So what that looks like is I just describe what I'd like with the memory and the agents being trained on what we're looking at recursively.

That outcome is often just as good as me going through that manual step. Again, these types of outcomes are still being validated by us on the team, by the people who are doing the development, but then all the the outset of anything that we would change goes right back into the models, goes to the product team, the software engineers, so that the next time I ask the same exact thing, call it...

I'm looking for 200 acres in Texas that are within a mile of a transmission line. That then gets me even better outcomes the next time I do it even though the prompt is the exact same. Another way that we are really pushing kind of the frontier with even...

With just within paces is that anything we deem to be automatable, but isn't in the platform yet or isn't being worked on by, actual software engineers, with the tools we have today with Cloud Code, Cursor, some of the the codex models at OpenAI. I am not a software engineer whatsoever, but we can get quite good outcomes using those tools. So we will tinker with quite a bit of, any flow that we think is repeatable, and a first version of that outcome, is large...

Is largely good enough to get that piece of work done. And then we we hand that off to to the product team, the software engineers, who can then productionize it properly and make it repeatable. An example of this is we were mapping a utility service territory for one of our customers. In this specific territory, there wasn't a hosting capacity map that had data on capacity.

So we had to get a little creative. There was a pre application process that was relatively inexpensive. We reached out to the utility and asked them, just in short, would it be alright to try to map your entire service territory with the pre app process? Would that break your system, or is that something that there are rules against?

They said, no. Please feel free. Go for it. So we found all 300 substations, wrote a script, and basically coded the inputs of that application and shot them out to all 300 plus substations, and in a couple days, got back the results from the pre apps.

Whereas historically, it might have been, okay. I'm gonna find potentially the most attractive substations. I manually input the application form. I send that, wait a week until I get the results, and that delays the development process.

But in this case, just a a vibe coded tool had a great mapping of the entire service territory, and then that's something that we ended up building in the platform for future use. Anything you'd add on...

I guess, day to day, Kyle might see us vibe coding tools as either a headache or joy because we're trying to push the product, but sometimes we're we're, just spinning up tools that might not be necessarily efficient. But anything else you'd add, Kyle?

Just to make it clear, or in terms of analogy that I find useful, least, like, for the audience. So the way in which we work with Tony's team, is really, like, thinking about scaling up the more mature workflows. Right? So, essentially, like, Tony's team goes out and charts the development path, and over time, they kind of, like, form the initial trails or, like, the game trails through the woods.

And as we see more steps along that game trail, we understand those workflows better, then we can kinda continue to, like, put our thumb on the scale as a product team and invest in scaling up the custom scripts that Tony's team has built into maybe custom agentic workflows, specific skills, things that make things more scalable. So a lot of the the products that, you may see today are the services, that you would use to interact with our team. Like, a lot of our modular reports are power flow studies. This has always been built by, you know, an expert within paces doing something manually or, you know, with AI the first time to iron out the workflow and oversee a lot of things end to end, as we then invest more resources in scaling that up.

So just a hopeful analogy, I think, is to to make that a bit practical on how we build product at at paces. And, yeah, everything you see today is is really, like, a manifestation of that process.

Cool. And so I just wanna hit on a couple key things before we get into the demo section. So three questions to ask before you are trusting an AI output. The first is really getting into the actual data that the AI is using to make the decision.

What is its underlying source? Right? This is really important for us as a product team because we wanna essentially build, like, the rails for you as a user to go through and vet the decisions, and make sure that it's very transparent in terms of what types of decisions, are being made by the agent. The second is how do I train my agent with, like, the proper context management and everything in order to determine how fast it'll learn.

Right? Some things are very simple to communicate to a human. They can go off and do it for very open ended tasks that require critical thinking. But if you can invest in creating a very detailed skill or protocol that you can feed into the system, that's something that an agent can do and we can iterate on over time.

So really thinking about, like, what what is it gonna take to scale up this work, and how fast, would a human learn versus, like, like, an agentic system. And then finally, this is, obviously one of the most important ones, but what are the stakes for the decisions? Right? So what what would it cost to be wrong?

And so at that point, you know, if you think about the analogy of agents really as interns going about doing work, you wouldn't necessarily trust a junior analyst to make, like, a multimillion dollar interconnection decision. That's where, you know, people like Tony come into the fold to make those calls, but you would want them to go and vet and and aggregate as much information and synthesize information for you in order to that decision, yourself.

Anything you wanna, touch on here, Tony, before we get into the demo?

No. I think, yeah, that covers it quite well just on the third piece on on question number three. What would it cost to be wrong here? Going back to the point on the recursive learning. So each time that anyone on our team says, well, we would just tweak this slightly because x and x reason, that isn't lost just in a conversation, you know, in the office between Kyle and I.

That is going back and really training the output for the next time so that, ultimately, today, the output of of a model and these different tools might be at the analyst or junior level, but we think at the pace, things are being trained and and evolving quite quickly. A lot of those heavier decisions can be not made, but put you in a better position to make those decisions quite soon. And the internal feedback, to improve the next output is an extremely important process that is across the board at paces, whether it's the, the permitting and and zoning experts, whether it's the power engineers, whether it's, ourselves on the development team. Each of those pods, that feedback is being recorded and is being really taken into consideration for the next round.

Yep. Absolutely. And, certainly, like, the emphasis of our team internally and a lot of our software engineers that are most, privy to, like, performances of of the newest models and everything, very keen on on trying those out as fast as possible and making sure we're always staying, you know, at the cutting edge, but without the proper guardrails in place to to make sure, we're trusting the models to their current capabilities.

Cool. So now what I'm gonna do is go through a, development scenario with the Paces agent. So what I'll be focusing on is, two steps within the workflow that you're probably familiar with within, Paces, and then I'll be passing it to Tony, to talk through how he will use the Paces agent for a step deeper in the workflow when you're actually creating a development plan for a specific site. So first, I'm going to update and start a new Cloud Code session or a new, Paces agent session.

I'm gonna copy paste my prompt here. So what I'm gonna do for this session is essentially I want to run a data center search in Texas in a specific area. So I'm gonna tell the agent, generally the qualities of the real estate that I'm most interested in, what makes a suitable site for me so that I can create that initial shortlist and begin vetting them in more detail. So, essentially, I'm telling the agents, you know, what size data center I need, how much buildable acreage I will likely need for that, as well as, like, specific characteristics of the grid and, nearby infrastructure that I would need in order to see a successful, result.

I'm also, at the same time, going to kick off another agent session deeper in the workflow.

So here, what I'm telling, the agent to do is basically take a list of sites that I've already vetted after a search result. And what I wanted to do is basically take the highest scoring sites within that list and create a presentable asset that I can then share with my development partner. So that way, I can basically take, you know, the cream of the crop for what the system has vetted from my initial search, package it up in a very presentable material, that I can then, share it with whoever may be interested in in talking about the site.

And having two windows open is actually, like, recommended for this work. So, essentially, you know, the agent is going to be telling me exactly what it's doing. It's, going through. It's finding the correct tools.

Right? So you can think of the agent taking the open ended instructions from myself, the human, going over and looking over what tools and deterministic data is going to be most apt for the task at hand, and then gonna come back to me to confirm the plan before it begins doing further detailed work. And so when I have two different sessions open because it is, you know, taking this time to do some background work, I use cloud code like this as well where I have, like, you know, two to three windows open in at a given time, and I'm essentially providing, like, feedback to that system. I'm

having multiple conversation threads with Claude to, like, here, I want you to summarize this note...

These notes for meetings a, b, and c for this meeting, or in another Cloud Code session. I'm basically, like, working on road mapping. So this is, like, fairly common in terms of, like, how we use Cloud Code within our organization.

Alright. So we got some results here, and you can see that the the agent is telling me that it has everything that need to build this out. It's got the geography and size of the real estate, our infrastructure, proximity parameters, where essentially it's confirming some of the information that it has available. So it's confirming whether I want 10 megawatts, you know, at... Of of headroom for a 50 megawatt data center. I'm gonna say that's actually okay. I wanna do, like, a bread for search and then kind of, like, filter it down after.

I would say... And it's also gonna confirm exactly how I should score the site. If I get a lot of, like, outputs, like, what am I going to how am I going to assess which are better than than others? And I'm gonna say I'd like you to emphasize withdrawal headroom.

Alright.

Give it those instructions.

Come back.

Cool. And so what I want the agent to do, and this is really, like, one of the more powerful aspects of using the agent within our platform, is you can, like, customize the types of exports. So, like, I really wanna see within this initial prompt, top five sites, and I wanna see one satellite image with all the infrastructure nearby so I can assess proximity visually and make it more appetizing. And then I also wanna show the buildable area overlay. So I basically wanna say, you know, here's exactly what, you know, based on my environmental settings are telling me.

I could put, like, the concrete pad potentially.

Yes. Go with my data center specific environmental setting.

I always say please to the agent.

Cool. So I'm gonna approve and kick off the search. So, basically, this is another... This was, like, one of the early features we shipped after we launched the agent, but what we call, like, the harness, the way in which you kinda interact with the agent, we found it very useful to present, like, you know, search criteria before you kick things off in this format.

Cool. And so it's gonna say this will take a bit. As our search is due, you're free to close the window. It'll all basically tell me once we're done.

Here, what the agent is now doing is it's, like, cycling through per site, pulling the necessary, layers in order to take those screenshots and making everything presentable for a PDF output, and then it's gonna come back to me, when it's done. So at this stage, this takes a little while to run to produce the the PDF output. And so, yeah, I'll kick it over to Tony, basically, to walk through his segment of the demo. And then when I get the mic back at the end, I'll show you what the output of this, PDF looks like. So, Tony, if you wanna take over, feel free to go for it.

Excellent. Yep.

Alright.

So if we follow the flow that that Kyle went through with the agent, you run your search, you find the sites that you actually want to pursue. But then when you start pursuing them, what we found very helpful is to have that all live in one place. So we built something called the pipeline view, and you've got different stages of development here. This is quite just high level rudimentary, but these are all customizable based on what you would do internally.

You can make as many or as few stages and customize them as however you'd like. It's also very easy to use. You can just drag and drop projects as they progress. So this, we found, is a great place to have every project that's progressing live in one place.

I also like to view them geographically across the country, see which products are in development, which are under site control, etcetera, just an easy view. But at the project level, any project's gonna progress. You'd like to do deeper diligence to make sure that that, call it, deposit or application fee for the interconnection application is is worth it. You want to vet the power piece, the critical issues piece on on the buildability. Those are also things that are possible within Paces. We do a number of reports. But at the project level, this is kind of the the hub where all those documents would live.

And before...

For me doing projects in the development world, before even kicking all that off, I'd want to know a kind of a development matrix or a Gantt chart showing me exactly what the steps are to reach interconnection studies being approved, what the permits are, what required in that area, what the application process looks like, how long it takes to get approval. Basically, all the nitty gritty that goes into development to get you from identifying the site to NTP.

So what we built was the ability to have any document that's available about that site, whether it's, something that we generate at paces, whether it's something from a consultant, whether it's coming from a data room, if it's a project that's being bought, and you can upload those into the document section of that site. In this case, I've uploaded a due diligence report that a consultant ran as well as outstanding permits as a bit of And so the step after that would be, okay. Great. I know about the site. The agent itself knows high level how development works, and the more documents you feed it, the more information it has to to build a proper development Gantt chart. So similar to Kyle, instead of me taking this and manually doing it with Smart Sheets or a number of tools that do Gantt charts, we built this into the platform. So I'll start a conversation with the Paces agent.

I'll say, hi, PACE's agent. Like, how I like to try to be try to be polite. I am progressing this project, and I'd like to create a full Gantt chart based on the documents provided.

Again, I think it's very important to note that sometimes agents and and anyone who doesn't come from a software engineering background can feel a little bit daunting. But here, it's pure natural language, nothing technical, and the outputs are the same as someone with a coding background would be. So it's going through.

It all shows you the thought process. I'll build again for this project.

It's gonna check the documents, ask to read and understand them.

And then what will happen next is it'll propose a kind of a step by step approach of how the Gantt should be built. I'll validate that, and then it will go ahead and build it.

The creation of the actual Gantt chart sometimes takes a few minutes. I'll show you one that that we built in the past, but just to show you the process of of what that looks like getting to this point. So the agent will start going and building the Gantt chart, and this is what it looks like when it's finally done.

You've got kind of the the preengagement pieces of who you should be contacting.

In this case, it's an AEP interconnection, so what that system impact study looks like, how long it takes, how many business days, if there's a resource entity registration, if you're new to a market. In this case, it's an ERCOT, what that looks like. So it's quite comprehensive, and it can be as high level or as as micro down to the exact steps as you'd like. That's kind of the beauty of working with the hero agent.

It's, you give the information that you want, and it builds it. And so this is manually editable. So these are all things that I can change and say, okay. This is dependent on this going through.

These are the dependencies that could potentially block this stage.

But as we know in development, things things come up. There are obstacles, never roadblocks, things that can...

You can get around, but time lines sometimes get pushed, budgets change. So this is a dynamic Gantt chart where, call it the expected range was for March 9. I can now push that out by a week. Confirm.

That all changes, and it's all dynamic from So that's if I wanted to manually change this, and it can be as as detailed or or not as you'd like, but we can also use the Paces agent to do that on our behalf. So again, natural language. Say, the interconnection study phase is getting pushed out by two months. Adjust accordingly.

And then all the dependencies that we related to getting the SIS back will be updated. So while it's doing that, I'll check-in on this, oop, on this hero agent.

Where was he?

And it gives me the details. So I'm gonna revise and see what it has pulled out of these documents. So it's got acquisition and closing, three phases, permitting, regulatory, eight tasks. I can go in and vet one by one, but for the sake of time, I'll just approve.

And then it'll get going in the background and build it. So right now, there isn't one. That's what we're building. And, again, what... Just kinda walk through how we get to the stage as it builds it.

And as Kyle mentioned, I always like to have two or three windows open on Cloud Code, same for for PACE if you're working on multiple work streams.

So here, you've reviewed the schedule. The interconnection study is the system impact study. A two month slip moves it to this date, and it's reviewing it. So I get to review and say, okay.

I need to update the task by two months. Correct. All the dependencies also move. Approve that, and it changes.

Applying the changes now. Let's see. This also takes sometimes over five minutes, so might not happen while we're still on the demo, but once that's completed, it will be generated here in this section, and I can come back moving forward to this project and see what that looks like.

Let's see.

Here we go. So it took... Again, just to recap, it took the two documents that I've given, diligence report and outstanding permits.

We walked through the approval process, and this is what the result looks like.

Anything you wanna add, Kyle, or kind of how the the Gantt piece works?

No. I think you, yeah, covered it covered it well. I think, like, kinda I...

What I'm thinking about as, like, you've been going through this as well as I've been going through this is, like, you know, the the multiple cloud code sessions at the same time analogy, really helpful. Like, ultimately, agents do take time to do the background work and work through different tools. I think, you know, you've seen a couple, like, error messages flash up on on Tony and I's screens. We've been going through this.

I would say when you're using paces, don't necessarily be, alarmed by that. That's just basically...

Like, what's what's beautiful about agents is that they can run into roadblocks as they're doing the work and then figure out how to get by the roadblock, themselves as they're focused on that, like, higher level task.

And then I think the the third thing, I'll emphasize too, which, again, is applicable to Tony's session as well as mine, is that the more specificity you can give, the agents upfront with, like, what you're trying to accomplish, the the more open ended tasks it can accomplish, and the less it's going to, like, check-in with you to... On on minor details throughout the workflow.

And so let's see if this one's ready for us.

Alright. So you can take us back to... Or I'll take you back to the original prompt I gave it for our PDF export.

You can see once we confirm billable area settings, all the different tools it's it's using. And so it's basically telling you how it's going about proceeding with this task. And then at the end, here's our PDF.

It'll take a moment to download in the app.

And here we are. So our five sites basically have, like, a PACE's branded deck for you.

Tells you exactly what we screen for, gives you the shortlist, and then it also gives that per project overview as we go through. Right? So it's essentially giving you a map with a legend. It's giving you the multiple area and, like, the the key figures at a glance. Another great thing about the agent, for any of, like, the formatting changes or, like... You know, I don't really necessarily need you to, like, give me, like, the watch out section.

You can simply give that feedback right back to the agent, and it will take all that feedback into account and then produce a new PDF for you to to download.

But for now, wanna keep moving on to our our wrap up slide before we get into the q and a session. So just to conclude here, I think, and summarize this framework. So always match the tool to the decision. Right? So AI for volume and reasoning at scale, humans for final judgment on higher stakes decisions. Definitely be asking yourself those three questions before you use an AI tool in terms of, like, how you wanna validate the information that you're looking on, and that's on paces as well and and, you know, product overall to give you the rails to be able to do so very seamlessly in that transparency. That's a huge emphasis for us.

The trust really comes down from the data foundation. Right? So all of...

Every decision an agent makes is negligible unless that information underlying it is good or at the very least, the risks of that information are clearly summarized to the agent and therefore you when you're making those decisions.

And then finally, ultimately, all this is geared towards really helping that market framing, you know, slide Tony talked about at the beginning where we really want to eliminate the speed and accuracy trade off. That's how we, you know, improve bottom lines for all developers and and actually deploy infrastructure at the throughput needed to meet the, you know, the the load growth that's now coming online. So quick things you can do this week. Definitely try out the the product with some of the steps that, you know, we have outlined or that that Tony and I showed you today. And then also, you know, just in in any anecdotal, you know, insights we've had about how we use CloudCoder or agents internally, definitely encourage all of you to to tinker with other AI tools out there as well and and take away these principles too. Anything you wanna add on on Tony before we get to the q and I session?

Nope. You nailed it. At the end of the day, trust and speech should not be the trade, and that's what we're working on.

Cool.

Alright. So now happy to spend the remaining time talking through any questions, from the audience. So, yeah, Tony, do you wanna look through the the chat and pick some out?

Yep. Absolutely. We've got a couple coming in.

So thank you for the question, John. What is the most common no go on a project that your team runs into? I will...

I'll answer and then...

And hand it over you to Kyle if you if you've got anything else to add. But, I think that's an excellent question, but quite broad. It really is dependent on the project type, on the market, the technology. I'd say if we're talking about on the load side, the data center side, the biggest no go we're probably seeing is capacity constraint At the end of the day, for these grid connected projects, since we have internally power flow modeling capabilities, you go as deep as possible to understand how many megawatts are available at this node or substation.

So a biggest no go is everything looks great in terms of site characteristics, proximity to to all the relevant pieces that you need, but there's just no capacity at that substation. The timeline would push you out, with the upgrades needed beyond what would be reasonable. Everything else that you would consider that can be a project killer if, it's not zoned correctly for that project use case and the rezoning, process is something there there isn't precedent on. It would be quite hard to go through.

That's often no go. Just proximity to relevant infrastructure if it's too far away and the cost to, call it, build a new, distribution line. Or if you're doing a smaller data center project, but there's no fiber around you, the cost of getting fiber to that to that location, just proximity to infrastructure would also be a big no go reason.

Kyle, anything to add to that?

I was just gonna say, yeah, upgrades are the biggest project pillars, and then I think, yeah, definitely second everything you mentioned. And one of the things that emphasize is moratoriums and sentiment is is one of the the big blockers right now. So that's another thing we've we've really, like, invested a lot of product scoping into and and and building out is the ability to, like, quickly determine who your adversaries or allies might be when you're building infrastructure in a given local community.

So, overall, I would say upgrades and and sentiment are within broadly that bucket of local permitting.

Alright. We've got a question from anonymous attendee. What modules have been the highest demand or value for data center developers?

I'll touch on three things high level, and then, Kyle, you can go deeper since that's more more in your domain. But I'd say, again, leading with power, just where where the capacity is, the capabilities of being able to model power as accurately as possible to what the utility methodology is when you go through that interconnection process, and to Kyle's point, understanding what the upgrade costs are as closely as possible to what, the utility would would give you as well.

Power number one. Two, tracking shift in sentiment and, just who the players are who are making the decisions of whether a county or or township or even state are gonna go into a moratorium or not. Just tracking that very closely. We've done a lot of...

The team has done a lot of great work on identifying the key stakeholders and understanding just, precedent historic shifts and what that could look like in the near term future. And then the final piece is just everything that would be on backup power generation redundancy for for fiber. So a big piece is just still the buildable acreage on-site, understanding, what could potentially be built in terms of, battery storage and and solar backup configuration, knowing what the time to power looks like, through the the grid connected route, and then what a bridge solution looks like. Paces does a lot of good work on on being able to model that accurately.

So those three things are probably the biggest, and I'll hand it over to to you, Kyle.

Yeah. I would say, yeah, we we... Like, you know, you covered quite a bit there, and I think, like, one of the the things that's been interesting as we've shipped new modules is people keep... Or or customers continue to just order the kitchen sink, which is just, like, they'll take everything. Like, how can you derisk as deep as possible on as many fronts at once?

But the other mental model that I use and and one that is is fairly common on, like, a bespoke basis is the the local zoning and permitting module.

Just because, like, generally, what's most valuable to you is what's hardest for us to build. Right? And it takes, like, you know, hours, days to really understand the nuances of a local community, read through its different ordinances, cross reference information, come up with, like, a recommended or, like, you know, a real... Is there a a proposed pathway for my site, and what are... What is that permitting metrics going to look like? And so that's taken us a lot of, like, custom agentic work and really leveraging that division of labor that I was alluding to earlier to build out. So that's one that that takes the most time is really... Takes the most time to get right, I would say, and, also, it's been, one of the the ones that's, yeah, most most highest in demand.

Alright. How do you ensure the security of sensitive project data when entered into the AI agent?

Kyle, that's an excellent question. I'll hand it to you on the data piece.

Yeah. So, basically, how we approach building the system is every single data that you bring into the product is, like, firewalled or carefully guarded within your organization within paces. So whether you upload custom data, upload sites, that is, you have a walled garden, essentially, like, within your organization. That's no different from what the agent has available. Right? So just as you can run a search in different organizations, the agent can run searches in different organizations. But, like, what projects you can look up... Look into and, what custom data maybe you've uploaded, that's, like, completely siloed to, like, the agent within your organization.

A common question we also get on this is whether, like, your information is being used to train data or or train our models. We actually don't train LLMs. Right? So we are focused on building, like, the harness.

So how Anthropic and OpenAI, how their foundation models interact with different tools that we provide, and then the specific prompting and context and skills that we create for our agents around those highly tailored workflows. That's what we're interested in building. And so anytime you essentially, like, upload sensitive information for your development workflow or or go about a a session, there's no common feedback that's being trained during something foundationally. It's going through the product team so that we can can build, you know, more in a more traditional product way, the improvements to to your user experience in that way.

Alright.

Next question is, are you working on any projects with behind the meter solutions due to excessive interconnection timelines, and how are they working through the process if you are? Yes. Very, very prescient point. Kind of alluded to it earlier as one of the three big things that, data center developers are looking at is what could be a bridge to power specifically, behind the meter behind the meter renewables.

And so for a number of our customers on the development as a service side, first is understanding the ever evolving interconnection timelines. As we all know, it's quite dynamic. A lot of of states and ISOs and utilities are introducing, batch processes, different ways of evaluating projects as opposed to what was traditionally, what the process looked like. So one is keeping our our ears to the ground, making sure we're in in the right rooms and having the right conversations to understand what the the process is gonna look like, and then having the the edge on actual buildability, actual proximity to the different types of energy sources for a bridge to power or backup power.

So in short, the answer is yes. We are doing that, quite frequently. And the way that we are making sure that the information that is is being passed on is by, being in the right rooms and still having access to the best data in terms of what projects can actually build as a bridge.

Alright. Let's see what we've got next here. What nonpublic or critical data layers do you provide that would be hard for a company to use Claude code or core... Or codex to perform similar analysis? Excellent question. Kyle, I I guess you wanna take this and talk a little bit about some of the data moats we have?

Sure.

I think what's interesting about the AI wave is it's, like, very easy to build a v one that accomplishes a lot of tasks, allows you to move quickly. I think that there's, like, a couple elements when I think about, when you... Like, that... That's actually the natural reaction we kinda, like, have to think about from a product perspective. And and what's talked about, like, within the the AI product community is, like, are Cloud Code and OpenEdge just going to eat everything? Right? What's the point of of building paces if everyone can can build their own version of paces in two seconds?

I think that's where the data moat really comes into play, where we essentially, we have access to CII information nationwide. We also have the scale to synthesize multiple data vendors, and we also have, like, years of historical, like, records of this geospatial data and, like, the foundational ETL to set that up. So that's still a massive engineering lift in a process and a difficult process to go through to, like, get, like... Basically, get, like, an entry point into those data systems. And so the data moat is is really a matter of, like, scale of, like, the breadth and depth that we have across data across so many different categories.

I would say the additional one is really how tightly we work with Tony and the development team. So we've got best in class AI engineers from places like Meta and NVIDIA who are sitting side by side with Tony in the office every day and, basically, like, building custom agents for the the actual workflows that, you go through on a development basis. And so if, you know, you're a nontechnical user, and you're basically building something over cloud code, that can get you very far. But there's a certain threshold within the complexity of these tasks where you do have to build, like, different types of agents to work together. So for the local zoning and permitting flow, for example, we don't use just cloud for that. We basically found that Claude, Gemini, and Codex are all really good at different things. So Gemini is really good at, like, you know, unstructured data and, like, the computer vision to take messy, like, spreadsheets and, you know, PDFs and convert them to text.

Claude and Anthropic is really good at, like, open ended, like, instruction level work and essentially, like, writing the report. But Codex is really good at, like, making a semantic map of the documents and then going deep and structuring that data and breaking down, like, essentially, the best way I can describe it as a as a semantic map that Claude then uses to write the report. Right? So those types of insights really come from, like, taking a a very deep step or a deep perspective on these workflows and allow us to go to version two or version three and continue to build on top of that.

So just to conclude, like, definitely encourage everyone to build specific applications that you have for v one use cases. But overall, like, the way we really think about it is, like, that that massive data mount, as well as, like, the the custom knowledge of the agentic workflows that we have over time and how we can feed, like, that information and that knowledge of those work workflows into a flywheel that compounds over time as we see more projects and and and, essentially, more work, you know, move throughout our our our platform.

Excellent. Unfortunately, we're overtime and very happy to see there's a lot of engagement. We have, I think, 20 questions still coming in. But in the interest of time, we will answer those by email. Anything else you'd like to add, Kyle, before we we sign off?

No. All set. Thank you for all the the great questions, and, hope everyone found this useful.

Yep. Thanks again, everyone. We'll leave this open for just another minute. If any questions, still wanna be submitted, we'll make sure we get to all those in writing by email. Email.

Perfect. Thank you all.

‍