One of the reasons I built Streamline was to help insanely cool climate tech companies like Charm Industrial. They develop pyrolyzers to burn biomass in low oxygen environments, and inject the bio oil deep underground for permanent carbon removal.

Charm is based in SF, and during SF Climate Week I got to tour their facilities.

During the tour, they mentioned an interesting project. The built AI agents to monitor hardware logs to flag miscalibrated components. I couldn't help but wonder AI can help a company

The problem

I got connected with Peter after that and quickly learned that one of Charm's biggest problems is site selection. More specifically, they need geospatial datasets that don't exist in the public domain.

The initial instinct was to outsource this. Let's pay a consultant to build this out across multiple weeks. But we quickly realized there were even issues in the data they delivered, and not having control over how it was generated led to a lot of unnecessary back and forth.

But more importantly, we realized AI agents are actually pretty good at this.

You see there isn't a public ArcGIS server that directly gives you subsurface permeability across the entire US. That was what we wanted. But there are multiple datasets published by the oil & gas industry that document sedimentary formations for the purpose of wastewater injection.

Once we realized this, we started to notice this pattern everywhere. AI agents can pretty reliably write code to build data pipelines that we can quickly iterate on.

The broader problem

But acquiring the underlying data to visualize as map layers is just the beginning.

Let's walk through an example. Here is a question that pretty much every AI datacenter developer is trying to answer right now:

Where can I find X MW of substation headroom per Y acres of buildable land?

1. Assembling the data

First, we will need data about the points of injection (POIs) – where they are, how much estimated offtake capacity they have, and the assumptions behind the power flow studies that generated these numbers. We will also need to understand how electricity might be delivered to our site via transmission and distribution lines.

Next, physical characteristics of the land. One layer each for topography – slope, elevation, mineral rights, and easements. And that ties directly into the geotechnical risks. We'll want to map out out possible overlaps with SFHA floodzones, wetlands, areas of high wildire risk, etc.

Like I said earlier, AI is already pretty good at this. And this makes sense because it essentially reduces to an easier version of the web scraping problem.

We initially POC'ed this with ChatGPT and then moved to Cursor. But then when we moved to Claude Code, and never looked back.

2. Defining the criteria

And once you have all these layers, you have to define the criteria. By what year do we need the substation headroom by? For datacenters, this typically assumes 3-5 years out but timelines have been compressed. And related to that, what does our power ramp look like after the first year? What can we accept upfront and what do we need to grow into?

What does "buildable land" mean? Are we willing to accept 10% slope grade on the parcel because we are confident we can level it? Or do we only want shovel ready sites?

In a hyper competitive world like datacenters, your advantage can either come from (A) data you have exclusive access to or (B) your interpretation of it. It's pretty common for players to procure data like power and fiber, so really the edge is in the criteria.

In a sense the criteria codifies how the biggest decisions are made. It's the "secret sauce" that determines how much risk we can underwrite on a deal. To get to no fast, and get to yes first.

3. Analyzing our data

Ok so we've decided on a criteria and we have the data. Now our job as a GIS analyst is to put it all together, and this really just means writing a lot of code.

We're probably using PyOGRIO for reading/writing common geospatial formats like FlatGeobuf, Shapefile, GeoJSON, etc. And then we'll toss it into Shapely for geometry operations like finding intersections, buffers and spatial predicates. And of course all of that will flow through pandas and numpy for tabular data manipulation.

And you guessed it – agents are really good at this too.

The GIS agent

To summarize the example above, it roughly breaks down into:

And so that's exactly what I've been building at Geoforge. An AI-native GIS platform that is centered around a GIS agent called Thor.

The first use case we focused on nailing: building map layers from scratch.

There are a couple of cool things that are happening in this short recording.

Public datasets are extremely finnicky. And agents unsurprisingly do very well here – much better than humans might I even say. AI agents are patient in ways we are not, and can quickly recover very well from failure modes and try 10 other things while I'm still reading the original error codes.

And all of this is built as code in the background. So what you end up with is data pipeline you can execute again and again. On top of this, our agent will automatically QA the data, upload it to the Geoforge cloud platform, and figure out the best way to visually present it as well (styling, labels, layer groups, etc.).

Here is what it looks like once it's done:

As a user, you can always see the full methodology behind each layer so you can understand what's going on. In the early innings, this is where we spent most of our time. Reading these artifacts gives you a very good sense of how the agent is approaching the work so that became our locus of control.

But very soon we started building 5, 10, even 15 layers in parallel. And the rest of the system was designed to scale with that.

In the map above, when all the layers are turned on we are interacting with over 15GB+ of data in browser. This works because we use tileset servers to only render the tiles we need in the current viewport and zoom level – kind of like virtualization.

And now the fun part. Going back to this:

Where can I find X MW of substation headroom per Y acres of buildable land?

