Inspiration

AI is moving fast. The power grid isn't.

According to Lawrence Berkeley National Laboratory, data centers could account for 11.8% of U.S. electricity consumption by 2030. But building the infrastructure to deliver that power takes time. Even after engineers find a suitable transmission route, they still have to deal with land access, tower placement, and negotiations with individual property owners.

Theo previously worked in the transmission operations department at KEPCO, Korea's electric power company. From that experience, he saw how difficult coordinating with landowners could be and how those discussions could affect a project.

That gave us an idea. What if route planning, landowner negotiations, and compensation were all connected? What if a landowner rejected an offer and the system could actually find another route instead of leaving the team to start over?

That's why the three of us, Theo, Pratham, and Seohyun, built EasyGrid.

What it does

EasyGrid connects transmission route planning, AI-powered landowner negotiations, and simulated compensation payments in one workflow.

Here's how it works:

  1. Plan a route. Users place a substation and a data center on a 3D map. EasyGrid compares possible transmission routes based on distance, estimated construction costs, and impact on surrounding land, using the demo's modeled terrain and placement constraints.

  2. Identify affected landowners. Once a route is selected, the system shows which parcels it crosses, where towers would be placed, and the estimated compensation for each affected property.

  3. Negotiate through an AI phone call. An AI agent contacts a consenting participant acting as a fictional landowner. The participant can ask questions, discuss the project, and negotiate compensation. The agent operates within compensation limits set by the server.

  4. Automatically reroute after a refusal. This is our favorite part. If the landowner rejects the proposal, EasyGrid records the refusal, excludes that parcel, and calculates an alternative route. The demo can then continue with another fictional landowner on the updated route.

  5. Move from agreement to payment. When an offer is accepted, the agreed amount is carried into a contract for review. Both demo parties must sign before a simulated, one-time compensation payment can proceed.

All properties, landowners, and compensation amounts are fictional. Phone calls can be live, but the contracts and payments are simulated. No actual land rights are transferred, and no real money moves.

How we built it

We built the 3D map using Three.js and vanilla JavaScript. Our route planner uses geometry, placement restrictions, and modeled costs to compare different transmission paths.

We used TypeScript and Zod to define and validate the data moving between the planner, phone agent, and agreement system.

For the phone calls, we integrated Cartesia for voice interaction and Claude for negotiation. Rather than accepting every positive-sounding response as an agreement, the system checks whether the landowner actually accepted the current offer. SpacetimeDB stores the call state and results.

The detailed web demo runs on Cloudflare Workers, with D1 storing agreements and simulated payment records. We also built a separate rule-based finance worker that checks signatures, compensation amounts, and payment status before approving a simulated payment.

We integrated a Capital One Nessie sandbox adapter for financial records as well. It runs separately from the public demo's payment simulation, so a sandbox record should not be confused with an actual settled payment.

The most important part wasn't any single technology. It was getting all these pieces to respond to each other. A rejected offer needed to change the route. A new route needed to update the affected landowners. And an accepted offer needed to carry the correct amount through the contract and payment process.

Challenges we ran into

One of our biggest challenges was understanding what actually happened during a phone conversation.

A landowner might reject the compensation amount but still be open to the project. They might say "yes" to a question without agreeing to the offer. We had to make sure the system could tell the difference and wouldn't treat an unclear response or a failed call as approval.

Another challenge was keeping everything consistent when the route changed. If a landowner had agreed to one route, that agreement shouldn't automatically apply to a different one. We linked agreements to their routes and negotiation records, kept track of excluded parcels, and added checks against outdated agreements and duplicate payments.

We also spent time adjusting the phone conversations. We wanted the agent to answer questions properly without making every call longer than necessary.

Accomplishments that we're proud of

We built a working demo that connects route planning, AI phone negotiation, agreement review, and simulated payment.

What we're most proud of is the rerouting process. When a landowner refuses, the system doesn't just display a rejection message. It uses that decision to change the actual plan and lets the workflow continue.

We also got the negotiated compensation amount to flow into the agreement and payment review without having to enter it again manually.

Our tests cover ambiguous responses, acceptance and refusal, restoring saved states, and preventing duplicate payments.

It's still a prototype, but seeing the entire process work together was a big milestone for us.

What we learned

We learned that making an AI agent talk is one thing. Making its decisions reliable enough for the rest of an application to act on is much harder.

We needed to know exactly which offer was accepted, which property it applied to, and whether anything had changed since the conversation started.

We also realized how important it is to balance speed with clarity. A fast phone call doesn't help much if the landowner doesn't understand what they're agreeing to.

More broadly, we learned that AI becomes much more useful when it doesn't just answer questions, but helps move a real workflow forward.

What's next for EasyGrid

Our immediate priorities are bringing our separate demo implementations together, reducing delays in phone calls and system updates, and making the project easier for others to run.

Longer term, we want to work with utilities, transmission developers, and right-of-way professionals to test the idea with real-world requirements and appropriate geospatial data.

We think there's a real business opportunity here. Transmission projects involve a lot of coordination between engineering teams, landowners, legal teams, and finance departments. Reducing repeated outreach, manual data entry, and rework after route changes could save time and administrative costs.

We haven't measured those savings in a real project yet. That's something we'd want to validate with industry partners.

EasyGrid also wouldn't replace engineering reviews, legal approvals, or the permitting process. Real deployments would need accurate property data, expert review, identity verification, and secure financial integrations.

Our goal is simple: make the work between planning a power line and getting it built less complicated.

The demand for electricity is growing. We want to help the infrastructure catch up.

Built With

Share this project:

Updates

Submission history