project · 2024-2025
Query Intelligence (QI), Natural-language interface for navigation
A production agentic navigation system that turns natural-language queries ('find me a quiet café between my next two meetings') into structured plans grounded in real-time location data. Full-stack, React/Next.js + Python FastAPI + Azure OpenAI, with a RAG pipeline for semantic POI search and autonomous multi-step execution planning.
A natural-language interface for TomTom’s navigation services. Designed and built end-to-end, deployed iteratively against real customer feedback.
See it work (scripted demo)
The user asks one sentence with three intents in it: a route, a stop, and a category constraint. The PLANNER (one LLM call) parses the intent into a typed plan with explicit subgoals. The EXECUTOR (no LLM, just business logic) walks the plan, calls service APIs, and stitches the result. The map updates as each tool call lands.
Demo basemap: open-source CartoDB / OpenStreetMap tiles, no API key required. Production TomTom systems run on TomTom's own vector maps; tiles are swapped here so the public portfolio stays key-free.
This planner-executor split is the design choice that makes QI feel reliable. The LLM never makes data-shaped decisions (“which restaurant?”, “what’s the route?”); those are deterministic API calls in the executor. The LLM only makes intent-shaped decisions (“user wants a routing query with a mid-stop POI constraint”). Two lanes, no overlap.
What it does
A user asks for something the way they’d phrase it to a friend, “a quiet café within 10 minutes’ walk from this address that’s open right now”, and QI:
- Parses intent with an LLM into a structured plan (constraints, candidate filters, ranking criteria).
- Executes the plan as a multi-step program over TomTom’s services, geocoding, POI search, opening-hours filter, walk-time isochrone, ranking by user preference.
- Returns a grounded answer with explicit references to the underlying data (which API call returned which place, why it ranked first).
That last step is what makes it production-ready vs. a hack. Every recommendation can be traced back to its sources, the LLM doesn’t get to invent locations.
Architecture
- Frontend: React / Next.js, Vercel-style streaming UI so users see partial reasoning as the agent works.
- Backend: Python FastAPI, async tool-calling orchestration.
- LLM layer: Azure OpenAI (GPT-4 family) with structured-output tool calls.
- RAG: vector index over POI taxonomy + business descriptors so semantic queries (“artisanal”, “kid-friendly”, “quiet”) map to the right POI categories without keyword brittleness.
- Execution planner: autonomous multi-step graph; each step is a typed tool call with explicit pre/postconditions so the agent can replan on partial failures.
My role
Designed and built end-to-end. From whiteboarding the planner DSL through shipping the production deployment, including the customer-facing iteration loop, demo, gather feedback, ship the next refinement, repeat.
Why this earns a spot in projects
QI taught me what “forward-deployed” engineering actually means. It’s not “build an MVP in 2 weeks”, it’s “ship something to a real customer in 2 weeks, sit with them while they use it, and ship the next version 5 days later based on what you watched them do.” That iteration cadence shaped how I now design every agentic system: minimum viable surface area, observable internals, fast deploys, ruthless prioritisation of the friction users actually hit (not the friction I imagined they’d hit).