The most capable AI systems of 2026 can reason about almost anything that lives in text. They can summarise dense legal documents, explain a 50,000-line codebase, plan a multi-step research project, and execute multi-step tool calls against APIs they’ve never seen before. The frontier of what they cannot do is shrinking by the month.
There is one conspicuous gap. AI agents struggle to reason about the physical world — not because the models can’t, but because the data about the physical world isn’t in a form that’s queryable. Most of what is known about any given site, building, asset, or location lives in places the agent cannot access: a hard drive in a surveyor’s office, a folder on a project manager’s laptop, a series of emails between contractors, a shared drive the agent has no permissions to and would not understand if it did.
This is the bottleneck for the next generation of AI applications. And it’s not a model problem. It’s an infrastructure problem.
What AI does with structured data vs unstructured files
The capability gap shows up immediately when you compare two parallel problems an AI agent might face.
Problem 1: code. “Refactor this authentication module to use the new session library.” The agent reads the relevant files, identifies the patterns, generates the change, runs the tests, iterates. The code is structured (it has a syntax tree), addressable (it has file paths and line numbers), and queryable (the agent can grep, search, and traverse). The infrastructure is mature. The agent can do real work.
Problem 2: a physical site. “What was the condition of the front retaining wall at the property the firm surveyed in February?” The agent has to find the firm’s spatial data store (which may not exist as a single thing), authenticate to it (probably can’t), find the right property (folder structures are inconsistent), find the right capture session (ditto), open the relevant point cloud (no browser viewer for the agent to consume), interpret the geometry (no addressable spatial primitive to query), and finally produce an answer. The agent can’t do real work because there’s no infrastructure to reason against.
The difference is not in the models. The difference is that code lives in systems that were designed, over decades, to be programmatically queryable. Spatial data lives in systems that were designed to be human-navigable folders.
For agents to do useful work over physical-world data, the data has to live in systems that are programmatically queryable. That’s what a system of record for physical environments is.
Why physical-world data is the next frontier
The world isn’t in a database. Most of it isn’t even in a digital format. The fraction that is digital — drone surveys, point clouds, GIS layers, building scans, inspection records, environmental monitoring data — is overwhelmingly unstructured: files in folders, with no consistent schema across organisations and frequently no consistent schema within organisations.
This is starting to change for the simplest of reasons: the value of the structured form is finally exceeding the cost of structuring it. As long as the only consumer of spatial data was a human looking at it once, folders were fine. As soon as the consumer is an AI agent that needs to reason across thousands of captures, time-windows, and locations, folders are the bottleneck.
The next decade of AI infrastructure investment, in my view, will be substantially about putting the physical world into a form that AI can reason over. Not because the models need help — they don’t — but because the data layer beneath them needs to catch up. And the data layer beneath physical-world reasoning has barely started to be built.
For background on the underlying organisational primitive, see what is a site record.
What a spatial record looks like from an AI perspective
For an AI agent to do useful work over a body of spatial data, the data needs four properties: it has to be addressable, structured, time-aware, and access-controlled.
Addressable
Every file, every site, every capture session needs a stable identifier the agent can refer to. Not a filename. Not a folder path that might change next week. A persistent identifier the agent can store, look up, share with other agents, and refer to in future conversations.
This is the most basic infrastructure requirement, and it is the one most existing storage doesn’t provide. A file in a Dropbox folder doesn’t have a stable identifier in any useful sense. A file in a database-backed platform does.
Structured
The agent needs to know, without parsing the file content, that this file is a point cloud captured on this date at this location for this purpose. Filename conventions don’t provide this reliably. A schema with explicit fields — file type, capture date, site, contributor, format — does.
The schema doesn’t have to be complex. The minimum viable schema is the fields that make a site record work: site, capture session (timestamp), contributor, file type, viewer assignment.
Time-aware
Spatial data is fundamentally about how places change over time. An agent reasoning about a physical environment needs to be able to query what did this site look like in March 2024, what changed between this capture and this one, what is the most recent capture for this property. This requires the time dimension to be a first-class part of the schema, not derived from filenames.
A time-indexed site record provides this natively. Every capture session is timestamped to the date of capture, and the agent can query the chronology directly.
Access-controlled
Finally, the agent needs to operate within a permission model that matches the human permission model. If a human user has access to a particular site, the agent acting on their behalf should have access to that site. If they don’t, the agent shouldn’t.
Row-level security in the underlying database — where access checks happen at query time, against the same identity model the human user authenticates with — provides this naturally. An agent gets exactly the same view of the data that the human gets, no more.
The MCP layer
The protocol that’s emerging for connecting AI agents to external systems is the Model Context Protocol — MCP. MCP gives AI agents a standardised way to discover and call tools, read resources, and operate against external state.
A Swyvl MCP server is on the roadmap; the section below sketches the surface we’re building toward, not a shipping product.
For spatial data infrastructure, MCP is the right abstraction for exposing a site record system to an agent. The surface looks roughly like this:
- A list-sites tool to enumerate the sites the user has access to
- A get-site resource to read the details of a particular site, including its capture sessions
- A list-files tool to find files matching certain criteria across sites
- A read-file-metadata resource to inspect a specific file
- Possibly a get-thumbnail or get-preview resource for visual context
With these primitives, an agent can answer questions like “what was captured at this property in the last six months” or “find all the point clouds from any site in this region with captures in the past year” without needing access to the underlying file storage at all.
The architecture pattern is agent → MCP server → spatial data platform → row-level-security-filtered query. The agent doesn’t need raw storage access. It needs a structured query interface against an organised record. The platform’s job is to be that organised record and to expose the right MCP surface to make it queryable.
What the agent-facing future looks like
Concretely, here are some of the use cases that become possible when spatial data is in this form.
For asset owners. “Pull together everything captured at the Newcastle bridge in the last two years, summarise the inspection findings, and flag any defects that have appeared in more than one inspection.” The agent queries the bridge’s site, identifies the captures, reads the inspection reports, cross-references findings, and produces the summary.
For surveyors. “Build me a status report of all active client projects, including the most recent capture session, what was delivered, and whether the client has accessed it.” The agent queries each project site, checks the share-link audit logs, and assembles the report.
For heritage agencies. “Identify any properties in the portfolio that haven’t been inspected in 18 months and produce an inspection schedule.” The agent queries the portfolio, sorts by last inspection date, and generates the schedule.
For environmental monitoring. “Compare the orthomosaics from the last four quarterly captures of the coastal monitoring sites and flag any sites with unusual change rates.” The agent queries the sites, retrieves the orthos, runs a comparison, and surfaces the outliers.
For field service. “Before dispatching a technician to this address, summarise the site’s history — what’s been done, what to watch for, and any open notes from previous visits.” The agent queries the address’s site record and produces the briefing.
None of these capabilities are limited by the models. The bottleneck is the data layer and the protocols that expose it — and that’s the layer we’re building.
The economic implication
The organisations that put their spatial data into a structured site record now are buying themselves a position when this layer of agent-driven workflow becomes mainstream. The organisations that don’t will be retrofitting against legacy folder structures at exactly the moment their competitors are operating with structured records.
This is a familiar pattern in technology adoption. The cost of being early is small (set up the platform, change a workflow). The cost of being late is large (years of accumulated data that needs to be ingested and structured before agents can reason over it). The decision window for being early is now to mid-2027.
For more on the broader argument about secure, structured spatial data storage, see secure cloud storage for spatial data.
Where Swyvl fits in this picture
Swyvl is being built as the system of record for physical environments. The current product solves the immediate problem — spatial data delivery, branded share links, organised site records, browser-based viewers — and that’s where the first three years of work are concentrated.
The longer-term shape of the product is exactly the AI-queryable layer described above. The data model is already structured: every file is keyed to a site, time-indexed to a capture session, classified by format, audit-logged on every access, and access-controlled at the database level via row-level security. The MCP server that exposes this surface to AI agents is on the roadmap.
The bet is that the structured spatial record built today is the right substrate for agent-driven queries tomorrow. Organisations that adopt the structured record now are not just getting better delivery, better organisation, and better audit — they are getting infrastructure that an entire generation of AI tooling is going to expect to be there.
If you’re building AI infrastructure that needs to reason about physical environments, or if you’re an organisation thinking about how your spatial data needs to be organised for the next decade, get in touch. We’re early, the gap is large, and the work that gets done now is the work that compounds for the longest.
For early access discussions, the contact form is the right starting point. For a sense of what’s already built, the free tier is the easiest way to see the system in action.