Personal AI assistant

Being an orderly person, I have kept track of almost everything in spreadsheets. Tabular data is practical in many situations, but getting answers to everyday questions can be needlessly complicated. For example, if my wife asks where has all the money gone or is our water and electricity consumption going up or down, being able to get the answer and ask follow-up questions directly in natural language would be easy and interesting.

I wanted to find out through an experiment how well a language model suits analysing this kind of data through technical interfaces, and whether the same approach could be applied in client work.

I know AI applications let you share files, but that would not serve the goals of the demo. Moving the data into a database permanently also makes it easier to collect data automatically in the future.

Architecture

The technical foundation is a PostgreSQL database and a command-line client written in JavaScript. The language model is Claude, but the architecture is designed to be independent of the service provider.

Data is shared with the language model by giving it a description of the database structure (the schema) and instructions for interpreting it at the start of each session. The model writes the SQL it needs, and the client runs it against the database. At this layer only read queries are allowed, and all other commands (e.g. ALTER, DELETE) are blocked. In a client environment I would also restrict the database user’s privileges.

Writing the code

True to my own style, I named the program hi-assistant. I had Claude build the client from a small spec. Development went relatively smoothly, though some manual work and guidance were needed.

For the most part, the data migration went from spreadsheets through CSV files into the database. I won’t cover setting up the database here.

Challenges along the way

Column names are not enough for the model. A column name that is clear enough to a human can be too vague for a language model. When descriptive comments were added to the database columns, the model’s ability to understand what the data means improved clearly. For example, in the vinyl record collection (yes, really) the field reference_code is not fully self-descriptive. When the description is EAN/UPC or record company identifier, the model does not have to guess.

In the end, that was not a natural place to explain all the detailed instructions. Each area of data ended up with its own manifest file, which continues where the column description falls short. That would also be needed if the database product did not support comments. The manifest files are given to the model together with the schema at the start of the session.

The application has a poor memory by default. The previous questions and answers are not known to the model. This is due to the stateless design of the technical interfaces, which means the client has to send the history every time. The desktop and phone interfaces we are used to handle this by summarising the entire conversation so far with every question. I ended up building a memory that works for the duration of the session but does not persist. The conversations are short enough that all of the data can be sent to the model repeatedly.

Example conversations

Click the topics that interest you open.

Question> Do last winter’s frosts show up in energy consumption?

**Yes, and very clearly!** Last winter (2025/2026) was clearly the most energy-intensive in the recorded history:

**Winter season comparison (December–January–February):**

**Total consumption (average):**
- Winter 2022/2023: 1,335 kWh/month
- Winter 2023/2024: 1,611 kWh/month (+21%)
- Winter 2024/2025: 1,416 kWh/month (-12%)
- **Winter 2025/2026: 1,730 kWh/month (+22% on the previous winter, +30% compared to 2022/23)**

**Conclusion:** Last winter’s frosts show up very clearly in consumption. January 2026 broke all previous records, and the whole 2025/2026 winter season was on average 22% higher than the previous winter and as much as 30% higher than winter 2022/2023.

Question> At which general store is the bill usually the biggest?

Among general stores, **Bauhaus** clearly stands out from the rest in both average purchase and largest single purchase:

**Average bill:**
1. **Bauhaus: €122.49** (41 visits)
2. K-Rauta: €44.66 (111 visits)
3. Puuilo: €30.10 (187 visits)

Bauhaus appears to be the place for big renovation and construction projects, whereas for example Puuilo is visited more often but with smaller purchases.

Question> Which has held its value better - Artek or Ikea?

**Artek has held its value clearly better than Ikea!**

[...a list of individual products here...]

## Conclusion:

**Artek clearly wins** - all Artek products have risen in value, on average 19% into the plus. Ikea’s average is dragged down by one poorly performing item, even though the Gulliver changing table was an excellent investment. Artek is the more consistent and reliable store of value, whereas with Ikea the variation is large depending on the product.

Question> What kind of music taste do I have? Keep it short.

**You have the taste of a classic rock collector, with a strong Finnish emphasis!**

Your collection (179 records, almost all LPs) highlights:

🎸 **Classic rock from the 80s and 90s**: U2 (7 records), Rush (5), Dire Straits (4), AC/DC (4), Pink Floyd (4), Led Zeppelin (3), Queen (3)

🎤 **Grunge & alternative**: Alice In Chains (4), Pearl Jam, Faith No More, The Smashing Pumpkins (3), Soundgarden

🇫🇮 **Finnish rock**: Irwin Goodman (4), Eppu Normaali (3), Leevi And The Leavings (3), Dingo, Yö, Kolmas Nainen, 22-Pistepirkko

🎭 **Progressive and metal**: Opeth (3), Katatonia, Metallica

🎬 **Movie soundtracks** (5)

🎹 **Electronic music**: Synth-pop, house, breakbeat, trance

**Style**: Wide-ranging but rooted in the rock classics of the 80s and 90s. Appreciates both international and domestic, both mainstream and more progressive. A collector’s approach - vinyl is the format of choice. Nostalgia meets quality!

What I learned

AI answers that are based on data in a database have proved reliable enough in this use. The AI’s tendency to make things up generally does not apply when it has factual data to work with. The vinyl collection example contains one error: Soundgarden was hallucinated onto the end of the list, even though it has never been in the collection. Incorrectly formed database queries are also a real risk.

With larger amounts of data or longer conversations, the conversation history would have to be summarised somehow.

Where this fits

The same structure works anywhere an organisation has data in a database and people want to ask questions about it without a report builder or SQL skills. In client work, data quality, access rights and privacy questions would come up. In this solution, personal data does flow towards the language model.

What’s next

I have many ideas, and perhaps the most interesting is building a vector database from suitable data. That would give me a feel for how useful unstructured, free-form text could be.