- What it is
- An AI that takes a question about a big database of traffic signals, digs through it on its own, makes charts and maps, and writes up a report.
- Why I made it
- Making a report by hand means picking tables, writing SQL, exporting results and putting it all together yourself. I wanted to see if you could just ask a question in plain English instead.
- What I did
- I built it at my 2026 internship at GPI: a server that plans the report, researches with read-only queries, saves what it finds, and writes each section from those findings.
- How it turned out
- It worked, but the small models we could run locally weren't smart enough to do it reliably, so it stayed an experiment. It taught me how to tell when the problem is my code and when it's the model.
The details
How it worked
Simple questions got a short answer, and asking for a report started a longer process. I split that process into steps, because one AI call couldn't do everything at once. First it planned the report and the questions to answer. Then it researched: it looked up the tables it needed, ran read-only queries, and saved each result as a finding. Last, it wrote each section from those saved findings, so the report was based on real numbers instead of whatever the model remembered.
- QuestionAsked in plain English
- plan
- UnderstandA research plan and a report outline
- research
- Read-only SQLFinds the tables and runs safe queries
- Saved findingsEvery result is kept as evidence
- Charts and mapsDescribed by the AI, drawn by the server
- write
- ComposeOne section at a time, from the findings
- Report
Charts and maps
The AI could ask for charts and maps, but it never wrote plotting code. It just described what it wanted and the server drew it. Maps could show heat maps, points or clusters of signals.
Keeping it safe
The AI could write its own queries, but only ones that read data, with a row limit and a timeout, on a read-only database connection. So even a bad query couldn't change anything.
Why it stayed an experiment
Small models were fast but stopped researching too early or wrote shallow reports. Bigger ones did better but were way too slow on the computer I had. I added retries, better prompts and tests, but that can't make a model smarter than it is. It was still worth doing, because it taught me how to tell when the problem is my code and when it's the model.