Location questions are often wonderfully simple to ask.
“Where should a family with kids live in Munich?”
“Which areas feel lively, but still comfortable?”
“Where do parks, cafés, schools, and everyday services come together?”
These questions sound casual, but answering them well requires more than a good sentence. It requires looking at a city through data, comparing many smaller areas, and turning the result into something a person can actually understand.
That is what we have been exploring at GeoForm.
Over the last few weeks, we built the first version of an AI location assistant: a focused assistant that combines natural language questions with structured location data and returns answers directly in the GeoForm experience.
This article starts with the demo video and then walks through what we built, how it works from a user perspective, what directions we are considering next, the technology behind it, and what we learned along the way.
Demo
GeoForm Location Assistant recommending areas for families with kids in Munich.
The Assistant Experience
The first version of the GeoForm AI location assistant works with a configured region. A user opens the assistant, writes a location question, and receives an answer supported by structured data and map results.
For example, when someone asks for family-friendly areas, the assistant can look at parks, playgrounds, schools, libraries, leisure places, cafés, and other relevant points of interest. It then compares smaller areas across the city, identifies stronger candidates, and explains the result in everyday language.
The final answer combines a readable explanation, a ranked set of matching areas, and a map view that makes the result concrete. This matters because location decisions are rarely made from text alone. Seeing the answer on a map immediately changes the conversation: users can notice clusters, gaps, nearby landmarks, and areas that simply make sense when viewed spatially.
This is the core product idea: location data becomes conversational while remaining grounded in carefully selected datasets. The same assistant pattern can support many different questions, from family relocation and tourism planning to retail site selection, property analysis, and underserved-area discovery.
What Comes Next
This is the first version, so we intentionally kept the scope focused. The current assistant works at region level and answers one question at a time. That already gives us a useful foundation for experimentation, demos, and feedback.
Several next steps are already visible:
- More datasets
Enriching the assistant with streets, addresses, public transport, environmental layers, commercial datasets, and domain-specific data. - Richer landmarks
Improving the human-readable descriptions and local context attached to recommended areas. - Follow-up conversations
Allowing users to continue the exploration with questions such as “Show only quieter areas”, “Compare the top two”, or “Focus on the western part of the city.” - Neighbourhood and address-level exploration
Moving from city-wide recommendations toward specific districts, neighbourhoods, and addresses. - Specialized assistants
Creating dedicated assistants for family relocation, retail site selection, tourism, property reports, investment analysis, or urban planning.
The next steps should be driven by feedback. This first version gives us a concrete way to demonstrate the interaction pattern, test it with real use cases, and discover where it creates the most value.
Technology
The AI location assistant was built as a native GeoForm capability, using the same platform, deployment, and delivery foundations that already support the product.
- GeoForm provides the data foundation and visual experience. It manages location datasets, serves them through the platform, and presents the final results on a map.
- GeoForm Portal provides the management layer. It makes it possible to configure assistants for selected regions, connect them with the right datasets, and manage how they are presented inside the GeoForm ecosystem.
- GeoForm Widgets provide the externalization layer. They allow an assistant to be exposed outside the management experience, embedded into customer-facing workflows, or presented as a focused standalone capability.
- OpenAI models provide reasoning and answer generation. GPT-5.4 mini is used for selection and planning activities, while GPT-5.5 generates the final answer presented to the user.
- LangChain, LangGraph, and LangSmith provide execution structure, orchestration, and observability. They help transform a collection of prompts into a transparent and manageable workflow.
- Codex and ChatGPT played a significant role during development. They accelerated implementation, while architecture, scope, and product direction remained human-driven.
- RabbitMQ and asynchronous workers provide reliable background execution. More demanding workloads run outside the synchronous request path, keeping the platform responsive.
- Kubernetes, ArgoCD, Hetzner, AWS S3, CloudFront, and Route 53 provide deployment and delivery foundations. The solution can scale independently and benefits from proven cloud-native infrastructure patterns.
Architecturally, the assistant is loosely coupled with GeoForm through APIs. GeoForm remains responsible for data management, visualization, configuration, and user experience. The assistant runs as an independent workload managed through asynchronous processing and can scale separately from the rest of the platform.
In short:
GeoForm provides the location platform. OpenAI provides reasoning. LangGraph provides orchestration. The cloud platform provides delivery muscle.
Lessons Learned
Building this first version was a useful reminder that AI-assisted development can move implementation forward quickly, but the quality of the result still depends on clear technical ownership.
A few things turned out to matter most:
- Architecture supervision remains critical.
Coding assistants can generate a lot of useful code, but they do not automatically protect system boundaries, simplify design, or avoid unnecessary abstraction. Those decisions still need strong human direction. - Structured validation is essential.
The assistant works better when plans, parameters, selected categories, and final outputs are treated as structured data, not just text. Schemas and validation made the workflow easier to control and improve. - Retries need to be designed deliberately.
Some intermediate results will be incomplete, invalid, or simply weaker than expected. Controlled retries made the system more reliable without turning the workflow into an open-ended loop. - Tuning happens across several layers.
Improving the assistant was not only about changing prompts. It required adjusting code, schemas, prompts, validation rules, and output structure together. - Model selection is part of the engineering work.
Different models behaved differently across planning, structured selection, reasoning, and final answer generation. Choosing the right model for each step mattered.
The strongest lesson is that useful AI systems are not created by prompts alone. They come from the surrounding engineering: architecture, structured validation, retry logic, model choice, and careful iteration.
Questions?
Any questions, comments, or suggestions? I would love to hear your feedback.
What would you be most interested to see next: adding more datasets, making answers easier to place on the map using streets and addresses, exploring results through interactive drill-down sessions, or focusing the assistant on selected parts of the city?
If you would like to partner on building something like this, explore a specific use case, or discuss how an AI location assistant could work with your own data and workflows, reach out at jacek@geoform.io.