AI agents need more than access to 3D spatial data
MCP makes it easy to give an AI agent access to a 3D dataset, but access isn’t the same as being able to work with the geometry inside it. A point cloud of billions of points can’t be read like a document or sent whole to a model, so questions like “what changed on site?” or “how has this stockpile evolved over three years?” depend on infrastructure that indexes and queries 3D data natively. This article explains why LumiDB built that foundation first, how it lets domain experts like surveying firm TERRATERRE build their own tools on top of it, and why agent-generated answers still need to be verifiable against the underlying geometry.
Written by
Published on
Do not index
Why the next generation of spatial tools will be built on infrastructure that understands the data itself.
We're getting very good at giving AI agents tools.
Through the Model Context Protocol (MCP), an agent can search a company's documents, query a database, interact with software and combine information from different systems. A question that once required someone to navigate several applications is now a casual request in natural language.
Our industry produces enormous volumes of 3D data, too. It would seem like a match made in heaven.
We’re seeing a growing ecosystem of agent-accessible GIS tools, and MCP interfaces for 3D platforms are beginning to emerge, too.
But what interests me is the subtle gap between giving an agent access to a dataset and giving it the ability to actually work with the spatial information inside it.
In practice, those two things will look very, very different.
MCP is the connection, not the data infrastructure
Imagine asking an agent to find a survey from last September. If the dataset has sensible metadata, that’s relatively straightforward.
Now, ask it which parts of a construction site have changed since that survey, or how the volume of a stockpile has evolved across several years of scans.
The agent needs more than a filename, a bounding box or a picture of the site. It needs access to the underlying geometry, the relevant classifications, coordinate systems, survey dates and appropriate analytical operations. It also needs a way to retrieve only what is relevant to the question, and to produce a result someone can check.
A point cloud might contain billions of points. Sending the whole thing to an AI model makes no sense. Downloading it and processing it from scratch for every new question makes even less sense.
This is why I believe the underlying data architecture matters so much.
Many established data systems were designed around documents, tables, 2D features or the metadata attached to 3D models. They can tell you about a dataset without necessarily being able to interrogate its full 3D contents efficiently. Large-scale reality-capture data needs spatial indexing and query mechanisms built for its geometry and size.
MCP can give an agent a door into that system. But the system on the other side still has to understand 3D.
We started with the indexing for a reason
I think 3D data is hard to understand for two main reasons. One: it’s huge. A single site scan is made up of billions of datapoints. Two, all that data only makes sense spatially.
You can't meaningfully read a point cloud from beginning to end like a document or table. You have to ask for a particular place, at a particular level of detail, and retrieve the relevant geometry. Without a spatial index, that simple question can become a massive file transfer and another processing job.
At LumiDB, we made a deliberate choice to build that indexing and querying infrastructure first. It gives people, applications and agents a practical way into the data.
With that foundation in place, the same point cloud can serve a browser viewer, a GIS application, a custom-built tool or an AI agent through a consistent interface. Each can work with the information it needs without turning every interaction into another file-transfer exercise.
That matters for the people producing survey data as much as for the people using it.
A surveyor can deliver excellent CAD drawings, plans and a complete point cloud, yet the client may still struggle to explore the underlying scan. The problem is not the quality of the survey. It's that the files don’t automatically give the recipient an immediate, effective way to explore them.
If that data remains accessible after delivery, the client's next question doesn't always have to mean another export, another specialist application or another request back to the survey team.
Agentic access is a natural extension of that idea. The next person, or agent, trying to use the survey might not know anything about point-cloud formats. They might simply know the question that needs answering. With agentic access, they can answer it.
What happens when the domain experts can build the tools?
The idea of an AI chatbot describing a 3D scene is intriguing enough. But, it’s what people could build once when underlying spatial operations are now reusable building blocks.
We've seen what AI-assisted, or "vibe", coding can do for web applications. I think spatial professionals should be able to build their own tools in a similar way, without first having to become software engineers.
Imagine a mining team asking:
Build me a dashboard showing how stockpile volumes have changed over the past three years, across all our sites.
Or a utility vegetation team saying:
Create a tool that helps us identify areas near power lines where tree thinning should be prioritised.
There's still real engineering between a prompt and a dependable application. But this is the direction I think we're heading: tools shaped by the people who understand the problem, assembled with AI assistance on top of trustworthy spatial data and analysis tools.
We have already seen a smaller, very real version of this. TERRATERRE, a surveying firm in France, used generative AI and the LumiDB API to build two point-cloud viewers: one for its own team and another for its clients. Their team knows surveying, not software engineering. That domain knowledge helped it specify tools closely matched to the work its people and customers actually do.
Surveyors who understand the daily workflow are better placed to define the right application than a software company guessing what the workflow should look like.
With the right infrastructure, more of that relevant expertise can become working software.
The answer still has to be trustworthy
Of course, being able to ask a question in plain language does not guarantee a correct spatial measurement.
An agent must call the right analytical tools, work with appropriate source data, respect permissions and make its results verifiable. Some decisions will always require professional judgement. We should be especially careful not to confuse a convincing AI-generated explanation with a validated result from the geometry.
And I don't expect LumiDB to be the only company building towards this. The emergence of 3D and geospatial MCP tools is a good sign that the industry is starting to move in the same direction.
My hypothesis is that the most useful agentic spatial applications will depend on infrastructure that is 3D-aware from the beginning. Adding an AI interface to an archive is one step. Making the underlying reality-capture data genuinely usable is the bigger task.
For years, we've focused on improving how accurately and efficiently we capture the physical world.
The next opportunity is to make all that information much easier to act on, whether it’s by people, by software and by agents.
Want to see LumiDB in action for yourself?
Put your own spatial data to the test.
Written by
