Applied AI
Building CityScope: An Agentic Guide for Exploring a City
CityScope started as a city-mobility workspace. The useful product appeared when I narrowed the question: if I have just arrived somewhere, can an agent turn the time I have and the experience I want into a route I can actually take?
Reading note
A clearer write-up of the product thinking, system choices, and tradeoffs behind the build.
In this post
The agent should make the journey feel personal; deterministic routing should make it dependable.
The moment CityScope is built for

The product is for a familiar travel moment: I have two hours in London, I want a scenic ride, and I would like a good coffee on the way. The traveller should not need to understand H3 cells, mobility datasets, provider APIs, or agent traces before getting something useful. They choose a city, choose run or cycle, add a starting point and rough duration, and say what sounds good.
The result is intentionally concise: a real route on the map, an approximate distance and duration, a few named places worth seeing, one food or drink stop when requested, and links that make the plan practical away from the desktop.
An agent with useful boundaries
Google ADK provides the planning runtime and Gemini 3.5 Flash interprets the traveller's request. The model identifies the city, activity, approximate length or duration, start and destination clues, and preferences such as parks, landmarks, coffee, or food. It can choose among approved route characteristics, but it cannot invent coordinates, polylines, or provider payloads.
Traveller request
↓
Gemini 3.5 Flash + Google ADK
↓
Curated city route concept
↓
Google Maps Grounding + optional City Data MCP
↓
Validated waypoints
↓
Google Routes
↓
Route map + named stops + share actions- Run maps to Google walking geometry and is described to the traveller as a run.
- Cycle maps to Google bicycle geometry and keeps the appropriate routing limitation visible.
- Normal plans are capped at four place searches, five waypoints, and two route attempts.
- Provider failures become a short retry message rather than raw API or validation output.
Grounding matters more than fluency
A confident paragraph is not a route. CityScope uses a curated library of city route concepts as planning hints, then grounds useful landmarks and stops through Google Maps. Google Routes remains authoritative for the geometry, distance, and duration that appear in the product. Historical mobility data can support a decision through City Data MCP, but it is not allowed to block a valid template, Maps, and Routes journey.
Coffee and food were an important test of that grounding discipline. When the traveller asks for one, the system searches near a useful part of the route, selects at most one real result, includes a rating only when Maps returned one, and carries the place link into the result. The same place normalization and deduplication keeps the map to a small, understandable itinerary rather than a cloud of generic pins.
What changed during the hackathon
The earliest interface treated the mobility evidence as the product. It exposed rankings, activity panels, H3 areas, provider traces, and large result lists. That architecture was useful, but the experience asked a traveller to think like an analyst. The recovery work was mostly subtraction: remove the panels that did not help someone take a good route, make the map dominant, and translate every technical label into a traveller-facing action.
- Reframed the opening screen around explore, run, cycle, time, start, and desired experience.
- Moved activity analytics and technical traces out of the primary journey.
- Reduced route results to a short explanation, distance, time, named stops, and practical links.
- Added city- and mode-specific prompts plus a visible planning state while the agent works.
- Kept provenance available without making it the first thing a traveller has to read.
What I learned
Agentic product work is often less about giving a model more freedom and more about designing a useful boundary between interpretation and execution. Gemini is good at turning a loose request into intent. Curated knowledge gives that intent local shape. Maps and Routes provide real-world grounding. Deterministic validation keeps the chain bounded enough to trust and debug.
A multi-step agent becomes compelling when the user experiences one clear outcome, not every internal step.
CityScope is still a prototype. Requested length is approximate rather than mathematically optimised, running relies on walking geometry, route coverage varies by provider support, and the curated route library is a starting point rather than a live popularity feed. Those limits are acceptable for the current product because they are honest, visible, and leave a clear path for expansion.
Try the project
I created this article for the purpose of entering CityScope in the Google All Things Agentic Hackathon.