Your AI Agents also need spatial semantics

AI is changing how geospatial work gets done, forever. Not so long ago, a general-purpose model could barely write a correct spatial query. Today’s models can plan a multi-step analysis, write the SQL, run it against a data warehouse, and return a map, all from a plain-language question. At CARTO, we call this Agentic GIS, and it is already putting spatial analysis in the hands of people who never had access to it before.

But, in analytics, an AI Agent is only as good as its understanding of your data. Point a model at a table full of columns like amt_ttl_pre_dsc and it has to guess what they mean. Ask it for revenue by region and it might pick the wrong column, invent a calculation, or join two tables on a field that only looks like a key. This is the problem semantic models solve. A semantic model is a structured description of what your data means: which columns matter, how business metrics are defined, and how tables relate. It gives the agent the business context to turn a question into an accurate answer instead of a plausible one.

There is a catch for anyone working with spatial data. Today’s semantic model standards treat a geometry column like any other field. They have no concept of a spatial index, a geometry type, or a spatial relationship. For a geospatial platform, that gap matters. This post looks at why AI Agents need spatial semantics to reason about location, and introduces semantic model support in CARTO AI Agents, built on an open standard and extended with the spatial context that no other semantic layer provides.

The spatial dimension in your data also needs semantics

Give an AI Agent a table with an index column containing H3 spatial indices, and without more context, it sees a string. It does not know the column is a spatial index, what resolution it holds, or that it can be rolled up to a coarser resolution for a regional view. It might treat it as a plain identifier to filter or group on, or join two datasets on a look-alike column when the relationship that actually matters is spatial containment.

Spatial data carries properties that change how an agent should reason about it:

• Geometry type. The geometry type hints at what the data represents and how to work with it. A point is a discrete location, such as a store, a sensor, or a customer address, and lends itself to proximity, clustering, or hotspot analysis. A polygon is an area, suited to containment checks and area calculations. A line often represents a route or a network segment. The analysis that makes sense depends on the type.
• Spatial indexes. An H3 or Quadbin column is a spatial key, not a label. The agent needs to know the system, the resolution, and how to aggregate and render it.
• Spatial relationships. Stores sit within territories. Properties intersect flood zones. These relationships are geographic, expressed with functions like ST_CONTAINS or ST_INTERSECTS, not foreign keys.
• Geographic hierarchies. Data sits at a level (store, ZIP code, county, state) and the agent needs to know how to move between them when a user asks for a different level of detail.

None of this is captured by a standard semantic model. Without spatial context, an agent falls back on naming conventions and trial and error, and we end up writing prompt guardrails to stop it from doing the wrong thing. With spatial context, the agent knows to aggregate an H3 layer at the right resolution, to use a spatial join when there is no shared key, and to render a spatial index like H3 or Quadbin as its grid rather than as a column of strings. The difference is spatial analysis a business user can rely on.

Building on an open standard: supporting Apache Ossie

We did not want to invent yet another format. In 2025, Snowflake, Salesforce, dbt Labs, BlackRock, and a wide group of data and analytics vendors launched the Open Semantic Interchange (OSI), a vendor-neutral standard for describing semantic models so that any tool can read and write them without losing meaning. The goal is to end “semantic drift,” where the same metric is defined differently in every system. The initiative has now entered the Apache Software Foundation as Apache Ossie (Incubating), a sign of how much industry weight is behind it.

We think this is the right effort to back. A shared standard means that metric definitions your team maintains centrally in your data warehouse can travel into CARTO and stay consistent with the rest of your analytics stack.

CARTO is a Working Group Member of the initiative, focused on bringing geospatial into the specification. We are working with the community so that geometry types, spatial indexes, and spatial relationships become first-class semantic information across every platform and tool, not only ours. We have opened public discussions proposing how spatial data should be described (field-level spatial data and spatial dimensions), and our own implementation already uses Ossie’s extension mechanism to carry this context while the standard matures.

Semantic models are now part of CARTO AI Agents

You can now give a CARTO AI Agent a semantic model as part of its configuration in Builder. It sits alongside the use case, instructions, and tools as another layer of context the agent uses to understand your data. There are three ways to create one:

• Write or edit it in CARTO. A built-in editor lets you define datasets, fields, metrics, relationships, and spatial context directly, following the Apache Ossie structure.
• Import a YAML file. Bring in any Ossie-based semantic model as a YAML file and refine it in CARTO. Not on Ossie yet? That is fine too. Bring in any valid semantic model YAML file and CARTO will still import it, so you keep one definition of your metrics across your whole stack.
• Let the Agent Configuration Assistant build it. Describe your data in plain language and the Agent Configuration Assistant does the detailed work of writing the semantic model, spatial context included.

Here is what the spatial part looks like in practice. Below are two fields from an Ossie semantic model, each using CARTO’s extension to carry the spatial meaning. The first is a polygon geometry at the census block group level:

- name: geom
  expression:
    dialects:
      - dialect: ANSI_SQL
        expression: geom
  description: "Census block group polygon boundary (WGS84)"
  custom_extensions:
    - vendor_name: CARTO
      data: |
        {
          "spatial_data": {
            "type": "polygon",
            "srid": 4326,
            "geography": {
              "level": "census_block_group",
              "hierarchy": { "parent": "census_tract", "children": ["census_block"] }
            }
          }
        }

The second is an H3 spatial index column at resolution 8:

- name: h3_index
  expression:
    dialects:
      - dialect: SNOWFLAKE
        expression: h3_index
  description: "H3 cell index at resolution 8, the spatial join key"
  custom_extensions:
    - vendor_name: CARTO
      data: |
        {
          "spatial_data": {
            "type": "spatial_index",
            "spatial_index": {
              "system": "h3",
              "resolution": 8,
              "hierarchy": { "parent": 7, "children": [9] }
            }
          }
        }

With this context, the agent knows the first column is a polygon it can use for choropleth maps and spatial joins at the census block group level, and that the second is an H3 index at resolution 8 that rolls up to resolution 7 and renders as an H3 layer. Multiply that across every dataset in the model and the agent stops guessing about your spatial data and starts reasoning with it.

Cheaper, consistent, and correct

To see how much this matters, we ran agents on deliberately hard, enterprise-style data: cryptic column names, business terms that are not obvious from the schema, and joins you cannot see just by reading the tables. We asked the same business questions with the semantic model switched off, then on. Three differences stood out.

• Cheaper: The agent stops hunting through the schema and writes the right query sooner. In our evaluations that meant around 50% fewer database queries per answer, and up to 67% fewer on the hardest questions. Fewer queries means faster answers and lower warehouse cost.
• Consistent: Without a shared definition, the same question can return a different answer depending on how the agent decides to calculate it that time. Ask for the store facing “the most local competition” twice and you might get two different stores. A semantic model pins the definition down, so the same question returns the same answer, and results are reproducible.
• Correct on business terms: When a field’s meaning is not obvious, say a competitor-strength index or a build-status flag, the agent is left to guess, and sometimes it declines to answer at all. With that term defined in the semantic model, the agent answers correctly where it otherwise would have given up.

Get started today

Semantic models turn an AI Agent from something that can answer questions about your data into something that answers them the way your business defines them, spatial data included. It is a step toward agents that GIS teams and business users can both trust.

Semantic model support is available in CARTO AI Agents today. Start a free 14-day trial, or request a demo to see it working on your own data.