In this demo environment, what we did was we decomposed this into 2 "derived" layers:

• Buildable land (50 acres) -> Composite analysis scoring 5M+ 25 acre H3 polygons across Texas along 8 binary exclusion factors (seismic class, wetlands, flood zones, etc.) and 6 weighted scoring factors (terrain slope, soil quality, natural hazards, etc.)
• POI Service Areas (250MW+) -> Drawing service boundaries areas with 5 mi radiuses based on POIs that have 250MW of headroom

We then combined these 2 layers into a a final Top Joined Parcels layer. This layer intersects the 2 derived layers above and enriches it with parcel-level information like ownership history, zoning, etc.

Weeks of work done in a few hours.

Death to prompt engineering

When we first launched the agent, we got a lot of positive feedback. And it honestly shocked me too with how capable it was. It was able to do a lot of things beyond what it was designed for. And I now believe that emergent behavior is what defines truly agentic products.

But something else consistently surprised me – people didn't know how to interact with the agent.

Most users open the chat and get stuck there. And what's ironic is that the mental block is self-imposed. It's people thinking "I don't know how to write a good prompt for this" when in reality all they need to do is braindump.

On our first calls, I would literally ask the user some questions and directly translate verbatim what they say to me into the text input field. And then I would share my screen to confirm with user that the agent did what they wanted to do.

With those initial learnings, we reworked the core harness to reflect this philosophy:

1. No one should have to be good at prompt engineering
2. In fact, the agent should prompt you if things are unclear

These changes improved the experience a lot, but it's understandable that people continue to think this way. LLMs are improving exponentially, and unless you use them everyday you are probably falsely anchored to a model that required careful prompt engineering.

Key takeway: knowing how your users use AI outside of the problems your product is trying to solve is a key part of discovery as well.

Agents as execution engines

If you remember, there's a crucial part of the workflow in setting a criteria for site selection that agents are not good at (yet).

For those use cases, we decided to build a UX that made it easy for the user to steer the experience and be in control. And once that's set, you delegate to the agent do all the repetitive work and heavy lifting.

One workflow where being able to do this effectively makes a huge difference: triaging inbound.

Say you are a datacenter developer in the news. You get hundreds of phone calls from landmen, brokers, etc. pitching you new sites everyday. They promise that the site is "shovel ready" and has good access to power. Your job is to validate this quickly before someone else can potentially get to it first.

So we built an inbound tracker with customizable diligence criteria:

As a user, you define how diligence is done across the things you care. This is done by managing your criteria – each corresponds to a new column in the tracker and has custom instructions and quantitative thresholds so diligence is reliable.

Each cell in the main tracker table captures a result that can be expanded upon in the "Report" tab.

Each report takes you deep into the analysis done to create the summary metrics. And all of this is done on top of the existing map layers that the agent built. Bonus: our reports are fully interactive HTML which means you can play with them..

And lastly, if you don't like what you see, you can change it.

In the "Trace" tab, you can see the full thought process that the agent took to build the layer. Here you can fire off follow-up instructions, ask questions, etc. so you're still in control.

The inbound tracker is just one such use case that takes the agent beyond chat.

A truly agent-first platform is powered by the agent - everywhere. Chat is a great interface for flexibility & observability, but humans are much better with high signal-to-ratio interfaces like tables, reports, etc. If an image is worth a thousand words, Excel spreadsheets are worth a million.

The core agent is just the engine of the train. The nice, plushy leather seats are things like the inbound tracker that will deliver immediate value and map 1 to 1 with business problems.

Closing thoughts

A few other observations from working on Geoforge:

• AI eats labor (and moats probably) -> Defensibility in the GIS market comes from data moats. Vendors like FiberLocator have built their business around data that no one else has access to. The software platform they built is just how they amortize the cost maintaining this dataset. But when you think about what makes a dataset "proprietary" in most consulting engagements, it's the human labor and intelligence that has gone into producing the output. We've run a few experiments with running agents overnight to augment datasets and it's worked well enough for me to believe that eventually all of these moats will disappear.
• Everything reduces to coding -> Frontier labs believe that coding is on the path to AGI, which means that if you can reduce your problem to a coding problem then everything will just work better. For example, we switch from using Anthropic's pptx agent skill to generating HTML files and the latter just works so much better. Find ways to make everything about coding.
• Explore more, exploit less -> I think unless you spend at least 50% of your time exploring what's possible with AI, you will miss a lot. As someone who defaults to execution mode, there were many hard earned lessons that led me to this conclusion. Now I spend a lot of my time reading about what people are doing on X, Hacker News, and just talking to people.
• Don't bet against agents -> My views across much of 2023 and 2024 have been "it's not ready yet" and I can say that this take has consistently aged like milk. Don't bet against how AI capabilities will evolve. Skate to where the puck is headed.