Why LLMs can't reason about location – and what you can do about it

LLMs suck at location reasoning

LLMs are remarkable at language. They can summarise a contract, write a function, even explain quantum mechanics to a five-year-old.

But ask an LLM a question about locations, routes, distances, or real-world spatial relationships and the answer is often confidently wrong. It's not a model problem; it's a data problem.

And it's becoming the single biggest blocker for AI products and their users that need to understand location and operate in the real world.

What location reasoning actually means

When a person asks an LLM-powered product to find them something – a new home, a hotel, a job, a clinic – location plays a key part.

They describe the location in terms of the journeys around it and the real places that contextualise it – all in natural language: twenty minutes on the tube, a walk from the station, 30-minute catchment area, accessible from both A and B.

That's how people experience place. By time, by transport links, by the journey ahead.

And to answer those queries well, AI needs to reason about how locations match and connect, not just where they are – it requires computation over maps, infrastructure networks and to understand when signals change over time.

That's location reasoning. And most AI products today can't do it.

We built an LLM comparison tool to demonstrate the impact of integrating TravelTime with an LLM. The standard LLM returns a response to the user's query as normal – but there is guesswork, approximations, and an admission of no real-time data.

On the other hand, the LLM with a TravelTime integration sends the user's query alongside a list of TravelTime Endpoints and their schemas. The LLM uses tool calling to specify the API requests which the backend then executes. It interprets the returned results to give an accurate, data-backed answer to the user's query.

Contact us if you want to see the tool in action.

Why models alone can't fix this

LLMs are pattern-matchers over text. They've read travel times mentioned in millions of articles, even pulling from forums like Reddit.

But reading "twenty-minute metro ride" doesn't tell a model that this specific origin is twenty minutes from that specific destination at a specific time of day. The model is interpolating from text and not reasoning in the real world.

To overcome this, engineers integrate location APIs and databases.

However, most location databases were built to plot points on a map. They model coordinates and straight-line distances, not journeys.

So, when an LLM tries to answer a journey question, it's reasoning over data that doesn't represent the thing it's being asked about. It amplifies the bad data – and sometimes just makes it up.

The result is a confident sounding yet unreliable output that delivers poor matches, leading to poor decision-making, and eroding trust the moment someone checks the answer.

What this looks like in practice

Flawed analysis in location intelligence

Location analysis used to mean structured queries, map visualisations, and human interpretation.

AI agents have changed this process: lots of the work now happens in the backend of location intelligence tools, with the answer delivered confidently to the user within seconds.

Whether that answer is right depends on the data underneath it. Point an agent at a location database built on inaccurate or out-of-date information and it still produces a confident, well-structured response – but it won't reflect reality. The agent doesn't necessarily flag the gap, but it will fill it.

The output is a site-selection call, a catchment model, a network plan that gets acted upon. The map renders, scoring adds up, but the spatial reasoning was never sound – and the cost only surfaces once the decision has been made. A sharper model over weak location data doesn't compensate for it. It only amplifies it.

Marketplace AI search that delivers poor results

Location-based search in marketplaces has only even been as good as the data beneath it. Filters and structured search masked the weak spots: location was handled in coordinates and miles, so a mile-radius query over mile-based data looked fine, even when the underlying matches were crude.

The rise of AI search and agents in digital marketplaces – property, jobs, service booking, automotive, healthcare, and more - has changed how people look for results and expect recommendations. Users no longer just click through filters that map to the platform's underlying datasets; they describe what they want in their own words and expect the product to understand.

A model can understand "Homes within 45 minutes of Liverpool Street," for example, but understanding the language isn't the same as meeting the request intent. If the request can't be mapped to relevant, accurate data, the output is low-quality matches, or worse, an apologetic dead end: "commute time not recognised," or "we don't support time-based queries."

Each of these is a failure dressed up as a shiny new AI feature. And as users come to expect products to understand what they really mean, these stop being edge cases and become real product problems.

The missing location data layer

The fix isn't a smarter model. It's giving the model better data to reason over.

This must be data that represents how millions of different locations actually connect across the globe, not just where they are or the distances between them:

• Real travel times across road, rail, and transit networks
• Time-of-day awareness
• Multi-modal routing that accounts for how people actually travel
• Wait times and schedule changes

It's the foundation that turns "twenty minutes on the tube at 8am on a Tuesday" from a phrase the model has seen before into a structured request it can execute against real-world, accurate datasets.

Without integrating new data layers that sit alongside the model, smarter location reasoning is an impossible task.

Beyond the data layer: performance and pricing

Accurate data is the foundation of good AI-powered products. But at the scale AI operates, the right data isn't enough on its own.

AI agents don't query like people: they loop, run in parallel, and chain requests in ways human users never did. As reliance on agents grows, both the complexity and the volume of those queries climb.

That shift puts pressure on two additional things:

• Infrastructure must handle the call patterns AI generates: your underlying infrastructure, like your location data layer, has to keep pace with AI call patterns and user demand without failing under the load.
• Vendor pricing model must allow for growth: you can't build a product on a vendor (and set of integrations) that punishes you every time your agent thinks. AI workloads are unpredictable - the costs you face can't be.

What it means for builders

If you're building anything where location matters – search, agents, decision-making tools, recommendation engines – the question worth asking isn't just "is my model good enough?"

The teams that get this right will ship AI products and features that are intuitive and match true user intent. And the teams that don't will deliver location experiences that look impressive in demos and press releases yet fall apart in reality.

It's a question of infrastructure, not intelligence. It's the piece most AI products are missing today.

It's also where TravelTime delivers value.

How TravelTime supports your AI build

TravelTime gives AI the location data layer it's missing: accurate travel times across road, rail, and transit networks, time-of-day awareness, multi-modal routing built on real-world data, POI data that reflects reality. It's delivered through a set of high-performance endpoints your LLM can call directly.

Instead of guessing, the model picks the right tool for the job: isochrones for everything reachable within a time limit, matrices for travel times across thousands of origins and destinations at once, H3 for aggregating and analysing areas, routing for door-to-door journeys, and POI search for the real places that give a location context.

Beyond the data accuracy, TravelTime is engineered for how AI actually consumes APIs.

TravelTime API has predictable fixed pricing for unpredictable workloads and scaling products, caching rights so repeat queries don't break your budget, and infrastructure that keeps pace with the call patterns that AI features generate.

It's the location API your LLM needs to stop guessing about places and start delivering real results.

Build AI features that understand location

Whether you're shipping AI search, designing an LLM agent, or rethinking how your platform serves users in an AI-first world, the location layer underneath matters more than ever.

Chat to us about your project or get a free API key to start testing.