Why We Built Linubra
Most second-brain tools make you do all the work. We built one that thinks.
Part 1 of the series: Building Linubra
Every knowledge worker has lived the same five minutes. A conversation three weeks ago — lunch, a phone call, a hallway chat — and now you need one specific thing out of it. A name. A number. A commitment somebody made.
You open your notes. Nothing. You search your email. Close, but not quite. You scroll your calendar trying to reconstruct the day. Twenty minutes in, you either find a fragment or give up.
That’s the problem. Not “we don’t have enough apps.” Not “our search is too slow.” The problem is that the thing you actually want — what somebody said to you, three weeks ago, in context — lives in your head, and your head is the only place it ever lived.
Two Kinds of Tool. Both Broken.
Walk into this problem from one direction and you land on manual note-taking. Obsidian, Notion, Roam, the whole “second brain” school. Every insight typed by hand. Every connection linked by hand. Every tag, every backlink, every folder, maintained by hand. For the rare disciplined note-taker this works. For the rest of us the system stays empty — not from laziness, but from the sheer weight of the maintenance tax.
Walk into it from the opposite direction and you land on passive recording. Rewind, Limitless, the ambient capture tools. They log everything — screen, audio, transcripts — and promise you can search it later. And you can. You get keyword search over transcripts. You get timestamped recordings. What you don’t get is an answer.
Ask a passive recorder “What did Mark say about the Q3 budget?” and it returns a transcript snippet with those words in it. Ask it “How has Mark’s position on the Q3 budget shifted over the last month?” and the room goes quiet. It captured the data. It didn’t build the knowledge.
Is there really a difference between losing a memory and being unable to find it? On the day you need it, no.
What a Reasoning Memory Engine Actually Does
Linubra sits between the two. Capture is effortless — speak into your phone, paste a link, jot a note. No manual filing. No tags. No backlinks.
But unlike a passive recorder, it doesn’t stop at storage. When a memory lands, the engine runs five things against it:
- Extract. People mentioned, action items, decisions, sentiment, location, time. Structured JSON, not a summary.
- Resolve entities. “Dr. Schmidt”, “Patricia”, and “the neuroscientist from Berlin” all point to the same person. The graph knows this.
- Embed semantically. The memory lands in a vector space where conceptually similar memories cluster, even if the words don’t match.
- Detect contradictions. A new claim that conflicts with an older one gets flagged, not silently overwritten.
- Connect. People to events. Events to projects. Projects to commitments. Commitments to deadlines. A graph, not a pile.
All five run in the background while you go about your day. What comes out the other side isn’t a transcript archive. It’s a graph of your world that grows more useful every time you add to it.
The payoff is the questions it can answer. Not “find me the file that contains X”, which is what search does. Questions that need synthesis — brief me on Project Aurora before tomorrow’s meeting, when did Sarah mention her birthday, what did I commit to the engineering team this quarter. A 2025 paper in Nature Scientific Reports found that knowledge-graph-augmented retrieval improves factual accuracy by 13.6% over plain vector RAG (Nature, 2025). That number is the reason we build a graph instead of flat-searching embeddings.
And because the graph crosses domains, it can catch things siloed tools can’t. A pattern between work stress and running injury risk. A deadline that moved three times and nobody wrote down. The knee and the board meeting, later in this series, is the story of one of those.
The Bet on Long-Context
None of this was possible two years ago. The architecture only works because a model can now hold hundreds of memories in a single context window and reason across them without losing the thread.
Specifically, we bet on Gemini 3 Pro. Four capabilities made the call:
- Audio in directly, without a separate transcription step.
- Entity resolution across memories separated by weeks.
- Structured extraction from messy, half-formed speech.
- Consistency across a context full of real memories, not benchmark needles.
The bet comes with costs we’re not going to pretend aren’t real. It’s compute-intensive. Entity resolution across long time horizons still fails in ways we’re actively fixing. And the privacy question — your memories, in someone else’s cloud — is the one we take most seriously, which is why your data never trains the model and why we wrote a separate post on what data sovereignty actually means when the data is this personal.
What Comes Next
This is the first post in a series about how the system works under the hood. The ones already written:
- The hidden cost of your second brain — why the maintenance tax kills tools people would otherwise love.
- The knee, the board meeting, and a pattern — a cross-domain pattern the graph caught months early.
- Your life is not training data — what privacy architecture actually looks like when the payload is your life.
Still coming: the knowledge graph schema (PostgreSQL, pgvector, property graph vs triple store, and why we picked what we picked), and how entity resolution decides that “Mark” and “Marcus from accounting” are the same person without asking you.
If you’re building in this space, or you’re tired of losing important details to the gap between your meetings and your notes, I’d like to hear from you.
