Personal research and development
Year
Ongoing
Brief
An AI assistant that runs entirely locally, remembers over time and can be put to the test
Fields
AI agents, knowledge graphs, voice interfaces, model evaluation
What does it take for an assistant based on language models to be genuinely useful day after day, without sending anything outside the computer it runs on? This research project exists to answer with a working system, not a slide deck.
It is the lab where I try out the solutions I then bring to projects for companies and firms.
A memory you can read and correct
Most assistants forget everything at the end of a conversation, or remember in a way nobody can inspect. Here memory is a knowledge graph: people, facts and relationships written out explicitly, with rules that check their consistency.
A new piece of information does not immediately join the things taken as certain. It goes through a quarantine area, and becomes stable memory only after verification. It is the same principle as the ontologies I wrote my thesis on in 2013: back then it was theory, today it is what stops a model from confidently remembering something wrong.
Voice: listening, answering, letting itself be interrupted
The assistant wakes on a keyword, transcribes speech, reasons and answers out loud. Put like that it is a simple chain. In practice every link adds delay, and a conversation with two seconds of silence between one line and the next is not a conversation.
Much of the work went into designing the details that make the exchange feel natural: being able to interrupt, asking it to repeat, getting a nod of acknowledgement while the system is still working, not having symbols and punctuation read out loud.
Local models: working with limits
Everything runs on my own hardware, with no external services. That means reckoning with graphics card memory, choosing which model to load for which task, and providing a reduced mode for when resources are needed elsewhere.
It also means accepting that a small model goes wrong differently from a large one. It can say “done” without having done anything. The most useful lesson of the project is that these errors are not fixed by politely asking the model to be careful: the checks have to be written in code, outside the model.
Testing: knowing whether a model is better or just different
Every time a new model comes out the question is the same: is it worth switching? To answer it I built a kit of repeatable tests, based on real tasks, which compares models and flags regressions separately — things that used to work and no longer do.
It is the least showy piece and perhaps the most valuable: without measurements, choosing a model is a matter of taste.
How it is built
The architecture and the decisions are mine; the code comes from working together with AI coding assistants, with different agents that write, review and verify. It is a way of developing that I use openly, and it requires being able to explain the reason behind every choice: why a graph and not a plain archive of texts, why the quarantine, why certain guards live in the code.
Want something similar on your company’s data? Let’s talk.