This is a submission for the Built with Google Gemini: Writing Challenge
What I Built with Google Gemini
Our client is a digital health insurance company serving 26,000+ members across East Africa. Their Relationship Managers and HR partners had no way to query their own data without routing requests to engineers — meaning answers to routine questions like "How many wellness visits did Company X complete this quarter?" took hours or days. I lead my practicum team to build an AI-driven conversational analytics platform that lets non-technical staff ask questions in plain English and get instant responses — as tables, charts, and plain-English summaries — tested on development MongoDB data.
Architecture: Classify → Generate → Execute
The core insight was that sending a raw natural language query straight to an LLM and hoping for accurate MongoDB Query Language (MQL) output is unreliable in a healthcare context. So we split the work into two stages:
Intent Classification — Gemini classifies the query into one of 14 predefined intent types (e.g., aggregate_one, filter_lookup, geographic_breakdown)
MQL Generation — Gemini generates the aggregation pipeline with the right prompt template and schema context injected for that specific intent
Demo
What I Learned
The main takeaway from this project is the superpower that LLMs like Gemini now give us as builders. What would traditionally require weeks of work — designing a custom analytics dashboard, assembling a dedicated team to maintain it, and hardcoding queries for every use case — was reduced to just the time needed to integrate Gemini with the relevant database collections. The system is also dynamic: it adapts automatically to new data structures, and the active collections can be expanded or reduced with just a few clicks.
Another important lesson is to build guardrails and logic that guide the LLM on what it can do and what it has access to. In this project, that was achieved through a configuration page where administrators can select which collections and fields Gemini is permitted to query. The existing authentication and authorisation infrastructure was also leveraged to enforce which users can access specific query results. The value of audit trails became very clear throughout the process — logging LLM behaviour and query outputs made it significantly easier to track errors, identify failure patterns, and continuously improve the overall system.
Teamwork — both within our practicum team and with the client's technical team — was critical to the progress we made. We set up weekly meetings for feedback and testing with the system's intended end users, which made it straightforward to quickly refine our approach and align closely with the client's requirements.
Finally, AI tools like Gemini are genuinely powerful — but only when used with intention, structure, and the right guardrails in place.
Google Gemini Feedback
With the right level of context and guidance for Gemini, the accuracy of the generated queries increased significantly. We initially started with no context, and the generated queries were more of a gamble than a reliable output. After setting up an intent analyser and passing the table schemas to improve context, the results improved significantly.
Where we hit friction: Date handling was the biggest pain point. Gemini generated date filters that looked correct but failed silently — returning zero results because it used JavaScript Date string literals instead of MongoDB ISODate objects. We had to encode this as an explicit rule in every prompt and add a post-generation validation layer.
Multi-collection queries hit an accuracy ceiling too. Single-collection queries exceeded 85%, while multi-collection $lookup queries dropped noticeably as injecting context for multiple schemas increased prompt ambiguity. Semantic retrieval via a vector database is the planned fix.
Top comments (0)