In the final section of my previous post, LLandre in Wonderland, published on April 5, 2026, I briefly anticipated that something was taking shape: an open-source conversational agent project named Retriva.
At that time, it was still more of a declaration of intent than a finished artifact. A reasonably structured idea, yes. A promising direction, certainly. But still an object suspended somewhere between architectural diagrams, scattered notes, experiments, and that dangerous form of optimism that affects engineers when they open a new repository and believe, against all historical evidence, that this time the project will remain clean forever.
Well, some time has passed.
And I can now say that Milestone #0 has been achieved.
This does not mean that Retriva is complete. It does not mean that it is production-ready in the strictest, most boring, most enterprise-approved meaning of the expression. It does not mean that all the rough edges have disappeared, or that the path ahead is short.
It means something more modest, but also more important.
It means that Retriva exists.
Not as a slide.
Not as a concept.
Not as a late-evening thought written in a notebook.
Not as one of those “I should really build this someday” ideas that quietly die under the weight of everyday responsibilities.
It exists as a fully functional application.
And for a side project developed in the narrow corridors left available by work, family, fatigue, curiosity, and the occasional moment of doubt, this is already a rather respectable miracle.
What Retriva is
Retriva is an open-source conversational agent designed around a very concrete need: enabling natural-language interaction with a private knowledge base.
The original motivation behind the project was twofold: first, to challenge myself with a non-trivial AI engineering project that would force me to put into practice what I had studied over the past few years; second, to build a way to query, in natural language, the knowledge base created from a long-standing document archive, originally implemented as a MediaWiki-based website.
This second point is important. Retriva was not born from a desire to create yet another chatbot demo. The world is not exactly starving for chatbot demos. If anything, we are probably living through a historic oversupply of them.
Retriva was born from a practical problem: organizations accumulate knowledge for years, sometimes decades, and then slowly discover that retrieving that knowledge is much harder than producing it. Documents exist. Pages exist. Archives exist. Wikis exist. But the ability to ask a direct question and receive a grounded, contextual answer remains surprisingly difficult.
This is where Retrieval-Augmented Generation enters the scene — not as a fashionable acronym to decorate a README file, but as a natural architectural answer to a real operational need.
From the beginning, another requirement was non-negotiable: confidentiality. The system was conceived with the explicit constraint that external services should be avoided, so that the information contained in the knowledge base would not leave the company perimeter.
That requirement shaped the entire spirit of the project. Retriva is not just “a chatbot.” It is an attempt to build a controlled, inspectable, extensible conversational system for private knowledge.
Milestone #0: from idea to working system
The main result of this first milestone is simple to state and much less simple to achieve:
I implemented a fully functional application consisting of four separate modules.
Those modules form the first complete skeleton of Retriva. They are not isolated experiments stitched together only for the purpose of a demo. They are intended to be parts of a real system, each one responsible for a specific area of functionality, each one contributing to the overall goal: making private knowledge accessible through conversation.
At this stage, the achievement is not that every component is perfect. It is that the full chain exists.
There is now an application structure.
There is separation of responsibilities.
There is a working architectural foundation.
There is enough substance to stop saying “I am planning to build” and start saying “I have built the first version.”
This difference may sound small from the outside. It is not.
Any developer knows the distance between an idea and a running system. It is the distance between enthusiasm and implementation. Between architecture and dependency hell. Between “this should be straightforward” and three hours spent understanding why a container, a configuration file, and a Python package have silently formed a criminal organization.
Milestone #0 is the moment when the project stops being imaginary.
That is why I consider it a milestone in the strictest sense. It marks the point where Retriva became real enough to be criticized, improved, refactored, tested, documented, and — hopefully — used.
The four-module structure
The current version of Retriva is organized into four distinct modules:
- Retriva WebUI
- Retriva Gateway
- Retriva Core
- Retriva Eval
This may look like a simple list of components. It is not. It is the first real architectural statement of the project.
Each module exists because it has a reason to exist.
Retriva WebUI is the visible face of the system — the place where interaction happens. It is where the user meets the machine, where questions are asked, where answers begin to take shape. In many ways, it is the least “technical” part and yet the most exposed one: if the experience is poor here, nothing else matters.
Retriva Gateway acts as the mediator — the controlled entry point that orchestrates communication between the interface and the underlying intelligence. It is the layer where requests are routed, managed, and made coherent. If the WebUI is the voice, the Gateway is the nervous system deciding where signals should go.
Retriva Core is, predictably, the heart of the system. This is where the actual reasoning — or at least, our modern approximation of it — takes place. Retrieval. Context construction. Interaction with models. The Core is where the promise of “ask your knowledge base in natural language” stops being a slogan and becomes an implementation.
And finally, Retriva Eval.
This is the module that, in a way, makes the entire effort intellectually honest.
Because building a conversational system is relatively easy.
Believing that it works is even easier.
Proving that it works — or at least measuring how well it works — is where things become uncomfortable.
Retriva Eval exists to make that discomfort explicit. To introduce evaluation as a first-class concern, not as an afterthought. It is a reminder that any system producing answers must be subjected to scrutiny, comparison, and continuous verification.
Without evaluation, a conversational agent is just a very confident storyteller.
With evaluation, it has a chance — not a guarantee, but a chance — to become a reliable tool.
What I find personally satisfying about this four-part structure is not its elegance (which would be an overstatement at this stage), but its intention.
It reflects a decision: to treat Retriva as a system, not as a script.
A system with boundaries.
A system with responsibilities.
A system that can evolve without collapsing under its own weight.
Of course, I am fully aware that future versions of myself will look at this architecture with a mixture of disappointment and mild contempt — the same way we all look at our past designs.
This is expected. It is even healthy.
Because the opposite would mean that nothing has been learned.
For now, however, this structure is enough. It is stable enough to build upon, clear enough to reason about, and structured enough to avoid the most immediate forms of chaos.
And for Milestone #0, that is not a small thing.
The strange experience of coding with modern agents
There is another aspect of this milestone that I cannot ignore: the role played by modern coding agents.
I have been working in technology long enough to have developed a healthy skepticism toward revolutionary claims. In our industry, everything is revolutionary for approximately three quarters, after which it is either forgotten, renamed, or sold as a platform.
But I must admit something.
Using modern coding agents seriously — not for toy snippets, not for writing a function that reverses a string, not for generating yet another example of a REST endpoint — is astonishing.
There is no softer word that feels honest.
A good coding agent does not merely autocomplete text. It participates in the development process. It helps reason about structure. It identifies inconsistencies. It proposes tests. It remembers conventions. It accelerates refactoring. It can move from documentation to implementation and back again with a continuity that, until recently, would have sounded like science fiction disguised as vendor marketing.
Of course, it is not magic.
It makes mistakes.
It sometimes misunderstands.
It can be confidently wrong, which is a trait it shares with many humans in technical meetings.
It needs supervision, direction, correction, and a developer who still knows what he is doing.
But when used properly, it changes the rhythm of development.
Not because it eliminates the need for engineering judgment, but because it amplifies the amount of ground that one person can cover.
This is the part I find genuinely remarkable.
The experience is not “the agent writes code and I watch.” That would be both boring and professionally worrying. The experience is closer to having a tireless junior colleague with infinite patience, no resentment toward repetitive work, and the unfortunate habit of occasionally hallucinating an API.
Still, the productivity gain is real.
Very real.
The technical manager’s forbidden dream
And here I must confess something that will sound dangerously emotional for a technical manager.
This project has given me a deep sense of individual productivity.
I know. We are not supposed to say this too loudly.
Technical managers are expected to speak in terms of team enablement, organizational leverage, alignment, stakeholder value, cross-functional synergy, and other expressions that make the soul briefly leave the body.
But deep down, every technical manager who was once an engineer — and never fully recovered from it — still dreams of individual productivity.
The dream is simple and slightly childish:
To have an idea.
To sit down.
To build it.
To see it run.
To improve it.
To understand every part of it.
To feel, at least for a moment, that the distance between thought and working software has collapsed.
This is not the productivity of dashboards, quarterly planning, or carefully color-coded roadmaps.
This is the ancient productivity of making things.
And I had missed it.
Retriva has reminded me how satisfying it is to be directly responsible for a technical artifact. Not responsible in the managerial sense, where responsibility often means attending meetings about why something is blocked by something else. Responsible in the old sense: the code works or it does not. The design holds or it does not. The system answers or it fails.
There is a brutal clarity in that.
And, frankly, a certain relief.
Why this matters to me
Retriva matters to me because it sits at the intersection of several things I care about.
It is technical enough to be challenging.
It is practical enough to be useful.
It is open-source enough to be shareable.
It is personal enough to remain motivating.
It also gives me a concrete laboratory for exploring many questions that, as technical people, we can no longer afford to treat as abstract:
How should conversational agents interact with private knowledge?
How much control do we need over indexing and retrieval?
How do we evaluate answer quality?
How do we keep the system inspectable?
How do we design AI applications that are useful without becoming opaque machinery?
How do we use coding agents without surrendering engineering responsibility to them?
These are not academic questions anymore. They are becoming ordinary engineering questions.
Retriva is my way of answering them by building something.
This is also why I expect this post to be only the first in a series. There is too much to cover in one article: architecture, ingestion, retrieval, evaluation, local deployment, privacy constraints, agent-assisted development, mistakes made along the way, decisions I already regret, and decisions I will probably regret later with even greater maturity.
In other words: enough material for several posts, and possibly enough for a small therapeutic journey.
What comes next
Milestone #0 was about making Retriva real.
The next milestones will be about making it better.
More robust.
More observable.
More testable.
More modular.
More pleasant to use.
More honest in its answers.
More explicit about its limitations.
I also want to document the process as transparently as possible. Not because I believe Retriva is a universal solution, but because I believe that building real AI applications — especially those dealing with private knowledge and enterprise constraints — is an exercise worth documenting carefully.
There is already too much discourse around AI that oscillates between miracle and apocalypse.
I am more interested in the engineering middle ground.
The place where things are useful but imperfect.
Powerful but constrained.
Impressive but still requiring judgment.
Automated but not autonomous in the irresponsible sense of the word.
That is where Retriva lives for now.
And that is where this series will begin.
Closing note
So, Milestone #0 is achieved.
A first version exists.
The application works.
The four-module structure is in place.
The project has moved from intention to implementation.
This may not sound dramatic.
But for anyone who has ever tried to build something non-trivial outside the comfortable boundaries of a formal project plan, it is dramatic enough.
Retriva has taken its first real step.
And I have rediscovered, with some astonishment and a little irony, that the old joy of building systems is still there — only now accompanied by agents that sometimes feel like witchcraft, sometimes like interns, and sometimes like the future arriving a bit earlier than expected.
Not bad for Milestone #0.
Not bad at all.
