How we built a GIS agent on Databricks with Felt's MCP server

We're used to AI agents building us pretty much anything now. A working app from a one-line prompt. A financial model. A full slide deck with charts already formatted. So putting spatial data on a map shouldn't be any harder, right?

In theory, no. In practice, it looks different.

We recently saw a post from Paul Graham where he tried using ChatGPT to map the territories the Saracens controlled on the Italian mainland in the 9th century. What came back was, in his words, "not very good at making maps yet", and made him note the irony of worrying about AI capability while getting that back. It's one of those thousands of posts testing what AI can and can’t do, but it names something real. The same agent that writes you working SQL and clean Python still breaks the moment you ask it for a map.

Ask an agent to show you which customers fall within a quarter mile of any of our installations and you'll typically get one of three things back: a confident list of addresses that don't exist, an apology followed by a Python snippet for you to run yourself, or a few hundred thousand tokens spent building a custom GIS from scratch that ships with its own bugs.

We call that the AI expectation gap. Business users now expect AI to answer any data question directly, including "show me this on a map." The tools have caught up on charts and text. They haven't caught up on spatial, because legacy GIS was never built with an agent in mind. Data lives in project files instead of queryable systems, results ship as exported snapshots instead of live connections, and the interface assumes a person clicking through a desktop application, not a tool call speaking natural language.

So we decided to actually build a GIS agent on Databricks and find out what closing that gap looks like in practice. Here's how it went.

From a Slack message to a live map

Here's what we wanted to know: could someone with no GIS background ask a real spatial question in Slack and get back something they could actually act on?

We picked a hard one: map Arizona energy infrastructure at risk from wildfires. That means finding the right tables across multiple datasets, writing real spatial SQL, and rendering the result as something visual and trustworthy, not a row count.

A supervisor agent on Databricks Agent Bricks took it from there, with Felt's MCP server installed from the Databricks Marketplace. A data finder subagent located the relevant tables on its own. A spatial SQL subagent buffered and simplified geometries to find every transmission line within five miles of an active fire, run against Lakebase, Databricks' serverless Postgres with PostGIS. Three and a half minutes later: a live, styled map in Felt, with fire perimeters, transmission lines, and substations layered in. Every query showed up as a trace in Agent Bricks, so nobody had to take the agent's word for any of it.

From there the question just kept going. How many substations and transmission lines are affected? Three substations, thirteen transmission lines, answered right in the thread. What about the underlying fire risk, not just the perimeters? A burn probability raster, streamed in from a Databricks-governed S3 bucket. What about solar, since the real question was exposure across the whole energy vertical? Found and added, from a table nobody pointed it toward. The fire buffers were too tight to see, so: widen them to five miles. Done.

Four layers, all pulled from Databricks, no desktop GIS tool, no hand-written query. And because it happened in Slack, anyone on the team could keep pushing on it the same way they'd push a coworker for one more cut of the data.

Why this needed both Lakehouse and Lakebase

GIS work has always needed two different things out of a database: large analytical queries across wide areas or many features, and fast, transactional, conversational queries where the next question depends on the last answer. Historically that's meant two separate systems.

Lakehouse handles the first. Lakebase, Databricks' serverless Postgres with PostGIS running on top of the lakehouse, handles the second, and it's what made the live, back-and-forth part of this demo possible. Because both sit on one governed copy of the data, an agent can move between the two kinds of queries without anyone maintaining a separate pipeline to keep them in sync.

Unity Catalog governs all of it: tables, files, MCP tools, models, and agents under the same permissions and lineage rules. Felt's MCP tools show up there the same way a table would.

Who can use it

If your team already lives in Databricks, this isn't a new tool to adopt so much as a new way to ask a question you were already going to ask. A data engineer gets a spatial agent that queries through the same governed tables and permissions as everything else, no separate export step. An analyst who doesn't write spatial SQL can ask the question in plain language, in Genie or Agent Bricks or a Slack channel, and get back something they can actually act on instead of a table of coordinates. A platform team building custom agents on Agent Bricks gets production-grade mapping without building a rendering layer themselves.

Hand the mapping to the agent. Keep the judgment calls for your team.

None of this replaces the judgment a GIS team brings to a hard spatial question. Knowing which datasets actually matter, what a five-mile buffer should mean for a specific asset, when a result needs a second look before anyone acts on it: that's still a person's call. Felt AI can help someone get there faster, too. Ask what's actually in a table of power plants or parcels, and it explains the attributes and suggests spatial analyses worth running, often the harder problem when you don't know a dataset well yet. That's not exclusive to Databricks either: Felt AI ships as the same kind of agent inside Felt itself, so a team gets this whether they're working through Agent Bricks or straight in their own workspace. But suggesting a direction isn't deciding one. What changes is everything that used to sit between the question and the answer. The agent finds the data, writes the query, and builds the map. The team gets to spend its time on the question itself.

Felt already has customers running this pattern in production. Fastned operates a network of 2,000 EV charging stations across nine countries and uses Felt and Databricks together to power site selection.

Here's the map the agent actually built. Zoom in, click through the layers, see for yourself.

Watch the whole thing happen, live, on the full webinar recording.

FAQ

What is Databricks Agent Bricks?

Agent Bricks is Databricks' open, multi-harness agent development platform. It's where the agent itself runs, deciding which datasets and tools to use for a given request, and it isn't tied to one model or framework.

What's the difference between Lakehouse and Lakebase?

Lakehouse is built for large-scale analytical queries across wide areas or many features. Lakebase is Databricks' serverless Postgres with PostGIS, built for faster, transactional, conversational queries, the kind a live agent exchange depends on. Both draw from the same governed copy of the data.

How do I know what the agent actually did?

Every query the agent runs against Databricks is logged as a trace in Agent Bricks, showing which tables it queried and what it returned, so a team can verify the work rather than take the result on faith.

Does this work with Databricks Genie as well as Agent Bricks?

Felt's MCP server is a standard MCP server, so any MCP-compatible orchestration layer can call it. Check with your Databricks team on Genie-specific support today.

Do I need to be a GIS specialist to use this?

No. The agent handles finding the data, writing the spatial SQL, and building the map. Deciding which question to ask and what the result means is still a person's job, but it no longer takes GIS expertise to get from question to map.