Your Voice Is the Interface
Voice-first AI should reason, not just transcribe
Part 5 of the series: Building Linubra
You speak at roughly 150 words per minute. You type at about 50. That’s not a productivity tip. It’s a 3x multiplier hiding behind a microphone button (Ruan et al., 2017, Stanford HCI Lab).
Every voice app on the market treats this as a transcription problem. Speak. Get text. Organise it yourself. The friction didn’t disappear. It moved from your keyboard to your inbox.
Voice isn’t faster typing. It’s a different interface. It carries context, emotion, hesitation, and the messy shape of a thought in the moment it’s being thought. A voice app that takes this seriously should reason across everything you’ve said, not just print the last thing you said.
The question is what happens after the recording stops.
Speaking Is Cheaper Than Typing. Cognitively.
Speed is the shallow metric. The deeper win is what speaking does to your working memory.
Bourdin and Fayol showed in 1994 that the physical act of writing consumes the same limited pool of working memory you need for actual thinking (Bourdin & Fayol, 1994, International Journal of Psychology). Speaking doesn’t carry the same overhead. The Stanford HCI lab later measured the downstream effect on a keyboard: 3.0x faster than typing on mobile in English, 3.4x in Mandarin, with 20.4% fewer uncorrected errors (Ruan et al., 2017).
The numbers are in, but they’re not the point. The point is that the thoughts worth capturing almost never arrive at a keyboard. They arrive when your hands are busy. Driving. Walking. Standing in the kitchen after a difficult phone call. By the time you sit down to type, the thought has already decayed. You reconstruct a lower-resolution copy from memory. Every keystroke loses context you can’t get back.
Voice inverts the relationship between thinking and recording. You don’t finish thinking and then record. You think by recording. The recording is the thought.
Everybody Stops at the Transcript
Transcription was the hard engineering problem for two decades. It’s now effectively a commodity. Word error rates below 5% across dozens of languages. You can get it from an API call that costs fractions of a cent.
And nobody built what comes after.
Look at the tools. AudioPen gives you a polished text summary. Otter transcribes meetings and highlights action items. Voicenotes lets you search across transcripts. Reflect adds backlinks between voice entries. Every one of them ends at text. The transcript is the product.
A transcript isn’t the product. A transcript is the input to the real work — the filing, the linking, the cross-referencing, the pattern recognition that turns raw words into something you can actually use next week. Every voice app I’ve looked at treats that work as the user’s problem.
What Should Happen After You Speak
A voice recording should trigger a reasoning pipeline, not a transcription job. Not as theory — as an ordered list of steps the system runs, each one doing something the previous one couldn’t:
Transcription. Table stakes. High-accuracy speech-to-text, typically under two seconds for a 30-second recording. This is where every existing tool stops.
Entity extraction. Who was mentioned. What projects were referenced. Which dates matter. Where you were when you said it. Not keyword matching — contextual extraction that understands “my manager Sarah” and “the Berlin office” as structured entities attached to the rest of the graph.
Graph update. New entities get linked to existing ones. If Sarah was mentioned last Tuesday and again today, both references resolve to the same person. New relationships attach themselves: Sarah works at the Berlin office. Sarah reported on the Q3 budget. The graph grows without you filing anything.
Contradiction detection. Two weeks ago you said the deadline was March 15. Today you said April 1. That’s not an error to flag. It’s a change to record, with both versions kept and the temporal shift made visible.
Embedding. The memory goes into a vector space where concepts cluster by meaning, not by the exact words you used. Ask “what did I say about the restructuring?” and it returns relevant memories even from recordings that never used the word “restructuring”.
Response. When you ask a question, the answer draws on the whole graph — not just the last thing you said, and not by concatenating transcripts.
Six stages. The first one is a solved problem. The next five are the project.
The Graph Is Where the Compounding Starts
If I had to pick the one stage that matters most, it’s the graph update.
The graph is where a voice note stops being a discrete blob and starts being a node in something that gets more useful every time you add to it. Every new recording makes every previous recording more findable, more connected, more contextualised. The first memory is worth almost nothing. The hundredth memory is worth a lot. The thousandth memory is a resource you can’t get anywhere else because nobody else has access to it.
Entity resolution is what makes this work. You say “Sarah” on Monday in a project update. On Thursday you say “my manager Sarah” after a team meeting. The graph links them — same person, now with a new attribute. By the following week it knows Sarah is your manager, is involved in the Berlin office project, and last discussed the Q3 budget on a specific date.
You didn’t organise any of that. You didn’t create a contact entry. You didn’t tag anything. You talked, and the graph built itself out of the patterns in how you talk.
Relationships also change over time. “Worked with” becomes “reports to”. “Discussed” becomes “committed to”. The graph isn’t static — it evolves as your understanding of your own life evolves.
Voice In, Answers Out
Most voice apps are one-directional. You speak in. You get text out. You then revert to the same screen-based, text-first workflow you were trying to escape.
The interesting case is bidirectional. You’re walking to a meeting. You say: “What did I discuss with the Berlin team last Thursday?” The system searches your graph, retrieves the three relevant memories, and answers with the numbers and the deadline and the open question about the Q3 roadmap. You walk into the room briefed. You never opened an app. You never typed a search query. You never scrolled through transcripts.
That’s the difference between voice in, text out and voice in, structured knowledge out. One interface for capture and retrieval, where talking naturally is the only interaction.
Voice stops being a convenience feature and becomes the primary interface the moment the reasoning layer behind the microphone actually exists. The bottleneck was never the input device. It was the absence of a system that could think about what you said.
Voice Is the Most Personal Data You Produce
A voice recording captures more than words. It captures the pause before a difficult admission. The change in pitch when someone’s uncertain. The background noise that places you in a specific room at a specific hour in a specific emotional state. Text strips almost all of that on purpose.
That means a voice-first reasoning system has a harder privacy problem than any text app. Not a bit harder. Categorically harder. Feeding this kind of data into a shared training set would be a privacy incident of a different order than leaked text notes.
Sovereign storage, zero data retention at the model layer, and user-owned knowledge graphs are not features to list on a marketing page. They’re the minimum conditions under which building a voice reasoning system is defensible at all. The architecture has to be built around the sensitivity of the data from day one — you can’t retrofit privacy later, once the product works.
The longer argument for this is in Your Life Is Not Training Data, earlier in this series. The short version: if you wouldn’t read the transcript aloud to a stranger, you shouldn’t feed it to a model that might.
Where This Goes
The industry spent a decade making transcription accurate and cheap. Both problems are solved. The next decade is whatever the transcript was supposed to be the start of.
Linubra is built for that second decade. Ten seconds of speech in; entities, relationships, contradictions, a queryable graph out. No typing. No filing. Just the microphone and the thing it’s been doing the whole time, which is carrying the actual content of your thinking.
If you want the architecture behind this — PostgreSQL, pgvector, the graph schema, why we picked the model we picked — that’s what the rest of the building-linubra series is for.
